| |
Krill
Registered: Apr 2002
Posts: 2844 |
REL files
... are useless and a waste of DOS ROM space to the detriment of proper seeking in files.
Change my mind! =) |
|
| |
tlr
Registered: Sep 2003
Posts: 1714 |
REL files for all your database needs. :)
I think a lot of BBS software uses those for random access. Not sure about C*base but I've seen it.
Do you propose a different random access read/write format? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11116 |
C*base uses it for the userlog iirc. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Quote: C*base uses it for the userlog iirc.
Yes |
| |
macx
Registered: Mar 2002
Posts: 250 |
A REL-file has been used more than 5000 times the past year and a half from a c64 in my datadungeon by 210 different users. I.e. not useless.
Boar's Head Tavern | byob.hopto.org:64128 |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Y'all seem to have missed the "proper seeking in files" bit. =) |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Are you suggesting to go back in time and change Commodore's implementation of REL files, to make it "proper"? (Well, obviously you do not suggest that, but you see my point.) |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
I'm afraid i don't see your point.
I'm saying that with seeking in PRG/SEQ files, REL would be pretty much irrelevant, as seeking allows for much more flexible random access. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting KrillI'm saying that with seeking in PRG/SEQ files, REL would be pretty much irrelevant, as seeking allows for much more flexible random access.
It would I guess, but as there is no real underlying file system, the only support for something seeking-like is using REL files.
Now if the DOS ROM implemented ext4, REL files would be completely irrelevant. |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
CBM DOS implements a real filesystem, of course.
And seeking is just a matter of following the block links and having some bookkeeping. :) |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting KrillCBM DOS implements a real filesystem, of course.
Fair enough, but very crude. As you know it's central directory and singly linked list only.
Quoting KrillAnd seeking is just a matter of following the block links and having some bookkeeping. :)
Doable, although it consumes a bit of memory drive side. A file could potentially fill the whole disk. |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Quoting tlrQuoting KrillAnd seeking is just a matter of following the block links and having some bookkeeping. :) Doable, although it consumes a bit of memory drive side. A file could potentially fill the whole disk. But you don't need a list with T/S of each and every file block, more link sync points for each further track the file occupies.
And i guess you can make them sparse (with a fixed maximum memory footprint) for a heavily fragmented file - just takes a bit longer to seek, but then fragmented files are slower than need be anyways. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quote: CBM DOS implements a real filesystem, of course.
And seeking is just a matter of following the block links and having some bookkeeping. :)
Aren't REL files exactly about the "bookkeeping" part? ;-) |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Quoting Silver Dream !Aren't REL files exactly about the "bookkeeping" part? ;-) Sure, but with on-disk overhead (side sectors) and drawbacks (such as having no support for arbitrary binary payload data).
I meant RAM-only dynamic bookkeeping to maintain an index structure. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quoting Krill[…] drawbacks (such as having no support for arbitrary binary payload data).
What do you mean by that? It's been literally decades since I wrote a huge (by C64 means - had to use 1581 almost to the limit) database using only REL files so I might not remember all the problems I had to overcome but I don't recall anything I could fit here. Or do you refer to the fact that one had to "predict" record length once and for all (records)? |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
BTW - that reminds me... I was wondering whether we have an established "de facto" standard for flattening REL files, which would preserve enough structure information to allow"deflattening" file back into the REL form? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11116 |
what about the good old PC64 format? (.R00) |
| |
doctorfargo
Registered: Aug 2011
Posts: 20 |
I know that a lot of early text adventure games used REL files because it was faster than SEQ files. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: I know that a lot of early text adventure games used REL files because it was faster than SEQ files.
Haven’t seen that, could you give an example? |
| |
JeeK
Registered: Nov 2019
Posts: 4 |
Some of my self-written DB-like applications used the REL file type. Typical address management stuff an so on. If I reminding right a program collection manager too.
The handling is much more complex and more or less error-prone. I think many projects might turn away from REL files in desperation to get it right.
My next generation program collection manager uses a bucket of SEQ files and works with parts of it directly in RAM. This gives a much better performance in handling large datasets ...
A REL file is the closest form of file organization in comparison to other typical (modern) filesystems. At least in sense of positioning to a random location into a file. Alas, some attributes are not easy to obtain, even such basic thing like the file size (but it can be calculated by a binary algorithm). Other things are missing at all, like a current position which could be used for continuous read/write/append of records (bytes or other data block).
But in retrospective I would say the linked blocked file type (PRG, SEQ, USR) are sufficient and very efficient for the typical needs those days. For 99.99 % loading programs this was and is still fine. Applications around databases in any kind was not the core application usage of a C64. But the business lines (PET, CBM II also known as B model line) do also use disk drives with the same or even newer DOS versions having one or other more business-like applications in mind to run on and which benefit from using REL files. |
