| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Disk ID causing trouble
Apparently when the 1541 seeks a track (using the ROM routines), it _doesn't_ ignore the ID which is inside the header block, but compares it to the ID stored on zeropage (can't recall the exact address right now). The seek command is issued by the "execute" jobcode ($e0) and, unless I loaded something from the disk before, the seek fails. To overcome the problem, I invoke the initialize routine at $d005 as first thing in my loader. Now two problems arise:
1. Unless run on a stock 1541, the loader locks up immediately (e.g. SpeedDOS)
2. If I flip the disk, I need to invoke "initialize" once again, but for some reason it fails this time (locking up). And I'm dangerously low on memory, so I cannot write my own routines which would eventually ignore the ID.
A simple solution is to format both sides with the same ID, but that would complicate copying, which is completely undesirable. I've been trying to catch up something in AAY1541, but no luck so far.
Any suggestions? Is there a way to tell DOS to ignore the ID, or set it as unknown so that DOS reads it from disk before seeking?
Btw, the problem might actually be occuring while seeking a sector using the routine at $f50a. |
|
| |
cadaver
Registered: Feb 2002
Posts: 1159 |
I could be horribly wrong, but doesn't the error handling routine decode the GCR header track/sector to $16,$17? So after it fails for the first time, you'd do
lda $16
sta $12
lda $17
sta $13
and it'd work on the next attempt. At least that has worked for me (disksidechanges etc.) in usual IRQ-loader driveparts, though I've been relying on the read-jobcode... |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Uhm, the execute job doesn't return an error code. If you don't overwrite the jobcode with an errorcode yourself, the execute will be invoked endlessly. However, when the diskside changes, I can try the seek jobcode for example. It should return the Disk ID Mismatch error. Thanks a lot for the tip!
There's another thing I'm curious about. Where do emulators take the ID from? (since D64 files don't have that data). It's probably the ID in the directory, but I'm not sure.
Off to see if this will work. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
What about setting the "disk changed"-flag in $1C and try to read a block? Should work + initialise the ID. Using the "I" routines is not a good idea, some 1541 ROMs do a head bump then (annoying). |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
The seek idea worked, even without lda $16:sta $12:lda $17:sta $13.
@Graham: The default value of $1c seems to be 0 (CCS). Will any nonzero value do the job? |
| |
anix
Account closed
Registered: Feb 2004
Posts: 35 |
about disk-change-flag, i modified one of my 1541 to not care about write-protect-notches and since i did that, i'm always getting errors about Disk-ID... is the notch-sensor the method that disk-change was detected? i think some turn-disk-parts have still worked, but maybe i should test it again |
| |
V-12
Registered: Nov 2003
Posts: 206 |
I got this problem about "disk id mismatch" since my disc drive fucked up for a first time. It was caused by broken power supply. It crashed up ROM too. So I replaced ROM in my disc drive and power supply and realised that now the disc drive always show me "disc id mismatch' error when I put new disc. And finally I've recovered the reason - broken photo-diode which checks if disc are protected or not (Inside the disc drive this diode is located at the left down corner on small green board). I suppose that maybe it's a possibility to make small modifications in ROM and remove that stupid disk id mismatch or just add automatickly initialisation before all disc operations. The best way is to replace broken photo-diode but from my experience you need to replace with exactly the same diode (from other disc drive).
Also another trick - if yours disc drive shows all the time "disc id mismatch" and the photodiode is probably broken, you can also write stuff on protected discs.
Since few years I'm using switcher for protected disc - I just solve both legs from the diode - it gives me "disc id mismatch" too but I can write stuff on protected files. But the photodiode is not broken.
Ok enough about it, let me know if you have more questions :) |
| |
anix
Account closed
Registered: Feb 2004
Posts: 35 |
@murdock: that's what i have done, shorted the leads of that diode through a spst... and since then i have the disk-ID problem. i guess there's no easy way to disable write-protect without causing the ID problem ? :( |
| |
Kisiel
Account closed
Registered: Jul 2003
Posts: 56 |
Murdock you can use BC108 transistor with polished top of the housing (it's round metal package).. becouse every transistor is a fotodiode. I change original fotodiode many years ago and this solution still working.. as you can check on every north party in poland :) I forgot what was with the emiter diode, but if you change it to yellowone it will be good choice :) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
The drive uses the write protect sense to find out if a new disk has been inserted. Shortening the sense will cause a lot of trouble. |
| |
V-12
Registered: Nov 2003
Posts: 206 |
anix: aah understand..I didn't readed carefully your last post :) well maybe only with changing the ROM of the drive it would work...but I know another solution which did my friend. He added the reset for the solved lines... I really would like to remove that "disk id mismatch" too without another electronic modifications. |
... 8 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
