CX16 terminal program initial start

[Xiphod]

Since I'm interested in doing some kind of TX/RX IO on an older (1975) system that I have, I've started looking into how to maybe implement a bit-bang RS232 for the CX16.

I'm familiar with the old UP9600 code for the Commodore 64. But that does things like:
lda $dd01 ; check CTS line from RS232 interface
sta $dc0c ; send startbit (=0) and the first 7 databits

Not sure if any of that is still supported here.

Can't we use the CX16 IEC? That's the 6-pin DIN on the back, or is that gone now?


While studying up on all that, meanwhile I have this initial demo of the user interface of my VTERM:
https://www.youtube.com/watch?v=7e6OXFqQuKI

Nothing super fancy yet, just still learning and testing with the r42 X16 emulator.

My main goals are just:
- basic BBS/telnet connection (via WiModem232)
- 2400 or even 1200 baud is fine
- feature to use the terminal to upload content from a modern PC straight into CX16 memory (the original early 1980s terminal program had features like this, to upload machine code straight to a user specified address)


A subsequent update would then add features like:
- scroll back
- log to file
- VT100/ANSI
- xmodem or similar

[Edmond D]

Since I'm interested in doing some kind of TX/RX IO on an older (1975) system that I have, I've started looking into how to maybe implement a bit-bang RS232 for the CX16.

<Snip>

Can't we use the CX16 IEC? That's the 6-pin DIN on the back, or is that gone now?

<Snip>

- feature to use the terminal to upload content from a modern PC straight into CX16 memory (the original early 1980s terminal program had features like this, to upload machine code straight to a user specified address)

<Snip>

I'm also interested in a true RS232 interface on the CX16. The specs (https://cx16forum.github.io/faq.html) says the IEC port is available, but that's not the port to use. There is an user port that will have some lines from one of the VIA chips that may be something to build upon. There also 4 user slots which is another avenue. There has been a lot of chat on serial ports here in the past, (re) visiting these threads would be useful.

Like you, I'm not looking for 56 Kbaud rates with multiple ports, or an Ethernet networking solution. Simple and well implemented solid true full RS232 is my target.

I do like the idea of uploading files directly to RAM. My effort might be to use the S19 format, since I'm a Motorola 68HC11 fan and that's what I already know. Research will have to be done based on looking at what the assemblers put out in terms of file formats- but that's another day.

I'll await till I have a shipping X16 box on my desk before I really start. That might take some time, but each day I hope is one day less one to wait.

[BruceRMcF]

Since I'm interested in doing some kind of TX/RX IO on an older (1975) system that I have, I've started looking into how to maybe implement a bit-bang RS232 for the CX16.

I'm familiar with the old UP9600 code for the Commodore 64. But that does things like:
lda $dd01 ; check CTS line from RS232 interface
sta $dc0c ; send startbit (=0) and the first 7 databits

Not sure if any of that is still supported here.

Can't we use the CX16 IEC? That's the 6-pin DIN on the back, or is that gone now?

According to the docs, in a board without the User Port, there is a pin header that brings out the unused pins on VIA#1, J4:

Desc Pin  Pin Desc
 CA1  1 [] 2  CA2
 PB0  3 [] 4  PB1
 PB2  5 [] 6  CB2

With the 65C02, you would be using TRB and TSB operations on the output pin, so the TX pin choice is arbitrary. With "BIT #n", is possible to read the status of any input pin, "LDA VIA1PortB : BIT #RXPin". However, that places the result in the Z flag, and it is more convenient for storing the bit to have the result in the C flag. Therefore, it is preferable to be able to perform:

        LDA VIA1PortB
        LSR

... so the status of PB0 is in the Carry flag in the same six clocks.

So I would propose RX as PB0 and TX as PB1.

Then PB2 can be set as an input pin for optional hardware flow control CTS, and CB2 can be used as an output (via the VIA register PCR, where the top bits %110 output a %0 on CB2 and %111 output a %1 on CB2) for optional hardware flow control RTS. In effect, setting the top two bits of the PCR register high means that TSB and TRB on bit5 in PCR can be used as the fourth GPIO that is needed for RS232C with full hardware flow control:

J4.3 = RX
J4.4 = TX
J4.5 = CTS
J4.6 = RTS

For a CMOS +5v UART connection that should suffice, so a USB to CMOS UART cable could plug straight into a small adapter with a 4pin SIL on one side and six pin block header on the other.

