#1870 VIA PORT LATCHING is wrong.

[Zibri]

on vice, if I do:

ldy #$00
loop:
CLV
bvc * lda #$1c0f
sta ($xx),y
iny
bne loop

I get 256 bytes of raw data.
That is wrong.
On real hardware you will get always the same byte (the last one read from 1C01.
UNLESS, you put $00 or $10 in $1C0B
putting 0 in bit#0 of 1C0B disables latching.. so 1C0F will reflect in real time the read byte coming from the external shift register.

adding LDA #$2
STA $1C0B
before the above code, makes it work on real hardware,
on vice, 1c0b is just ignored. (apparently)

[gpz]

try defining MYVIA_NEED_LATCHING at the top of viacore.c and see if that makes it work... fixing this properly would require proper testcases (which is why this is not enabled by default)

[Olaf Seibert]

See also bug #1828.

It would be nice if you could contribute a test program that shows precisely how the latching works.

Current assumptions:
- when CA1 has an active transition, and if latching is enabled, the latch gets the value input to port A.
- When port A is read from the normal, with-handshake port, you get the latched value IF latching is enabled, and the CA1 interrupt flag was still active. Reading from the port clears the CA1 interrupt flag.

What is unclear so far:
- When latching is enabled, what value will the latch be? If the CA1 interrupt flag is already active, does the latch get the value from the port's input at that time, or not? It would make sense if the latch always gets a value on an active CA1 transition; its value may just get ignored. But this is not what the current code seems to do. So we would need proof.
- If the CA1 flag is not active at that time, it probably doesn't matter, since the latched value won't be used anyway, until the CA1 flags is set, at which time the latch will get its value.

[Zibri]

when latching is enabled (the default) 1C01 and 1C0F contain the first received byte after the last READ of 1C01.
also:
with latching enabled, reading 1C0F gets you the same byte in $1C01 but it won't trigger the unlatching.

with latching disabled, both addresses will give you the last received byte, no matter if you read it or not.

An example:
with LATCHING on:
I read 1c01 and get a byte...
then I distract for a few minutes(!)
and read again 1c01.
I will get the byte AFTER the one read one minute ago.
if I read again 1C01 I will get the actual last read byte.
if instead I read 1c0f I will always read the byte following the one of a minute ago... and that will happen until I read $1c01 again.

with latching off:
I read 1c01 or 1c0f and get distracted for a month (!)
I read 1c01 or 1c0f again, and I get the last fully read byte.

[Zibri]

the latching mechanism is simple and bits #0 and #1 enable or disabe latching in both port A and B
Reference: pages 5 and 8 of 6522 datasheet:
https://www.princeton.edu/~mae412/HANDOUTS/Datasheets/6522.pdf

[gpz]

Do you really think we dont already know what the datasheets say? And that they dont contain all the details, when they are not even plain wrong?

[Zibri]

what I reported is the behaviour I see on a 1541 and 1541 II.
that's all.
and vice does not match that behaviour.

[Zibri]

oh.. I forgot! THAT APPPLIES also to $180C and $1801/$180F!
(it's the same chip!)

[Olaf Seibert]

I looked at the reverse-engineered schematics at http://forum.6502.org/viewtopic.php?f=4&t=7241#p93984 and http://forum.6502.org/viewtopic.php?f=4&t=7241#p93979 . I'd say that the ACR0 and IFR1 bits are handled the same (they are used for the clock input of the transparent latch - top right of the schematic). So the latch is only "latching" once the second of those values changes to the required value. So enabling latching before the CA1 flag is set, does nothing.

So I tried to model that in the code; it has a separate latch variable, because input isn't pushed into the VIA, but it's pulled when needed. So the model differs a bit from the real thing, though the effect should be the same, I hope.

Can you try the attached preliminary patch and see if it matches the hardware? Still with MYVIA_NEED_LATCHING #defined of course.

[Zibri]

Erata corrige to the OP:

ldy #$00
loop:
CLV
bvc * 
lda #$1c0f
sta ($xx),y
iny
bne loop

I get 256 bytes of raw data.
That is wrong.
On real hardware you will get always the same byte (the last one read from 1C01.
UNLESS, you put $X0 in $1C0B
putting 0 in bit#0 of 1C0B disables 1C01 latching.. so 1C0F will reflect in real time the read byte coming from the external shift register.

adding

LDA #$40
STA $1C0B

before the above code, makes it work on real hardware,
on vice, 1c0b is just ignored. (apparently)

[Zibri]

Another note:
The above is true on RH, but 1C01 contents are different (shifted) depending on the VIA CHIP revision. I am still investigating the details making extensive tests on real hardware.