Closed S0urceror closed 1 year ago
Okay, I did a bit more digging. I connected a Logic Analyser in between the STFM and the ACSI2STM board.
This is the result with TOS1.00
And this is the result with TOS1.04
Notice the double A1 line triggering on TOS1.00. I believe this is the reason it doesn't work correctly on 1.00. This is out-of-spec behaviour but unfortunately how it's sending things out. Maybe a newer firmware of the ACSI2STM could be made to ignore this.
But the good news is that on TOS1.04 it is working flawlessly. For now I will work with TOS1.04
Thanks a lot for this very deep analysis, and sorry for the very high latency (this project is very low priority for me right now).
This double A1 trigger is something I saw in other cases (esp. Putnik's free driver) so it may be worth investigating how I could handle that case "correctly" without killing the new (more stable) quick reset logic of 3.x. Anyway, this is certainly something that can be handled at firmware level.
Thanks for your response. Understand that after a while you have to focus on other things. In my own retro projects this is the same. Nevertheless ACSI2STM is a great project and I thank you for that.
I posted my findings so that they are documented for others as well.
I earlier checked your code to see where this could be fixed but on the other hand I have now TOS1.04 and that entirely fixes things and has much better compatibility with harddrives in general. I don't think I'm going back to 1.00.
Another user has the same A1 retrigger issue. I will add a workaround in the upcoming 4.0e (it will still be alpha/maybe beta).
4.00 will positively work with TOS 1.00 as I could reproduce and work around the double A1 issue. Closing.
My 1024 STFM has TOS 1.00.
If I boot EMUTOS from a floppy the ACSI2STM works fine. If I boot TOS1.00 from the built-in ROM the boot sector is not loaded.
Visible in a debug/verbose session is that somehow the command is received wrongly, like so:
But the TOS1.00 code, yes I disassembled it, really sends for LUN 0:
Which is correct. 1 sector starting at 0.
I see in the TOS code that the time-out between bytes is a maximum of 50msecs. Could it be that the STM32 timer4 implementation misses on of the [0] bytes during read?
P.S. hopefully soon I'll receive a TOS1.04 ROM so that I can test it with this one as well.