| |
Krill
Registered: Apr 2002
Posts: 3082 |
REL files
... are useless and a waste of DOS ROM space to the detriment of proper seeking in files.
Change my mind! =) |
|
... 9 posts hidden. Click here to view all posts....
|
| |
tlr
Registered: Sep 2003
Posts: 1807 |
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: 3082 |
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: 108 |
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: 3082 |
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: 108 |
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: 108 |
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: 11509 |
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: 1807 |
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. |
| Previous - 1 | 2 - Next |
