Commodore's
*BASIC* was poor in the 64, yes. It was reasonably fast but
allowed no access to the machine's graphics and sound without resorting to
PEEKs and POKEs and SYStem calls. In that sense, the ROM was crummy.
Commodore's BASIC? It's Microsoft's BASIC, right?
OTOH, the BASIC 7 of the C128 was excellent. The C128 ROM makes any cartridge
superfluous.
Yeah, BASIC 2.0 is just vanilla M-BASIC. In a machine that was that sound-
and graphics-sophisticated for the day, giving the user no access to it
without resorting to low-level control doesn't really make much sense. Look
at how quickly Simon's BASIC and the Super Expander came out.
Barring freaky
loaders of which there are many, ?LOAD ERRORs are unheard of
on the 64 and VIC-20 (unless you run the tape over with a truck or a faulty
bulk eraser -- and maybe not even then :-).
Load errors? No, not those, the machine simply goes on loading and loading, or
fails without an explanation.
Depends on the loader. If it's a commercial loader like, say, NOVATAPE, yes.
But the regular stock Kernal loader is highly reliable, just slow as heck.
From glancing
at Commodore Hacking (online 'zine), it seems the problem was
actually
addressed back on the C64, but not software supported, or being
disabled through lack of some simple components. The problem lies with the
VIC20.
The VIC-20 actually runs it better. In fact, the serial bus is 25% faster
on the VIC, and early 1541s have a compatibility mode to support this speed
boost. The main problem is the VIC-II interrupting the CPU every time it wants
to do DMA (this is part of the reason why sprites turn off automatically when
the Kernal LOAD routine starts), which interferes with the exact timing the
IEC bus protocol demands. To get this speed boost back, you send the drive
a UI+ command, and then turn the 64's screen off with POKE 53265,11.
This problem doesn't show up in the 128 when it uses the VIC-II for video
because its CIAs are different, and specifically wired for the faster speed.
That's the other part of the problem on the 64. I assume cost was the reason
it was not corrected -- it is fairly easy to do a board modification to allow
fast serial access on the 64 also, but you need a special loader as well since
the 64's Kernal does not support it.
GEOS had its
own *fast loader* but still used most of the 1541 DOS routines
for things like scratches and renames.
But the file system is incompatible, right?
Largely. GEOS VLIR tries to implement a multi-fork format. If you try to
LOAD a GEOS VLIR file with the Kernal routine, you get the info fork, not the
data fork. However, the disks are not low-level incompatible -- it is fully
possible to read GEOS VLIR files with direct sector access techniques like
U1 and U2 commands because they're still regular GCR sectors.
--
----------------------------- personal page:
http://www.armory.com/~spectre/ --
Cameron Kaiser, Point Loma Nazarene University * ckaiser(a)stockholm.ptloma.edu
-- For every credibility gap, there is a gullibility fill. -- R. Clopton ------
