| |
Zaphod
Registered: Jun 2012
Posts: 63 |
Release id #209983 : cc1541 V3.3
A tip. If you use -r to specify a start track, if said track is before 18 and you are using transwarp, it will go backwards instead of forwards. This behavior makes sense, but it is probably not what you would expect.
Transwarp can only use consecutive empty tracks . So you may run into the track 18 barrier when trying to add a file. Changing the order or starting track of files will help get around this. |
|
| |
Krill
Registered: Apr 2002
Posts: 2839 |
And when putting multiple Transwarp files on a previously empty image, how many of them fit depends on their order. This is because Transwarp files occupy entire tracks, and there are 4 different track sizes across the disk.
I briefly thought about some kind of detection/recommendation routine for minimal Transwarp file sizes across a disk, but didn't find anything that would not naively try all permutations on the files' order. But the number of permutations grows fast... It's almost like the bin-packing problem with its NP-hardness maps directly to this problem. =) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: And when putting multiple Transwarp files on a previously empty image, how many of them fit depends on their order. This is because Transwarp files occupy entire tracks, and there are 4 different track sizes across the disk.
I briefly thought about some kind of detection/recommendation routine for minimal Transwarp file sizes across a disk, but didn't find anything that would not naively try all permutations on the files' order. But the number of permutations grows fast... It's almost like the bin-packing problem with its NP-hardness maps directly to this problem. =)
OT: It's exactly bin-packing. I did a fit big bins first for my auto memory layout in EotB. It basically parses all the .lib and .o files emitted from CA65 to find all segments and segment sizes. It then places them in the 64 memory segments defined for the EotB-cart. This method freed up around 60kb worth of ROM and made a nice consecutive free area at the end of the cart.
That said, even a simple naive approach like mine is worth it. It doesn't have to be optimal (I.e. NP complete). |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Ah, i secretly hoped to trigger you. =)
Quoting JackAsserOT: It's exactly bin-packing. I did a fit big bins first Not so sure how exactly it's exactly that. =)
If you assume 4 bins (tracks 1-17, 20-24*, 25-30 and 31-35), then only the big bin (tracks 1-17) is a real bin w/r/t the bin-packing problem.
Items in the other bins may spill over to the next higher bin, and may change size (number of occupied tracks) depending on what adjacent part of them goes to which successive bin.
Quoting JackAsserThat said, even a simple naive approach like mine is worth it. It doesn't have to be optimal (I.e. NP complete). It appears that a few random or semi-random shuffles performed by the user are sufficient to find a good-enough solution. It could pack the showcase images densely enough (all 33 available tracks used) with relatively little effort and without an automated solution.
* Tracks 18 and 19 are occupied by directory and boot stub. |
| |
Zaphod
Registered: Jun 2012
Posts: 63 |
There are a few conflicting principles, in no particular order.
1) larger files should go in the bigger bin, cause they will load faster from there.
2) files should go in the bin that wastes the least space. This sometimes conflicts badly with number 1. this fits the greatest amount of data.
3) files should start as close to the directory track as possible, to minimize head seek times. this can conflict with 1, 2, or both.
4) smaller files in the same bin should be closer than larger files. this minimzes the maximum seek time.
5) if the order of loading is known, total seek time should be minimized. this can override number 4.
so actually a fairly complex problem to eke out every bit of speed. if storage space is the issue, though you don't need to try too much. then again, you are using transwarp for speed, not to maximize storage. :)
The real solution is a gui mastering program that lets peopl drag and drop transwarp files ono the disk. :) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting ZaphodThere are a few conflicting principles Indeed. But i guess the user can be trusted to use the -r ("restrict") option to specify a starting track. (Granted, with a bit of trial and error.) |
| |
Claus_2015
Registered: Oct 2012
Posts: 53 |
If speed is the most important factor, I think the main driving factor is clearly how often each file will be accessed. In a multi load game, there will always be certain files that only need to be accessed once during startup, while others are required more often.
I actually thought about giving priorities to files in cc1541 in the past, to decide where to place them on the disk. But in the end it seemed a complicated thing to handle by the user, with only a minor benefit. |
| |
Zaphod
Registered: Jun 2012
Posts: 63 |
There have been cases where i've had to use -r because the default is not optimal, though it's a greater issue when you need to work around preallocated blocks.
Koronis Rift was a nightmare in that regard, but i did it.
still should be some note that for transwarp, -r is the highest track if below 18, and the lowest track if above 18. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting ZaphodIf you use -r to specify a start track, if said track is before 18 and you are using transwarp, it will go backwards instead of forwards. This behavior makes sense, but it is probably not what you would expect.
Quoting Zaphodstill should be some note that for transwarp, -r is the highest track if below 18, and the lowest track if above 18. The note would be something in the vein of
"While cc1541 optimises for sequential loading of files or a directory buffer, and thus allocates standard-format files from track 1 upwards, Transwarp files are allocated like standard-format files allocated by the original CBM DOS.
I.e., starting from around the directory track and then away from the directory track.
Note that Transwarp files occupy contiguous chunks of entire tracks, and thus may not be split across the directory track or tracks occupied any other files." |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting ZaphodThe real solution is a gui mastering program that lets peopl drag and drop transwarp files ono the disk. :) Since the encoder is released under cc1541's permissive MIT-style license (while the C-64/drive-side 6502 assembly decoder/loader code is GPL-licensed), somebody may some day build just such a tool. =) |
| |
Claus_2015
Registered: Oct 2012
Posts: 53 |
The point will come, when the commandline help of cc1541 just is not sufficient anymore and real documentation will be needed. Well, I feel that point was actually already reached some years ago :-D. |
... 6 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
