Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ebanite]

After a long time, i got the idea to bring the original set of amos istruction to work directly inside windows, the first beta is almost ready, but i changed my mind, because there is somethings that i don't like in it....to be honest the questions is...Amiga got a strange kind of hardware, and to try emulate any kind of istructions i can't use the native chunchy format of graphics card, to emulate the copper with the rainbow effects i had to change solutions, now i rewritting the program to support a complete emulation of ghraphics hw, but that mines lower speed, of course faster then original, but slower then other language...
for this reason i make a new version that can run directly in native format of PC grahics, getting the most fast code, and one version devoted to compatibility...
What do you think about?

[skateblind]

I think someone on this site is already attempting that, infact, 2 people are. 

Samurai Crow and Sidewinder.

[Sidewinder]

Hello ebanite,

As skate said, Samurai Crow and I are working on a similar project called Mattathias BASIC.  The goal of this project is to implement an extensible compiler (initially in the AMOS syntax) that targets the LLVM.  This will allow portability and native execution on many different platforms.  Our current efforts are in the area of parsing an extensible language without the limits imposed by the AMOS extension system.  You can find the project on Source Forge.

We have also run into similar problems regarding emulation of the Amiga specific graphics functions on modern hardware.  Our idea was to create two different extensions to the core AMOS language, one for emulation of Amiga hardware and another for the use of only modern hardware.  Very similar to your idea.  Perhaps this is an area where we can collaborate?

Sidewinder

[SamuraiCrow]

Hello ebanite,

