Commander X16

On 9/21/2022 at 12:28 PM, Wavicle said:

Kevin posted an update to Facebook on the topic of 6522s and user port: Commander X16™ Prototype | Facebook

The most encouraging part of that post was the statement that this was not finalized, so hope still springs (for the moment, if not springing eternal) that the SNES Latch and SNES Clock outputs might be able to get swung around to PortB.

I can't use the pulse PA2 mode for SPI if there is an interrupt and the system toggle the SNES Latch and then starts banging on the SNES SCLK, all the while my SPI Select is still sitting low and my SPI SCLK is reacting to each write of PortA. Now, the Kernel could work around that by using the BASE+$0F register address that does PortA writes without triggering handshake, but I would rather avoid problems over editing the Kernel to work around them.

On Facebook, Kevin has proposed a "VIC-20 style" user ports, where effective use of many of the pins would require disabling the SNES Controller and the IEC port.

Some on Facebook have objected to this approach. They don't want the lines used by the system on the User Port. I am not in one or the other camp on this, but I do have a lot of sympathy for this position.

I have argued for my swap around that puts the NESDATA lines on PortB4-7, has four free GPIO on PortB0-3, and uses the CA2 handshake line as the NESLATCH output.

With the news of an official VIA Expansion User Port, I would grudgingly accept a small Motherboard Baseline user port of [PortX0-2 + CA1] or [PortX0-3] + [CB1 & CB2[ + VCC + GND., on either a single or double row pin block header.

it seems reasonable from a programmer perspective to have all the via lines dedicated to user port to originate frome the same side.of the via

On 9/24/2022 at 10:59 AM, Fabio said:

it seems reasonable from a programmer perspective to have all the via lines dedicated to user port to originate frome the same side.of the via

Yeah, I didn't think that through.

PA0=I2CDAT / PA1=I2CCLK / PA2=NESLATCH / PA3=NESCLK / PA4=NESDAT3 / PA5=NESDAT2 / PA6=NESDAT1 / PA7=NASDAT0

PB0=User / PB1=User / PB2=User / PB3=SERATO / PB4=SERCLKO / PB5=SERDATO / PB6=SERCLKI / PB7=SERDATI

CA1=User / CA2=User / CB1=User / CB2=User

An FTD TTL-Serial to USB cable ($6-$10) has a 6 SIL that is GND / CTS / +5V / TXD / RXD / RTS so if CTS is on the output-only CA1 and RTS is on the edge detect input CA2, the User Port pin header might be (TTT is a clippable pin allowing a keyed 2x6 block header with the keyed pin filled):

• 
  GND / TTT
  


• 
  CA1 / CB1
  


• 
  +5V / CB2
  


• 
  PB0 / +5V
  


• 
  PB1 / PB2
  


• 
  CA2 / GND
  

 





 

OK, so this approach can be summarized, "I2C bus and NES controllers on Port A, User Port and IEC lines on PortB, and all the handshake lines on the User Port". I really prefer putting the I2C bus on Port A, swapping the IEC to Port A, keep NESLatch and NESClk on Port A, using CA1 for NESLatch, but swapping NESDat to PB4-PB7 ...

... which would allow a "clean" borrowing of NES lines for Controller 3 and 4, which on many systems are not going to be in use.

However, that would require buy in from Micheal Steil, because the Kernel would have to be reassembled with the new locations of things.

It is simplest to place the I2CDATA/I2CCLK where PS2KDAT/PS2KCLK used to be, free up what used to be PS2MDAT/PS2MCLK and the single I2CDAT GPIO when the SSR was used for I2CCLK, setting up PB0-PB2 as the User Port GPIO User0-2, and having the use of CA2 as a fourth line that is output-only.

An advantage of this is that whether or not the system is going to drive any IEC lines is under software control after the autoboot has completed -- that is the Kernel doing something because you called the Kernel and asked it to do something, If you don't want it to happen, leave it be. So in addition to using CB1/CB2 as the serial port, there is the option of setting it up in write handshake mode, as long as you remember to turn write handshake mode off (or deselect the thing that is listening to the CB2 write handshake mode) when you are done.

Over on Facebook I sketched out some things that could be done with the User Port even without a VIA#2 expansion board. But things in FB discussions are often eventually lost in the mists of time, so I thought it best to copy them over here for something closer to safe keeping.

First is bit banged serial. C64 bit banged serial is 1200baud, and if it weren't for VIC-II badlines, it would be able to hit 2400baud. So at 8 times the clock rate, then I would suppose certainly 9600bos, maybe 19200 -- especially if using hardware flow control, so you could wrap the VBlank IRQ routine with a "CTS" as not ready, and restore its state on return from the original IRQ routine.

Second, a DB-9 Atari Joystick / Sega Two Button controller port. Using a parallel-in, serial-out (PISO) serial shift register connected to the CB1 and CB2 for its clock and serial output, and User0/User1 to latch the data and to pass through the serial clock, you can have a small board with a right angle DB9 input and a ribbon cable to the User Port to support traditional C64 joysticks. Also, an alternative Sega 6 button controllers could be supported by user User2 or CA2 as the output to the controller to get the rest of the button data (alternative because that design is incompatible with the Atari Joystick design).

Third, 2 or 4 DB9 Atari Joystick / Sega Two Button controller ports. Using a 2-4 decoder and a 4-1 selector you can use 2 GPIO to select PISO0-PISO3 and the third as the active select. I don't have time to go back into the Sega 6 button controller info to see if the Motherboard User Port has enough outputs to handle that as an alternative.

Fourth, an SPI interface for modern geegaws.

Fifth, a ribbon cable to bring the lines out to a breadboard and a set of serial shift registers and encoder/selecter to put 8 or 16 input and/or output lines on a breadboard.

So, as long as the CB1/CB2 lines are available and there are 3GPIO and an additional output, I think that is a User Board that has enough use cases to warrant including.

A couple years ago someone made a joke video about this project, and it showed a breadboard sticking up out of the case. Now you're telling us: this is actually possible, as a daughter board.

It's a little late for design changes here, but if this makes sense to @Michael Steil and @Frank van den Hoef the applications of this little machine expand from teaching programming to also teaching electronics. 

On 9/26/2022 at 1:49 PM, Ed Minchau said:

A couple years ago someone made a joke video about this project, and it showed a breadboard sticking up out of the case. Now you're telling us: this is actually possible, as a daughter board.



It's a little late for design changes here, but if this makes sense to @Michael Steil and @Frank van den Hoef the applications of this little machine expand from teaching programming to also teaching electronics. 

If used for general teaching electronics, I'd suggest that the Expanded User Port from the VIA#2 on an expansion board is a no-brainer ...

... but the thing about including "whatever is available and not otherwise used" on a User Port is that it is a teaser which can give a taste of what can be done without having any additional barrier to entry. If you can plug a $6 USB cable into the User Port pin header and talk to a laptop at 9600 bps bit banged serial, then the experience of doing that is going to sell more VIA#2 expansion boards when people ask around, "can't it go any faster"? "Oh yeah, sure, with a VIA expansion board you can run that serial interface 6 times faster at 56Kbps".



And "whatever is available and not otherwise used" is really what Commodore was doing, after all -- the absence of Serial Shift Register in the VIC-20 User Port and presence of two in the C64 User Port had to do with what was left over when finished using the VIA/CIA for reading keyboard, reading joysticks, and etc.



Note that this evening I did have enough time to look at the SPI_OUT and SPI_IN routines for the pure bit-banged SPI serial, which is about 200kbps in the two-way Out and In routine ... its 230-240 kpbs for just inputting a byte from the SPI bus with a dummy $00 going out, and 290-300 kbps for just outputting a byte to the SPI bus with a dummy $00 received. So the only 14% faster than I2C is while sending a byte of data in both directions, rather than one way ... just pulling data in, it's 38% faster and just putting data out, it's 70% faster.

Now, using the hardware SR and a NAND gate for Mode0 / Mode1 / Mode2, I get about 290kbps either both ways or output only, and 575 kbps input only Mode3 (540bps Mode0). That's with only the C1 pin free for a /Select line, but if talking to a RPi Nano being used as a USB flash drive bridge, 70KB/sec download is a lot better than the 1541 that I started this whole journey with, some 41 years ago.

For the expansion User Port based on the VIA on an expansion port slot:



PortA: MOSI. PortA7 tied to MOSI, PortA0-PortA6, DNC but set up as outputs, so they work as registers.

PortB:

• 
  PortB0-PortB5, /Select0-/Select5
  


• 
  PortB6: "SMASK", this is tied to an AND for Mode0 devices to convert a Mode3 SPI system based on the VIA into a Mode0 SPI bus
  


• 
  PortB7: "/Alert", an input that the SPI device holds low to send a special signal. Note that there are two spare NAND gates in the circuit to implement the Mode0/Mode1/Mode2 support, so if the device raises a line to send a special signal, that can be easily converted to a pull down /Alert.
  

CA2 is put into Pulse Output mode, and acts as SCLK (the Mode3 internal serial clock). The pulse is one full PHI2 cycle wide, so this particular interface is for SPI servant devices that can handle 4MHz or higher SPI clock (that is a fairly common top end speed for medium-fast SPI chips).

CB2 is the serial shift register input, with the SSR configured as driven by CB1.

CB1 is the serial clock input into the serial shift register. It is tied directly to CA2, not to the SPI_SCLK, since the VIA SR is a Mode3-only MISO.

CPOL is a location in the program memory that is $00 if Mode3/Mode2 is desired, set to %01000000 if Mode0/Mode1 is desired. This works as a mask for TSB/TRB operations to pull the SMASK bit up and put it back down, but only if Mode0/Mode1 operation is desired.

SPI_BYTE: ; Output byte in A, Input Byte returns in A, returns CC if /Alert is not sent, CS if Alert is sent

  STA VIA2_PORTA : LDA CPOL : TRB VIA2_PORTB

  ASL VIA2_PORTA : ASL VIA2_PORTA : ASL VIA2_PORTA : ASL VIA2_PORTA

  ASL VIA2_PORTA : ASL VIA2_PORTA : ASL VIA2_PORTA

  LDA CPOL : TRB VIA2_PORTB : LDA VIA2_SR

  BIT VIA2_PORTB : BEQ + : CLC : RTS

+ SEC : RTS

I get about 89 clock cycles (90 is alert is sent), so 89.888KB/sec, 719kbps, 4-5 times faster than the I2C bus.



For something like a MAX3001 SPI UART, this seems like it would be plenty fast to run it at very high serial port baud rates. For something like a Raspberry Pi Pico used as a Flash USB drive loader, it would copy fairly large files into the SD card fairly quickly as well as being a quite reasonable "keyring Disk9" to complement the built in SD card Disk8. And stepping up to a RPi Zero-W makes for a budget WiFi internet modem option.

I am copying my recent post to the Facebook post for safekeeping, since it is so easy to get lost on FB:



Note that a "retro" edge card user port is available simply by having an expansion card with an edge connector. As an expansion card, this doesn't have to be built right away, but having it "on deck" addresses desires for a retro VIC-20 / C64 style edge card User Port without requiring that to be built into the main CX16 board design.



Implementing the Serial Port parts of a C64 User Port top edge would be straightforward if there is a pin header on the main board bringing out VIA1_CB1 and VIA1_CB2.



Implementing a reasonably C64-alike User Port bottom edge would be straightforward on an expansion card: put out PortA (rather than PortB), so that CA1 and CA2 can serve as the handshake lines, PB2 and /Flag. This actually brings the output handshake full circle, since in the Vic-20 User Port the bottom edge is PortB and the VIA handshake or serial port lines CB1 and CB2. I think if old hardware might be plugged in here, the +/-9VAC lines should be DNC.



1: GND

2: +5V

3: /Reset

4: VIA1_CB1

5: VIA1_CB2

6: CB1

7: CB2

8: ???

9: ???

10: [DNC]

11: [DNC]

12: GND



Since VIA#2_CB1 & 2 are brought out on the C64 User Port Serial Port lines, they are not available as 8bit write handshake lines. Also, VIA PortA has both hardware read and write handshakes, making PortA the more flexible choice for the bottom of the User Port. Now rather than the C64 use of a GPIO on the output handshake line, the output handshake can be a hardware handshake line as on the Vic-20 User Port:



1: GND | A: GND

2: +5V | B: CA1

3: /Reset | ? PA0

4: VIA1_CB1 | ? PA1

5: VIA1_CB2 | E: PA2

6: CB1 | F: PA3

7: CB2 | H: PA4

8: ??? | J: PA5

9: ??? | K: PA6

10: [DNC] | L: PA7

11: [DNC] | M: CA2

12: GND | GND



Now there are only two lines to place. In the VIC-20 User Port they are cassette switch and IEC-ATN. In the C64 User Port, they are the CIA#2 output handshake line and IEC-ATN. As with the C64 User-Port putting a GPIO where the Vic-20 has a VIA handshake line, these would best be filled by PortB lines. As swapping PortB and PortA means that the PB6 and PB7 pins which interact with the timers in some timer modes are no longer available, PB6 & PB7 are likely the highest priority. These have the added advantage that they can be tested directly by "BIT PORTB" without setting up a Bit Mask, as the BIT operation sets the Sign and Overflow flag based on the values of bit7 and bit6, respectively:



1: GND | A: GND

2: +5V | B: CA1

3: /Reset | ? PA0

4: VIA1_CB1 | ? PA1

5: VIA1_CB2 | E: PA2

6: CB1 | F: PA3

7: CB2 | H: PA4

8: PB7 | J: PA5

9: PB6 | K: PA6

10: [DNC] | L: PA7

11: [DNC] | M: CA2

12: GND | GND



This fills the use case for the pin header layout in the OP, so the main board User Port can focus on simply bringing out the "spare" VIA#1 pins. Rather than trying for a "legacy" layout, it is laid out to a 6pin SIL to TTL serial cable can plug directly into one side of the pin header, and so that power lines are are identical for 5-pin SIL plugged into the second side of the pin header with "pin2" as Pin1.



1: GND | 2: GND

3: CA2 (CTS) | CA1 (/ACK)

5: +5V | 6: +5V

7: PB0 (TXD) | 8: CB2 (SDATA)

9: PB1 (RXD) | 10: CB1 (SCLK)

11: PB2 (RTS) | 12: DNC

Hypothetical question for the development team:

 

If someone else were to do another Wavicle-style home brew of a Commander X16 motherboard, and the only difference (as far as end-user hardware and software interface is concerned) is that it returns that second VIA to its place on the the motherboard and its place in the port architecture and memory map, and further assuming the screwdriver that the user port sonnected up somehow matches the planned Official User Port expansion card's pinout, voltage, signal, and bandwidth profiles exactly, would either that second VIA in its original position, or the User Port in its position among the circuitry break software compatiblity with the port architecture and/or memory map the Commander X16 system in its latest hardware and systems software specification, and/or would the presence of that second VIA and/or the User Port wired to it steal CPU cycles or otherwise interfere with Audio, Video, or I/O timing in any way, shape or form?

 

I ask this question because, as there are only four expansion slots expansion, and there is no other analogue to, say, cartridge slots on the motherboard, each individual expansion slot represents precious, extremely limited system real estate.  I had several concepts for Commander X16 expansion cards in my head, and relegating the User Port to an expansion card cuts into the basic expandability of the machine by at least 2/5 (1 fifth for the expansion slot itself, the second for the missing User Port/Header on the motherboard itself).  I know, one could theoretically reclaim some of that expanability by hacking the Commodore Datasette and/or Floppy Drive ports, but those appear only useful for software medium interface.