Re: BASIC for the CBM-II/8088

On Samstag, 21. Juli 2018 22:25:55 CEST smf wrote:
> 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.

Whatever a "standard file allocation table" means. There are so many different 
file systems with different types of allocation mechanisms.

In fact the DOS REL file implementation mixes the Commodore linked block chain 
with the "standard" filesystem mechanisms (as e.g. seen in Linux's ext2) using 
a bitmask (BAM) to find unused blocks and indirect blocks (side sectors) to 
implement a seek functionality. The larger (8250/1001 DOS 2.7) drives even 
implement double indirect blocks (super-side-sectors).
(see for example https://en.wikipedia.org/wiki/Inode_pointer_structure )

> I worked somewhere that had developed sales ledger, order processing and
> payroll packages for commodore PET using REL files.

I am not saying you cannot work around the bugs in the DOS REL file 
implementations. But you had to take care about allocating the REL file at the 
very beginning as dynamically extending was buggy, and some file sizes (max. 
record numbers) had problems too IIRC from implementing my own REL file code in 
C and comparing outcomes to equivalent DOS outcomes.

> While it would have been nice if the drives had supported seeking, it
> would have pushed the price up due to needing more RAM.

REL files implement an almost perfect seek mechanism with the P(osition) 
command, just with record number and position in record instead of linear 
address. The complication comes from the DOS "feature" to send an EOF at the 
end of the record.

André