Re: Super OS-9 REL volume: Question

From: Rhialto <rhialto_at_falu.nl>
Date: Thu, 1 Oct 2020 14:39:13 +0200
Message-ID: <20201001123913.GB11551_at_falu.nl>
On Tue 29 Sep 2020 at 08:30:42 -0500, vtgearhead wrote:
> I think the record separator explains it.  When I look at an IEEE bus trace
> of the OS-9 boot process I can see 128 bytes of binary data with a single
> trailing 0x0d character for every read operation.  So, for each 256 byte
> logical OS-9 sector, the driver throws away two separator bytes.   

There is no record separator on the disk.

Also, if you read from a REL file and reach the end of a record you get
an EOI. If you continue reading, you will be reading the next record.
For writing this doesn't work; excess data is ignored with an error.

Sometimes, the drive has to invent a character though, when there is
nothing to send. But on the IEEE-488 or IEC bus you can't send nothing,
since the EOI signal is sent together with the last byte.
This is the case past the last record of a file.
Unwritten records that are still within the file are filled with a $FF
character before the padding with $00 bytes to the end.

See this little test program. You can see these effects here.

list

 100 open 1,8,2,"0:relfile,l,"+chr$(10)
 110 print#1,"123456789";
 120 printds$
 210 print#1,"1234567890";
 220 printds$
 310 print#1,"1234567890more.";
 320 printds$
 400 record#1,1
 410 get#1,a$: printa$;:if 64 and st then print"eof";: rem goto 900
 430 goto 410
 900 close 1
ready.


run
00, ok,00,00,0
00, ok,00,00,0
51,overflow in record,00,00,0
123456789eof1234567890eof1234567890eof#eof#eof#eof#eof#eof#eof#eof#eof#eof#eof#e
of#eof#eof#eof#eof#eof#eof#eof#eof#eof#eof#eof
eof
eof
eof
eof
eof
eof
eof
eof
eof
eof
eof
eof
eof
break in  410
ready.

where # stands dor the checkerboard character chr$(255).

-Olaf.
-- 
Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
___  Anyone who is capable of getting themselves made President should on
\X/  no account be allowed to do the job.       --Douglas Adams, "THGTTG"


Received on 2020-10-01 15:00:03

Archive generated by hypermail 2.3.0.