> >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_at_stockholm.ptloma.edu
-- For every credibility gap, there is a gullibility fill. -- R. Clopton ------
Received on Fri Nov 17 2000 - 19:30:28 GMT