Incorrect implementation of input latches in VIA 6522

[mzattera]

Hi

Not sure where to post the below, but I think I found some inconsistencies in 6522 (VIA) implementation of input latching. I am not fluent with C++ (and MAME source) to fix it myself, but here it is. Is somebody could comment about it, it would be great (I am writing a piece of emulation myself, but it is Java).

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

From http://archive.6502.org/datasheets/mos_6522_preliminary_nov_1977.pdf
and http://archive.6502.org/datasheets/synertek_sy6522_via_1978_jan.pdf

MCS6522/SYS6522 OPERATION

[...]

C. PORT A REGISTERS, PORT B REGISTERS
[...] With input latching enabled, IRA will reflect the contents of the Port A prior to setting the CA1 Interrupt Flag (IFRl)
by an active transition on CA1 [...] With input latching enabled on Port B, setting CB1 interrupt flag will
cause IRB to latch this combination of input data and ORB data until the interrupt flag is cleared [...]

Auxiliary Control Register

[...]

1. PA Latch Enable
   The MCS6522/SYS6522 provides input latching on both the PA and PB ports. In this mode, the data
   present on the peripheral A input pins will be latched within the chip when the CAl interrupt
   flag is set. Reading the PA port will result in these latches being transferred into the
   processor. As long as the CAl interrupt flag is set, the data on the peripheral pins can change
   without affecting the data in the latches. This input latching can be used with any of the CA2
   input or output modes [...]

2. PB Latch Enable
   Input latching on the PB port is controlled in the same manner as that described for the PA port[...]

From: http://archive.6502.org/datasheets/rockwell_r6522_via.pdf

FUNCTIONAL DESCRIPTION

PORT A AND PORT B OPERATION
[...] With input latching enabled, IRA will reflect the levels on the PA pins at the time the latching
occurred (via CA1). The IRB register operates similar to the IRA register [...]

From: http://archive.6502.org/datasheets/synertek_sy6522.pdf

2.0 Port A and Port B
[...] Not until CA1 or CB1 has transitioned(as programmed in the PCR) will any data be latched.
Now a read of the input register will reflect the data that was on the port line at the time
of the latching transition. After this read the input registers will again appear transparent
until the next CA1 or CB1 transition. See Figure 2 [...]

====================================================================================

This means, accordingly to the data sheets (as I understand it):

1a) Even if input latching is set, unless a active transition happens on CA1/CA2, reading a port will return the
same result as if latching is disabled (that is, it will read input pins for port A and a combination of input pins/ORA for port b).
See Figure 2 Read A in http://archive.6502.org/datasheets/synertek_sy6522.pdf.

2a) An active transition on CA1/CB1 while in latching mode will latch the input. This, at the same time, sets
corresponding flags in IFR. Therefore "active transition on CA1/CB1" and "setting IFR flags for CA1/CB1" are synonyms.

3a) As long as latching is enabled AND corresponding bits in IFR are set, reading a port will return the latched value.
Note that, depending on how PCR is set (mode 000 and 010 for CA2/CB2 control),
reading/writing ports also clears corresponding bit in IFR, disabling latching which will cause next read to read actual inputs and not latched values.

Current MAME behavior (again, as I understand it) is:

1b) If input latching is set, always read the latched value.
Note this happens even if no positive transition on CA1/CB1 has happened yet, so I think the latch might not be properly
initialized.

2b) Works same as 2a)

3a) As long as latching is enabled, reading a port will return the latched value.
Clearing IFR flags for CA1/CB1 has no effect on latching. This means if a read/write is performed in mode 000 and 010,
which clears IFR bits, next read will still return the latched value.
This contrasts with Figure 2 Read C, D in http://archive.6502.org/datasheets/synertek_sy6522.pdf.

[mzattera]

I created a Pull request for this: mamedev/mame#10878

[cuavas]

There are various issues with the VIA emulation at the moment. However, there are multiple things that make fixing it difficult:

• There are errors in the earlier versions of the datasheets.
• There may be code elsewhere in MAME that depends on incorrect behaviour that ends up needing to be updated when the VIA itself is fixed.
• There actually are a couple of differences in behaviour of the Synertek version of the chip which correct issues in the MOS and Rockwell versions. However, I don’t know of any systems that actually depend on the bad behaviour of the older versions.
• The VIA code in MAME is fairly old and ugly, and has just been hacked to fix pressing issues.

I started rewriting it at one point, but I broke its interactions with other systems in MAME, and I never managed to finish the rewrite. Some of the fixes from that rewrite did make it in to master, and @galibert has fixed some issues that it had as well.

It would be great to have more of the bugs fixed. I’m just warning you that you’re walking into a minefield.