On Mon, 6 Sep 1999, Ethan Dicks wrote: > Implemented how? The difference between a PRG file and an SEQ file (besides > the bit in the directory entry) is that a PRG starts with the load address > as a low-byte, high-byte pair. It is only a semantic difference. Try SAVE"program,s",8 and it'll be a SEQ file. > USR files are undefined by CBM DOS No, they are supported as well. SAVE"program,u",8 works. Also DEL files are sequential, but they cannot be created without modifying the directory block using direct-access commands, can they? BTW, the burst mode in the C128 is so brain-dead that it cannot load SEQ files (at least not in the 1985 version). I think I saw in some documentation that there's a bit in the burst protocol that specifies whether it'll load anything, or just PRG files. GEOS uses the file type designator USR for its files, which have a non-CBM format called VLIR, I think. > and REL files are different depending on the exact version you have > (super-side-sectors and the like). It's amazing how much effort Commodore put in REL files. And still, comparing with more reasonable file systems (I don't think that a singly-linked list of sector numbers embedded in the data sectors is reasonable at all; it makes the files look like tapes, which you can only read sequentially) which support things like the fseek() call in the C library, there is nothing special in REL files. If I've understood correctly, the record length byte (which is the only thing unique to REL files) is just semantic information (acting as a multiplier for the record managing commands); the side sectors are laid in the same way, no matter what the record length is. I'd rather have had a reasonable equivalent of fseek()/fread()/fwrite() calls than REL files in Commodore drives. Marko - This message was sent through the cbm-hackers mailing list. To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tcm.hut.fi.
Archive generated by hypermail 2.1.1.