External RS-232 Interface, storage, and second screen.

[BruceMcF]

On addressing, remember that the state of all PortB output lines can be set in parallel. Also, it isn't necessary at the outset to allocate things to the Centronics output-only parallel printer port pint allocations when the User Port is not ACTUALLY a Centronics parallel port, but rather a set of VIA pin allocations that can emulate a Centronics parallel port.

That suggests to me a dedicated "reset register to 0" line. The CA1/CA2 handshake is dedicated to the "/Port0" operations.

So, to read from a "high" register, A=x, Y=register address. Note, "Wait/Ready" is GPIO input, not CA2.

(1) R/W=0, /Address=0, /Data=1, /Port0=1

(2) Wait/Ready=0?

(3) Write Register address

(4) Wait/Ready=1?

(5) R/W=1, /Address=1, /Data=0, /Port0=1

(6) Wait/Ready=0?

(7) Read register contents

(8) Wait/Ready=1?

(9) Return, A=contents, Y=register address

So, to write from a "high" register, A=contents, Y=register address:

(1) R/W=0, /Address=0, /Data=1, /Port0=1

(2) Wait/Ready=0?

(3) Write Register address

(4) Wait/Ready=1?

(5) R/W=0, /Address=1, /Data=0, /Port0=1

(6) Wait/Ready=0?

(7) Write register contents

(8) Wait/Ready=1?

(9) Return, A=contents, Y=register address

To write a packet:

(1) R/W=1, /Address=1, /Data=1, /Port0=1

(2) Read Port A (to clear CA1)

(3) R/W=1, /Address=1, /Data=1, /Port0=0

(4) CA1=1->0?

(5) Read data (clears CA1)

(6) If more data, goto 4

(7) Return, A=number of bytes not successfully sent (0 on success)

To read a packet:

(1) R/W=1, /Address=1, /Data=1, /Port0=1

(2) Read Port A (to clear CA1)

(3) R/W=1, /Address=1, /Data=1, /Port0=0

(4) CA1=1->0?

(5) Read data (clears CA1)

(6) If more data, goto 4

(7) Return, A=number of bytes not successfully sent (0 on success)

This requires:

(1) D0-D7 = Port A D0-D7

(2) R/W, GPIO Output

(3) Wait/Ready, GPIO Output

(4) /Address, /Data, /Port0, three GPIO Output

(5) Port0 UART Ready, CA1

(6) Port0 System Performed, CA2

(7) UART IRQ, CB2

(8) Reset UART, GPIO Output



So that fits the User Port (with CB2 jumpered in), as it is 8 data lines in Port A, the available CA1,CA2, CB2, and 6 Port B GPIO, when six are available.

As far as potential compatibility with an EPP interface, that's out, but as far as potential compatibility with a device that is designed to work over an EPP protocol but know that there may be a UART using the same port ... that's feasible, all it takes is allocating it's pseudo registers to $10-$1F, and having it ignore any reads or writes directed to any lower registers. For that:

Data0-Data7 = EPP Data0-Data7

R/W=EPP R/W output

Wait/Ready = EPP Wait/Ready input

/Address = EPP /Address output

/Data = EPP /Data output

/Reset UART = EPP /Reset

/Interrupt = /CB2 = EPP Interupt

/Port0 = EPP Not Used

/CA1 = EPP Not Used

/CA2 = EPP Not Used



 

[BruceMcF]

3 hours ago, TomXP411 said:

SPI 8 would be amazing, but you need 8 wires each direction, plus clock and Slave Select lines. 



4 bit SPI is perfectly doable right now. 

• 
  CA2 SCLK
  


• 
  PA0-3 MISO
  


• 
  PA4-7 MOSI
  


• 
  PB0-3 SS (4 devices)
  


