• Please review our updated Terms and Rules here

RAND_READ behavior

A

alank2

Veteran Member
Joined
Aug 3, 2016
Messages
2,264
Location
USA
This says that KAYPRO on CP/M 2.2 returns no_error (0) on the call to F_READRAND for record 18 so long as reocrd 18 is at the end fo the file.

github.com

File not found with CalcStart Dump vr_1.45 · Issue #6 · ivanizag/iz-cpm

Using Calcstar on an exising file with 3072 bytes: CalcStar Dump vr_1.45 CalcStar file name (<Return> to quit): demo.csd [[BDOS command 26: F_DMAOFF(0080)]] [[BDOS command 15: F_OPEN(cd1a)]][[Open ...
github.com github.com

BUT, shouldn't it fail if there is no random record there even if the random record being requested is directly after the last record in the file?
 
If CalcStar is simply performing the BDOS function for random read, it may not complain as long as there is allocated disk space at the record address. Remember that CP/M allocates file space in blocks, and on a Kaypro typically that is 2K bytes. So, a 3072-byte file actually consumes two blocks or 4K bytes, so record 0x18 is within the space allocated to the file. The description in the 2.2 manual is a bit vague about returning an error: "when a random read operation accesses a data block that has not been previously written...", but it does say "data block" and NOT "record". The documentation is usually pretty precise about terminology. A 128-byte record is NOT the same as a data block (file allocation block).
 
Do files know their file size in records though? or do they know their file size in terms of records according to the allocated blocks? If a file has 17 records in it on a system with a 2K block size, will compute file size show 17 or 32?
 
The CP/M filesystem does store the number of records in the last extent (well, all others are assumed full... most of the time). However, I see no evidence in the 2.2 BDOS source code that this is being checked. It only seems to check if there is an allocated disk block backing the record address.

You don't mention which Kaypro floppy format this is, but it seems that single-sided uses 1024-byte blocks while double uses 2048-byte blocks. For a 3072-byte file on single-sided, physical and logical EOF would be the same. But, of course that's just accidental. A 2944-byte file, or a 3200-byte file, would not have that property.
 
I think CP/M 2.2 has to know the file length. I have a file that is 89 records long (11392 bytes), but it takes up 12K when viewing it with the stat command (3 4K blocks?) in SIMH.

It fails on trying to read record 89, but record 88 is ok.

A>emu4004
readpage 88 0
readpage 89 1

If CP/M 2.2 didn't check the record length, then it should have read records up to 95 without an error returned.
 
CP/M knows the length of the file in 128 byte records, regardless of the block size. You can see this CP/M 2.2 disc formats page for the details of the directory entries that makes this clear.
 
CP/M *DOES* know the file length to the record. (CP/M 3 adds the option to also know the length to the byte). But what I'm saying is that RAND READ does not check the seek record to that detail. It only checks whether the seek lands within *allocated* file data.
 
>But what I'm saying is that RAND READ does not check the seek record to that detail. It only checks whether the seek lands within *allocated* file data.

Are you certain about this - see my test above with SIMH. It clearly returns an error when I request record 89 which is allocated.
 
Ah, I see what I missed. The "rseek" part of randiskread does not check the record count, but the diskread part does.
 
You must log in or register to reply here.
Back
Top