"standard" I/O compatibility

Hiraghm

Member
May 18, 2019
35
8
8
One of the things I do whenever I get a new vintage computer, or get one working, is get it onto my network.
Doesn't matter; even my Psion handheld, I gotta get it on my network before I'm satisfied.
Some of this is to facilitate transferring data. Some is just bloody-mindedness...

I think it would be important for the CX16 to support either USB (even 1.1) or ethernet. Or at the *very* least, standard RS232.
I don't think this has to be onboard; it would probably be best implemented as an add-on card. That way you can keep the price on the motherboard down.
Such an ethernet card I wouldn't expect to be able to go past 10mbs, and USB would be more versatile to have, anyway.

I don't know if 8-bit ISA compatibility with the expansion ports would be possible, but with the NuXT and other retro PC projects, it might be a good idea (if possible).
Maybe make it like the Amiga's ISA compatibility. Or, maybe an expansion chasis with an adapter in a CX16 slot cabled to an external ISA expansion box.

Just throwing some ideas out there that I've had in a few spare moments.
 

Dale Mahalko

Member
Jul 25, 2019
52
9
8
While I recognize USB and Ethernet are very common modern interfaces, the bus controller is probably as complicated as an entire 6502 computer or more.

It may be best to just target a few modern standards used on Arduino and Raspberry Pi, such as I2C, which supports up to 5 MBit/sec with at least the 2012 version..



The parallel address / data bus of the Pi is such a wasteland of crappy device implementations, with shields that are locked to specific address lines for no apparent reason except that the shield designer didn't want the expense of an extra chip to allow user-defined address selection.
 

Hiraghm

Member
May 18, 2019
35
8
8
While I recognize USB and Ethernet are very common modern interfaces, the bus controller is probably as complicated as an entire 6502 computer or more.

It may be best to just target a few modern standards used on Arduino and Raspberry Pi, such as I2C, which supports up to 5 MBit/sec with at least the 2012 version..



The parallel address / data bus of the Pi is such a wasteland of crappy device implementations, with shields that are locked to specific address lines for no apparent reason except that the shield designer didn't want the expense of an extra chip to allow user-defined address selection.
What about RS232?
 

GregZone

Member
Sep 29, 2019
32
20
8
What about RS232?
Yeah, I think if you wanted to connect the CX16 to the "outside world" your best bet would probably be via UART.

Either good ol'e TTL levels (which you could connect to another modern computer via a USB -> TTL Serial adapter).

Or, you go to old-school RS232 levels via a MAX232 chip (or similar).

:)
 

LRFLEW

New Member
Sep 23, 2019
17
4
3
the CX16 to support ... ethernet
I don't think this is such a great idea. It would have to use an expansion card to act as a buffer, but there are just too many challenges to it.

First off, it just isn't going to be able to get much bandwidth through. Assuming data can be read similarly to how it's done with the Vera, then the theoretical fastest the CPU could read data into (non-zp) RAM is 1MBps (4 clock cycles for the read, 4 clock cycles for the write). With overhead, you would be lucky to get even half of that, though. That means even a measly 10Base-T could saturate the device. Having too fast of a connection isn't a problem for the integrity of the connection, but it does mean that there needs to be a buffer for incoming/outgoing data, as the CPU cannot do it itself.

Secondly, while a simple Ethernet card could be enough to get data from the internet, it wouldn't be practical for getting data off of the modern internet. Most of the internet traffic now is encrypted, mostly using TLS, so if the goal would be to get it to work with modern internet services (even just downloading programs from websites), then TLS support seems mandatory to me. The data-rate for a simple copy is slow already, and adding encryption on an 8-bit 8MHz CPU would be incredibly slow. I'm tempted to try implementing AES just to see how slow it would be, but implementing RSA, ECDHE, and ECDSA required for TLS support would be horrible. This means for it to be practical, an Ethernet expansion card would need to be able to perform these computations on its own.

Both of these increases the complexity of the expansion card beyond the realm of practicality. At that point, you're better off just doing the internet things on your main computer and transferring things to the X16 via an SD Card.
 

codewar65

New Member
Sep 25, 2019
26
13
3
I don't think this is such a great idea. It would have to use an expansion card to act as a buffer, but there are just too many challenges to it.

