Scripting In Commodore BASIC For Windows & Linux

SomeoneGotMyNick writes "Someone more nostalgic than I am, and with a lot of time on their hands, had created a scripting language based on Commodore BASIC for Mac OS X. They recently finished a version that works on Windows and Linux. You can pass the text of a BASIC program as a parameter to the program. I found it odd that it took 1.8 MB of source code to compile to an interpreter that used to fit in 8K of ROM space. If this ever becomes popular, perhaps we'll see Obfuscated CBM BASIC contests." In a simliar vein, in the comments someone points out what is essentially an open source AmigaOS Classic.

Comments

There's also Freebasic.

[GrpA]

I guess basic is basic unless it's on a machine you're familiar with... I find Freebasic ( www.freebasic.net ) useful, probably because I came from the same era and did all my programming back then too, although I used a Spectrum and I'd never want to have to use that sort of keyboard again.

Freebasic is a fairly recent compiler that makes pretty neat code and has all the common C calls available to it too as well as being able to process native Qbasic programs (if you migrated from the C64 type basic to the PC later) without many of the limitations and nearly complete compatability.

It also allows cross-scripting between Mac, PC and Linux with the same program which I find useful too.

www.freebasic.net

GrpA.

ps. Basic may not be dead, but you still get funny looks when people see you programming in it. I think some consider it even more ancient and antiquated than cobol (which it's not).

Re:TI Basic

[mfh]

Was that a stock 99-4A or did you have the extended memory cartridge?

I had the 10 ton silver expansion box! 32k baby!!! It was the BEST! :) With the Speech Synthesizer to boot! Doc Watson makes me cry when I think about how much that thing cost me... right out of pocket too from my paper route!!

This particular code made use of CALL SPRITE, but also had the most advanced calls available. Man that brings back memories...

CALL COLOR, CALL CHAR, CALL SPRITE, CALL PATTERN, CALL MAGNIFY, CALL MOTION, CALL POSITION, CALL LOCATE, CALL DISTANCE, CALL COINC, and CALL DELSPRITE.

The cartridge was Extended Basic, which was totally elite at the time. :P

We were all designing color output, while the poor VIC-20 guys were still monochrome.

I still remember the text adventure, where if you type look up, a piano falls on your head. I think it was called Asylum or something? Man that is going way back to the summer of 1983, if memory serves.

Re:Commodore BASIC

[hpa]

A few things that made Commodore BASIC slow compared to some of the BASICs of the time:

1. A lot of parsing was done at runtime, rather than at entry time or program startup time. This meant that a lot of work got done over and over rather than once per execution, and also encouraged practices that made programs hard to read, like omitting comments and whitespace.
2. No support for integer-only arithmetic.
3. Very few high-level constructs. This didn't just turn programs into a mess of POKE statements, but frequently meant that a lot of them were needed -- all of which involved two floating-point to integer conversions to set a single byte.

Most BASICs at the time would at least tokenize at entry time, and many even converted programs to P-code for execution. It was still much slower than true assembly, but it wasn't anywhere near as bad as the CBM basic. Similarly, most (but again, not all) BASICs of the time supported integer-only arithmetic at least as an option.

I have to admit to being a bit spoiled at the time, since I first learned to program on the Swedish ABC80 computer, which had a very fast BASIC interpreter. Its follower, ABC800, even had a decent collection of high-level programming constructs in its BASIC. Too bad neither had acceptable graphics, nor a reasonable price point for home use (they ended up being sold mostly into schools and small offices.)