|
|
Post by mirkosoft on Jun 25, 2019 23:03:55 GMT
Hi!
I need to check file size before loading it into memory. I have own loader and of course it is no problem to get start address, but here is my knowledge hanging. I know that's easy to get size from blocks used - but I need exact size. Of course it can be ending address too 'cause calculate size from this is possible.
Best is get size of PRG, SEQ, USR, REL filetypes.
I know that getting of end address is possible only from PRG file.
Thank you for each help. Miro
|
|
|
|
Post by bjonte on Jun 26, 2019 7:57:01 GMT
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.
|
|
|
|
Post by mirkosoft on Jun 26, 2019 20:04:11 GMT
Ok, I do all possible.
Miro
|
|
|
|
Post by hydrophilic on Jul 10, 2019 7:34:11 GMT
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!  |
|
|
|
Post by mirkosoft on Jul 10, 2019 15:21:32 GMT
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
|
|
|
|
Post by WSoft on Mar 10, 2020 23:57:01 GMT
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.
|
|
|
|
Post by gsteemso on Apr 6, 2020 3:34:48 GMT
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.
|
|
|
|
Post by wsoft on Jul 7, 2020 11:47:09 GMT
Now THIS is a guy who knows his serial stuff. Question: wouldn't it be possible to examine ST to determine the last track and sector read (EOF)? Because at that point, the three zero's saved at the end of a basic program could be used as a marker for the ending location. Games and stuff wouldn't have the three zeros, though.
One option would be to fill the entire disk with zero's by creating humongous-sized files with nothing but zilch, validating the resulting "splat" file then deleting the filler files. Calculating the ending location of a file in that case would be easier because you know what to look for (at least you think you do but what if the program doesn't end after three zeros?). This way can get messed up if you think that constantly editing and saving a file is going to help; it doesn't. It would create problems quickly if you are constantly editing a new program, but with static files that you load all the time (and are not changing), it would be great. Constantly re-filling the disk with zero's in order to over-write scratched portions of the disk must be kept up with in order for future calculations to remain correct. Disks must be prepped with zeros in this case (preferably just after formatting them), which may cross the line with some folks who desire a more convenient or compatible solution. One good thing about the old ways of the CBM disk drives is that once it allocates a disk it will not try to write to the same sectors again when it pertains to other files, this means that the last sector of info will keep its zero's. The last sector should point to the last written location if you go by the zeros, and check for say, three of them at EOF so it remains compatible with basic programs. It should contain enough zero's to check for three if it is a basic program, if not then something is different and the file could be a game or something else.
(disclamer: this was a stupid post huh)
|
|
|
|
Post by bjonte on Jul 7, 2020 15:51:19 GMT
I don’t see how you would avoid reading lots of sectors to find the size. Even more sectors than the actual file contains.
This is kind of bending the disk format and if that’s allowed we can just store the size somewhere instead and require all writers to conform to that new standard.
|
|
|
|
Post by wsoft on Jul 7, 2020 16:04:50 GMT
Yeah. But it would work, in some cases. In others, it would be useless like in cases where the file size gets mixed up with that last sector. Sizes of disks are standardized so that shouldn't be a problem, just read the RESET ID of the drive. You could do this on a 1541, a 71 or an 81. I cannot account for the RamLink, but I don't see why it would be any different... because it stores files no differently than if you'd used a stock Commodore disk drive to save a basic program (all three zero's are included in any case, Commodore drive or no when pertaining to RamLink)
(Disclaimer: DOH that hurt, as well.)
|
|