First off, it just isn't going to be able to get much bandwidth through. Assuming data can be read similarly to how it's done with the Vera, then the theoretical fastest the CPU could read data into (non-zp) RAM is 1MBps (4 clock cycles for the read, 4 clock cycles for the write). With overhead, you would be lucky to get even half of that, though. That means even a measly 10Base-T could saturate the device. Having too fast of a connection isn't a problem for the integrity of the connection, but it does mean that there needs to be a buffer for incoming/outgoing data, as the CPU cannot do it itself.

Secondly, while a simple Ethernet card could be enough to get data from the internet, it wouldn't be practical for getting data off of the modern internet. Most of the internet traffic now is encrypted, mostly using TLS, so if the goal would be to get it to work with modern internet services (even just downloading programs from websites), then TLS support seems mandatory to me. The data-rate for a simple copy is slow already, and adding encryption on an 8-bit 8MHz CPU would be incredibly slow. I'm tempted to try implementing AES just to see how slow it would be, but implementing RSA, ECDHE, and ECDSA required for TLS support would be horrible. This means for it to be practical, an Ethernet expansion card would need to be able to perform these computations on its own.

Both of these increases the complexity of the expansion card beyond the realm of practicality. At that point, you're better off just doing the internet things on your main computer and transferring things to the X16 via an SD Card.
There are existing ethernet modem cards for c64 now.

The only socket connection I am interested in with the X16 would probably be irc, telnet, ftp, gopher, etc. http / https is SO bloaded these days, it would slag any 8 bit machine.
 

BruceMcF

Active Member
May 19, 2019
139
42
28
Pretty sure it (1) will have a UART (implemented in the Vera video chip) and a serial port, (2) will not have ethernet but there will be a commonly used UART to ethernet bridge and (3) will definitely not have native USB support on the CX16 board.

Confidence about (1) is based on the fact that when the design team found out that the WDC ACIA that they had planned to use was buggy, they relented and allowed the Vera feature set to be expanded to include a UART (512byte FIFO input buffer, single byte output). If they were not determined to have a UART, I reckon they would have balked at expanding the Vera feature set in that way.
 
May 22, 2019
486
250
43
The team has firmly rejected a built-in Ethernet option. It will not be happening.

There WILL be an RS-232 UART, as Bruce has explained, and this can be connected to a terminal server (ie: Network or WiFi "modem") for network access. With an ESP8266 or ESP32 based device and NodeMCU, you can have full access to standard network services.

While most people may opt for the simpler "AT" command set, I'm encouraging developers to look at natively supporting NodeMCU, since it's much more powerful.
 

BruceMcF

Active Member
May 19, 2019
139
42
28
There are existing ethernet modem cards for c64 now.

The only socket connection I am interested in with the X16 would probably be irc, telnet, ftp, gopher, etc. http / https is SO bloaded these days, it would slag any 8 bit machine.
http would not be for modern web pages, but more for old school html .... text & links in paragraphs and dot point lists, and actually meaningful ALT text for any IMG tags used.
 
  • Like
Reactions: codewar65

mchobby

