65C816 Handheld Planning

[Ardis]

I need to preface this with the fact that I have not built any kind of microcomputer or similar device before and have been doing research in my spare time. I'm coming into this with a decent understanding of how computers and 8-bit to 16-bit game consoles work at the hardware level, though I've never designed one from the ground up like this. I have a habit of taking on projects far above what I currently know and figure out what I need to learn along the way to get myself to learn new skills. Right now, I'm doing early research on building a 16-bit handheld game system using a 65C816 as its CPU and would like to help with being pointed in the right direction for my research and double checking what I think I know.

I'm looking to build a 16-bit handheld that has similar capabilities to a Sega Genesis or Super Nintendo in terms of graphics. I intend to avoid using FPGA solutions where I can. Graphics and audio solutions are where I might have to use an FPGA. If I do, I intend to hold it to the limitations of a system of the 16-bit era.

My plan is to try to create this as an open source handheld that anyone can build and develop for. Should I give up on this project, I do plan to make all of my project files available in case someone more talented than myself wishes to pick up where I left off. I've currently got notes and partial schematics which I'll expand as I finalize my parts list.

My goals with this project are as follows:

• It must be made using currently in production components that can be purchased by hobbyists, preferably parts that have ECAD files for EAGLE available as making new footprints and symbols is tedious
  The first prototype's parts must fit on a $100 order from a single parts supplier (currently comfortably within budget with $30 remaining to work with for audio and video solutions)
  Easy to develop for, at least comparable to using GBDK (toolchain for making Game Boy games using C that I use)

Technical goals:

