Getting end address from PRG, SEQ and USR is the same. You have to read the two first byte in each sector of the file until you get the end marker. In essence this means reading the whole file without storing it, unless you plan to upload some custom code to the drive that can do it slightly faster by only decoding the first two bytes of the sectors. It isn’t possible to get the file size in any compatible way other than reading these sector links, one way or another.
Yeah like bjonte said, you (unfortunately) need to scan the ENTIRE file in most cases (PRG/SEQ/USR). In the case of REL and GEOS files there are methods to access total file size without scanning entire file... sadly the methods differ (REL versus GEOS).
AFAIK, there is no standard method to determine total file size of GEOS/VLIR nor CBM/REL... I can tell you about my methods if you ask, but they are not perfect!
Yes, Robert, I'm asking. No matter if is your solution perfect - you're genial programmer in many ways. I want to know more. BTW: Can you provide me and this forum all extended arguments of Basic 7.80 - we all know that it has not any new command, it extends graphic commands for VDC, but have you any list of mods?
Thank you. Miro
Commodore 64 was great, Commodore 128 is bigger, better, faster and more powerful... Commodore 65 was almost here, but C256 is coming and it will be earthquake...
You can't pinpoint the exact ending address without loading the entire file into memory and then peeking the results of zero-page pointers 174/175. But you CAN let your software take an educated guess as to how long the file is by getting the total number of blocks used for that file and for every block you can subtract two bytes because every sector on disk has a pointer to the next-logical track and sector which uses those two bytes to point to that next 253-byte long string of data. The longer the file, the worse the actual block-count of the file but we correct that by taking the total number of blocks in the directory listed for that particular file and subtracting two bytes for every block mentioned. This should give you a ball-park figure that is close but not exact. Might be better to prepare the files beforehand for whatever software you have it planned for by first getting an accurate count by loading the file, and reading the 16-bit pointer at 174/175 immediately after loading, then passing that information on beforehand as pre-stored data (but that's no fun). You could also make a program that could alternately read each pointer WITHOUT reading any data. This info could be passed on to block-read statements that will keep reading the next logical t/s until the file is done, then you'd be pointed at the last t/s but seeing how I never needed to do this myself, I don't know how to get the exact end location either.
As most here have stated, the CBM DOS format has no inherent record of a file's exact size. That said, the directory on a disk does hold a count of how many blocks a specific file should be occupying, so an upper limit on the file's size is straightforward to calculate.
As another fellow just posted, a block on disk holds exactly 254 bytes (a pointer to the next slice of the file uses up two bytes of the raw disk sector holding it). Take 254 bytes * the number of blocks in the file, and there's your upper bound.
Of course, a file rarely ends on an exact multiple of 254 bytes, so the final block isn't usually completely full -- but to find out exactly how much shorter the file really is than that worst-case upper limit, you have to locate and examine the last block of the file to find out how full it is.
The only way to find that last block is to laboriously step through every sector in the file, squinting at the track+sector link stored in it to find the next part. That would take forever if you had to do it in the actual computer, but luckily the drives are programmable; there are utility commands you can give it that will let you do the whole sequence in one of the drive's internal work buffers.
Each track on a floppy disk has a "sector zero", but no CBM floppy has a "track zero". If you encounter a sector which claims its successor is in this nonexistent place, it really means there _is_ no next block -- you're at the last one. The byte that would normally hold the next sector number instead points to the last occupied byte in the sector, in the range [2...255].
There is one minor exception to the foregoing. If you are looking at a random-access (RELative) file, the side-sector structures associated with it hold pointers to every single block it occupies. Finding the last sector of such a file is _much_ faster and simpler, though you do still need to look at it to see how much is unused.
Alas, although the aftermarket GEOS VLIR files incorporate an enormous number of improvements, the actual structure of them leans heavily on the drive's existing, native file formats. In many ways, the format resembles a sheaf of individual SEQuential files, with many of the associated problems.
The world’s only gsteemso
Agitator-in-chief for the Seattle Retro-Computing Society