SWCHA tests

[JetSetIlly]

There's a very nice test for SWCHB in the AtariAge comment below. It cycles through all input combinations are produces either a blue screen (passes) or a red screen (fails).

https://forums.atariage.com/topic/167173-what-does-the-game-select-switch-actually-do/#findComment-2068829

Is there a SWCHA equivalent for this test? There is an test for SWCHA called TestSWCHA_IndvBits.zip which gopher2600 passes, but I would like a more comprehensive test similar to the SWCHB test.

@ale-79

From a comment in the code, my current truth table is this.

//	SWCHA_W   SWACNT   <input>      SWCHA
//	   0        0         1           1            ^SWCHA_W & ^SWACNT & <input>
//	   0        0         0           0
//	   0        1         1           0
//	   0        1         0           0
//	   1        0         1           1            SWCHA_W & ^SWACNT & <input>
//	   1        0         0           0
//	   1        1         1           1            SWCHA_W & SWACNT & <input>
//	   1        1         0           0

Taking each column to be a, b and c 

//	(^a & ^b & c) | (a & ^b & c) | (a & b & c)
//	(a & c & (^b|b)) | (^a & ^b & c)
//	(a & c) | (^a & ^b & c)

SWCHA_W is what's last been written by the CPU and is what's coming from the connected peripheral/controller. The last column, SWCHA is the output.

This comment dates back to April 2022. I did a poor job of recording how I created this but it would have been through observation of results from a real console (using something like this swcha_test2.bin.zip)

@ale-79 is this something you have knowledge of?

The reason this has come up is because confusion over how the Starpath demo unit works. I don't see how SWCHA can hold a 1 if SWCNT is set to 1 and the value of <input> is uncertain.

https://forums.atariage.com/topic/390261-starpath-demonstration-unit-rom-dump/page/3/#comment-5851035

[ale-79]

Port A works differently from Port B because it reads the actual logic level at the pin, even when it is set as output (Port B simply returns the value stored in "SWCHB_W" in that case).

So the behaviour depends on the specific device that is plugged in the port and more specifically to its ability to override the RIOT output.
The true table above is what you get with a standard joystick like the cx40: it uses mechanical switches that connect the pin to ground when moving the stick in the corresponding direction, and leaves it unconnected otherwise.
When the switch is closed, you'll always read a "0" from the pin even if it's set as output and you wrote a "1" in the SWCHA_W bit, because a direct connection to ground will override the RIOT output capability. With the switch open, you just get what the RIOT is outputting on that pin, as there's nothing interfering with it.

But peripherals that output voltages (e.g. from a logic IC), could also override the output in the other direction, that is pull up the pin to logic "1" even when it is configured to ouptut a "0".

[JetSetIlly]

Port A works differently from Port B because it reads the actual logic level at the pin, even when it is set as output (Port B simply returns the value stored in "SWCHB_W" in that case).

Right. So there's no general test like there is with SWCHB.

So the behaviour depends on the specific device that is plugged in the port and more specifically to its ability to override the RIOT output. The true table above is what you get with a standard joystick like the cx40: it uses mechanical switches that connect the pin to ground when moving the stick in the corresponding direction, and leaves it unconnected otherwise. When the switch is closed, you'll always read a "0" from the pin even if it's set as output and you wrote a "1" in the SWCHA_W bit, because a direct connection to ground will override the RIOT output capability. With the switch open, you just get what the RIOT is outputting on that pin, as there's nothing interfering with it.

Got it. I think I understand why the EOR works in the Supercharger demounit now, which was the motivation for my question. I was worried the truth table was wrong.

[ale-79]

I was worried the truth table was wrong.

The table is correct for a device like a standard joystick that can override a "1" pulling it down to logic "0" but cannot override a "0" pulling it up to logic "1".
Different device could result in a different true table. (e.g. they could be able to override the pins to both logic levels, or just to "1" but not to "0").

[JetSetIlly]

I was worried the truth table was wrong.

The table is correct for a device like a standard joystick that can override a "1" pulling it down to logic "0" but cannot override a "0" pulling it up to logic "1". Different device could result in a different true table. (e.g. they could be able to override the pins to both logic levels, or just to "1" but not to "0").

Understood. Maybe the demounit is like that but I've got it to work (up to a point) on the assumption that it does not operate differently.

What devices are there that do result in a different table?

[ale-79]

What devices are there that do result in a different table?

I don't know. It's an unusual thing to rely on the value read from the port when it is set set to output. (At least for port A. For port B it gives some extra bits of memory)

E.g. a 3 button genesis pad uses the ouptuts from a logic IC to drive the pins for left/right directions, and it might give different results than a standard cx40. The fact is that you typically don't set the port as output when reading it, so I don't think this has been investigated before.

EDIT: Trackballs are other devices that might behave differently. But again, you are not supposed to set the port as output in that case either.