| |
Kratznagel
Account closed
Registered: Aug 2005
Posts: 4 |
Searching for a fast-writing floppy routine
Hi there,
I am searching for a special floppy routine for the 1541 which I can use as a replacement for the CBM-DOS block-write command. Of course it should be faster than the original one. ;)
Can somebody help me out?
CU
Kratznagel |
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Hi,
check Plushdos (Plushdos) for some "disk systems" that also feature block-save routines (the intention to integrate them in the loaders was to save hiscores). They come in binary only (relocateable with the menu), so if you need the source, just tell me. There's also an irq saver, to save files and add their directory entry while running irq's on the c64 side. The routines in there are very old and outdated, though, meaning they are not as fast as it gets.
Somewhat later routines can be found in Fixup #$00 (Fixup #$00), in source format (Turbo Assembler). It features no block saving routines, but a more recent version of the irq saver (with a different transfer protocol, though).
Both savers use kernel routines to write the blocks, though, but the block-save routines in the disk systems mentioned above don't, and are much faster.
If you just need a bare block-write routine for your drive and you want to integrate that in one of your programs, come visit #c-64 on IRCnet and ask me for assistance in ripping the routines from the source and integrating it in your routine :D |
| |
Kratznagel
Account closed
Registered: Aug 2005
Posts: 4 |
Hi Krill,
thank you for your offer to help me out via IRC. :)
I'll first have a look at these tools and check if they are matching with my intentions. But be sure to get some further questions in the near future. ;)
CU
Kratznagel |
| |
Kratznagel
Account closed
Registered: Aug 2005
Posts: 4 |
Update: I successfully integrated the Plushdos Block Saver in my own Program, a fast D64-Writer for MMC64. It's working great! :-)
CU
Kratznagel |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quote: Update: I successfully integrated the Plushdos Block Saver in my own Program, a fast D64-Writer for MMC64. It's working great! :-)
CU
Kratznagel
Ah, nice. There might be some compatibility issues with this ooooold piece of software. If you encounter some, please contact me. |
| |
Kratznagel
Account closed
Registered: Aug 2005
Posts: 4 |
OK, it's nearly been done! Beta testing of my D64 writer plugin has finished. I'm going to upload a first offical release at CSDb in a few days. :-)
Some things had been discovered by the beta testers: The block saving routine seems to hang up for some reasons, i.e. when the destination disk's surface is physically corrupted or if the disk is not pre-formatted.
Is it possible to make the block saver exit in these cases and pass over an error code via akku?
One of the testers mentioned that the floppie's R/W-LED doesn't turn off after writing blocks (and uninstalling disk system). Further disk operations (i.e. re-installing and block-writing) makes the saver hang up in this case.
He uses a C64G in combination with a 1541c (with 251968-02 EPROM). Well, I have read that a 1541c has some compatibility problems anyway, which are rendering many speeders useless...
BTW: I am also searching for a fast formatting routine which I can integrate in my D64 writer...
CU
Kratznagel |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Would be nice if you could send me the source, so that i can take a look at which code you actually used, and if you applied it correctly. The 1541-C issues must of course be fixed, that a lot of speeders won't work with it is no excuse for doing the same. :D
I never wrote a fast formatting routine myself, and according to Graham, such things are not very good. You'd need to write one yourself or rip it from somewhere :D
regards. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: OK, it's nearly been done! Beta testing of my D64 writer plugin has finished. I'm going to upload a first offical release at CSDb in a few days. :-)
Some things had been discovered by the beta testers: The block saving routine seems to hang up for some reasons, i.e. when the destination disk's surface is physically corrupted or if the disk is not pre-formatted.
Is it possible to make the block saver exit in these cases and pass over an error code via akku?
One of the testers mentioned that the floppie's R/W-LED doesn't turn off after writing blocks (and uninstalling disk system). Further disk operations (i.e. re-installing and block-writing) makes the saver hang up in this case.
He uses a C64G in combination with a 1541c (with 251968-02 EPROM). Well, I have read that a 1541c has some compatibility problems anyway, which are rendering many speeders useless...
BTW: I am also searching for a fast formatting routine which I can integrate in my D64 writer...
CU
Kratznagel
I did a fast format for over5 (Over5-20021117). Source code here: http://www.kahlin.net/~tlr/c64/fastformat-20020423.tar.gz
(partly based on the SpeedDOS+ implementation)
It was later further optimized by Marko Mäkelä in cbmlink (http://www.funet.fi/pub/cbm/crossplatform/transfer/C2N232/cbmli..). |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
I wouldn't use most fast format routines. Usually they do not verify anything and also do not measure track lengths which results in a weird sector spreading on a track. The CBM format isn't that slow (because the slow serial bus routines are not involved) and very secure. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: I wouldn't use most fast format routines. Usually they do not verify anything and also do not measure track lengths which results in a weird sector spreading on a track. The CBM format isn't that slow (because the slow serial bus routines are not involved) and very secure.
A good (like the one I linked) formatter ofcourse verifies the written track! (total formatting time is roughly 24 seconds for a disk)
I formatted all my disks with the SpeedDOS+ format back in 1986-87. With very few exceptions they are readable without errors today. SpeedDOS+ uses an optimized measurement of track length, and speeds the actual formatting by calculating all sector headers for the track while simultaneously wiping the track. It also reduces the amount of "bumping" whenever possible.
My formatting routine uses a static intersector gap of 8 bytes. I find this perfectly safe, but you will ofcourse be a bit more sensitive to a drive with badly adjusted motor speed. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
I uploaded it here SpeedDOS+ Kernal if someone wants to have a look. There is one kernal replacement, and on replacement for the upper part of the 16Kb 1541 ROM.
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
A static gap is not perfectly safe since different drives have different spinning speeds. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: A static gap is not perfectly safe since different drives have different spinning speeds.
Ofcourse, but the speed should be close to 300 rpm if the drive is properly calibrated. If not, it is probably time to calibrate it.
I agree though that it would be better to measure the track. Have a look at how SpeedDOS does it. This formatter is just as fast as mine, and manages to measure aswell. I guess it makes the assumption that the floppy rotates at a constant speed, which is a fair assumption. This way it needs to measure only once. Also it has been proven in "battle" as I stated earlier. :) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Hardly any drive really has those theoretical 300 rpm. It ranges from 280 to 320 rpm. And in the future this problem is getting bigger since the spinning speeds get more and more uncalibrated. Also, some mechanics used for the 1541 had a default of ~280 rpm and not 300. |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Where do you get your drives from? I have tested eight drives and all of them have rotated between 295 and 305 RPM. Drives have ranged from Japan-made VC-1541 with original long board to C128D's internal 1571. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
One of my C128DCR drives has ~320 rpm, and I know that commodore used some 285 rpm mechanics in some 1541.
Anyway, even 295-305 is enough, 305 rpm has a tracklength of 7566 gcr bytes on a track and 295 rpm has a tracklength of 7822 gcr bytes. This makes a difference of 263 bytes in total or 12.5 bytes per sector gap!
Take for example this fast format routine with a default of 8 bytes sector gap: A sector has the size of 5+10+10+5+325+8 gcr bytes = 363. A track would be 363*21 = 7623... 57 bytes longer than a track on a 305 rpm drive, so the last sector overwrites 57 bytes of the first again -> format routine does not work at all on such drive. |
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
Sorry for zombifying that thread, but is there a software I can use to measure my drive rotation speed? |
| |
Devia
Registered: Oct 2004
Posts: 401 |
Yes. Try this
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Vice (x64, didn't try x64sc) gives me 356.5 RPM with this test program. :) Huhu.. |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
1541U gives 357RPM. |
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
Hehe, same here. Thanks for posting the link, Devia. Returns a healthy sounding 300.2 rpm for my 1571 in the 128 DCR. |
