Blue April - RC6502 Project Space

[Paganini]

I don't suppose there's any way to investigate that without an oscilloscope? I'm keeping an eye out for one, but it seems like even used, good ones cost well over $300.

[Paganini]

My current set up uses 11 pins for the LCD interface. Inevitably, in Ben Eater circles, people want to free up some pins by switching the LCD into 4-bit mode, which is an unholy pain. I was thinking that I have a whole unused shift register right there on the 6522, and I ought to be able to spit out data from the CB2 pin, latch it with a 74HC595, and have the LCD read from that, thus gaining 7 pins at the cost of one logic chip. (I still need a few pins for control signals). However, it's not working. At all. Maybe it's my relative inexperience, but I find the 6522 VIA data sheet to be unhelpfully laconic when it comes to using the shift register. Before doing any deeper troubleshooting, I just wanted to double-check that my understanding of how the 6522 works is correct.

Code: Select all

VIA_SR = $900A
VIA_ACR = $900B

    lda    VIA_ACR
    ora    #%00011000    ; set Shift Register to Mode 6 - Shift out under control of phi2
    sta    VIA_ACR

    lda    #some_byte_or_other
    sta    VIA_SR

I think that's all I should need to do to start spewing bits out of CB2; Although the data sheet says only - "In mode 6, the shift rate is controlled by the phi2 system clock (Figure 27)." - examining Figure 27 seems to indicate that I should also be getting a clock output on CB1 equal to phi2 * 1/2. My little multimeter has a clock setting that detects the system clock on the bus just fine, but when I attach it to CB1 it doesn't blink. What am I missing?

[GARTHWILSON]

Paganini wrote:

want to free up some pins by switching the LCD into 4-bit mode, which is an unholy pain.

I've used it in 4-bit in all but my earliest project in the late 1980's, and never had a problem. You do however need to write the function set three times in the LCD-reset routine to get a consistently reliable reset and set-up, as I mention in different points of my site, something we got from an applications engineer back then to solve a problem (before I ever even tried 4-bit mode), something that doesn't come through on the LCD data sheets.

Quote:

I was thinking that I have a whole unused shift register right there on the 6522, and I ought to be able to spit out data from the CB2 pin, latch it with a 74HC595, and have the LCD read from that, thus gaining 7 pins at the cost of one logic chip. (I still need a few pins for control signals). However, it's not working. At all. Maybe it's my relative inexperience, but I find the 6522 VIA data sheet to be unhelpfully laconic when it comes to using the shift register. Before doing any deeper troubleshooting, I just wanted to double-check that my understanding of how the 6522 works is correct.

Code: Select all

VIA_SR = $900A
VIA_ACR = $900B

    lda    VIA_ACR
    ora    #%00011000    ; set Shift Register to Mode 6 - Shift out under control of phi2
    sta    VIA_ACR

    lda    #some_byte_or_other
    sta    VIA_SR

I think that's all I should need to do to start spewing bits out of CB2; Although the data sheet says only - "In mode 6, the shift rate is controlled by the phi2 system clock (Figure 27)." - examining Figure 27 seems to indicate that I should also be getting a clock output on CB1 equal to phi2 * 1/2. My little multimeter has a clock setting that detects the system clock on the bus just fine, but when I attach it to CB1 it doesn't blink. What am I missing?

I would also AND-out bit 2 of the ACR, to make sure it's really a 0. Another thing is that I don't see anything in your code to strobe the '595. The 595's strobe input needs to be low to shift, then high momentarily to transfer what you just shifted into it to the parallel output. Make sure the 595's OE\ is low of course. The SR in this mode will take 16 clocks to transfer a whole byte, so make sure you're waiting long enough before strobing the '595 (or before starting another byte if you have multiple 595's in a chain). The circuit-potpourri page of my 6502 primer shows a circuit for using the VIA's SR for outputting tons of bits, at http://wilsonminesco.com/6502primer/pot ... #22_SR_OUT .

[Paganini]

GARTHWILSON wrote:

I would also AND-out bit 2 of the ACR, to make sure it's really a 0.

Thanks Garth! Just to double check, bit 2 of the ACR needs to be 0, because if it is 1, it will enable latching on Port B, which expects to use CB1 and CB2 as handshake lines, rather than serial clock and data?

GARTHWILSON wrote:

