From: A. Fachat <>
Date: Sun, 09 Jun 2013 16:25:26 +0200
Message-ID: <21761161.pmKW7Z0EiG@euler>
Hi there,

you might be aware of that I am currently investigating how relative files 
work. The reason for this is that I want to implement rel file support into our 
xd2031 AtMega firmware - so you can use rel files located on your PC attached to 
the CBM with a xs1541 or other xd2031-compatible devices.

So this is what I found and what I hope from you is to tell me if you spot 
something that is not correct....:

- when a rel file is created without writing to a record, it first shows as zero 
blocks, even though it consumes 2 blocks (so you have a directory with one file 
with zero blocks, but 662 blocks free). I.e. the first data and first side 
sector block are created immediately (speaking of DOS2.6)

- when positioning, the "+96" on the channel number does not seem to have any 
effect - it seems to work with and without it.

- When you position to a record number that is not yet there you get a "50, 
RECORD NOT PRESENT" as documented - but when you write to that, the file gets 
expanded "to that block". So if you address a record that _behind_ the one you 
wrote to, but is in the same disk block as it, it has already been created and 
you get an OK. So expansion happens disk-block-wise (which is logical, just 
wanted to state it here..)

- record numbers start at 1. If you try 0, it is handled as 1, without error

- position into record starts with 1. If you try 0, it is silently used as 1

- when a record is initiated, it is initiated with one "$ff" and the rest zero 

- Each separate PRINT# ends up in a new record. I.e. after an EOF on the 
IEC/IEEE bus the drive closes the record and goes to the next one, unless you 
re-position back into it.

- PRINTing a partial record fills the rest of the record with zero-bytes. If 
the PRINT did not start at the beginning of the record (e.g. due to 
positioning), the part before the PRINTed data is kept.

- Read with INPUT# and GET# reads until the last valid byte of the record, 
which gets sent with EOF. (length of the record see below)

- reading after getting the EOF continues reading the next record.

- Reading a few bytes of a record, then writing to the file (without re-
positioning) is ignored.

- writing to a record, then reading without re-positioning reads the following 

- I can create an all-zero-byte record, on reading I get a single zero-byte 
with EOF.

- the size of a record is all the data until and including the last non-zero 
byte in the record. A zero-byte in the middle is read without giving EOF.

- reading a full record, then writing without re-positioning in between writes 
to the next record.

Is this all correct? Do you know any more quirks with relative files?

Many thanks

       Message was sent through the cbm-hackers mailing list
Received on 2013-06-09 15:00:03

Archive generated by hypermail 2.2.0.