Welcome, Guest. Please login or register.

Author Topic: The old great AMOS  (Read 10985 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline dambalaTopic starter

  • Newbie
  • *
  • Join Date: Jul 2004
  • Posts: 12
    • Show all replies
The old great AMOS
« on: July 30, 2004, 09:00:37 AM »
Does anyone have technical infos about AMOS?

I mean, file formats and any other info that can help.

As I said in my presentation I'm writing a basic interpreter in Java that converts directly AMOS code in Java bytecode to make it run as fast as Java.

But I'm quite running out of specs...
 

Offline dambalaTopic starter

  • Newbie
  • *
  • Join Date: Jul 2004
  • Posts: 12
    • Show all replies
Re: The old great AMOS
« Reply #1 on: July 30, 2004, 11:04:42 AM »
------- XERON:
> Heh... "As fast as Java"? Isn't that an oxymoron?

Eheheh... you're right if you are speaking of Java on Amiga in this exact moment...

On other systems Java runs very fast, I can't see a great difference with C/C++.
Why Java?
It is really portable, not as C/C++. To make a C/C++ program run everywhere you have to insert many "tricks" to make it compile on several systems.
Anyway would be cool to write J2ME apps using an AMOSlike basic, no?

For sure on AmigaOS will be a real VM... I'm waiting it to return to Amiga!

------ szimbi:
> Could you be more specific?
> What fileformat?

AMOS source file format, AMAL file format and MAP file format...

> There is bank formats (.abk), and source format (.AMOS).

I'm already able to load SpriteBanks and Abk pictures (Pic.Pac)...

> Is the command set is made already?

Not all :-)
But...
For a list http://dambala.altervista.org/amos/status_2004_07_30.txt

It not yet a public project, I've started it only a month ago!

> It would be a nice thing that Amos source converting to java, but I'm think it is
> a huge job with a lot of problems.

Simply converting AMOS source to Java source should be very simple...
Now my program interprets the AMOS source on the fly, but to complete "julia.AMOS" it takes 30 seconds... :-(
I'm trying to convert my program:
Instead of interpreting on the fly, it will convert (compile) the AMOS source in Java bytecode and then let the VM exec the code for me...
Without creating a .class or a .java file, in this way you'll continue to use and modify your basic source file.

> You wouldn't need to worry about file formats, before the command set not working.

Right :-), but during the hard work it's always relaxing seeing some sprites flying around the screen.

Bye
 

Offline dambalaTopic starter

  • Newbie
  • *
  • Join Date: Jul 2004
  • Posts: 12
    • Show all replies
Re: The old great AMOS
« Reply #2 on: July 30, 2004, 12:06:48 PM »
I'm searching... :-)
I have yet some infos about AMOS source files but they are very cryptic   :-?

A little OT, these are two pics of my interpreter in action:

http://dambala.altervista.org/amos/basic.jpg
http://dambala.altervista.org/amos/basic2.jpg  
 

Offline dambalaTopic starter

  • Newbie
  • *
  • Join Date: Jul 2004
  • Posts: 12
    • Show all replies
Re: The old great AMOS
« Reply #3 on: November 26, 2004, 12:09:57 PM »
Hi everyone!

After a long busy period I'm back...

I'm happy that there is so much people still interested in AMOS :-)
I'm still working on the Java Interpreter and maybe soon I'll release the sources...

@bloodlin:
AMAL was great for multitasking, but maybe now is more simple to have many procedures as tasks than a strange "reduced" basic as AMAL.

I've not yet starting coding AMAL maybe is too early to speak about it ;)
 

Offline dambalaTopic starter

  • Newbie
  • *
  • Join Date: Jul 2004
  • Posts: 12
    • Show all replies
Re: The old great AMOS
« Reply #4 on: November 26, 2004, 04:34:55 PM »
Quote

bloodline:
AMAL showed me how brilliant multiprocessing was back in 1990! But you are right a new (multithreading style) system based on procedures would be better... but What I was asking was if and how you would support AMAL, as that would be vital for AMOS compatibility.


In this moment I don't think AMAL is a priority, but the interpreter is extensible, so AMAL could be 'inserted' in every moment in the AMOS compatibility module (containing all non generic basic commands).
Anyway I don't think AMAL is a great implementation issue, it's only a simplified basic, very simple to parse. :-)