Phonemark "Quick Data Drive" - info?, also WTD Commodore 15xx drive, info.

From: Cameron Kaiser <>
Date: Tue Jan 7 19:00:00 2003

> As I recall, most fast loading schemes reprogrammed the Commodore
> serial interface chip (through which all the peripherals were
> interfaced) to run faster, as well as usually providing some sort of
> error correction. Commodore's serial interface design on the 64 was
> among the worst features of the machine.

Being needlessly pedantic as always ;-) they didn't reprogram the interface
"chip" but simply redirected calls to the serial routines in the Kernal ROM
to themselves. The Epyx FastLoad is a typical device; it sets various
vectored Kernal routines to call a 256-byte block of code that sits in the
designated I/O area at $df00 (mapped in through some expansion port signal
magic from the 8K cartridge ROM itself). This code banks in the main ROM,
which overlays the $8000-9fff range, containing the actual loader. As has
been pointed out, since all Commodore disk drives are intelligent
peripherals, most loaders modify the OS on both sides of the serial bus
link and the FastLoad is no exception. It uploads a small asynchronous
loader to the disk drive that instead of the one serial bit I believe
uses the ATN line as a 2-bit parallel line (this was common practice in
many loaders) with a complementary loader on the 64 side, starts the
serial transfer, and then cleans up after itself, switches back to the
256-byte stub which banks the cartridge ROM back out, and exits back to the
calling program.

I particularly like the FastLoad since it works on PAL and NTSC machines
since the loader timing is not too fussy (believe me, there are many
loaders that are really picky about this), and it is insanely cheap and
plentiful. I own seven of them, and I don't think I paid more than $5 for
any one of them. The one I use in my 128DCR has a switch controlling one
of the I/O lines (I forget which) so that I can disable it easily and go
to 128 mode without having to unplug it.

> Before I got rid of my commodore 64 in 1990, I had an upgrade called a
> burst rom chip for it. This let me use the faster commodore 128
> accessories at their full rated speed rather than in 64 emulation mode.
> This plus a 1581 3.5 inch floppy drive was like having a hard disk. :)
> I do recall that this upgrade broke compatibility with the tape drive,
> and I wonder if that wasn't the big reason all the interfacing was so
> slow, to preserve compatibility with the tape system?

As I recall, it was not the tape that was the problem but early 64s that
had some problem with the CIAs then in use. Rather than actually try to
fix the problem, Commodore just crippled the serial bus protocol so it would
still function (just much more slowly).

Worse, the default serial bus protocol does not recover well from timing
errors. Things like VIC-II DMA really gum the works up (this is why the
Kernal turns the sprites off when you LOAD something, but it messes up
*all* serial transfers -- try repeatedly reading the disk error channel with
eight sprites showing on screen and it will randomly lock up [nothing a
quick RUN-STOP/RESTORE can't cure though]).

Certainly the C64 was capable of much more, but Commodore didn't get it
right until the burst serial mode which came standard on the 128s, 1571s
and 1581s, and was just breathtakingly fast (even by objective standards).

> The irony, of course, is that in this age of FireWire and USB, we're
> starting to see the same kinds of peripherals - intelligent,
> programmable, and the computer need not understand how to operate the
> hardware directly. It would be amusing (though almost certainly not
> profitable) to come up with specs of how the C64 might work today.

Well, on the C=one, we may actually see real USB on the clock ports, but it
still comes with a standard IEC serial bus port! :-)

----------------------------- personal page: --
 Cameron Kaiser, Point Loma Nazarene University *
-- The only thing to fear is fearlessness -- R. E. M. -------------------------
Received on Tue Jan 07 2003 - 19:00:00 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:35:59 BST