SmallDOS
November 1987, Commodore MagazineShortcut Disk commands for the C64 and Vic-20
|
"Why would anyone want or need a new disk wedge for the 64?"
Thus began my first successful magazine submission. According to CBM "lore", because the C64 and VIC-20 were intended to be price-busting home computers, Commodore anticipated that most users would use inexpensive cassette tape for program storage instead of the more expensive floppy drives. Therefore, the built-in BASIC Interpreter included no commands for accessing a disk drive. LOAD & SAVE defaulted to cassette. True, this could be changed by simply specifying a device number: LOAD"PROGRAM NAME",8 loads a BASIC program from device #8 -- a disk drive. To load a binary file, that is, a machine language program, required adding a ",1" after the device #, specifying a non-relocating load. SAVEing a BASIC program to disk was equally easy.
Other disk drive operations weren't as straightforward. The command to format a floppy, for example, was
OPEN15,8,15:"NEW:NAME,ID":CLOSE15
OPEN a file #_ on device #_ with a "secondary address" # (same as file #): send the command: then CLOSE the file -- which does one the Big Favor of also closing the secondary address. Other operations, such as deleting or renaming a file were just as bad. But WORST of all, in my opinion, was getting a disk's Directory. LOAD"$",8 read a directory into RAM as if it were a BASIC program, and it could be LIST ed to the screen, as if it were a BASIC program. And because a directory was treated as if it were a BASIC program, getting it wiped out any real BASIC program already in RAM!
To reduce the tedium, when purchased the 1541 disk drive included a Test/Demo disk, which had on it DOS 5.1 (a misnomer if ever there was one,) for the C64, and VIC-20 WEDGE for the Vic. Both programs were called wedges because they "wedged" into CHRGET, a routine BASIC initialization wrote in RAM, whose function was to GET every CHaRacter of a BASIC program and determine if it was part of a line number or a "token" signifiying a command, or a variable or expression, or text. Because it was in RAM, it could be altered to perform additional steps. (Altering BASIC in this way slowed it down somewhat and other methods, such as triggering a false SYNTAX ERROR, had less effect on execution speed. See Super Numbers III.)
Once the appropriate wedge was installed in the appropriate computer, getting a floppy's Directory became @$ and would not affect any resident BASIC program. To format a floppy, the command was @N:DISK NAME, LOADing a program became /PROGRAM NAME, and other disk commands were similarly simplified.
Happy happy joy joy. So why did I come up with new wedges?
The problem with DOS 5.1, as I saw it, was that it was 1K in length and resided in an area of C64 RAM that was used by just about every machine language program ever written for the '64. The VIC-20 WEDGE, while only about 300 bytes and relocatable (a necessity due to the Vic's small memory and its variable amount when expanded,) lacked some of the commands that DOS 5.1 had.
Despite the Vic Wedge's limitations I decided to use it as the basis of a new disk wedge. First I disassembled it to see how it worked. I found lots of BEQs, BNEs, BCCs -- relative branches -- to make it relocatable. The JSRs and JMPs were to system (ROM) routines, and their locations were different in the C64 and VIC. By loading the Vic Wedge into the C64 and POKEing the right values to the right locations before RUNning it, I made the Vic Wedge work on the C64.
 SAVEing the program (with a new name,) before RUNning it created a new, smaller disk wedge for the C64, which I called QD64. I then set about giving it some of the missing commands DOS 5.1 had.
 The "fairly involved" steps included lowering the Top of Basic to make room for the missing commands at the beginning of QD64, RUNning a BASIC program that POKEd the needed additional ML therein, (different versions for the C64 and Vic,) then SAVEing the newly expanded QD64 ML, typing in a BASIC program as a new "front end" for the wedge and, finally, creating a new "hybrid" program combining the new BASIC and ML programs.
 The Commands
  Not bad. Although some DOS 5.1 commands worked from within a running BASIC program, the VIC-20 Wedge commands, on which SmallDOS was based, worked only in "Direct" immediate mode. I did not consider this a serious limitation. At a little over 500 bytes, this new wedge was small enough to run on an unexpanded Vic. Unfortunately, expanded memory -- as little as an additional 3K -- was necessary to run the BASIC loader that POKEd the added ML into Vic memory. Looking back, perhaps I could've somehow economized on that part of the process.
|