Daryl's 65SPI IC shifts a byte in and one out (SPI goes both directions simultaneously) in 16 clocks. You'll probably need that much time just to handle each byte during the process anyway; so it wouldn't be slowing you down. He is re-working the design for a newer CPLD since the old one became unavailable. I still have several here I could let go of. The 6522 has a synchronous serial port that's just as fast, although not bidirectional. A few people have used it for one of the SPI modes. I'd have to sharpen my pencil to see what tricks (if any) there might be to using it for SPI.

The monochrome graphics LCD I've used, and another I plan to use, take a command to tell which dot row and column to start with in its internal memory. In this one, it wraps IIRC, so you would have to re-draw just the one row or column that wrapped around to the other side or end. I know I've seen other ones though that have an internal memory that's larger than the screen, so there's a certain amount of panning you can do without re-drawing anything.

Yes, just change the bytes you want to, and take advantage of the rest already being what you want.

You can often get free dual-trace, triggered CRT oscilloscopes that businesses or schools are getting rid of, in the range of 20-100MHz. Do yourself a favor and get a decent scope. One of these will be way better than most of the cheap new digital ones like the worthless DSO Nano you hook to your computer, and certainly better than the scope from the 1950's. Just be sure to get a decent pair of 10x probes with it, and take care of them. Good probes are not cheap. There's a lot more there than meets the eye. (The 6502 primer's section on basic workbench equipment discusses this.)

You're welcome. It was written to answer a lot of questions and problems that kept coming up over and over in the early years of the forum. It does get frequent small updates. The whole site probably has a thousand links, and I definitely can't check them all every week; so if you find that one has gone dead, please let me know.

It's mostly unrelated. If anything, a lower voltage may cause less trouble, because parts are the fastest at their maximum voltage, producing faster edge rates that are more likely to cause ringing and double triggering, and also responding more quickly to it and being less forgiving.

There are of course thru-hole sockets for PLCCs. Remember also that if you need additional parts or connections on the other side from a DIP, you can forgo the holes and just put pads down on the board to solder the DIP to, holding it on with solder fillets. That should be fairly easy to unsolder too, using solder wick.

On 5V vs 3.3V:

Generally CMOS logic runs faster at higher voltages, including the currently-produced WDC 6502 and 65816, and the 74-series logic chips to go with them. WDC specifies their CPUs to 14MHz at 5V, but only 8MHz at 3.3V. System designers, however, think less in terms of MHz and more in terms of nanoseconds; fewer nanoseconds elapse before signals become valid at the higher voltages.

Some chips and peripheral devices, however, are not 5V-tolerant - including the Raspberry Pi - and are likely to "let the magic smoke out" if even briefly subjected to 5V signals. Conversely, some devices are designed for 5V only and won't work reliably at 3.3V (though some do actually still work, even though it's out of official spec). To bridge the gap, you will need to use a level shifting interface. Not a complete disaster, but a complication. Read your datasheets for things like SRAM chips and display modules with that in mind.

