1 Oct
2007
1 Oct
'07
2:01 p.m.
Roger Merchberger wrote:
...
Well, if you were a Basic programmer (like I was at
the time) then you
*really* weren't missing much! IIRC, it's Basic is not run on the
primary CPU, but on the graphics chip! As such, it's a pretty limited
Basic, and dog slow... at least 10x slower (for a simple For/Next loop)
than a CoCo2, so for a home platform, you'd need to learn assembly or
purchase (read: more $$$) a dev package for C/Fortran/Forth/whatever
else might've been available for that box.
I never used a 99/4 of any flavor, but I recall hearing a very different
explanation why the stock BASIC was so slow. The graphics chip had
nothing to do with it; as far as I know there is no way to run code on
the graphics chip (it is a simple raster+sprite engine).
No, the real reason was that the BASIC was a two-level interpreter. TI
didn't have the time/resources to write a BASIC interpreter in native
assembly, so they procured a BASIC interpreter written in an abstract
machine code, kinda like p-code, such that TI would then just have to
write an assembly level program to interpret the "p-code". I'm sure
they made other enhancements to this BASIC interpreter in order to
support the unique features of the hardware, though.
This approach wasn't all that uncommon. The IBM 5100 did something like
that (although the "p-code" was the instruction set from a real IBM
machine). The early Dr. Dobbs were full of homebrew BASIC interpreters,
and many took this two-level interpreter approach, motivated more to
save space than anything else.
Finally, the "SWEET16" interpreter Woz wrote into the original Apple II
ROMs was intended for this type of speed/space trade off.