On a lark I connected the RD/WR pins straight to my 139's PHI2 qualified RWb/WRb pins, and it just worked.....

Throwing out a couple of thoughts:

As you're using an 8bit data bus I'd imagine the fastest way to communicate with an LCD would be via that 8bit bus. I know I've seen LCD displays that use a parallel interface but it's not something I've ever looked into so they might be quite expensive or just not match the 816's architecture nicely.

I bring up speed because even 320x240x16bpp @ 60fps is lot of data for an '816 to handle unassisted.

Let's say you're running 14MHz at 320x200x8bpp. The '816 - using block move instructions - will just barely be able to draw an entire frame 30 times a second. Crossing to more than 320x200 (say 320x240x8) means that the video memory is going to be split over two banks. And that's adding more complicated calculations to a CPU that's already only barely keeping up.

All is not lost though. The 816's block move instruction takes 7 cycles per 8bit pixel whereas if you use a dedicated hardware blitter you could get that down to 2 (or even 1) cycles per pixel. You can also use a colour palette if you want to keep 16bit or even 24bit colour but also still keep a pixel width of only 8bits.

For a preliminary build I'd suggest 320x200x8 is a really good starting point.

I wouldn't worry about the time it takes to capture the 816's bank address. Plenty of logic families have latches that have sub 10ns propagation times. I use LVC in a 3.3V setup but you could use AC or similar if you're running with a 5V setup. Probably AHC is what you're looking for if HC seems too slow.

Personally I fully intend to take Plasmo's 40MHz crown with an 50MHz '816 with the complete 24bit bus available. But that's just smack talk for now as I keep running into problems :lol:

*wonders how the poor CPU doesn't just catch fire at that speed*

I'd like to do my own retro gaming system and I'm shooting for about the same resolution (320x240 @ 15bpp), however, my plan is to use an FPGA to develop something along the lines of an SNES PPU.

My sprites and tiles would likely all still use a single byte per pixel. (Being relatively small in size, I foresee a single byte for a whole title/sprite selecting a palette bank)

This of course all works well if you're sending the pixel data down a VGA interface. (I think the OP was suggesting maybe doing that? Not sure how that works in a small LCD form factor.)

Of course the other part of what made the SNES really shine was that it had several different buses and a lot of different DMA operations that would go on during the blanking intervals of the picture.

I am open to suggestions for other LCDs if the ILI9341 is not suitable for the planned graphical implementation. The only part that is set in stone is a 65c816 in QFP (though I'll be using a DIP one for breadboard prototyping.)

Might need to do some research on that. Poking around on Digikey I found this:
https://www.digikey.com/en/products/det ... R/22531874

If I'm reading the specs right (and that's a BIG IF), then I believe it can do ~60/FPS when the dot clock is run at 8Mhz. Looks like it has several modes of operation, but importantly it appears you can send 24-bits/pixel data on a single clock pulse. It also appears to have a mode where you can operate it on an 8-bit bus through the green channel pins; assuming the pins on your FPGA are at a premium.

I haven't yet settled on a specific FPGA, but I do need to make sure it has enough data and address pins to access VRAM, receive instructions from the CPU and send data to the LCD. I'm hoping to keep the design simple, so I am hoping to give the FPGA direct connections to everything it needs. Though I am curious about the feasibility of having a second 65c816 or a microcontroller with a 16-bit 65c816 as its core being set up as the graphics controller.

I can't find the specific article I found, but there was someone who was aiming for similar graphical performance (320x240@60fps with 16-bit color) using a Lattice iCE40HX series FPGA, so that is currently one of the options I'm considering.

I have not settled on one yet for my design either, though right now I'm using a Cyclone 5 (which seems to be the Cadillac of FPGAs)

As for using the 65816 as a graphics processor itself, that can be done. Super Mario RPG did this with the SNES where the cart had a second 65816 used just to do graphics processing. (Though that version of it had some additional niceties, like multiply and divide instructions)

The reason I'm aiming for 60 frames per second is to have it be on par with other handhelds of the era like the Game Gear and Game Boy which both ran and drew at 60 frames per second. That said, the CPU won't be sending anything directly to the LCD. I intend to offload as much of the graphical processing onto the FPGA as possible (the CPU would just be telling the FPGA to move tiles around and read tiles from the ROM into VRAM for the most part.) I'm looking to make it treat graphical data similarly to how a Game Boy organizes it, though with more RAM allocated to it. I'm trying to avoid leaning too much on the FPGA, using it as a stand-in for a custom graphics chip I don't have the money to have built.download lagu

Can the SPI interface handle 320x240 with 16-bit color at 60 frames per second? If so, I'd rather use that than the 18-bit parallel RGB LCD I'm currently using.

I might use an Arduino LCD shield for testing, actually, because it would be easier to attach to a breadboard than the ribbon cable of the LCD I'm currently looking at. I have one lying around that I picked up years ago but never used. Just need to figure out how it works. I'm trying to avoid relying on things that are too modern like a MicroSD card. I intend to have a flash memory chip to hold the firmware since I have a GQ-4X programmer already.

The first phase was to get something working on a breadboard. Just a simple program that writes "Hello World" to the screen.

There will be voltage regulators changing voltage on things due to no combination of parts I'm looking at settling on a single voltage, so I suspect I'll have voltage lines for 1.8V (or whatever the FPGA needs), 3.3V and 5V going through the board.

I'm trying to avoid using an FPGA that is powerful enough to be the entire system as I feel like that would defeat the purpose. Any programmable logic chips I use would be used as stand-ins for custom chips that I cannot afford to design and manufacture, but I would want the functions they perform to be in line with what chips of the 16-bit era were capable of.

Given your goal of achieving 60 FPS to match handhelds like the Game Gear and Game Boy, and your strategy of offloading graphics processing to the FPGA, what specific graphical operations are you planning to handle with the FPGA? Additionally, how do you plan to manage synchronization between the CPU and FPGA for smooth frame updates?

Personally, I wouldn’t get hung up on the thought of “a too powerful FPGA”. As soon as any gatekeeper sees mention of an FPGA, they’ll take aim at you. It’s a given.

I’d be more worried about getting your system up and running and then see what you can do to optimise, etc… You have a massive task ahead of you just to achieve what you want to do, so put your focus towards that.

Just my 2c.