Re: BASIC for the CBM-II/8088

From: Mia Magnusson <>
Date: Mon, 23 Jul 2018 23:11:30 +0200
Message-ID: <>
Den Sat, 21 Jul 2018 22:25:55 +0100 skrev smf <>:
> 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.