Den Sat, 21 Jul 2018 22:25:55 +0100 skrev smf <smf@null.net>: > On 21/07/2018 18:35, André Fachat wrote: > > REL files are complicated and the implementation is rather buggy, > > also depending on the DOS version. > > > > You cannot sequentially read the whole file as after the first > > record read there comes an EOF already. > > REL files aren't complicated, they aren't complicated enough. > > Instead of implementing a standard file allocation table on disk and > in ram, they let you use your own scheme. > > I worked somewhere that had developed sales ledger, order processing > and payroll packages for commodore PET using REL files. > > While it would have been nice if the drives had supported seeking, it > would have pushed the price up due to needing more RAM. I can't say anything about required amount of ROM code (maybe even less if the REL stuff is thrown out), but if semi-slow seeks were good enough the drive could read the first two bytes of every sector in one track in one go, and some simple LRU scheme could cache the read data making it fast seeking short distances, rather fast seeking a bit longer forward, and rather slow seeking backwards but still far faster than if all data has to be read the standard way (with interleave - spinning the disk several revs for reading each sector, and also transfer all data to the computer). Especially for the IEC drives just reading the sectors to drive RAM without transfer to the computer would speed up seeks enormously. If super fast seeks would be wanted, even for files covering a whole disk, then two bytes for each sector would be needed, or rather (in the 1541 case) 10 bits for each sector. That would be 1,2k or 800 bytes depending on if two bytes or 10 bits is used. At least for the larger drives, especially the 8050/8250 business drives, I think commodore could well have installed at least 8k ram in the drives. For productivity software that can force the user to only use new/blank disks, it would be possible to create a file that fills the disk sequentially and then just foul the drive rom that the next block of a file is at any wanted position, and let the program in the computer calculate that position. Combining this with setting the pointer of where in the already read sector the next byte going to the computer is, you could actually do arbitrary seeks while reading. It would probably be a lot more complicated to do arbitrary seeks while writing, but writing blocks of 254 bytes would be good enough. But if you anyway will use a non-standard format you might as well just store the data raw starting from a given block. -- (\_/) Copy the bunny to your mails to help (O.o) him achieve world domination. (> <) Come join the dark side. /_|_\ We have cookies.Received on 2018-07-24 00:00:05
Archive generated by hypermail 2.2.0.