#1206 C64 userport RS232 CTS the wrong way around

[Andre Fachat]

I am trying to use the RS232 interface for communication, and found that compared to the real C64 I had to reverse the polarity when reading the RTS signal on userport (CIA2 PB) bit 6

In the C64 ROM, from EF01 you see that the CIA port bit needs to be 1 to allow to send a byte (BVC CTSERR).
My code indeed works this way with the real hardware, but in VICE I have to change the code to BVS CTSERR.

[gpz]

Are you sure the interface you are using is correctly inverting the line? And how exactly are you using the rs232 emulation?

We did a lot of testing with userport rs232 before 3.4 release (when we fixed it for tcpser), i'd be surprised if such bug still existed.

[Andre Fachat]

The question is, is inverting the lines the right thing to do? I actually see different solutions, some that invert, and others that don't. E.g. GGLABS does it here https://gglabs.us/sites/gglabs.us/files/glink-lt.pdf while the (probably older?) https://www.c64-wiki.com/wiki/RS-232 does not.
That is why I looked at the kernel's userport RS232 implementation, that in (sorry I mistyped above) EF0C clearly says "BVC ctserr" according to https://www.pagetable.com/c64disasm/#EF0C

[Andre Fachat]

btw I'm using "x64sc -rsuser -rsuserdev 2 -rsdev3 "|socat - PTY,link=/tmp/viceser" -rsdev3baud 9600 -autostart osa.d64" and then connecting to the resulting PTY device under /tmp/viceser with minicom

[gpz]

"The question is, is inverting the lines the right thing to do?"
yes, an interface that works with the terminal programs from the good old times must invert the handshake lines. without it it will only work with a handful programs which are either specific to a certain interface, or which has an option for the polarity of the handshake lines. (my testcases for this have been CCGMS, Novaterm and C*Base BBS)

that said, i am not sure if the handshake lines are emulated at all when using piping to an external program like you do - never used it :)

[Andre Fachat]

But so the interfaces that invert the handshake lines do not work with Commodore BASIC in X-line mode. As Commodore BASIC does not expect this, right?
Maybe a new VICE setting for the inversion of this lines would be in order here?
Knowing this I will have to make my software aware of different types of interfaces anyway though.

[gpz]

mmmh my interface worked with basic ... but no idea if i used handshake =)

it would be good if you could try with tcpser - as this is known working (and i consider everything else broken, because noone used or tested it for two decades at least)

but indeed, such option is probably a good idea in any case

[gpz]

btw, here is what we collected while working on it: https://vice-emu.pokefinder.org/index.php/RS232

[Andre Fachat]

I finally found that my RS232 interface was completely broken (I bought one off of the fleabay because I couldn't find mine and was too lazy to build a new one ... bummer, had to completely resolder the handshake lines, they were all input/output reversed...). So my software now works with VICE and my real C64 setup.

[Greg King]

But so, the interfaces that invert the handshake lines do not work with Commodore BASIC in X-line mode? As Commodore BASIC does not expect this, right?

No, it's the adapters that do invert the handshake lines that work with Kernal's standard RS-232 driver. The Glink-lt adapter is right; the C64-wiki is wrong. (Magnify the Glink schematic a few times, then look at the names of the lines that go in/out of the Max232 chips. You'll see a bar over those names. Those chips use inverted lines; the adapter "reverts" them for the user port. A one bit means "active"; a zero bit means "inactive".)

[gpz]

i moved the shiftregister stuff to a new ticket -> #1219

closing this one