6502.org

Is an LCD 'backpack' out of the question? Lots of possibilities (I2C, SPI, Serial, custom). Here's a design that drives the LCD in 8-bit interface mode while using a 2-pin interface to the host.

Hmm. Yes, switching out to an SPI based interface would work, I've already got an SPI bus going on the board and I do have a spare SPI CS pin. Obviously it'd be slower than directly writing to the chip, but that is a possible solution certainly.

I use a single VIA for:

• LCD
• 5-key keypad
• beeper
• printer port
• T1 interrupts for software real-time clock, calendar, and alarms with 1/100th-second (10ms) resolution
• I²C port
• triggering the A/D convertor (which puts the data on another VIA)
• "Abort" button (like Reset but less drastic)
• and a synchronous serial port for things like my analog oscilloscope raster-graphics display

all at the same time.

As for room, you can put other ICs under the VIA:


ICs under ICs are slightly visible in this photo also: But really, for the amount of work you're going to put into it, the price of a second VIA is peanuts. Using the LCD in its 4-bit interface is easy, and probably won't be any less efficient than trying to manage it through other parallel logic which may slow your maximum clock speed down anyway, and certainly won't be as slow as doing it through SPI if you have to bit-bang it (although I do like SPI, even bit-banged!). Michael's idea using the '595 could be pulled off with the VIA's serial port, shifting at half the phase-2 rate without the processor having to bit-bang. In fact, I've done the following to get well over a hundred output bits from the VIA's SR (shift register):



Similarly, you can also use the VIA's SR for tons of input bits:



or even both inputs and outputs on the same VIA SR, at the same time, using a 74xx126 section to stop the final 165's output when you're outputting to the 595's, to prevent contention.

It's all in the 6502 primer.

If I seem a little feisty, it's because a rather new tire with no apparent previous damage blew out on our son's van a few hours ago on the freeway and he fishtailed and rolled the van over and over. It's a total loss. Fortunately he's not hurt.

I know one can, unfortunately in this case, its not a matter of being unable to, I just don't want to.
Not with an SMD VIA.
Well, the parallel logic design above which introduces waitstates should only slow down the processor when its actually accessing the screen, and it will make the software a lot simpler - no bit-banging of any kind. I think there's pros and cons to both approaches.

I'm already using the VIA SR in exactly this manner to drive the keypad and status lights. I would rather not overload it with having to manage the screen as well.
Perhaps it might surprise you to learn I have read your entire primer multiple times. Not to mention several other parts of your website. I cannot describe how useful they've been. Nevertheless I am a relative newbie to all this and I like to get other people's opinions on things before I spend vast quantities of money getting PCBs made. Earlier in this topic with Jeff's help we got the decoding logic down from 10 chips and a 5-chip large prop delay to 3 chips and a 2-chip prop delay, so it was clearly worth it.
I am very sorry to hear that, but I am glad he is OK. I can definitely sympathise, having had my fair share of crashes, scars included.

Glad everyone is OK Garth.

Yikes! Good to hear he's okay.

There's been mention in the past of using a ROM or RAM chip for address decoding but I haven't seen it used. Could this be a viable decoder solution for lower speed systems? Could a 55-nS Parallel Flash chip decode fast enough for a 4-MHz system?

Cheerful regards, Mike

PS: Happy to hear your son is ok, Garth.

In that circuit, there's nothing to mask off the A14-A16 lines from the RAM when accessing the Standard RAM area. You'd need a multiplexer controlled by the decoder ROM, or perhaps sacrifice three of the I/O chip selects in order to "pass through" the A14-A16 lines when appropriate (there's some spare address inputs on the decoder ROM so it could be done). Also I've not come across ROM chips that are that quick, but I assume they must exist.

How are you making these diagrams? they're absolutely beautiful

Sorry! The memory map insert was incorrect. That drawing is for your design with two RAM chips so the 128K RAM is only selected when the 6502 addresses the $8000-BFFF block.

* Drawings are from Microsoft Excel

As you noted, supporting a single 128K RAM chip instead of two RAM chips would require giving up some of the decoder I/O chip select outputs...

Such decadance I have to try. Pray explain how Excel can be coaxed into making such images.

I use 55ns UV-erasable EPROMs in my POC units. Atmel makes a 45ns OTP ROM, which I've also used in my POC units. I believe that is currently the fastest ROM available from production stock.

You can get 45ns, 5v flash from Microchip, provided you don't mind using PLCC parts.

Still fleshing out ideas. I wonder if anyone other than Jeff (Dr Jefyll) recognizes the bank select method in the crude design below?


reference: Ultra-fast output port using 65C02 illegal instructions

I recognise it. I did very seriously consider using something like it, but I decided that it was important that the bank bits be readable as well as writable so that subroutines / interrupts can save and restore them. For your CLKGEN is that a PIC?