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: 849
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: 1101
you mean iffl ;)
2007-07-19 18:47
Oswald

Registered: Apr 2002
Posts: 5094
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: 849
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: 5094
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: 5094
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
t0m3000/hf^boom!^ibx
rexbeng
BYB/Hokuto Force
Freeze/Blazon
MCM/ONSLAUGHT
Peacemaker/CENSOR/Hi..
aegis/ascraeus/r3turn
psych
CA$H/TRiAD
Guests online: 139
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Diskmag Editors
1 Magic  (9.8)
2 hedning  (9.6)
3 Jazzcat  (9.5)
4 Elwix  (9.1)
5 Remix  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.049 sec.