Hello,

It has come to my attention that Mattathias Basic is at a crossroads in its development. We'd asked for questions on the Mattathias mailing list but that doesn't reach very many people.

For those of you who don't know about it, Mattathias Basic is an open-source sequel to Amos Basic that is being developed as a modern way to compile old Amos codes and a modern programming language. We're trying to make it cross-platform using SDL and OpenGL on the original version and bang the hardware for maximum performance on the AGA version to follow. (ECS users should use Amos Basic Professional instead.)

Features slated to be included: Object-oriented programming, extensions written in Mattathias (making this an extensible programming system).

@Samurai_Crow

This looks like a BIG project! I would love to purchase this program when finished errrum, once I buy an AOS4 machine naturally. Why a classic version?

I wish Michael Ness well!

http://www.flyingpaper.com/

_________________
If you're going through hell, keep going. -Winston Churchill

@debrun

The reason for a classic version is that Amos Basic never supported AGA and even its extensions never offered very good support for AGA features. There won't be an ECS or OCS version, though, so those people will have to make do with AmosPro.

@Samurai_Crow

Very cool project! Especially the SDL approach. It will bring back a lot
of AMOS apps in a more system non-banging way.
I would consider dropping AGA support though, and focus more on the multiplatform version, as I doubt many, if any AGA users would use it.

_________________
AOS4 Betatester, Peg2, G4@1ghz, Radeon 9250 256mb, 1gb RAM.

http://www.asciiarena.com
http://www.uprough.net

@spotUP

The SDL version comes first, definitely. But there are still some features bandwidth-wise that are more efficient on AGA than on SDL. You see, there may not be a 68k version of the SDL version unless there is a lot of demand for it. SDL runs like a dog on 68k.

@Samurai_Crow

The project is open source, right? No need to change the licence as I see it.

If your problem is garnering interest from the community, in the form of either funds, or development help, then I guess there are a few things you could do.

A mailing list is good, which you have.
The problem I see, on this, and numerous other projects, is development is slow to the point of seeming dead.
You have to be careful not to bite off more than you can chew.
You should lower your expectations for the first release.
The sooner you get some graphics up, even if everything else is not fully implemented, the more exciting the project will seem on the outside.
Regular updates on your website, so it seems there is active development.
Even a blog would be interesting.

A list of software, that **could** be ported to stir development effort. For instance, if AMOS existed we'd have this and this.

First impressions are that this is a never ending project,
You need a development road map, starting from version 0.1.
A project plan, listing all the things that need to be done, and a rough estimate of how long each will take. Bounties could be coordinated for particular tasks.
Like for instance, putting people in charge of particular extensions, or SDL integration etc.

A link to the website in your sig so I even know where to begin.

Ok. Going back to my happy place.

_________________
Leo Nigro, CTO Commodore USA, LLC
Opinions expressed are my own and not those of C= USA.
Commodore/AMIGA "Beautiful, High-Performance, Home Computers for Creativity and Entertainment."

@BigBentheAussie

The biggest problem is making a parser that can accept extensions. We were planning to make a subset of Amos that had all of the graphics and sound handling code in a collection of extensions. We have design documents in our Yahoo group so if people join up and read them and tell us what they think of our plans, then we can implement them more efficiently.

Now it is beginning to look like I should start out with the support libraries with all of the graphics support and sound support and leave the parser and Amos compatibility until later. This fall, I'll be able to get my professor to help me with learning to program the parser so we can look into that then. This seems to be the most popular poll entry at the moment.

That was a good idea about the signature since the Mattathias pages are on Yahoo.com and Sourceforge.net for the source code. The sourceforge project is linked on the Yahoo group page anyway so I set my signature for that page.

Why don't you join up to the Yahoo group? Emails are optional but membership is required to read the contents of the file archive where the design documents are stored. Let us know what you think about them.

@Samurai_Crow

I would say AMOS compatibility is really important for such a project. Because many folks already knows how to program in AMOS or even have some AMOS sources lying around.
I think you should have the AMOS compatibility in the first release, even a reduced one will do for a start (for example AMAL might not be necessary), but then you'll gain some attention, which might help you attract some more developpers to help you in the development.

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@Samurai_Crow

I would rather see AmiBlitz developed for OS4. it's far more amiga friendly than anthing based on amos ever will be.

AmiBlitz is freeware, the source is available to anyone... it needs a native compiler and a few bugs in ted sorted out...

_________________
OS4 Rocks
X1000 beta tester, Sam440 Flex (733)

Visit the Official OS4 Support Site for more help.

It may be that your sole purpose is to serve as a warning to others.

@Severin

AmiBlitz is useful but, since AMOS was a port of STOS from the Atari ST, it is much more suitable for portable programming. I agree that it is not as Amiga-friendly but, for a portable environment, that is actually preferred. When completed, Mattathias will recompile old AmosPro sources on Windows as well as OS4 and MorphOS.

@abalaban

The goal of Alvyn Basic was complete compatibility with AmosPro and hasn't progressed very far. It uses the Amos syntax as a bytecode and requires the source to be able to run anything. It doesn't help that its editor was written in Java either.

Since Mattathias and Alvyn are both GPL licensed source codes, we can borrow from one to fix the other. Alvyn doesn't have a compiler and Mattathias probably won't have an editor for a while. But, since AmosPro itself is a free download, we can use that as an editor and interpreter for now under EUAE.

-edit-
The point I'm trying to make is that, since we're starting over from scratch, we might as well redecorate and add a few features. The way we're planning to add extensions to the language itself will make Amos extensions look primitive. Due to the nature of an extensible language, we'll be able to add lots to it once we get the extension format ironed out.

Last edited by Samurai_Crow on 25-Jun-2007 at 06:12 PM.

@Samurai_Crow

Wasn't there an open-source Hisoft-Basic clone in the works at one point? Are there any other open-source Basic systems on the Amiga that are as close as Hisoft-BASIC was to being drop-in compatible with AmigaBasic? I know about ACE, but it only does a subset of AmigaBasic, and it forces you to use single-letter variable names...

I'd kinda like to see FreeBasic ported to the Amiga, or something of the sort. FreeBasic is a clone of Microsoft QBasic, which is of the same family tree as AmigaBasic (which was, itself, a rebadged Microsoft Basic, more or less the same one that was on the old Radio Shack Color Computer).

_________________
"I love peacenicks, they're so easy to conquer." --Ivan J Ironfist, the Dictator

@debrun

Thanks for the well wishes.

@Others

I have been working on this project for approximately four years now, and I want to complete it as soon as possible. So my approach has been to take the shortest path to a release. This led me to use some helpful tools such as Flex and Bison to create the lexer and parser in previous alpha versions. This approach was quite successful.

However, it became clear to me this spring that Bison is not flexible enough to easily integrate the extensions. This led to the current pause in development as Sam and I set out to create a formal development plan. However, work on this plan has stopped while Sam went to school and I became busier at home and work.

I'm an advocate of essentially implementing a modern, portable version of AMOS and adding other things (such as making an object oriented framework) later, possibly as an extension.

The parser is the current issue, but it is not an insurmountable task. I have several ideas on how to implement it and only need the time to work on them.

As with any large project, we need to take it in small increments and use proven techniques until it is completed. I believe we have fallen victim to the oldest pitfall in the book. We have rushed into coding without the design stage properly completed.

I propose that anyone who is interested examine the current design documents on the Mattathias BASIC mailing list at Yahoo groups and leaving feedback there. We can then use those discussions to refine the design and provide a more detailed development road map.