New Member
Oct 13, 2019
13
1
3
About Ethernet on X16
I would like to share my own experiment with Arduino and MicroPython with WizNet5500 modules wich are already dealing with the complex part of TCP stack.
They are available for Arduino ( https://www.adafruit.com/product/2971 ) or Feather (Adruino alike, still W5500 module ( https://www.adafruit.com/product/3201 ). I had also tested it with MicroPython ( https://github.com/mchobby/pyboard-driver/blob/master/eth/readme_ENG.md ).
This module uses a SPI bus and runs on very low ressource systems (and Arduino does have 2K of RAM) with Open-Source driver.
So I this this would also be a interesting for retro-compuling...

This is call for a conclusion to me: X16 should expose a SPI bus and and I2C bus.

Both are commonly supported and would allow a huge kind of applications with the X16 including internet connectivity (via SPI)!
The I2C bus would allow to connect LOOOOOOOOOooooootttttt of sensors to a X16. Do not hesitate to check the QWIIC product line to have a rough idea of the possibilities (QWIIC is simply connector carrying I2C bus @ 3.3V)
I already ported the WII Nunchuck driver (it is an I2C peripheral) from Arduino to MicroPython ( https://github.com/mchobby/esp8266-upy/tree/master/modwii ), it would be very fun to support it on X16.
I can even suggest a great connector for that: the UEXT connector, a open-source standard supported by Olimex Ltd. Really cool for plug and play operation.

Native SPI/I2C or through VERA board?
I think that the best approach would be to access the SPI and I2C directly from X16. I2C and SPI buses can even been emulated (Bit Banging).
Overcomplicating the vera would not be a good idea (I guess).

Cheers
 

BruceMcF

Active Member
May 19, 2019
139
42
28
As far as bit-banging SPI, AFAIU, the User Port still has around 14 GPIO from the VIA chips, which is ample pins for bit-banging a four wire bus with multiple additional selects.

For a hardware SPI, the Vera already has an SPI port to talk to the internal SD card. It has one select and locked at 12.5MHz SCLK (1/2 external clock, I'm guessing 1/4 internal clock). Adding two select lines. two mode-select bits & a four bit countdown register to control the SCLK speed could fit into a single register location ... at VIA toggle SCLK at underflow and the countdown running at external 25MHz Vera clock speed, "1" is 12.5 MHz, "2" is 8.3333MHz (system clock), "3" is 6.25MHz (supporting max 8MHz devices), 7 is 3.57MHz (supporting max 4MHz devices) and 13 is 1.92MHz (supporting max 2MHz devices).
 
May 22, 2019
486
250
43
And don't forget the lines that were being used by the LCD. Those might get repurposed, but I'd love to think those could also be used for SPI or as GPIO.
 
  • Like
Reactions: BruceMcF

BruceMcF

Active Member
May 19, 2019
139
42
28
And don't forget the lines that were being used by the LCD. Those might get repurposed, but I'd love to think those could also be used for SPI or as GPIO.
At 8MHz, I'm not fussed about bit-banging SPI, and if you are willing to bit bang SPI, then any 4+ GPIO is SPI.

Was the LCD controller connected to a VIA, or was it connected directly to the bus? If it was memory mapped I/O on the bus, freeing up space in the I/O page doesn't automatically release GPIO. But as long as an complete VIA Port is on the User Port, 8 GPIO is 3 lines for the SPI bus and 5 select lines, which should be "enough".
 
Last edited:

mchobby

New Member
Oct 13, 2019
13
1
3
And don't forget the lines that were being used by the LCD. Those might get repurposed, but I'd love to think those could also be used for SPI or as GPIO.
Don't forget the I2C. The LCD could even be wired to the I2C socket (via I2C backpack for LCD), so reuse the 2 lines (SDA,SCL) of the existing I2C output created on the X16 (instead of many lines for direct LCD wiring). As we can connect several sensors on a single I2C bus, it is a Win-Win solution.
 
May 22, 2019
486
250
43
Was the LCD controller connected to a VIA, or was it connected directly to the bus? If it was memory mapped I/O on the bus, freeing up space in the I/O page doesn't automatically release GPIO. But as long as an complete VIA Port is on the User Port, 8 GPIO is 3 lines for the SPI bus and 5 select lines, which should be "enough".
Those character LCDs use (I think) a 2 or 4 bit SPI interface. David did a video on those a while back when he created an interface board to connect one to his C64.
 
  • Like
Reactions: BruceMcF

BruceMcF

Active Member
May 19, 2019
139
42
28
Those character LCDs use (I think) a 2 or 4 bit SPI interface. David did a video on those a while back when he created an interface board to connect one to his C64.
If is is SPI, it could be that the most recent discussion of how much GPIO is available is in light of not having the LCD in the final board. 2-wire or 3-wire output-only mode 3 SPI would be very easy using the VIA serial shift register, but it would convert one Port B line to SCLK, and one GPIO from either port to /Select if it was 3 wire output only.

One of the team members mentioned that one of the two serial shift registers was in use and the other free at that time, which IIRC was after it was mentioned that the LCD panel was not part of the final motherboard design ... so that serial shift register slated as not being in use might be hooked up to the LCD panel in the early prototype board.

Don't forget the I2C. The LCD could even be wired to the I2C socket (via I2C backpack for LCD), so reuse the 2 lines (SDA,SCL) of the existing I2C output created on the X16 (instead of many lines for direct LCD wiring). As we can connect several sensors on a single I2C bus, it is a Win-Win solution.
I'm not 100% sure I'm following this ... what existing I2C output?
 
Last edited:

easyprototype

New Member
Sep 21, 2019
10
2
3
Canada
Unless one of the dev team guy specifically stated that the LCD is hooked on a serial port (SPI/I2C/whatever), it is most certainly not. Looking at the "part 2" video, the LCD is very far away from any of the peripheral ICs. Those 16 pins LCD are meant to be hooked directly on the data bus and have been around for at least 30 years. Reading/writing them on a 8-bit bus is the same as accessing SRAM. Accessing the LCD through a serial interface when you can access it directly from the data bus doesn't make sense.

All LCDs with a SPI/I2C bus are parallel-access LCDs with a parallel to serial interface added.

NXP makes a SPI chip with a 8-bit bus interface but is is becoming obsolete. There is no SPI chip for the 6500 ecosystem since SPI interface didn't exist back in the days. You can emulate one by software but we don't want that. Commodore software-emulated serial buses before on their cheapest machines and they ended-up making them slow as hell and unreliable.

Steckswein (https://steckschwein.de/hardware/via-65c22-as-spi-master/) are currently fudging a SPI with a 65C22 but they have problem with it. If it ends up working, we could have a semi-hardware, full 65xx SPI port with tons of chip select. After that adding I2C is easy as there is a lot SPI to I2C chips compared to almost no parallel to I2C chips :(.
 
  • Like
Reactions: BruceMcF

BruceMcF

Active Member
May 19, 2019
139
42
28
Steckswein (https://steckschwein.de/hardware/via-65c22-as-spi-master/) are currently fudging a SPI with a 65C22 but they have problem with it. If it ends up working, we could have a semi-hardware, full 65xx SPI port with tons of chip select. After that adding I2C is easy as there is a lot SPI to I2C chips compared to almost no parallel to I2C chips :(.
I was reading that with interest, as that approach would seem to line up with the User port resources ... if there is a complete Port A plus part of Port B including the countdown clock output pin, that would be the same except fewer chip select ... but if there's a Port A to talk to the external shift register, the VIA serial line, SCLK, the external shift register select pins and two additional pins, then the same User Port board that carries the shift register could also have a 2 to 4 decoder to have a three chip selects and a NC state.

But SPI is something that a CPLD can do, so an expansion board that is providing some SPI devices could probably include those plus a hobbyist external SPI bus at the same time, just using the CPLD.
 

easyprototype

New Member
Sep 21, 2019
10
2
3
Canada
But SPI is something that a CPLD can do, so an expansion board that is providing some SPI devices could probably include those plus a hobbyist external SPI bus at the same time, just using the CPLD.
A CPLD/FPGA can do everything. We can even fit the entire X16, whatever it will be, into a single FPGA. What I don't like is that CPLD and FPGA come and go faster than even the most short-lived X86 processor. Case in point: "Let's use the Gameduino" said the 8-bit guy. "Damn, its FPGA is already obsolete!"

Using a FPGA to build a VGA video card is inevitable. For the rest, I would rather use discrete components and a serie of IC that has been in production for 40 years. Such a design can be maintained and upgraded, especially if the board is modular and we have full access to the address/data bus.

But honestly the design team is located on Facebook, not in these forums. I'm not sure our suggestions even reach them.

Me, I just hope for full bus access. Then verything becomes possible.
 

picosecond

New Member
Sep 27, 2019
11
3
3
Northeast U.S.
What I don't like is that CPLD and FPGA come and go faster than even the most short-lived X86 processor. Case in point: "Let's use the Gameduino" said the 8-bit guy. "Damn, its FPGA is already obsolete!"
That's quite an exaggeration. The FPGA used in Gameduino was introduced in Q1 2007. And while Xilinx are not exactly encouraging its use in new designs, it is still in production. The last time I checked its EOL has not been announced. The XC3S200A is definitely long in the tooth but calling it obsolete is a stretch.

That being said, porting the design to Spartan-6 would have made lots of sense. You get a lot more chip for similar cost. That family will remain in production until at least 2027.
 
  • Like
Reactions: OzWizard