| |
vedos
Account closed
Registered: Jul 2003
Posts: 33 |
C-64 formatting program which supports multiple disk drives simultaneously and has proper error checking
Can anyone recommend me a good disk formatting program for C-64 (I'm using 1541 and 1541-II drives) which supports multiple disk drives (preferrably simultaneously) and has a proper disk error detection (as far as I've understood eg. Action Replay MK VI's format doesn't check for disk errors). The speed isn't that important. I just want to format working disks. :) |
|
| |
Krill
Registered: Apr 2002
Posts: 2968 |
If speed is not an issue, just use the built-in format:
openN,8,15,"n:disk,id"
where N can be at least any number between 0 and 15, and the 8 is obviously the drive number.
This command immediately returns, so you can issue it multiple times on multiple connected drives. Just increase N with every invokation.
However, before re-using an N, you need to
close N
I don't know how well this does error-check on disks, but you can get no better format than the ROM routines, which are that slow for a reason. (And you can always use a tool like Disk Checker to check) :)
|
| |
hevosenliha
Registered: Sep 2008
Posts: 48 |
I guess this is just me, but I've always had problems using the built in formatter, on 1541, 1541-II and Excellerator+ (and that drive was brand new...)
The disks simply just don't work reliably when formatted with the built in... When formatted with some turbo formatter I've had no problems what so ever.
The latest utility I've used is from alpha flight, but I don't think it can be used on multiple drives... |
| |
Skate
Registered: Jul 2003
Posts: 494 |
Action Replay's format command (@n) always worked for me. And I find it early to check disk at format level. Copy whatever you want, then make an error check with a tool like which Krill suggested. |
| |
vedos
Account closed
Registered: Jul 2003
Posts: 33 |
Quote: If speed is not an issue, just use the built-in format:
openN,8,15,"n:disk,id"
where N can be at least any number between 0 and 15, and the 8 is obviously the drive number.
This command immediately returns, so you can issue it multiple times on multiple connected drives. Just increase N with every invokation.
However, before re-using an N, you need to
close N
I don't know how well this does error-check on disks, but you can get no better format than the ROM routines, which are that slow for a reason. (And you can always use a tool like Disk Checker to check) :)
In which way this reports if there are errors during format? I'd like a program which could be used to format using 2 to 4 disk drives at once. Does anyone know if such program exists? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
Quote:Action Replay's format command (@n) always worked for me.
uh yeah, because it does no error checking whatsoever. AR even formats a slice of bread =)
if you want a reliably formatted disk, DONT use AR to format (and avoid most other fastformatters too). either use the cbm dos one (which indeed does all necessary error checking) or the one from grahams TFR (which is a bit faster, and still has verify) |
| |
Skate
Registered: Jul 2003
Posts: 494 |
@Groepaz: did you read my message to the end? I say it's not necessery to make an error check until you finish copying your files. quick format, copy, then check for errors. even if your disk is damaged but your files are not covering that track/sector, hell with that error. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
I hate to say it, but groppie is kinda right here :) |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Fast Hack'em, worked since 1985 |
| |
Krill
Registered: Apr 2002
Posts: 2968 |
Quote: Fast Hack'em, worked since 1985
Which version are you referring to? I found none which has a multi-drive formatter. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
Quote:Groepaz: did you read my message to the end? I say it's not necessery to make an error check until you finish copying your files. quick format, copy, then check for errors. even if your disk is damaged but your files are not covering that track/sector, hell with that error.
its not that easy unfortunately. as long as you are never going to write again to that disk, then everything is fine. (thats why many people dont remember AR fastformat as problematic). the problems arise whenever you are going to write something to the disk.... because:
a proper format routine as a first step determines how many bit cells can be written to a track in one rotation (the duration of a bit cell it can write is fixed, but the rotation speed is not). now it calculates the number of padding bytes that must be used to fill the various gaps on the track. many fastformatters skip this step completely and use hardcoded values for an assumed rotation speed of 300rpm. (and this is what saves a lot of time, its not the verify of actual written blocks - that can be done in a single additional rotation).
and this is why omitting the above eventually becomes a problem:
assume you ar fast-formatted a disk on a drive that spins slightly slower than 300rpm. the consequence would be that all gaps are slightly shorter on the medium than they should be. now you put this disk into a drive which is slightly faster than 300rpm.... you can read the disk fine, no problem. but when writing to the disk all hell breaks lose: when writing a block, the drive looks for the sector header, and when the sector is found waits until the data block comes by, switches to write mode and then writes out a full block. due to the analog nature of the media (rotation speed is not fixed) the actual physical area on disk which represents this written sector doesnt always perfectly match the old same sector, but "moves back and forth" a bit - thats why the padding gaps between data blocks and sector headers exist. now remember, the drive we are using is a bit too fast, and this very gap is a bit too short. what eventually happens now is that the data block overwrites the sync mark before the following sector header - resulting in that sector beeing unreadable (sector header not found).
and thats why a proper format routine is win :) |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
now up it to codebase :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
@groepaz: Well said!
In my practical experience most drives have been close to 300 rpm but that's not guaranteed. Also many fast formatters (including my older one) assume the same static gap for all speed zones. Some (e.g jiffy dos) assume different static gaps for each speed zone which is slightly better.
Whereas the normal 1541 formatter measures track length for each track, the speed dos+ formatter improves speed by only measuring the track length once per speed zone.
I have done a prototype formatter that only measures track length once per format and then scales the value for each speed zone. That seems to work quite well.
|
| |
The Shadow
Registered: Oct 2007
Posts: 304 |
The fast format in Fast Hack 'Em can be found in the file copier. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: The fast format in Fast Hack 'Em can be found in the file copier.
I checked the one in this release: Single File Hack'em.
It is the typical static intersector gap=8 without verify.
|
| |
Mace
Registered: May 2002
Posts: 1799 |
@ Groepaz: thanks for the insight :-)
Not that I can make any use of this information, but I like reading about it...
BTW, mind the 'goof' of Single File Hack 'em. |
| |
The Shadow
Registered: Oct 2007
Posts: 304 |
The pure, uncracked version of Fast Hack 'Em is the best to use. Choose the File Copy option from this version of Fast Hack'em V6.00 |
| |
Krill
Registered: Apr 2002
Posts: 2968 |
Mace: You might enjoy reading loading times & drive compatibility then :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
"BTW, mind the 'goof' of Single File Hack 'em."
the problem you describe is very common, and not only fast-hackem (yes, all versions) have it. eg warpcopy has it too :) |
| |
Mace
Registered: May 2002
Posts: 1799 |
Krill: the concise description of Groepaz is much more pleasant to read than endless code snippets with GCR bit rotations ;-) |
| |
Krill
Registered: Apr 2002
Posts: 2968 |
Mace: Scroll down to the bottom :) |
| |
Skate
Registered: Jul 2003
Posts: 494 |
@Groepaz: you win but I'll stick to the @n with my exactly 300rpm ultramegasuper drive ;) |
| |
Frantic
Registered: Mar 2003
Posts: 1646 |
Just thought it would be useful to mention in this thread that TLR recently released a proper fast formatter (although for one drive only, it seems):
http://noname.c64.org/csdb/ |
| |
Frantic
Registered: Mar 2003
Posts: 1646 |
Just thought it would be useful to mention in this thread that TLR recently released a proper fast formatter (although for one drive only, it seems):
Format II |
| |
Count Zero
Registered: Jan 2003
Posts: 1920 |
Someone turn groepaz into an admin! Erm... Nevermind. :)
He sure is a genious in explaining this nicely. Should have been done in 1988 to a wide audience already. :(
EDIT: Another reason this often passed without much notice is that many speeders update BAM and directory using standard kernel routines and track 18 is like always (at least often) fine then regardless of drive speed and misalignements.
/cz
|
| |
vedos
Account closed
Registered: Jul 2003
Posts: 33 |
Ok. I'm almost sold, but it'd be kickass with simultaneous (or even ok with not simultaneous) multidrive support.
I was also wondering what the TAILGAP option means. There's NORMAL and OPTIMIZED. Can anyone explain what these means?
Thanks for the program tlr! |
