Post by hydrophilic on Jun 22, 2014 8:57:57 GMT
Um this could go under BASIC or ML, but for easy testing, I just put it under BASIC. And I won't be (intentionally) giving any code... this is just some ramblings of an addicted programmer, and hopefully YOU will have some thoughts to post on the subject...
So (ah where to begin)... the 1541 is pretty nice in terms of PRG and SEQ files. Although slow compared to non-CBM systmes, it is much faster than cassette. Which is good.. on the C128 the fast-serial of 1571 and 1581 (etc.) makes it better.
But there is still a problem: the PRG / SEQ format only allows for forward ("linear") reading of file data. This was such a problem that Berkley invented the VLIR type for GEOS. Also if you want to port C programs to a Commie, you are often fû¢ked when it comes to FSEEK (used in many C programs) because it is not possible with PRG /SEQ files.
CBM realized this "linear problem" and creaed the REL format. It kinda of fixes the "linear" problem. For example, you actually can "FSEEK" with the BASIC "RECORD" command (only in version 4.7+, but possible with extra work in v2). In the past I have "pooh pooh"-ed the REL file (but you can't prove it now!). Anyway the important thing is REL allows non-linear / "random" access to file data.
Now I'll assume you are not very familiar with REL... so then you may be wondering why GEOS would create VLIR when there is REL? Well the main reason is probably that each REL record is limited to 253 actual bytes of data, but most VLIR recrords are over 254 bytes. Another thing is effeciency: each VLIR record may be of any size, but every REL record uses the same size on disk. ** disclaimer: I never worked for Berkley Softworks, so I am only guessing why they created VLIR **
My previous bashing of REL files (still can't prove it) is because of problems I personally had. THis is due in part to "quirks" in REL files as handled by CBM-DOS (doesn't matter if 1541,1571 or 1581) and also due to quirks of BASIC 7.0, and also due to original (buggy) 1571 ROMs.
But recently I have discovered more about these "quirks", and thus REL files seem more promising. Note: on "raw" disk format, REL files are quite simple (well, to me) but it is the other stuff (CBM-DOS / BASIC / Buggy ROMs) that has made me make negative comments before.
Anyway, I discovered you can use REL files to store arbitrary/binary data. The way BASIC works, you might (I did) think that REL couldn't hadle binary data.
So lets assume you created a REL file with the maximum record length (254 bytes). In each record, you can read/write up to 253 bytes of arbitrary/binary data, but only if you use ML or BASIC's GET# / PRINT CHR$(). In other words, using BASIC INPUT# will fail with arbitrary/binary data (this is due to special handling of null, CR, comma, and double-quote characters). But using ML / BASIC GET# works fine... for 253 of 254 bytes.
One weird thing I noticed (with any REL record size, and never documentent in any CBM disk manual that I know) is that you can never read the last character from a REL record. So in the example/assumption of 254 bytes per record, I said you can read/write any 253 bytes of data. But not 254 bytes. This is because CBM-DOS (now it is not a BASIC problem.... applies to ML too) will only GET# 253 bytes reliably from the record. If you try to use GET# to fetch last byte of a record (any size) it will (a bug in my opinion) not return the last byte of the current record, but instead return the first byte of the next record.
In other words, trying to use REL files with arbitrary/binary data is almost doomed with BASIC INPUT# due to the way it handles some characters, but BASIC GET# ( or an ML call to KERNAL GETIN ) works fine if you don't try to read the last byte of the record. Personally, I find it odd that I have never seen this documented. I can't say it has never been documented, but I surely don't remember reading about this "quirk".
The other "quirk" which is well-documented (in both BASIC-Guides and DiskDrive-Guides published by CBM) is that you may need to use RECORD command twice... pretty please! In my opion this is a bug (a long standing bug too). Anyway, the problem seems to be (by looking at DOS ROMs) that when a RECORD crosses a sector (block) boundry the DOS may be holding the last sector in memory (buffer) but reading/writing to the first sector (start of record) does not read/write the correct sector (block)... in other words sometimes it will read/write the next sector (block) of the REL file.
Finally, if you have the original 1571 ROMs, then REL files are 100% un-reliable because CBM-DOS uses a special "BCD" mode of the CPU without disabling interrupts (so the interrupt would use the wrong / special "BCD" mode too).
Sorry, I don't have a real summary/conclusion... but I will try one anyway: if you are willing to sacrife the final byte of a record, then REL files can be used with arbitrary/binary data. This means FSEEK is possible, but it means the data file would need to be formatted such that the last byte of each REL record is unneeded. If you are not trying to implement FSEEK, it means REL files may still be useful if each "chunk" of data is less than 254 bytes (max 253).
I imagine some are totally confused by now. I imagine those with REL experience may be only partly confused
Anyway, if you comments about using REL files, do tell!!!! Thanks!
A
So (ah where to begin)... the 1541 is pretty nice in terms of PRG and SEQ files. Although slow compared to non-CBM systmes, it is much faster than cassette. Which is good.. on the C128 the fast-serial of 1571 and 1581 (etc.) makes it better.
But there is still a problem: the PRG / SEQ format only allows for forward ("linear") reading of file data. This was such a problem that Berkley invented the VLIR type for GEOS. Also if you want to port C programs to a Commie, you are often fû¢ked when it comes to FSEEK (used in many C programs) because it is not possible with PRG /SEQ files.
CBM realized this "linear problem" and creaed the REL format. It kinda of fixes the "linear" problem. For example, you actually can "FSEEK" with the BASIC "RECORD" command (only in version 4.7+, but possible with extra work in v2). In the past I have "pooh pooh"-ed the REL file (but you can't prove it now!). Anyway the important thing is REL allows non-linear / "random" access to file data.
Now I'll assume you are not very familiar with REL... so then you may be wondering why GEOS would create VLIR when there is REL? Well the main reason is probably that each REL record is limited to 253 actual bytes of data, but most VLIR recrords are over 254 bytes. Another thing is effeciency: each VLIR record may be of any size, but every REL record uses the same size on disk. ** disclaimer: I never worked for Berkley Softworks, so I am only guessing why they created VLIR **
My previous bashing of REL files (still can't prove it) is because of problems I personally had. THis is due in part to "quirks" in REL files as handled by CBM-DOS (doesn't matter if 1541,1571 or 1581) and also due to quirks of BASIC 7.0, and also due to original (buggy) 1571 ROMs.
But recently I have discovered more about these "quirks", and thus REL files seem more promising. Note: on "raw" disk format, REL files are quite simple (well, to me) but it is the other stuff (CBM-DOS / BASIC / Buggy ROMs) that has made me make negative comments before.
Anyway, I discovered you can use REL files to store arbitrary/binary data. The way BASIC works, you might (I did) think that REL couldn't hadle binary data.
So lets assume you created a REL file with the maximum record length (254 bytes). In each record, you can read/write up to 253 bytes of arbitrary/binary data, but only if you use ML or BASIC's GET# / PRINT CHR$(). In other words, using BASIC INPUT# will fail with arbitrary/binary data (this is due to special handling of null, CR, comma, and double-quote characters). But using ML / BASIC GET# works fine... for 253 of 254 bytes.
One weird thing I noticed (with any REL record size, and never documentent in any CBM disk manual that I know) is that you can never read the last character from a REL record. So in the example/assumption of 254 bytes per record, I said you can read/write any 253 bytes of data. But not 254 bytes. This is because CBM-DOS (now it is not a BASIC problem.... applies to ML too) will only GET# 253 bytes reliably from the record. If you try to use GET# to fetch last byte of a record (any size) it will (a bug in my opinion) not return the last byte of the current record, but instead return the first byte of the next record.
In other words, trying to use REL files with arbitrary/binary data is almost doomed with BASIC INPUT# due to the way it handles some characters, but BASIC GET# ( or an ML call to KERNAL GETIN ) works fine if you don't try to read the last byte of the record. Personally, I find it odd that I have never seen this documented. I can't say it has never been documented, but I surely don't remember reading about this "quirk".
The other "quirk" which is well-documented (in both BASIC-Guides and DiskDrive-Guides published by CBM) is that you may need to use RECORD command twice... pretty please! In my opion this is a bug (a long standing bug too). Anyway, the problem seems to be (by looking at DOS ROMs) that when a RECORD crosses a sector (block) boundry the DOS may be holding the last sector in memory (buffer) but reading/writing to the first sector (start of record) does not read/write the correct sector (block)... in other words sometimes it will read/write the next sector (block) of the REL file.
Finally, if you have the original 1571 ROMs, then REL files are 100% un-reliable because CBM-DOS uses a special "BCD" mode of the CPU without disabling interrupts (so the interrupt would use the wrong / special "BCD" mode too).
Sorry, I don't have a real summary/conclusion... but I will try one anyway: if you are willing to sacrife the final byte of a record, then REL files can be used with arbitrary/binary data. This means FSEEK is possible, but it means the data file would need to be formatted such that the last byte of each REL record is unneeded. If you are not trying to implement FSEEK, it means REL files may still be useful if each "chunk" of data is less than 254 bytes (max 253).
I imagine some are totally confused by now. I imagine those with REL experience may be only partly confused
Anyway, if you comments about using REL files, do tell!!!! Thanks!A