If you would be interested in doing copper emulation for the PC, I think that the best way to do it would be using a fragment shader on OpenGL.  (If you were going to use DirectX, you'd be just as well off using an extension for DarkBasicPro instead of reinventing the wheel.)  That shader would allow the simulation of a color palette on newer graphics cards that don't support 256 color resolutions as well as allowing you to simulate the copper rainbow effects.  I was considering putting some restrictions having only one copper list per color palette entry.  (Eg. color 0 could only have one rainbow instead of 4 as AmosPro supports.)

If you're interested in collaborating, join us at our Yahoo group at http://tech.groups.yahoo.com/group/mattathias/ or send us a private message on this board or an email would be just as good.

If interested, then thanks for the help!  If not, that's fine too.

Keep us in mind,

--Sam

[ebanite]

Hello to everyone
..I know that there are other people are making a porting of Amos Syntax in other plattaform, but i'm doing that in Delphi, with some critical code in pure assembly, i want in the future use a more multi plattafrom target, but not now, i have the idea to use the Pixel shader to emulate some kind of amiga hardware but that means to exclude some platform, for the moment my project still a interpreter language like originally amos did. and after add a just in time compiler (like fkash 10)...i hope to transport my projet in web side application,making an extension like flash or silverlight..but i don't care for the moment..it's to early to plan a expansion of my project...
I wont to collaborate or to share any information to get the best, and for to see as soon as possible a real implementaion of native amos on windos(linux mac os etc...)...
for more information, now i coded a emulation of copper and hardware blitter...plus something about screen and bitmap managment,but i'm looking for more optmization, because i wont to port the new amos inside Amiga Os, and in this case retro compatibility is a must...

A particular thank to Sam and Sidewinder , i'm so interested about your project, we can share information and get the extra mile, i'm not so confidente about Shader, my emulation is pure CPU intensive usage, but still the best solution for platfom that haven't a shader HW extension.

take care...

[ebanite]

Hello

It's my first beta about amos porting...it's not bug free, the editor don't work properly, and just the Help examples function ( not all of them)...is not possible to edit new file or save it..sometimes the program crash...
Please use only for demostration, use only the Help exapmples file (you can  find  them inside the 7z archive)..and don't excpet any kind of big speed..it's a prototype version..the new one is coming...be patience....


take care

[Sidewinder]

Hi ebanite.

Just so I am clear, you are coding this in Delphi?  How advanced is your interpreter?  Does it support all of the AMOS instruction set or are you focusing on the graphics implementation details right now?  Are you creating a link library for the emulation functions or are they inline with the code?

[Sidewinder]

Your beta appears to be quite advanced.  Excellent work!

[ebanite]

thank's guys....
I'm coding in Delphi, the interpreter (beta version) for the moment can get around 120 istruction of the original set, but it can manage all istruction, and give the same output of amos pro ( now only for the standard extension), now i'm focusing on graphics emulation, it's is a static library because i'm working on emulation side only, but the plan is to have more dinamic library to cover different side of graphics ( emulated, native PC, enanched), that means the future version will be to able to cover any kind of solution for the user, from simple emulation of amiga HW to new graphics standards like 3d, shader and whatever.....
Now the project is start again from the root, because Amos Pro got a lot of limitatio on the sintaz (no structured type, no const, no dynamic variables etc), my next step after a good emulation is to expand the grammar of amos basic, put inside new type of object, non only simple var, but record type, class, advanced object and of course it will be able to compile it self....(but it's is so far for the moment)...

[SamuraiCrow]

Hello ebanite,

Have you thought about endian dependency when developing structures and object-oriented programming?  The Amos Bank format is the closest that Amos has to a structure format for using with network transmission and file buffering.  Endian correction of the file formats is necessary if you want to be able to read files written with Amos in your interpreter.  (Windows uses a little-endian byte ordering while Amiga uses big-endian.)

Our extension for the PC, Mac and Linux will, in the first version, use SDL Engine which is the runtime library used by sdlBasic.  You can find it at http://www.sdlbasic.altervista.org but it's written in C.  It includes network-endian (aka big endian) correction for the bank format and the Peek/Poke command sequences are tied to the bank structures so that it allows files and network packets to be cross-platform compatible.

I'm not trying to offend you and I haven't run your interpreter as I'm on my Macintosh at the moment, but if you plan on making your interpreter cross-platform, you'll need to think about some of this other stuff to make it compatible.

[ebanite]

@samuraiCrow

For the moment is not matter speaking about portability of my project, my first goal is make a stable version for windows, now the interpreter translate any file that become from amos in lillte endian (only for the format that i know the structure), in automaitc way, when in the future i'll move to other plattaform i have to take care about byte rappresentaion. For unknow bank format (like custom data) the poke and peek istruction are self cognitive, they can understand if the bank is a standard amos bank or not, and choose the properly way how to read the internal data.
I developed a new amos format, that bring inside information about the native platform, in this way the interpreter will be able to convert the data structure in the corect way for the target platform , the new amos file format had a lot of new information inside, to become free from any kind of dependence, from old amos restrictions (like poor extension system), and from platform restrictions (endian format).
Another thing, i'm gonna to use less external library for my purpose, becouse sometimes the cross platfrom library had some problems in some kind of platform (sometimes they haven't the same final output, or some "call" are not implemented or not exist for a specific platform). my idea is to use when is possible native library from the target plattaform. It's done by a abstract low level library, that is coded for each platform, the rest of the code still the same for every OS.
May be when it will be time to migrate to another Os. i'm gonna to ask help to someone to porting the Low level library.

[Sidewinder]

@ebanite

The plans you have for updating the syntax of AMOS are similar to the plans we have for Mattathias.  And the plans you have for the graphics system is also similar to what we have.  The major differences are that we are using C++ and LLVM to create a compiler and you are using Delphi to create an interpreter.  So the real question is, can we effectively collaborate in light of these differences?  It would be a shame to split the AMOS community over which new language is "the" sequel to AMOS.  So at the core here is how I see it:


The things that you have that the Mattathias project could most use are:

1. A runtime library - which you already appear to have working quite well.  We would need it to be portable though--possibly written in C/C++ or otherwise compiled to LLVM bit code.

2. An expanded AMOS BASIC grammar that includes object oriented features.  This seems to be the reason you are doing your rewrite in the first place.


The things the Mattathias project has that you may be able to use are:

1. A portable framework.

2. A compiler with support for extensions and additional grammars.

3. Additional help working on emulating the Amiga specific bits of AMOS.

4. Additional help working out a new AMOS grammar.

5. Additional help working on making the runtime portable.


We seem to be on parallel headings.  Do we join up or continue separately?

[ebanite]

@sidewinder

Good question!!
The differences about ours projects are just in the programming language, and it may be is not a big problem, porting code from c/c++ to delphi and viceversa is not difficult, and of course i can do everythings alone, this project need a lot of time to become a real solid application, and becouse it, i can say yes i want joint up with your project.
But still some differences, the program style, anyone code in a self way, may be should be a big problem. Each of us start in different time and different way to porting amos to a new life. that for me sounds like a waste of time in the begining. Of course if i'm gonna join with your project. most of my work become obsolete and useless.
It's not properly simple, may be we can share information and cooperate to the same project, but i think i still to envelope my private project. I have to look about your framework, how your project is structured, and what style are you using inside code.

best regards

[ebanite]

...I forgotten to put some files inside the 7z archive, some examples don't run becouse need a bob bank....
unzip this archive in the same folder where you have unzipped the last one...


take care....

[SamuraiCrow]

I am glad we can work together.  I look forward to seeing some of this runtime library.  (Sidewinder and I was getting behind schedule as it was so having some added help is very welcome!)  I can help you port your library to MacOSX and Linux but it has been years since I've programmed in Pascal and I'll have to learn the Object Pascal syntax to read your Delphi code.