{"id":273,"date":"2009-07-28T00:01:47","date_gmt":"2009-07-28T08:01:47","guid":{"rendered":"http:\/\/www.pagetable.com\/?p=273"},"modified":"2009-07-28T00:01:47","modified_gmt":"2009-07-28T08:01:47","slug":"load8","status":"publish","type":"post","link":"https:\/\/www.pagetable.com\/?p=273","title":{"rendered":"LOAD&#034;$&#034;,8"},"content":{"rendered":"<p>Commodore computers up to BASIC 2.0 (like the Commodore 64, the VIC-20 and the PET 2001) only had a very basic understanding of mass storage: There were physical device numbers that were mapped to the different busses, and the &#8220;KERNAL&#8221; library had &#8220;open&#8221;, &#8220;read&#8221;, &#8220;write&#8221; and &#8220;close&#8221; functions that worked on these devices. There were also higher-level &#8220;load&#8221; and &#8220;save&#8221; functions that could load and save arbitrary regions of memory: The first two bytes of the file would be the (little endian) start address of the memory block.<\/p>\n<p>With no special knowledge of &#8220;block storage&#8221; devices like disk drives, BASIC 2.0, which was not only a programming laguage but basically the shell of Commodore computers, could not express commands like &#8220;format a disk&#8221;, &#8220;delete a file&#8221; or &#8220;show the directory&#8221;. All this functionality, as well as the file system implementation, was part of the firmware of the disk drives.<\/p>\n<h3>Sending a Command<\/h3>\n<p>Sending commands to the drive was done by using the &#8220;open&#8221; call with a &#8220;secondary address&#8221; of 15: The computer&#8217;s KERNAL just sent the file name and the secondary address over the IEC bus as if it were to open a file, but the floppy drive understood secondary address 15 as the command channel. So for example, deleting a file from BASIC looked like this:<\/p>\n<pre>\nOPEN 1,8,15,\"S:FOO\": CLOSE 1\n<\/pre>\n<p>&#8220;1&#8221; is the KERNAL&#8217;s file descriptor, &#8220;8&#8221; the device number and &#8220;15&#8221; the secondary address. Experts omitted the close, because it blocked on the completion of the operation.<\/p>\n<h3>Getting Data Back<\/h3>\n<p>While the &#8220;OPEN&#8221; line for disk commands was pretty verbose, it was still doable. Getting the error message of the last operation back was more tricky: It required a loop in BASIC that read bytes from channel 15 until EOF was reached.<\/p>\n<p>Getting a directory listing would be in the same class of problem, since it requires the computer to send a command (and a file name mask) to the floppy and receive the data. Neither BASIC nor KERNAL knew how to do this, and since this was such a common operation, it wouldn&#8217;t have been possible to have the user type in a 4 line BASIC program just to dump the directory contents.<\/p>\n<h3>The BASIC Program Hack<\/h3>\n<p>Here comes the trick: If the program to load started with a &#8220;$&#8221; (followed by an optional mask), the floppy drive just returned the directory listing &#8211; formatted as a BASIC program. The user could then just &#8220;LOAD&#8221; the directory and &#8220;LIST&#8221; it if it were a BASIC program:<\/p>\n<pre>\nLOAD\"$\",8\n\nSEARCHING FOR $\nLOADING\nREADY.\nLIST\n\n0 \"TEST DISK       \" 23 2A\n20   \"FOO\"               PRG\n3    \"BAR\"               PRG\n641 BLOCKS FREE.\n<\/pre>\n<p>In this example, &#8220;TEST DISK&#8221; is the disk name, &#8220;23&#8221; the disk ID and &#8220;2A&#8221; the filesystem format\/version (always 2A on 1540\/1541\/1551\/1570\/1571 &#8211; but this was only a redundant copy of the version information which was never read and could be changed). There are two files, 20 and 3 blocks in size respecively (a block is a 256 byte allocation unit on disk &#8211; since blocks are stored as linked lists there are only 254 bytes of payload), and both are of the &#8220;PRG&#8221; type.<\/p>\n<h3>Encoding of Commodore BASIC Programs<\/h3>\n<p>The floppy was aware of the encoding that Commodore BASIC (a derivative of Microsoft BASIC for 6502) used and prepared the directory listing in that way. A BASIC program in memory is a linked list of lines. Every line starts with a 2-byte pointer to the next line. A 0-pointer marks the end of the program. The next two bytes are the line number, followed by the zero-terminated encoded line contents.<\/p>\n<p>The LIST command decodes a BASIC program in memory by following the linked list from the start of BASIC RAM. It prints the line number, a space, and the line contents. These contents have BASIC keywords encoded as 1-byte tokens starting at 0x80. Character below 0x80 are printed verbatim. Here is what <tt>10 PRINT\"HELLO WORLD!\"<\/tt> would look like:<\/p>\n<pre>\n0801  0E 08    - next line starts at 0x080E\n0803  0A 00    - line number 10\n0805  99       - token for PRINT\n0806  \"HELLO!\" - ASCII text of line\n080D  00       - end of line\n080E  00 00    - end of program\n<\/pre>\n<p>The example directory listing from above would be encoded by the floppy like this:<\/p>\n<pre>\n0801  21 08    - next line starts at 0x0821\n0803  00 00    - line number 0\n0805  '\"TEST DISK       \" 23 2A '\n0820  00       - end of line\n0821  21 08    - next line starts at 0x0821\n0823  14 00    - line number 20\n0825  '  \"FOO\"               PRG '\n0840  00       - end of line\n[...]\n<\/pre>\n<p>A couple of things are interesting here:<\/p>\n<ul>\n<li>The line with the disk name and the ID is actually printed in inverted letters, which is done by having the &#8220;revert&#8221; character code as the first character of the first line, i.e. the floppy makes the assumption that the computer understands this convention.<\/li>\n<li>BASIC will print the file sizes as variable-with line numbers, so the floppy adds extra spaces to the beginning of the line contents to have all file names aligned.<\/li>\n<li>The floppy needs to populate the next line pointers for the linked list.<\/li>\n<\/ul>\n<h3>The Link Pointer<\/h3>\n<p>The obvious question here is: How can the floppy know where in the computer&#8217;s memory the BASIC program will live? The answer is: It doesn&#8217;t. The BASIC interpreter supports having its program anywhere in memory, and loading programs that were saved from other locations on memory &#8211; or possibly other Microsoft BASIC compatible computers with a different memory layout. The VIC-20 had BASIC RAM at 0x0401, the C64 at 0x0801 and the C128 at 0x1C01. Therefore, BASIC &#8220;rebinds&#8221; a program on load, searching for the zero-terminator of the lines and filling the (redundant) link pointers.<\/p>\n<p>The floppy therefore only has to send non-zero values as the link pointers for BASIC to accept the directory listing as a program. In fact, a 1541 sends the directory with a 0x0401-base, which would be valid on a VIC-20. The reason for this is that the 1541 is only a 1540 with minor timing fixes for C64 support, and the 1540 is the floppy drive that was designed for the VIC-20.<\/p>\n<p>Therefore, if you do <tt>LOAD\"$\",8,1<\/tt> on a C64, the extra &#8220;,1&#8221; will be interpreted by the KERNAL LOAD code to load the file at its original address (as opposed to the beginning of BASIC RAM), and since there is screen RAM at 0x0400 on the C64, garbage will appear on the screen, because the character encoding of screen ram is incompatible with BASIC character encoding.<\/p>\n<h3>Directory Code in 61 Bytes<\/h3>\n<p>There are two problems with this &#8220;directory listing is a BASIC program&#8221; hack: Listing the directory overwrites a BASIC program in RAM, and listing the directory from inside an application is non-trivial.<\/p>\n<p>Therefore, many many implementations to show a directory listing exist on the C64 &#8211; and I want to present my own one here, which is, to my knowledge, the shortest existing (and maybe shorted possible?) version. It is based on a 70 byte version published in &#8220;64&#8217;er Magazin&#8221; some time in the 80s, and I managed to get it down to 61 bytes.<\/p>\n<pre>\n,C000:  A9 01     LDA #$01     ; filename length\n,C002:  AA        TAX\n,C003:  A0 E8     LDY #$E8     ; there is a \"$\" at $E801 in ROM\n,C005:  20 BD FF  JSR $FFBD    ; set filename\n,C008:  A9 60     LDA #$60\n,C00A:  85 B9     STA $B9      ; set secondary address\n,C00C:  20 D5 F3  JSR $F3D5    ; OPEN (IEC bus version)\n,C00F:  20 19 F2  JSR $F219    ; set default input device\n,C012:  A0 04     LDY #$04     ; skip 4 bytes (load address and link pointer)\n,C014:  20 13 EE  JSR $EE13    ; read byte\n,C017:  88        DEY\n,C018:  D0 FA     BNE $C014    ; loop\n,C01A:  A5 90     LDA $90\n,C01C:  D0 19     BNE $C037    ; check end of file\n,C01E:  20 13 EE  JSR $EE13    ; read byte (block count low)\n,C021:  AA        TAX\n,C022:  20 13 EE  JSR $EE13    ; read byte (block count high)\n,C025:  20 CD BD  JSR $BDCD    ; print 16 bit integer\n,C028:  20 13 EE  JSR $EE13    ; read character\n,C02B:  20 D2 FF  JSR $FFD2    ; print character to stdout\n,C02E:  D0 F8     BNE $C028    ; loop until zero\n,C030:  20 D7 AA  JSR $AAD7    ; print carriage return character\n,C033:  A0 02     LDY #$02\n,C035:  D0 DD     BNE $C014    ; skip 2 bytes next time (link pointer)\n,C037:  20 42 F6  JSR $F642    ; CLOSE\n,C03A:  4C F3 F6  JMP $F6F3    ; reset default input device\n<\/pre>\n<p>(There is a similar implementation <a href=\"http:\/\/noname.c64.org\/csdb\/forums\/?roomid=11&#038;topicid=17487\">here<\/a>.)<\/p>\n<p>There are two limitations of this code though: It omits the extra space between the block number and the filename, leading to a slightly different output, and it cannot be interrupted.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Commodore computers up to BASIC 2.0 (like the Commodore 64, the VIC-20 and the PET 2001) only had a very basic understanding of mass storage: There were physical device numbers that were mapped to the different busses, and the &#8220;KERNAL&#8221; library had &#8220;open&#8221;, &#8220;read&#8221;, &#8220;write&#8221; and &#8220;close&#8221; functions that worked on these devices. There were &#8230; <a title=\"LOAD&#034;$&#034;,8\" class=\"read-more\" href=\"https:\/\/www.pagetable.com\/?p=273\" aria-label=\"Read more about LOAD&#034;$&#034;,8\">Read more<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,5,13,32],"tags":[],"class_list":["post-273","post","type-post","status-publish","format-standard","hentry","category-2","category-archeology","category-floppy-disks","category-tricks"],"_links":{"self":[{"href":"https:\/\/www.pagetable.com\/index.php?rest_route=\/wp\/v2\/posts\/273","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pagetable.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.pagetable.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.pagetable.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.pagetable.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=273"}],"version-history":[{"count":0,"href":"https:\/\/www.pagetable.com\/index.php?rest_route=\/wp\/v2\/posts\/273\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.pagetable.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=273"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.pagetable.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=273"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.pagetable.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=273"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}