Another thing is that I don't see anything in your code to strobe the '595. The 595's strobe input needs to be low to shift, then high momentarily to transfer what you just shifted into it to the parallel output. Make sure the 595's OE\ is low of course. The SR in this mode will take 16 clocks to transfer a whole byte, so make sure you're waiting long enough before strobing the '595 (or before starting another byte if you have multiple 595's in a chain). The circuit-potpourri page of my 6502 primer shows a circuit for using the VIA's SR for outputting tons of bits, at http://wilsonminesco.com/6502primer/pot ... #22_SR_OUT .

I do have a strobe for the 595 later on, in the subroutine for sending a byte to the LCD; I wanted to make sure my basic conception of 6522 shift register operation wasn't flawed before I looked any deeper. I'll go make sure that bit 2 of the ACR is 0 before I do anything else.

[GARTHWILSON]

Paganini wrote:

GARTHWILSON wrote:

I would also AND-out bit 2 of the ACR, to make sure it's really a 0.

Thanks Garth! Just to double check, bit 2 of the ACR needs to be 0, because if it is 1, it will enable latching on Port B, which expects to use CB1 and CB2 as handshake lines, rather than serial clock and data?

No, you're thinking of bit 1. Bits 2, 3, and 4 of the ACR determine the SR mode. When I set up the ACR for this, I leave bits 0, 1, 5, 6, and 7 alone.

[Paganini]

Oooh, right. Logic error! Thanks for spotting that.

Also, on the subject of "read the fine print," turns out the 595 timing is all high-going, but the 6522 SR is low-going. I added an inverter, and everyone is much happier now. All the right LEDs are lighting up in my simplified testing circuit. Time to go back to the LCD!

[GARTHWILSON]

Quote:

Also, on the subject of "read the fine print," turns out the 595 timing is all high-going, but the 6522 SR is low-going. I added an inverter, and everyone is much happier now. All the right LEDs are lighting up in my simplified testing circuit.

The SR changes the data line to the next state immediately after the falling edge. It idles with the clock line high, and the first falling edge has invalid data. It expects the receiver to clock the data in on the rising edge, which is what the '595 does, as it is positive-edge-triggered. The following is a diagram of an LCD test fixture I made with connectors for various LCD brands, using a '595 and 4-bit mode. It's from the 3x5" quick-reference ring binder I keep on the workbench for my workbench computer. What should be labeled, but isn't, is that the 595's clock input, pin 11, which goes to pin 1 of the header to my workbench computer, is the VIA1CB1 connection. No inverters. I've used this fixture to test quite a few different intelligent character LCDs (all of which worked fine with it).

I can post my code, but it's in Forth.

[Paganini]

GARTHWILSON wrote:

The following is a diagram of an LCD test fixture I made with connectors for various LCD brands, using a '595 and 4-bit mode.

Studying your schematic, I think that you never check the busy status of the LCD. I'm guessing that means you use software timers in your FORTH code to make sure you wait long enough between bytes. Do I have that right?

Also, looking at the way you have the latch clock connected, I suspect you wait until all 8 bits are shifted into the 595, then use one pulse on PORTB7 to latch the whole byte at once. That is a cool idea. I tied those two together so that the output register was always one bit behind the shift register, as described in the datasheet. I think I have been overcomplicating things. I'll have another go at it this this afternoon.

[GARTHWILSON]

Paganini wrote:

Studying your schematic, I think that you never check the busy status of the LCD. I'm guessing that means you use software timers in your FORTH code to make sure you wait long enough between bytes. Do I have that right?

Yes; I've always just given it enough time to just make sure it's ready for the next instruction, rather than polling it. The Hitachi driver IC's data sheet has the maximum execution timings listed so you can know how much to give it to be safe if you don't poll.

Quote:

Also, looking at the way you have the latch clock connected, I suspect you wait until all 8 bits are shifted into the 595, then use one pulse on PORTB7 to latch the whole byte at once.

Right.

[Michael]

Which pins on the VIA are being used in SR mode to drive the CLK, DAT, and LAT inputs on the '595, please? Can the CLK pin be re-tasked to output a '0' or a '1' after shifting 8-bits into the '595 shift-register?

I've used two or three pins to drive a 74HC595 or 74HC164 and an HD44780 type LCD display in 8-bit mode. Basically, one line is used to both latch the '595 outputs and strobe the LCD 'E' input and the CLK line is re-tasked to drive the LCD 'RS' (Register Select) input after loading 8-bits into the '595 shift-register. I'm just not sure how you might re-task the CLK line in VIA SR mode. An Arduino demo' is attached...

Good luck. Have fun...

LCD_3P8B_Class.ino.txt

(3.9 KiB) Not downloaded yet

[GARTHWILSON]

The VIA's SR uses CB1 as the clock and CB2 as the data. CB2 can be made to output a steady high or low state. You could make a circuit that makes the 595's latch input go true if the CB1 clock line has been high more than a few periods' time instead of toggling, and make the latch input go false again the next time CB1 goes down. It would involve a resistor, a capacitor, a diode, and a Schmitt-trigger inverter or NAND. You'd probably want to put the LCD's enable on the higher one of two consecutive bits of the 595's output, so that the little glitch on that first shift doesn't mess anything up.

[Michael]

Perhaps you could just use CB2 plus two port pins and bit-bang the driver and enjoy using the LCD 8-bit interface mode? Also, there may be an advantage using the 74HC164 over the 74HC595. That is, the ability to load 8-bits of data onto the outputs without sending it to the LCD which might come in handy for driving column or row lines on a multiplexed keypad or display (???).

[GARTHWILSON]

You can of course daisychain those shift-register ICs too, for loads of I/O bits. I had something like 140 bits on it on a work project 30 years ago.

[Michael]

There are also serial LCD backpacks that might be driven by a single VIA pin (bit-banged serial). I created one long ago using an 8-pin 12F683 PIC (see below) but a more up-to-date version might use an 8-pin 16F15313 ($ 1.03 @ Mouser) which can be programmed using a relatively inexpensive Arduino Nano clone.

[GARTHWILSON]

I've never used the serial intelligent character LCDs, but the graphics LCD I show in the third picture (a video) at http://wilsonminesco.com/6502primer/displays.html is interfaced by SPI. However, every time I use the character LCDs' parallel interface, I multiplex the lines (except the Enable line) with other things too.