• Uses a 65C816 running at 10 Mhz or higher (the one I'm looking at has a maximum supported clock of 14 Mhz)
  Displays a 320x240 resolution with 15-bit color at 60 frames per second (the LCD screen I'm considering for the prototype supports QVGA and 18-bit color) <=== This is where I believe I will need the most help
  Makes the full 24-bit address bus of the 65C816 available to software developers (currently using the de-multiplex setup suggested in the 65C816 datasheet, but it might not be suitable for higher CPU speeds)
  Minimal use of FPGA chips, using other types programmable logic chips where possible. Any FPGA used will be the bare minimum to achieve the task of a chip it's a replacement for and will be limited to what 16-bit era consoles could do
  If it fits in the budget, I'm considering a graphics co-processor that would allow SNES Super FX-esque 3D graphics (at least if I go the FPGA graphics route)

The first phase of this is to get a breadboard prototype assembled, but doing this requires I have a parts list to order. I have a CPU, basic address demux solution, RAM, an LCD and shift registers for the controllers, but haven't determined what I need to drive that LCD yet. The first thing I'm looking for help with on this project. I'm looking through various 65816 and 6502 projects with video output, but I'm not using VGA and don't know if I can base viability of the chips they're using on that. The LCD I'm currently looking at (DT028BTFT by Displaytech) supports 18-bit RGB input. I'm not 100% sold on this one as I am trying to find something closer to a 3" screen at a similar price and may have to revise my LCD choice based on what kind of video output I can generate within my budget.

I'm currently watching a video series of someone getting VGA output out of a 65816 using an Atmel ATF22LV10 PLD to see if his solution might be viable for my project, though it is a bit over my head so I'm trying to do the necessary reading to understand his solution. I wanted to see if anyone else had other video output solutions to suggest that would not be difficult to adapt to an LCD screen instead of VGA output.

[barnacle]

Good morning and welcome!

A couple of points: I wouldn't lean too heavily on the ECAD requirement: Eagle has gone somewhat out of fashion with hobbyists since Autocad took over and changed the licensing and you might consider Kikad - although it's a bit of a jump from Eagle's UI, there are very many parts available for it.

And secondly, I've been looking at ways to do 'ttl' hardware for VGA, SVGA and similar; depending what you want to do it can either be pretty simple with basic counters and such, or a nightmare

Neil

[Ardis]

I've been meaning to switch over to Kicad, but I'm a procrastinator by nature (notice the difference between my join date and actually making that post.) I'm planning on making that switch as I migrate everything from Windows to Linux on my main PC.

As far as I can tell, the three major considerations I have on a video solution are:

• Performance, being able to achieve the 320x240 video resolution at the desired framerate and color depth.
  Cost, keeping the project under the $100 budget for parts
  Size, keeping the IC layout compact enough that I can fit this in a handheld device (target size is comparable to the lower half of a Nintendo DS with a similar button layout)

I don't know if we can call what I'm doing VGA as the LCD I'm using doesn't take VGA signals. The LCD I'm looking at has two supported options, MCU and 18-bit RGB.

[barnacle]

One more to consider: power consumption

Does your display allow writing to individual pixels, or do you have to sequentially squirt a whole field at once?

Neil

[pjdennis]

Ardis wrote:

Technical goals:

• Uses a 65C816 running at 10 Mhz or higher (the one I'm looking at has a maximum supported clock of 14 Mhz)
  Displays a 320x240 resolution with 15-bit color at 60 frames per second (the LCD screen I'm considering for the prototype supports QVGA and 18-bit color) <=== This is where I believe I will need the most help
  …
  Any FPGA used will be the bare minimum to achieve the task of a chip it's a replacement for and will be limited to what 16-bit era consoles could do
  If it fits in the budget, I'm considering a graphics co-processor that would allow SNES Super FX-esque 3D graphics (at least if I go the FPGA graphics route)

Given the target resolution, color depth and frame rate, I think you would want at least some form of graphics compressing for typical games. The FPGA solution may be the most realistic option. You can have the FPGA contain the frame buffer(s), drive the LCD, and include functionality such as point, line and sprite drawing.

I’ve seen a few examples online (With HDL code) of people using FPGAs in a way similar to this, so you can probably find something to use as a starting point.

[Ardis]

barnacle wrote:

One more to consider: power consumption

Does your display allow writing to individual pixels, or do you have to sequentially squirt a whole field at once?
Good point. The documentation for the LCD doesn't specify, so I'll have to look into that if not contact them directly. That said, the LCD I was looking at was chosen not only for price and resolution, but because it was on the lower end in terms of power consumption.

Neil

pjdennis wrote:

Given the target resolution, color depth and frame rate, I think you would want at least some form of graphics compressing for typical games. The FPGA solution may be the most realistic option. You can have the FPGA contain the frame buffer(s), drive the LCD, and include functionality such as point, line and sprite drawing.

I’ve seen a few examples online (With HDL code) of people using FPGAs in a way similar to this, so you can probably find something to use as a starting point.

I figured I'd probably have to go the FPGA route. The hard part is that most of the projects I've found are doing VGA output to an external monitor while the LCDs I'm looking to use take a different video signal. It makes it hard to figure out the right specs for an FPGA to consider for the project. I want to make sure the FPGA is cheap, compact and low power consumption, being the bare minimum to achieve the video output goals.

[Agumander]

If you're using the DT028BTFT you linked and don't need external VGA, you should be able to just write to the ILI9341's display buffer and not worry about generating syncs and fields.

The MVN/MVP block copy instructions will let you copy a byte per 7 cycles. Assuming 10Mhz CPU, 320*240 res, 16-bit color you could fill the screen 9 times per second. An FPGA could be used to copy a byte every cycle, though you'd still need to be economical with your pixel writes to get a good framerate.

How do you intend to store software for your handheld? If you go the cartridge route you could put the configuration memory for your graphics FPGA on the cartridge and let games bring their own custom functionality for the GPU. That might make the FPGA feel more like an interesting feature rather than a cop-out.

On the general open-source note, be sure to look at not only the price of components but also their quantity available and whether alternates from other manufacturers would be available. This is what's causing me the most headache as I scale up my own 8-bit console project. If you only plan on building one then any components are fine, but once you start sharing the project you start worrying about emails with the subject "Part Life Status Notification".

[barrym95838]

I know that it's not as fancy as your proposal, but perhaps some valuable insights can be gained by studying the Dodo? I'm always impressed by finished projects, and the Dodo seems like quite a fun little machine to learn from by example.

[barnacle]

Agumander wrote:

worrying about emails with the subject "Part Life Status Notification".

It's even worse when the boss says, we need three hundred thousand of those next year...

(I had a personal project some years ago which used an out-of-mfr display, but of which there were tens of thousands available. A couple of dozen in, the warehouse burnt down and ate the lot )

Neil (who spent a year off and on writing a slab of code to identify every component we used, and an awful lot more, just from the manufacturers' part numbers. I went right off Würth on that project - everything they do is a single part number, no parametrics at all)

[Ardis]

Agumander wrote:

If you're using the DT028BTFT you linked and don't need external VGA, you should be able to just write to the ILI9341's display buffer and not worry about generating syncs and fields.

The MVN/MVP block copy instructions will let you copy a byte per 7 cycles. Assuming 10Mhz CPU, 320*240 res, 16-bit color you could fill the screen 9 times per second. An FPGA could be used to copy a byte every cycle, though you'd still need to be economical with your pixel writes to get a good framerate.

How do you intend to store software for your handheld? If you go the cartridge route you could put the configuration memory for your graphics FPGA on the cartridge and let games bring their own custom functionality for the GPU. That might make the FPGA feel more like an interesting feature rather than a cop-out.

On the general open-source note, be sure to look at not only the price of components but also their quantity available and whether alternates from other manufacturers would be available. This is what's causing me the most headache as I scale up my own 8-bit console project. If you only plan on building one then any components are fine, but once you start sharing the project you start worrying about emails with the subject "Part Life Status Notification".

I'm not sold on that specific LCD yet. It's just the one I'm currently considering and budgeting around. I have been looking for other options. Because handhelds live or die on their LCDs, I'm okay with ordering one from another site if someone has done something similar and has a suggested model. That said, I want ones from reputable manufacturers, not nameless AliExpress garbage. I was looking at it because it was the cheapest option for a 2.8" LCD that didn't have worrying power consumption and was capable of 320x240 (though this one is a 240x320, meaning I'll have to run video signal sideways.) If there are better options for getting 320x240 to an LCD at 60 frames per second (which is what Game Boys runn at,) or even 30 to match NTSC, I'll happily hear those out, too. I was planning to offload as much of the video functions onto the FPGA as possible. It would organize and draw graphics in a similar manner to a Game Boy as I'm more familiar with that than any other console.

Games would be stored on flash cartridges, yes.

I'm not planning to make just one, but I have no delusions of this catching on and being a viable product when everyone buys FPGA driven systems that sell for less than my bill of materials and come with thousands of pirated games pre-installed. The goal is to create an open source homebrew system that anyone can build and can be adapted based on parts availability. Something I would like to aim for is making it so it can be turned into a home console or given a Jamma connector for an arcade cabinet using the same core parts.

barrym95838 wrote:

I know that it's not as fancy as your proposal, but perhaps some valuable insights can be gained by studying the Dodo? I'm always impressed by finished projects, and the Dodo seems like quite a fun little machine to learn from by example.

The Dodo was one of the things that got me thinking of this idea. I'm not fond of the screen resolution, though, so I figured I'd look into making something more functionally similar to an SNES using a 65C816 (since the 65816 is what the SNES's CPU is based on.)

[Proxy]

oooh, interesting project idea! i hope you go through with this one.

i've had a similar idea a while back, using one of these cheap TFT shields designed to directly plug onto an Arduino (most of which use the same controller as the DT028BTFT you mentioned):

320x240 @ 16-bit or 18-bit color with an 8-bit parallel interface (instead of SPI like they usually have), plus a built in touchscreen and µSD card slot.
so all you need is a CPU, some RAM, ROM, and logic to combine everything and you'd have a complete self contained system that (besides a µSD card and power) doesn't require any external connections like a keyboard or UART to function. though of course that does require some software to take care of user input, the display, and a file system.
then you just need a battery setup with a protection/charging circuit and you would have the worst DIY smartphone in the world!

but i've shelved that project for now because i did a bit more digging about these shields and found that while they boast both 3.3V and 5V operation, they will not function without a 5V supply and only the LCD controller has some level shifters, and while the µSD slot does get it's 3.3V from the onboard regulator, the data lines are directly connected to the pins on the side, so on a regular 5V arduino using a µSD card with this for a long time will likely damage the card.
so overall don't buy these if you plan on using the µSD slot.

but the overall idea is not dead. you could still try something similar by just using Adafruit's variant of the board. while it's obviously a lot more expensive, it's also much higher quality and larger, leaving more PCB space for the board that it would plug into, plus it has proper level shifting and it does actually work with only 3.3V power and IO. (which i'd recommend anyways if you plan to go battery powered).

running everything at 3.3V would also give you the chance to just go with an FPGA like a MachXO2 which are relatively affordable.
i know you said you wanted to avoid an FPGA, but honestly i don't thnk a 65816 can feed the LCD data fast enough for a usable framerate...

let's just do some math:
If set the display to 16-bit color mode, every pixel needs 2 Bytes of data. so for 320x240 that's 150 kB which need to be send within ~16.6ms to achive 60 FPS. (assuming the worst case where each pixel needs to be updated).
that works out to ~108ns per Byte (or 216ns for 30 FPS), the controller has a write cycle of 60ns so it could in theory be possible, but definitely not if the CPU does it manually (even at +20MHz).

so using an FPGA to implement some hardware acceleration, like a DMA controller/Blitter, will help the CPU out massively.
you could go a step further and have the CPU work with 8-bit color and have the DMAC convert the 8-bit color to 16-bits before sending it to the LCD using an internal look up table or similar. this would obviously lower the total colors from 65k to 256, but would make operations like copying and blitting twice as fast while also reducing the memory footprint.

welcome to hardware design, where every decision is a trade-off!

anyways hope you continue this project and keep us updated!

[plasmo]

I've been playing with similar idea but with 68000 or Z80 which are significantly slower than 6502 at the same clock cycle. Here are a couple designs for Arduino mega2560 enclosure.

6502 can run reliably to 25MHz. With the help of CPLD, 25MHz 6502 with 512KB RAM and CF disk can fit easily in an Arduino enclosure. Add a 320x240 QVGA display shield, you'll have all 5V, small, compact, and inexpensive unit without using FPGA. I think it is very realistic goal. Go for it!
Bill

[Proxy]

getting a system with a display like that running without an FPGA (or even CPLD) is not an issue, i mean the interface is almost the same as for a character LCD.
but since it seems that Ardis aims for pretty high refresh rates it would require a bit more horse power to pull off, even with a speedy CPU.

and i guess you're right that they could just go for it. no reason to aim for perfection on the first try. how about just getting a 65816 system running on a breadboard in the first place, then adding one of those shields with a bunch of wires (or an adapter board), and then go full PCB. maybe mess around with some GALs or CPLDs as well. just one step at a time.

on a side note,
one thing i also didn't mention is that while the cheap shields have no level shifting for the µSD card slot, you can sort of use it with 5V by using open collector oputputs for SS, SCK, and MOSI, with 3.3V pull ups on them. which can be "faked" using a VIA (or any chip with programmable IO) and some diodes facing towards the VIA pins.
the diodes make it so that when the VIA drives the pin low it gets pulled low on the µSD card, but when it drives the pin high it's like high-Z on the other side, so the pull-up drive the µSD card pin to 3.3V. or you could just use a uni-directional level shifter IC...

the MISO lines requires no level shifting, even though 3.3V is technically too low for 65xx chips to recognize at 5V, in my experience it works perfectly fine and i think it's just another case of the 65xx datasheets being a bit too pessimistic.

[Ardis]

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.

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.

[Proxy]

Ardis wrote:

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.

nope, sadly not. SPI is way too slow for that.
the Datasheet for the ILI9341 mentions that the maximum speed of the SPI interface is 10MHz, so transferring a whole frame of data will take ~122.8ms (~8 FPS).
when it comes to graphics you just need large bandwidths which means wide data buses or very high transfer speeds.
so like said if you want to actually get 60 FPS you have to use atleast the 8-bit parallel interface at pretty high speeds, or the 16/18-bit one at half the speed of the 8-bit interface.

Ardis wrote:

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.

that's a bit of a confusing statement, µSD cards are almost 30 years old at this point, and both very cheap and easy to interface. you yourself wanted to use SPI for the display which has an equally if not more modern LCD controller on it, so why draw the line at storage?
and yea i would recommend using Flash chips for the boot code of the system. and if you give the CPU access to the ~WE pin on them you can have the CPU reprogram its own boot ROM, which can be risky but also pretty convienent as you then don't need use an external program to update the ROM.
though still having some form of storage would be a good idea, being able to load, store, and transfer files conveniently between your system and a PC can be very useful for software development.

Ardis wrote:

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.

what other parts do you have planned that would require up to 3 different voltages?
basically all FPGAs i know of can run at 1.8V-3.3V, the ILI9341 specifically needs 3.3V, cheap SRAM, Flash/ROM chips are also available for 3.3V, and the 65xx have a voltage range of 1.8V-5V.
so unless i'm missing something, you should be able to just run the whole system with only 3.3V.