• 
  PB4-5 free (I'll still use them for CTS and Data Ready)
  

This actually the same speed for full duplex communication as the 8-bit half-duplex protocol I suggested, or EPP. But when the data is going mostly one-way, it's not as efficient. 



The advantage is that it's simple to implement, and there's lots of stuff out there that already implements it in hardware.

If using CA2 pulse as SCLK (which works), that is:

• 
  PA0-3 MOSI
  


• 
  PA4-7 SS (4 devices)
  


• 
  PB0-3 MISO
  

... because if you put MOSI and MISO on Part A, CA2 pulses for every write AND for every read, so bidirectional read/write (as when status of the write is returned on MISO) becomes impossible. Having a SS mask somewhere, you can have the four bits out in A, "AND SS_setting : STA VIAxPortA " and the pulse is triggered, so you can read PortB for the input.



With one line, you only need one bit of Port A, since CA2 can work as the SCLK and the serial shift register can be the input by tying CA2 to CB1. Since SPI shifts low bits first and the 6522 VIA enters input at bit0 and shifts it up toward bit7, it's most convenient to have PA0 be MOSI ... you also would want a page that has the reversed bits at each page address ... eg, address Page+%00110101 contains %10101100.

  LDX #7

  STA PortA

- LSR

   STA PortA

   DEX

   BNE - 

   LDX SREG

   LDA BItFlip,X

   RTS



... which at 110clocks is appreciably faster than bit banging the SCLK but a hardware PHI2/2 SCLK SPI s 11 clocks JSR/RTS, 8 clocks write output byte, read input byte and 16 clocks to transfer, or about 35 clocks. So throughput is about three times faster with full hardware SPI than with CA2 output pulse SPI.

A 6522 SPI is natively Mode3 ... a downward pulse for a clock and latching the outputs/inputs at the trailing edge of the clock. Mode0, with an upward pulse for a clock and latching outputs/inputs on the leading edge, requires an AND gate and a control bit, to hold the clock low and manually release it so the leading edge of the CA2 pulse is treated as the trailing edge of a "long" first clock and the trailing edge is the leading edge of the next "long" clock.

  LDX #7

  LDY 1stState

  STY PortB

  STA PortA

  LDY FollowState

  STY PortB

- LSR

   STA PortA

   DEX

   BNE - 

   LDX SREG

   LDA BItFlip,X

   RTS

... which adds another 16 clocks to the overhead for routine. Then a second control bit which inverts SCLK when set (through an XOR) would give all four modes. In both of those circuits, it is the unmodified CA2 which is connected through to the CB1. Two PortB outputs for mode control and four for DeviceSelect exactly fits the six available.

If PB0-3 are the Device Select, PB4 the CA2 Through/Filter, and PB5 the clock invert, the Setup is A=Mode#, Y=Device#

SETUP_SPI:

   AND #3

   TAX

   LDA SPIMODE0,X

   ORA SPIDEVICE,Y

   STA 1stState

   ORA #$10

   STA FollowState

   RTS

SPIMODE: !byte $00,$30,$20,$10

SPIDEVICE: !byte $01,$03,$07,$0F

[TomXP411]

Okay... so rather than keep discussing this in theory, I'm thinking about grabbing a W65C816SXB from Amazon (the WDC 65816 prototype board.) It has a VIA and appears to have all 16 PA/PB pins accessible through the VIA connector. So I can use that to test VIA communications code. 

[BruceMcF]

Go for it. My physical test units are whichever of my C64's still work, if either of them do, and they are on the wrong  continent for me to access, so I am focusing on bringing up my port of eForth.

[Andre]

Sorry for the late reply.

I'm totally with @BruceMcF about the handshake mode of the CA1/CA2 pins of the VIA. Pls see the VIA datasheet for the details how it works.

On the pin assignment I am not clear what the difference is between PB4/ACK and CA1 (or CA2?) Is ACK and output or input?

On SPI - you can have an easy SPI interface with the VIA using a single ser-2-par shift register, and XORs for other modes. See here http://www.6502.org/users/andre/csa/spi/index.html

 

[BruceMcF]

It's a little confusing because the pinout is given from board side rather than connector side, and the block header is not numbered in the same way as the DB-25.

CA1 is on DB-25 pin 10, which is an input pin, ACK in the Centronics parallel port, Interrupt in the enhanced parallel port (rising edge).

CA2 is on DB-23 pin 11, which is an input pin, BUSY on the Centronics parallel port, WAIT/READY on the enhanded parallel port.

I don't know if ACK is an edge or a level, but in any event since it is a response to the data being written, you can be sure that you are ready for it if you need to set up CA1 to detect it.

CA2 on BUSY is a mistake for the Centronics parallel port, because BUSY is not an event, it is a state, so it should be connected to GPIO. It makes more sense to put CA2 on paper-out. Then even if you miss the edge, the BUSY will be high and the printer itself should also be indicating paper-out when we look to see why it isn't printing.

PB4 is on DB-25 pin 15, an input pin, which is Error|Fault for Centronics (not used in EPP). If it is low, it means no error. If BUSY is high, you check whether Error is also high to determine whether it makes sense to wait for the printer to stop being busy, or whether to tell the user that there is a problem with the printer.

[TomXP411]

So at this point, I've given up on the WDC prototype board. i've tried to contact WDC a couple of times with questions, and they have never returned a single one of my messages. I can't even download the support software to make the board run. At this point, I'll probably have to just prototype my ideas on Arduino using software and wait for the real hardware before building the 6502/6522 side of things. 

[rje]

I'd like to develop your documentation a bit.  In particular, recording the reasons for the choices made.

For example, I suspect the Arduino MEGA is chosen based on its UART, but also perhaps due to its ability to handle +5V on its GPIO... and there may be other reasons?

This also helps me engage with the project: Since I own a MEGA that's not currently allocated, I could build one of these things.

 

[TomXP411]

47 minutes ago, rje said:

I'd like to develop your documentation a bit.  In particular, recording the reasons for the choices made.



For example, I suspect the Arduino MEGA is chosen based on its UART, but also perhaps due to its ability to handle +5V on its GPIO... and there may be other reasons?



This also helps me engage with the project: Since I own a MEGA that's not currently allocated, I could build one of these things.



 

As you suggest, the MEGA has 5V signal pins, and it has multiple UARTs. The Arduino Uno doesn't even have enough pins for a full serial implementation.

Part of the intent is to support multiple serial ports simultaneously; one might be used with a level converter for a real RS-232 device, another might be used with an ESP32 for network communication, and another might just connect to another device at TTL levels. 

For example, my use case would be:

• 
  ESP32 for BBSs and multiplayer games
  


• 
  TTL serial port for connecting to Altairduino
  


• 
  RS-232 serial port for connecting to Altair 8800 Clone
  


• 
  USB for connecting to PC
  

 

[rje]

31 minutes ago, TomXP411 said:

• 
  ESP32 for BBSs and multiplayer games
  

Oh wow!  I like that.  Door games?  (OK this needs its own discussion thread)