Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Efficient use of sectors on 1541 disks.
2007-07-19 18:22
Conrad

Registered: Nov 2006
Posts: 856
Efficient use of sectors on 1541 disks.

A question/idea(?) to loader-coders...

I've been curious on how the .prg file structure is laid out on a standard 1541 floppy disk, particularly on sector use.

Sometimes you always get a sector with completely wasted bytes - for example, if a program's last sector from a chain only needs about 8 bytes of memory (plus the first 2 for end marker and number of bytes left), that means the other 246 bytes are wasted, that could of been used by another small program.

I'm not too sure if anyone has actually written a loader which does this, but a nice idea would be to have an offset parameter value stored somewhere in the directory sector for each file. Reading this up in some 1541 manual, Byte locations #22-#25 in a directory file structure are known as unused. These could be used to store the offset values, which shouldn't really harm the directory at all. The only problem would be that the standard kernal loader may bring back errors due to ignoring these particular locations and then possibility of loading corrupted data into memory. Only loaders coded by us could do this job.

The last few days I've been learning about drive coding and I never knew how much control you can have with the 1541's memory :) It's early days for me yet, but soon I'll understand more and then give this idea a try.

If anyone has thought about this idea before, I would really appreciate their opinion :)

Thanks.



2007-07-19 18:39
Burglar

Registered: Dec 2004
Posts: 1137
you mean iffl ;)
2007-07-19 18:47
Oswald

Registered: Apr 2002
Posts: 5127
yeah this was already done in various implementations, generally it is called iffl, and usually used for storing cracked game data.

btw this is a common problem with modern filesystems aswell AFAIK, but the storage capacity seems to be growing fast enough, to make it a minor issue.
2007-07-19 18:58
Steppe

Registered: Jan 2002
Posts: 1510
Oswald, you're right. Back then my disks used to have 664 blocks free. Nowadays, with storage capacity growing rapidly, I can without problem save 700-730 blocks onto it. They call it oversaving, hehe.
2007-07-19 19:12
Conrad

Registered: Nov 2006
Posts: 856
I see,

Well, since there are now better file/disk systems already invented, I guess this won't be a worry after all :) yet I may give this idea a go sometime - for good old standard 644 block disks :).

Thanks for your input guys :)
2007-07-19 19:15
Oswald

Registered: Apr 2002
Posts: 5127
you can also use the directory track to store data, track 18 in default is fully reserved for the dir.
2007-07-19 21:13
Steppe

Registered: Jan 2002
Posts: 1510
But joking aside, isn't there an IFFL rant over at covertbitops.c64.org?
2007-07-19 21:16
Oswald

Registered: Apr 2002
Posts: 5127
IIRC there is
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Chesser/Blazon
hedning/G★P
Krill/Plush
d4ng3r
acrouzet/G★P
CA$H/TRiAD
tlr
encore
Barfly/Extend
Didi/Laxity
Sychamis
lotus_skylight
Mythus/Delysid
Guests online: 265
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Codeboys & Endians  (9.7)
4 Mojo  (9.6)
5 Coma Light 13  (9.6)
6 Edge of Disgrace  (9.6)
7 Signal Carnival  (9.6)
8 Wonderland XIV  (9.5)
9 Uncensored  (9.5)
10 Comaland 100%  (9.5)
Top onefile Demos
1 Nine  (9.7)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.5)
6 Scan and Spin  (9.5)
7 Onscreen 5k  (9.5)
8 Grey  (9.5)
9 Dawnfall V1.1  (9.5)
10 Rainbow Connection  (9.5)
Top Groups
1 Artline Designs  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Performers  (9.3)
5 Censor Design  (9.3)
Top Crackers
1 Mr. Z  (9.9)
2 OTD  (9.8)
3 Antitrack  (9.8)
4 Fungus  (9.8)
5 S!R  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2025
Page generated in: 0.046 sec.