Microdrive detection timeout #397
Comments
|
Hi @skiselev, So, yes, this is very likely to be the same situation I have seen on several occasions. IDE drives are supposed to assert BUSY almost immediately at power-on or reset and hold it asserted until they are ready for I/O. RomWBW implements a somewhat arbitrary delay of about 300ms before checking for BUSY. This value has changed many times in the past as I have tried to balance the needs of different hardware while trying to avoid long arbitrary delays. I find that the more "intelligence" the drive has, the slower it is to assert BUSY because it seems to need to run through the startup time of whatever microcontroller is being used. CF Cards have this anomaly, but I have found that 300ms is almost always enough time. As a short term solution, RomWBW has a BOOT_DELAY config setting. It will simply delay the boot process by the specified number of seconds prior to initializing hardware. Could you play with this and let me know if that helps? It is not a very granular timer, but it would still be good to know how many seconds of delay are needed. Thanks, Wayne |
|
I'll try to the BOOT_DELAY and report back. It might take a few days... One solution might be adding a longer delay for the HDD BUSY specifically. That wouldn't affect the systems that don't have an HDD, or that use Flash-based CF cards, that don't hold BUSY signal for long. |
|
Thanks. How would I differentiate an HDD before needing to use the BUSY signal? |
|
Not sure if this will help, but I've used both the original IBM Microdrive (340MB in CF type II format) in IDE mode and the last Hitachi 3K8 35-pin PATA IDE interface with my own W65C02 system. Sensing/initializing the drive has never been a problem. I initially check for a phantom address (upper address byte) by reading the drive's status register (a bit unique to the 6502) and if it's different, I try to initialize the drive as a standard IDE device. That starts by looping on the busy bit in the alternate status register. Once that clears, I send a self-diagnostic command ($EC) to the drive. Upon completion I check for a $50 (%01010000) in the alternate status register, which shows the drive is ready and not seeking. If this passes, you should be good to go. Also note that the self diagnosis command will also show bit 0 of the error register active if the self diagnostic test returns without an error. The 65C02 for the BIOS is on my github. |
|
Thanks @floobydust. I need to take a look at your code and see if I can gain anything from it. My code already does the "wait for busy bit" and everything works fine from that point on. The issue is knowing if I should wait for the busy bit or not. I don't want to sit and wait 30 seconds for a busy bit that will never clear because the hardware is not there. I need to review your code to see if your mechanism to detect the IDE interface itself is better than what I have. I will do that as soon as I can. Thanks, Wayne |
|
Hi @floobydust, OK, I reviewed your code and it all makes sense. It is actually roughly equivalent to what I am doing. My code allows about 20 seconds for a drive to spin-up. Unless Sergey's drive is taking more than 20 seconds to spin up (seems unlikely), I suspect that the interface is behaving differently than I expect. My code tries very hard to avoid stalling for 20 seconds waiting for a non-existent drive to spin-up. Part of this process involves using a long (20 second) timeout at the point where a well-behaved drive will spin-up. According to the spec, a drive should hold busy asserted from power-on until it is ready to process I/O (completed spin-up). It sounds like @skiselev's drive (and perhaps yours) is handling the initial command exchange before spin up has completed, then it forces a much longer busy wait when a real I/O is requested. At this point, RomWBW would have switched to a short timeout. Your code checks the IDE status register to determine if an interface exists. Subsequently, it uses a long timeout. This works great in many scenarios. However, with some drives/systems supported by RomWBW this will result in a 20 second stall on every drive detection because reading the IDE status register cannot determine accurately whether the interface is there or not. Sorry for the long response. 😀 Anyway, with all of this said, it occurs to me that it would be very helpful if @skiselev could turn on the trace functionality in RomWBW and go through a system startup so I can see exactly where this timeout is occurring. Sergey, this means setting the following line in your config file: There is extensive debug tracing in the IDE driver of RomWBW and this output will help me understand the exact place the timeout is occurring (probably). Thanks, Wayne |
|
Oops, that line should have been: |
|
Hi Wayne. So, for my code, there's no preset timeout value. The oddity with the 6502 (and even the W65C02S) is a "phantom read" when you attempt to access a memory location that has nothing there. I use page $FE00 for all I/O with my 650C2 systems (and again, the 65(c)02 has NO specific I/O access). If there is no device (memory or hardware registers) at the requested address, the A reg returns with the upper byte address, which is $FE in my scenario. Using this a a reference, there's no valid bit combinations that an IDE device could return from the status register that would equal $FE. As a result, this makes it easy to determine if an IDE device is present at the decoded address. Once that is validated, the rest of checking for a valid IDE device is pretty straightforward. I haven't done much with the Z80 in a long time (read..... decades), so I've no idea of what an IOREQ of the IDE device status register address would return if the device was not actually there. Maybe that's a possibility to test for?? For all of my Microdrive devices, the time to validate it's existence,i.e., busy bit to become non-active, is pretty short... less than a few seconds. Granted, for older IDE drives, spindle spinup could be a longer time, but if you can determine if an IDE device is truly "there" by doing an IOREQ to the status register, then you should be able to sort out the rest of the testing for a working IDE device being present. Note: for all of my BIOS coding, I used the Seagate IDE manual: Not sure if this really helps or not, but hopefully you can find a procedure that can determine if an IDE controller exists before attempting to run self-tests to validate it's exitsistence. Regards, KM |
|
I have a couple of the Hitachi Microdrives coming from eBay. Once I get them, I should be able to track down the exact issue and will report back on whether I can fix it. Thanks, Wayne |
The Microdrives behave slightly differently than either normal spinning drives or CF Cards. This update removes the "short" timeout that is used in the IDE/PPIDE drivers which caused timeout issues for the Microdrives. The short timeout was originally used to workaround excessive wait/stall during boot of some media. I don't think it is necessary any more because of additional intelligence in the initialization routines.
|
I have addressed this issue in RomWBW Development Snapshot v3.5.0-dev.56. Supporting the Microdrives was not hard -- just needed to increase the timeout in the driver. The only potential issue is with other scenarios stalling at boot due to the long timeout. I think it is OK and will test futher. For now, this should correct the power-on error with the Microdrives. I will leave this issue open for a few days in case there is further related feedback. Thanks, Wayne |
|
I have not seen any problems in my testing, so I am going to go ahead and close this issue. Reopen if necessary. Thanks, Wayne |
This issue is probably a bit geeky (but isn't it all?!).
I tried using a Hitachi 6 GB Microdrive, which is an actual spinning hard drive in a CompactFlash form factor.
It appears that RomWBW doesn't give it enough time to "spin" on boot. So I am getting a "BUSY TIMEOUT" error.
When the system is restarted from the RomWBW boot loader it properly detects the disk
The text was updated successfully, but these errors were encountered: