Okay, I will now point by point deflate your Atari hubris. ;-)
> The Commodore 64 had the worlds worst rom operating system ever created.
> Most publishers just mapped it out and went straight to hardware to get
> good results.
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.
However, the Commodore Kernal (note spelling; Kernal is actually an acronym)
is excellent. Commodore standardised a jump table across all their 8-bit
machines, even the 6509s and the lamented 65, so that a jump to $ffd2 on any
Commodore 8-bit with the possible exception of early PETs always gets you
to the print-a-character routine.
> The sound was somewhat better than the Atari and MUCH
> better than the Apple. The C='s main fault was the i/o. The machine
> could read tape ok, but to read disks it had to emulate the tape drive and
> run at it's speed. This is really horrible. My Atari's hard disk is
> divided into several 16mb partitions (firmware limit is 64mb per partition
> but that is still waiting for a new dos). Specs are 1428 files per
> directory with a 254 char limit for a path. You can stack paths but why?
> A single 16mb hard disk on the C= would have to be partitioned into 180k
> 'floppy-sized' chunks and then addressed using machine calls to the
> drive's rom in order to get a simple directory. There are no directories
> or even CP/M-like 'user areas' to separate data. All that has to be
> virtualized by each application within it's own code.
Ahem. Disks are not emulated by tape in the 64. In the 64, Commodore had
buggy hardware and decided to cripple the serial bus to compensate, hence the
speed. Many, many companies designed fast loader applications; my favourite,
the Epyx FastLoad, uses some of the other serial port pins to do parallel
transfers. Tape is terribly slow also, but then again highly reliable since
programs are actually written twice, and then checksummed on top of that.
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 :-).
As a followup, Commodore fixed the serial bus in the C128. In 128 mode with
a fast-serial peripheral like a 1571 or 1581, serial bus transfers fly.
And they say USB is an original idea. ;-)
Also note that the 64 doesn't care what the hard drive's format is. It doesn't
have to, because it has no DOS internally (just Kernal routines to write
commands to the serial bus and the devices listening are expected to know
what to do). So while the CMD hard drives, which are the major serial bus
hard drive these days, can run in an emulation mode where they pretend to be
a whole lot of disks in a jukebox, they can just be one huge disk and it
doesn't make any difference to the C64. The only reason they offer that mode
is for clueless commercial software that expects to be in a "real" 1541.
Partition switching is not that hard either -- sending a / disk command is
not very onerous. If you want real paths, there's a 80-byte patch I have
somewhere that emulates it through recursive / disk commands.
The 1581 is the same way, except it doesn't have the "1541 jukebox" mode.
But all Commodore drives that natively offer subdirectories do it with /.
> There is no DOS for the C=. At least none that allows you to run the
> majority of software. There is none because the i/o and ram schemes never
> allowed for one. GEOS does not count because it bypasses or manipulates
> the original ROM os for greater functionality at the expense of near total
> incompatibility with non-GEOS software.
I don't understand. The DOS is in the disk drives, and you send it commands
over the serial bus. This means you can implement anything as a filesystem
device as long as it understands serial bus protocol. If you mean like an
Atari DOS menu, well, we're clueful enough not to need menus in the Commodore
world. ;-)
GEOS had its own *fast loader* but still used most of the 1541 DOS routines
for things like scratches and renames.
--
----------------------------- personal page: http://www.armory.com/~spectre/ --
Cameron Kaiser, Point Loma Nazarene University * ckaiser_at_stockholm.ptloma.edu
-- if (you.canRead(this)) you.canGet(new job(!problem)); -- Seen at JavaOne ---
Received on Thu Nov 16 2000 - 09:04:30 GMT