OSS Compatible BASIC

[Stephen]

Hello,

I'm toying with the idea of building
a version of BASIC that would ultimately be
compatible with OSS's BASIC XE or BASIC XL.
I'm curious if there's any interest in the
Atari community about something like this,
or if this has been attempted before (nothing
show'd up with Google).

I know there are _many_ fine emulators
out there already, and anyone who wants to run
a BASIC program can do so as if they were
running on actual hardware.

But, I'm talking about writing this in
C/Unix and using X windows (hopefully allowing
ports to other graphic architectures easily)
- not a 6502 emulator.

Naturally, the initial objective is to
fully support existing BASIC programs at their
save'd level (and list'd level, too). One big
item I don't think would be practical to support
is the USR function. Hybrid programs are best
run in one of the available emulators. However,
I'd try to support many of the common
PEEK/POKE locations.

The real emphasis of the project would
be the language itself - not an Atari H/W
emulator. Having a natively written OSS
compatible BASIC would be interesting (and fun).

Besides running existing BASIC programs
_really really_ fast (compared to emulation),
some of the original limitations could be
put aside - how many times have you caught
yourself wishing that the original Atari's
had 8-bit (or deeper) color? Or more than
38/40-columns? More _modern_ graphics
statements beyond PLOT/DRAWTO? Etc.?

I think this is a non-trivial project,
but I think there might be merit in it.
I'm not talking about building a VB type
of BASIC either. This version would still
be an interpreter in the manner that the
Atari BASIC(s) interpreted their source.
I though of BASIC XE in particular because
that was designed to be extendable (statements
only, if I remember correctly - though
I don't think it was ever documented)
and I thought keeping that model (of course
in modern terms using shared libraries, etc.)
would be a good starting point.

I welcome any suggestions, comments, etc.

Stephen Lawrow

[SgtSilicon]

I admire your enthusiasm, but I fear there wouldn't be much interest;
even among old die hard BASIC XL/XE fans. Here's why I think so:

1. Most programs written in it, even most simple ones, use hardware
specific features. As you say, USR, but even things like any graphics
or sound fit this category. Only basic text input and output and
mathematical processing could be used within this model.

2. Those that have the skill to heavily modify programs to work out
would then be subject to #3.

3. There are already really good program development tools for modern
platforms. BASIC XL wouldn't really add anything. Those who can
program would I think choose these tools over a BASIC XL style tool.

Just my take on it.

PS: are you the author of Mac/65?

On Tue, 02 Mar 2004 07:59:55 -0500, Stephen <sdlno...@comcast.net>
wrote:

** To email a reply, please remove everything up to and
including the underscore in my email reply header.

[Andreas Magenheimer]

Well,
there already has been a "Battle of the Basics" in the past - or
otherwise said, we already have enough Basic interpreters (though some
od them are hard to find):

- Atari Basic Revision A, B and C
- Microsoft Basic
- Microsoft Basic 2
- Advan Basic
- OSS Basic (various versions);
- OSS Basic XL
- OSS Basic XE
- Turbo-Basic (type-in listing, by HC thus PD status!)
- Hypra-Basic (from Compyshop magazine, PD!)
- Fast Basic (by Tom Hunt? PD!)

and Basic Compilers, like:
- ABC by Datasoft
- MMG compiler
- Synergetic Software Systems Basic Compiler
- Advan Basic Compiler
- Turbo-Basic Compiler (PD! also compiles Atari Basic);

and a few more which I do not remember right now. Me, I would like to
see a PD Basic and/or Turbo-Basic compiler, that creates a "stand-alone"
ML-file like the ABC and MMG compiler did (ok, its actually the Runtime
and the compiled file appended to one ML file)... It is a little
awkward to load the CTB-Runtime every time you want to load a single CTB
file... The PD compiler should only speed up the reading (and poking) of
Atari Basic Data lines, since they take the most time among old Basic
listings... -Andreas.

P.S.: If you still program a new Basic interpreter, let us know,
anyway...

SgtSilicon schrieb:

[Stephen L.]

Hello,

I appreciate the responses I've
received and I'm researching the list of
BASICs Andreas provided (+ the ones listed
in the FAQ). I believe that all of these
run on a 6502 - are there any that run
natively under C/Unix?

Primarily, I'm keeping the BASIC
compatible with the Atari/OSS model
because I believe that's what most of the
legacy BASIC programs were written in
(even un-published ones).

-> SgtSilicon:

1. I think its possible to provide
enough "hardware" support to make
it worthwhile. I admit, though,
I don't really know how many
BASIC programs rely on the USR
function to provide a significant
part of their functionality (I know
the PEEK/POKE can be dicey, too).

Existing hybrid BASIC programs which
rely on the USR function can run in
one of the emulators available.

2. Not every has the skills or the time
to port a BASIC program to another
more modern architecture/language.
It might be beneficial for these
individuals. But, see #3 ->

3. This is a hobby effort on my part.
If it get to be impractical or ugly,
I'll abandon the effort -- it's possible
nothing may come of the idea.

I'm not really thinking of
developing a _new_ programming
language. I agree that there are
_many_ better alternatives to Atari
BASIC for new program development
on the newer hardware available.
I'm not sure if any of these have
the simplicity/elegance that these
olde BASICs had. (But to be fair,
these _had_ to have this quality
because of their limited resources
available to them - let's see Perl
fit in 8 kilobytes!)

I thought about doing this with Action!.
But, 1. I'm not as familiar with its
inner workings, and 2. I don't believe
there were many products produced
with it (commercial or share/freeware).
And finally, 3. there's a special
place in my heart for Atari/OSS BASIC
(mushy violin music okay here).

It will be an interpreter, because
I think that's the easiest way to
implement the language and add
extendibility at the same time.

> P.S.: If you still program a new Basic interpreter, let us know,
> anyway...

I don't expect to have anything
too soon, but I'll definitely post anything
of interest to the group.

Again, thanks to the individuals
that have replied.

> > PS: are you the author of Mac/65?

Yes.

---
Stephen Lawrow

[SgtSilicon]

Hi. Well I did want to answer your request for input honestly, even
if it did turn out to be less than enthusiastic. I guess from my
perspective something like that could be cool, but I just fear the
effort you would need to go through might be a lot. As long as it's
just for fun why the heck not . ;-)

And by the way: I have always really admired Mac/65; great job! I
think it's one of the best assemblers ever made for an 8-bit computer.
Not unlike the tradition of other O.S.S. languages like BASIC XL for
example.