mame
mame copied to clipboard
mamedev
upd765: why do we invert the drive ready_r() (and external_ready) here?
As far as I've been able to figure out, the floppy_info ready field is a simple bool indicating true when the drive is ready. There are many cases in this driver where the value of get_ready() is tested, with a false creating an error or status to indicating the drive is not ready.
Similarly, the floppy.cpp ready_r() method returns a simple true/false indicating that the drive is ready or not ready. The actual input line on the upd765 is active high, so I think that rules out chip-based factors (and the fact that all the relevant values/functions are typed as bool does too).
This problem is masked in the later chips which have drive polling disabled by default, but the symptom in my case was a lack of interrupts (caused by drive ready state change) after a reset. Removing this inversion has fixed a number of symptoms I experienced.
Can someone who knows this device better than me comment?
https://github.com/mamedev/mame/blob/590c9922a38b68b83a54f8f8959004bcaff3ad10/src/devices/machine/upd765.cpp#L263-L268
In floppy.cpp ready_r() returns false when the drive is ready and true when it isn't. That's why it's inverted in upd765.cpp get_ready().
Why does it return inverted logic in a bool like that? Can it be renamed to something less confusing (like not_ready_r) or changed to a READLINE or something where it's less implicit that true is asserted?
I think this is because on hardware the real line out of the chip is /RDY, ie, inverted logic.
I think this is close to the reason it is how it is. I believe several of the lines in and out of the floppy drive itself are inverted, but on the upd765, the RDY input is active high. If this is the case, it's just lends even more weight to using lines and the ASSERT_LINE/CLEAR_LINE protocol.
Yeah, but when we're using logic levels like that we tend to use read line member, the use of negative logic with a bool like that would've thrown me, too.