For a TTL UART connection, that probably will work, but if it proves to be flaky, any HCT family OR or AND gate will convert TTL inputs to CMOS inputs -- for instance, 74HCT08. Since J4 does not include +5V and GND, that has to be sourced from another jumper ... perhaps pins 2 (+5v) and 6 (GND) of the Controller #3 & #4 jumper.

For a CMOS +3.3V UART connection (not +5V tolerant), the inputs are the same situation as a TTL intput ... if it proves to be flaky, an HCT gate will convert TTL level intputs to CMOS +5v level inputs. In addition, if the other side is not +5v tolerant, a few resisters for voltage dividers would be needed for the two output lines.

For genuine RS232C, there are a number of TTL to RS-232 adapters available with a 9-pin RS232C port and a pin header for the TTL side, using a MAX232C chip, so given a TTL UART connection and +5v/GND, the RS232C can be provided.

[Xiphod]

How compatible will the user-port that is relocated onto the expansion cards be with legacy C64 or PET software (e.g. code that used the user-port for the SNES gamepad, or a CBM WiModem)?

I suspect some slight adjustment is needed, if just to handle the case of a user having multiple user-port cards?

>> So I would propose RX as PB0 and TX as PB1.

Ok, and a ground? The thing about a plastic case: where's the ground? We'll find it somewhere.

I had a video using the old Tandy Color Computer with just 3-wires (TX/RX/GND) to bit bang:
https://www.youtube.com/watch?v=iD3fVowBuMk

Even the CoCo3 struggled past 1200 baud with the "raw" onboard serial IO (a couple terminals managed 2400).

The RS232 Pak on that system (using a 6551) got up to 19200 baud (with the newer more optimized assembly).

In either case, AT&C0 was issued on the modem to disable the need for RTS/CTS.

Well, on the CoCo's, the serial IO pins ranged from -12V to +12V to indicate the bit transitions. How do we deal with that to remain compatible with the bulk of existing modems (or WiModem emulators)?

[TomXP411]

Based on my testing with the WDC dev board, you do NOT want to use the User port for serial I/O.

You can use it to drive an Arduino, which works fine, but you have to use it as a parallel port to make that work effectively. In fact, I can drive an Arduino Mega at about 30KBps that way, which works out to 300Kbps on the Arduino's serial port.

However, that's not the most cost effective method. We might be able to use that in combination with an ESP32 for networking and serial I/O, but it's kind of wasteful, when there are two different UARTs that could be used: the 65C51 or a 16550 (the most popular UART for PCs, back in the 90s.)

The W65C51N uses 4 addresses (data, status, command, control), so you can fit several in a single 32-byte I/O block.

My thinking is to build a card with room for up to 4 W65C51N chips, with each hooked up to an 8 pin header that can be used for different purposes:

• ESP32: The first chip would be connected to an ESP32 for networking purposes. File transfers using https, plus telnet and raw TCP and UDP should all be available and easy to use
• RS-232: using an external level shifter, you can provide a DTE or DCE device for connecting to a modem or host system, or to a PC.
• MIDI: by using a different level shifter, you can enable MIDI communication to musical instruments or lighting consoles
• TTL: connect directly to a USB UART for transferring data to a PC.

I'm thinking if we had room for 2-4 UARTs, plus an ESP32, people could use them however they wanted. It would just be a matter of accessing a specific set of addresses for each COM device.

[Xiphod]

At cbmstuff.com they offer two versions of the WiModem: a CBM user port version (blue header) and an RS232 version (24-pin D-shell that's been around since early 1970s, easily adapted to the more modern 9-pin serial).

The CBM user port version works on the Commodore PET (up to 2400 baud with PETTERM40x.PRG), and on the C64 (up to 9600 baud). This is just info - while it would be nice for the CX16 to still support stuff like this, it's been emphasized that it is not intended as any kind of "C64 clone".


The reason for these limited baud rate speeds is because at ~1MHz, the terminal program has to do things like translate VT100, ANSI and handling screen scrolling on its own. The more efficiently the code can do those things, then higher baud rates could be supported (or, of course, running that code at a higher clock rate -- which the modern Arduino and ESP32's do, resulting in 500K+ baud rates). In 1980, COMPAC software could do 19200 baud on the CoCo1 if the only job of the terminal software was to stream bytes into memory (but the onboard Serial IO stuff needed some PIA hardware, that IIRC handled the task of accumulating serial bits into full bytes).

A UART helps a lot in buffering up send/receive bytes in parallel (to the CPU doing things like rendering ANSI codes) - but "bit banging" is a "minimalist approach."

I still use a classic serial port to control the motors on my telescope. I suspect some folks still use a serial to control plotters or 3D printers.