PSG register 7 and Joystick in OpenMSX

Paragon (1832)

11-02-2019, 06:02

Hi, I think I noticed something that works differently in OpenMSX 0.15 and on real hardware. The very first release of XRacing (downloadable here: https://github.com/santiontanon/xracing/releases/tag/1.0), has a bug and joystick should not work (it does not work on real hardware). But in OpenMSX, using a keyjoystick, it does work.

The bug is that I'm setting bit 7 of register 7 of the PSG to 0, which should mess up the joystick.

By NYYRIKKI

Enlighted (6093)

11-02-2019, 07:40

santiontanon wrote:

The bug is that I'm setting bit 7 of register 7 of the PSG to 0, which should mess up the joystick.

Hmm... I don't think you have diagnosed the problem correctly... If you really would do that the openMSX would give you a red warning about it on screen and log it to "Status Info"-tab on Catapult... I don't say that you don't try, but MSX-BIOS fixes your error before it reaches the PSG in order to protect the hardware from short circuits. (In case you still use WRTPSG routine) I think there must be now something else wrong in your program.

By santiontanon

Paragon (1832)

11-02-2019, 08:28

I indeed use the WRTPSG routine, since I am going for maximum compatibility.

You might be right of course, since I cannot know for sure as I am away from home this year due to work, and I don't have an MSX with me. But people have reported the joystick does not work on that version of XRacing on real hardware, but it does work on OpenMSX. So, there is a difference in behavior there, which is what I wanted to report

But I am now very confused, since after I fixed those PSG values I was mentioning (in this version: https://github.com/santiontanon/xracing/releases/tag/1.0.2), the joystick seems to start working (from what people report to me), so that is definitively related to the problem! but you are right that the BIOS should be fixing those values. So, I am not sure what can explain this behavior then!

By Wlcracks

Hero (572)

11-02-2019, 16:20

I missed out the 1.0.2 but it works on the vg8020/00.
Thanks!

By santiontanon

Paragon (1832)

04-03-2019, 22:07

Just picking up this thread, in case if helps finding the difference between OpenMSX 0.15 and real hardware.

In real hardware:
- joystick does not work on this version: https://github.com/santiontanon/xracing/releases/tag/1.0
- but it works fine on this version: https://github.com/santiontanon/xracing/releases/tag/1.0.4

Joystick works fine on both versions in OpenMSX though. The difference is that I was setting bit 7 of register 7 in the PSG to 0. What confuses me is that I am using the BIOS "WRTPSG" routine to write to PSG registers, and NYYRIKI mentioned that this routine should prevent me from setting a 0 there. But in any case, the difference between the emulator and real hardware is there. Reidrac mentioned having the same exact issue in his latest MSX game yesterday on Twitter, with the joystick working on OpenMSX but not on real hardware, as he was setting this bit to 0 as well.

By Manuel

Ascended (19687)

04-03-2019, 23:07

So, the question is what exactly happens if you set that bit to 0....

By gdx

Enlighted (6439)

05-03-2019, 00:05

NYYRIKKI wrote:

santiontanon wrote:

The bug is that I'm setting bit 7 of register 7 of the PSG to 0, which should mess up the joystick.

Hmm... I don't think you have diagnosed the problem correctly...

I already had this problem. When the bit 7 of register 7 is not set and bit 6 not reset the joystick responds badly. By cons it does not react the same on all MSX. It seems that it has no effect on some MSXs. On others it depends on when we access the PSG, and some people say that can damage the PSG of some MSXs.

NYYRIKKI wrote:

If you really would do that the openMSX would give you a red warning about it on screen and log it to "Status Info"-tab on Catapult...

openMSX does not always warn us. It does not seem to take into account bit 6 or there is a bug.

It would be nice if OpenMSX gives us more info when these bits are wrongly set. (CPU registers status for example)

By TomH

Champion (375)

05-03-2019, 16:23

In order clearly to state the problem, I think this is what we're talking about:

Setting bit 7 of register 7 of the AY to 0 means Port B is an input. In particular that means that the value provided for output on Port B's bit 6, which is supposed to select between joystick 1 and joystick 2, isn't supplied.

Per the AY's data sheet: "each [IO] pin is provided with an on-chip pull-up resistor, so that when in the "input" mode, all pins will read normally high".

So when we're talking about "the joystick", has anybody tested whether it simply becomes the case that a joystick can still be read, but it's now always the second one?

By wouter_

Hero (535)

05-03-2019, 18:45

openMSX only gives a warning when port (bit 6) is wrongly set as an output, not when port B (bit 7) is wrongly set as an input. Because only the former can cause damage. And actually right after reset port B is very briefly set as an input. So a warning about this would be annoying.

Apart from this warning, openMSX always treats port A as input and port B as output. In other words: it ignores bits 6 and 7. That is because many real MSX machines do the same. In particular those machines that have the AY8910 integrated in some larger chip (MSX-engine) rather than as a discreet component.

Initially openMSX did emulate the PSG port directions, but we changed this in 2005 because of this bug report. Short summary: there is MSX software that sets the wrong port directions, but nevertheless works correctly on many MSX systems.

Ideally openMSX should always behave the same as the real hardware. But that requires knowing exactly which machine do and which don't ignore the port directions. We don't know that and therefor we decided to error on the safe side (that is: make MSX software behave as is probably intended).

If there's enough interest we could make this behavior (ignore port directions or not) configurable in the machine description files. But then we need help to test many real MSX machines.

By NYYRIKKI

Enlighted (6093)

05-03-2019, 19:28

BIOS protecting you seems to be also bogus information... I just checked and the WRTPSG routine looks like this:

WRTPSG:	DI
	OUT (#A0),A
	PUSH AF
	LD A,E
	EI
	OUT (#A1),A
	POP AF
	RET

... this idea seems to come from BASIC SOUND-command, where there is additional check:

	CP	7	
	JR	NZ,SKIP
	RES	6,E     
	SET	7,E	
SKIP:	JP	WRTPSG

By santiontanon

Paragon (1832)

05-03-2019, 21:13

Thanks for all the info every one! This seems more complicated than I initially thought!

The idea of having it configurable in the machine description files sounds like a good idea to me though. If this is not specified, perhaps the emulator could assume the current behavior, but if it's specified, then it would either ignore or not those bits accordingly. In this way, this would not break anything that is currently working, but if anyone tests on real machine and discovers that those bits are taken into account, the machine descriptions could be improved bit by bit. (no idea how much work this is though)

This would also allow developers like me to just create a machine set to consider bits 6 and 7, just to be able to test our games with emulators as thoroughly as possible before testing in real hardware