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.