On a related note, avoid 74LS series logic in current designs, and note also that 74HC is less than optimal these days (though it's cheap and is fine for slow logic). Prefer 74AHC where available, or 74AC if the specific chip you want isn't in 74AHC. The 74AHCT family can be used to correctly interpret TTL (as opposed to CMOS) signals which don't go to the positive rail quickly enough, such as the output of 74LS series logic.


I did some mental arithmetic based on what I remember of the BBC Micro's video system. This is capable of producing a PAL-compatible 640x256x1b 50Hz signal from a 16MHz dot clock (Mode 0), by reading 8 pixels worth of data into the Video ULA during the Phi1 phase of the 2MHz 6502 cycle, during which the CPU doesn't "see" the bus. (The ULA was an early, mask-programmed version of what we would now call a PLD.) This offers a useful baseline for video timings, from which we can extrapolate. Many other classic micros used an odd-looking CPU frequency, because the same oscillator was used to drive the CPU and the NTSC or PAL colourburst carrier; the BBC Micro separated these concerns.

Keeping the same 16MHz dot clock and assuming 8-pixel-square characters, you could implement a "text and attribute" 80x32 mode in 5KB, which is relatively affordable. This would require fetching one byte full of character data and another byte full of colour data (4 bits each of foreground and background colour index) per 8 pixels, which you could easily squeeze into the Phi1 phase of a 4MHz CPU, or with a bit more difficulty into an 8MHz cycle (a 55ns SRAM should just about be able to keep up, if you have fast glue logic). You'd need to buffer these results so that they were presented to the character ROM and the CLUT synchronously with the leading edge of the relevant character cell. The CLUT would be a small RAM with 4-bit address and as many bits as you like of width, directly driving RGB DACs; you could update it during any blanking interval. Put the output of the character ROM in a shift register, clock that at 16MHz, and use each shifted bit to switch which half of the colour attribute is presented to the CLUT.

You can then add flexibility in the system by offering per-scanline programmable display address, character-ROM row number, pixel shift-register divider, scanout delay and length. Your text is now capable of being moved with pixel granularity, scaled up both vertically and horizontally, or simply skipped to free up a bit more RAM. If your character ROM can be put in a pass-through mode, you can go the other way and provide unique pixel data in each scanline, giving you a H/V-scrollable bitmap graphics mode with some colour capability - but consuming as much as 40KB RAM at full size and resolution.

Food for thought…

BitWise mentioned the original Gameduino, which has VGA output on it. However, there is also the Gameduino 2/3, which come with a built-in display. It is interfaced over SPI, though, which may complicate things.

Welcome, backspace119! I'm a bit late to this party. You don't lack for ambition, and I commend you and will follow with interest... but I would echo advice to first build something simple: the minimal viable prototype, if you like. Build one to throw away. You'll learn a lot from that, and you can keep yourself from the distractions of adding features or chasing performance - you really want to start by making something which works! Modular is a related approach, but you can lose time and momentum figuring out how to support all the ideas you have, but haven't yet implemented.

One small comment, though, you mention wanting solid state storage, and lots of RAM, and lots of ROM. I think you don't need all three. Solid state storage is an excellent fit for retrocomputing, so that's a great idea, and a memory map full of RAM is also very liberating, compared to many historical machines. But you don't need much more ROM than it takes to load a binary from the solid state: it needn't even be smart enough to read a filesystem. (You may learn a lot even from this exercise, unless you happen already to have a good understanding of bootstrapping.)

I'd also, to some extent, echo the comments that a high resolution display is slightly at odds with a low performance CPU: unless you don't care too much about screen refresh, or you have a sprite engine or tile-based display or similar. I hope we all know that gameplay trumps everything else, if games are your target application. "Pac-Man's screen resolution is 224 x 288, so this gives us a total board size of 28 x 36 tiles." Space invaders was monochrome, 224×256 resolution. Tetris runs nicely on the NES at 256 x 240.

It certainly makes sense to write something of a kernal and some graphics library, but you might as well load it from solid state into RAM - I think. Maybe the thing to optimise is the ease of development and update. With almost all software on an SDCard, you just have to whip it out of your micro, slot it into your PC, and copy your latest code. Updating any kind of ROM is probably going to be more involved. But don't take my word for it - do a bit of reading and a bit of sketching of possible solutions.

Certainly in the few bringups I've been involved with, getting to the point of booting to a monitor program with a hex loader has been a major milestone, because it's then easy to paste hex dumps over a serial connection to load software under development. (I've generally worked with systems that have a serial port.)

As far as PLCCs go, and other programmable chips, I've never used them, and I'm not sure how to use them, I'm willing to learn though, as it seems a lot of ICs are not really made with the 6502 in mind, so I may need to implement some custom functionality.

I think you were thinking of CPLDs (complex programmable logic devices). PLCC stands for "plastic leaded chip carrier," a type of IC package that has pins J-leaded around all four sides. The 65c02, '22, '51, '134, and '265 are available in PLCCs.

It's easy to mark out a single 256-byte page, directly between the RAM and ROM spaces, for I/O. All you need is an 8-bit magnitude comparator, which outputs less-than (RAM), more-than (ROM) and equal (I/O) signals. You can then subdivide that page further into 16x 16-byte chunks using a 4-to-16 decoder, whose enable pin is tied to the equal output of the comparator.

If you think RAM will get tight, you could take a page from my book and provide paged RAM banks. In the design I'm theorising at the moment, there are sixteen 1K areas between a 16KB ROM zone and a 32KB flat RAM zone, with an 8-bit page register (just an 8-bit latch) associated with each. The page register is connected to the high address lines of a 256KB SRAM chip, with the low ten bits coming from the CPU. Not only does this give some good RAM expansion opportunities, but it can be used as a vehicle for accelerated multiplication and division, by filling that RAM with lookup tables. Since what I'm trying to build is a high-precision, high-utility calculator, that sort of good arithmetic performance might turn out to be useful.

You could also use those banked areas to attach large EEPROMs for reasonably fast non-volatile storage. I think 4MB chips are readily available with a convenient interface, significantly larger in capacity than most classic micros' floppy drives, yet faster and easier to work with. Put routines to flash files from the serial port into those EEPROMs in your main ROM; I advise including a checksum test. With careful mechanical design, you could turn those into pluggable cartridges.

Or you could make life slightly easier by using a 65816 instead of a 65c02. That gives you a 24-bit address space, even if you never leave emulation mode, because the new opcodes with "long addressing" still work. You'll still need a small boot ROM at the top of the 64KB space, just to handle bootstrap, but you can map something much larger into high memory and just not bother with paging.

About how much are you selling those SPI chips for?

any other neat chips you're selling?

I paid $4.25 each plus shipping. How's that? (I lose the amount of the original shipping, but it's not enough for me to be concerned about.) I should have put them on the front page of my site, but I never thought of it. I think I have about a half dozen.


The only actual ICs I supply separately are the pairs of 1MB EPROMs with the large look-up tables. Otherwise just the little memory modules shown on the front page of my site, one for 4Mx8 of 10ns 5V SRAM, and then the tiny boards and connectors for SPI-10 serial flash memory. I have not sold any of the latter, probably because I never did come up with a price and promote them, and now I'd have to look up how much the connectors cost me since I can't remember. The price of the bare boards themselves would probably be dwarfed by the postage if someone only bought one or two, LOL. Last year I did not get any real 65xx activity done, as my work had me busier than usual. I hope to get with the program again this year and add another module or two to facilitate the construction of hobby computers, and maybe another major feature to my website too. This is all to promote the interest; so although I have a legitimate business (and I have to collect sales tax from California customers), it does not need to be profitable to keep going indefinitely.

As for the 65816: A16-A23 are multiplexed on the data bus; but if a 64K address map is enough, you don't have to latch, decode, or use those high eight bits. You still get a ton of benefits from the 816's added instructions and addressing modes, and the fact that you can put A in 16-bit mode, and you can put the index registers in 16-bit mode, the stack pointer is 16-bit also, the "zero page" is called "direct page" because you can move it around (and it's not required to start on a page boundary), and probably a lot of other benefits I'll think of as soon as I click "Submit" here. It really opens up a bigger world. If you're timid (which is fine), you could lay out a board that accommodates either the '02 or the '816 by using jumpers. The '816 powers up in '02-emulation mode though (albeit with a lot of extra instructions available). After you get your feet wet, you'll probably want to put it in native mode in the reset routine and never touch that mode bit again.