So, for the record, because my AY implementation is already used by two machines that are not MSXs, and will likely be used by more in the future, I've a slightly different calculus to make on the AY output issue than the openMSX team — if I want to assert that there exist MSXs that do not obey the IO direction controls, therefore for maximum compatibility I should ignore them, then probably the most natural mechanism would be to expand my AY class to model both actual AYs and the cut-down sort. But the base position should be that if it advertises itself as an AY then it should be exactly an AY.
So the next release will implement strict original AY behaviour (indeed, that's already on master, if you're building for yourself) and I'll just have to keep it in mind that it might make sense to add an alternative in the future.
I'm definitely not comfortable with keeping a mis-emulation of the AY without knowledge of the facts even if it just so happens to correlate with a bunch of mis-reimplementations of the AY.
Quick update: the emulator has been updated, partly to tweak a couple of video things, but also to improve its implementation of the AY's input/output ports.
The MSX it models now acts as though it has a discrete AY; the specific flaw that has been fixed is that setting a port as input now causes objects observing it for output to see the value 0xff.
Thanks a lot Tom! Downloaded and just tried it with XRacing, and now the old version with the joystick problem correctly ignores joystick input! Awesome! Thanks a lot for the update! This and the updates Manuel is doing to OpenMSX for this issue as well are immensely useful to me as a developer with rare access to real hardware!
Already tried the latest openMSX build as well?
oh, haven't tried it yet! I saw you had implemented it in your post, but didn't realize it was already on a build. I'll download the latest build tonight and give it a try!!!!
Again to note, for the record: openMSX had opted to provide an implementation of the AY that ignores the direction bits for compatibility. In Clock Signal I'd simply made a coding error that left the observed output levels of a port undefined if it was configured as input. In Clock Signal you now always get the behaviour of a discrete AY. I believe that in openMSX it's configurable.
Net behaviour in Clock Signal now, for the record:
- a port configured as input which is receiving an input will report that input;
- a port configured as output which is receiving an input will report the logical AND of the nominated output and input;
- a port configured as input will appear to be outputting 0xff to anyone elsewhere on the bus;
- a port configured as output will output whatever is the nominated output.
75% of that is from the data sheet, the other bit is from observed behaviour of a real AY in an Amstrad CPC.
TomH: thanks for this. FYI, we now added that 3rd case to the emulation, as the datasheet also seems to indicate that behaviour. And with that we got the same behaviour for XRacing as on real hardware. Thanks again!