I've been learning a lot building and modifying the ben eater 6502 project, and reading this forum along with Garth's primer.

Currently I have the 20x4 LCD hooked to a VIA with port A for 8-bit data, and 3 pins of port B for the LCD's enable, r/w and r/s pins.

This makes the code a bit fiddly since you need to set up port A and B with the right data while keeping enable low, and then re-write on B to strobe the enable.

Is there any reason not to replace the VIA port B pins with something like the address decoding scheme used to route to ram/eeprom/via?
I think I saw an example of this somewhere. e.g. connect LCD r/w to the 6502/6522 r/w, connect LCD r/s to address line 0, and LCD enable to (say) address line 4. With the idea that I can (say) read to VIA_ADDR + 16 + 0 for chip-enable read of LCD reg 0, or write to VIA_ADDR+16+1 for write to reg 1.

Would something like that work? It seems more elegant than the port B approach so I suspect I'm missing something.

On a related note, I've seen some other threads talking about "clock-qualified" chip select as either a good or bad thing. e.g. here: viewtopic.php?p=87825 Is that to ensure the data lines are set up before the CS happens? Do I need to worry about that with a simple 1MHz setup? That didn't seem to feature in the ben eater discussion.

Yes, you can place the LCD directly on the data bus. The datasheet claims operation up to 2MHz bus, however it works on my system which runs at around 7.3MHz. I have a GAL that generates the logic. I found that I needed to include Phase 2 in the logic for the address decoding (fed to the E input on the LCD). Otherwise, I just fed A0 directly to the RS pin and RWB directly to the R/W pin. Then it uses two addresses - one for commands and the other for data.

https://github.com/SamCoVT/SBC/tree/master

There is a PNG image of the schematic and the PLD file used to program the GAL available there if you want to look at the details.

You *can* do that, but the timing can get pretty fiddly. One thing you might consider as an "in-between" measure is to use the LCD in 4 bit mode so that it only has to occupy one of the VIA's ports instead of both.

You have to make sure that you don't accidentally write to random areas of RAM if /WE goes low before the address lines have settled. One way to do this is to qualify chip-select with Ø2. If your RAM isn't selected until Ø2 there's no way it can be accidentally written to during Ø1. The down side of this approach is that you lose half the cycle (in your case, 500ns), so your RAM has to be fast enough to get done in time. At slow clock speeds this is unlikely to cause problems.

For a method that will work at faster speeds and is possibly more "logically correct," see Dr. Jeffyl's post here: viewtopic.php?f=4&t=511&hilit=139&start=15

I particularly like that `139 method, and have used it in all of my own SBCs. BDD has a version that uses a Quad-NAND gate to do essentially the same thing. He will probably post it here, because he posts it to all of these threads.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

As usual lots of great insight, thank you! SamCoVT - nice to have a working proof, i'll give it a try.

Garth - I do currently have the LCD multiplexed on the VIA: it shares port A for data with a keyboard (an mcu bit-banging into a '595 shift register which handshakes on A1 to trigger a key ready interrupt) and an SD card (SPI shifting out thru VIA's SR and in thru another '595 SR using the delayed+inverted CB1 clock trick (d-flip-flop latched on inverted phi2). The SD i/f is still a work in progress...

Anyway, I currently use PB0/1 for LCD rw/rs, and PB2/3 to select LCD/kbd/SD/none with a 2-to-4 '139 decoder. But as I kept reading more about address decoding I wondered why not use address pins instead of VIA pins, and have different address subranges within the VIA range to talk to each device. Good point about still decoding them so I don't trigger random writes to devices outside the VIA range...

I also have PB7 on the VIA loop timer driving a mini speaker (or LED) which is great for morse code debugging or playing tinny music

I think most of the LCDs are using clones of the HD44780 these days, but it's difficult to know what's under a "glop top". I currently have a Newhaven Display LCD installed (I think) and their datasheet claims an ST7066U controller - looking up that controller shows the min width for E is 140ns (with the datasheet last updated in 2006), so I guess I'm not overclocking by as much as I thought I was. They also want 1200ns from the start of one enable strobe to the next, but that isn't as bad as it initially looks because it takes multiple cycles to load A with a command or data and write it out to memory.

I am overclocking the LCD in my application, though. I've used 4 different LCDs from 3 different manufacturers (I think - some were unmarked) and none have given me any issue at 1MHz, 4MHz, or 7.3MHz as long as I wait long enough after powerup before I start initializing them. The ST7066U example code shows waiting 40ms, but I usually just use a 100ms delay and that has worked on every LCD I've ever used.

I'd be interested in hearing if you are able to get this to work.