So I really hope I'm not repeating a question here but I took a look around the web (and found some posts on the forum but not exactly what I was looking for) and couldn't find much for exactly what I want to do.

I've wanted to build a 6502 SBC for a really long time, probably almost a decade, but I've never actually gotten around to doing it. I'm fairly familiar with electronics (although more with analog than with digital) and I've built some projects before (cmoy, which I hacked on some other features to, O2 Amp/Dac combo, lots of arduino stuff, tons of 3D printer board work (swapped a MEGA2560 from an arduino to a board recently that had a dead mcu) and a couple others). I read the primer and I'm still a bit confused on my starting point. The section that discussed how to start gave me some good info on what to do, so I got a notebook and started planning out features for it, and was looking to start memory mapping and trying to figure out the address decoding.

I should mention, this project is sort of a gift to my fiancee, who really loves retro electronics, specifically video game stuff. Because of this, I'd like to build it with a color display and run PAC-MAN on it. I want to use the machine for a lot of other small projects as well, and as a way to learn digital electronics.

I have about a decade of programming experience in high level languages, and I've worked with stack based programming before, so I'm fairly confident that I can get this done eventually but I think the biggest hurdle here is I've not put together a lot of digital circuits.

So with the precursor, let me explain a little bit about what I've come up with so far

I'd like to use a 65c02 or similar, but I've not ruled out the '816
I'm not aiming for super high speed, but was hoping for 2-4Mhz if I can swing it
I'd like to have 32-64k RAM, I realize I probably won't need this much, but I'd like to have it just in case (if I use a '816 I'd like to try for over 1MB)
For ROM, I'd like to have 32-64k as well, but I'd also like to investigate the possibility of using EEPROM that I can program from the 6502
I have a small CNC router that I've made double sided boards with before, will I be able to make a double sided board with it for this (it does through hole pretty well, but struggles on super small traces, I'd say resolution goes down to about 0.2mm) ? I'd like to do it this way instead of going to a fab just for the fun of it (I'm using KiCad and FlatCAM for my CAD/CAM stack)
I've looked at a few video chips that have been paired with the 6502 before, but most are either not sourceable or don't do exactly what I want
Because of the item above, I've been thinking about the possibility of running a RGB display with a parallel connection (specifically I found this one but it's not exactly what I want, and it's barely 3.3v tolerant)
I want to attach a full keyboard, possibly PS/2 but I may run a USB keyboard over a PS/2 adapter, as the only PS/2 keyboard I have laying around is really broken
I'd like to have mass storage of some kind, probably an SD card over SPI, although I'm open to suggestions
I want to have audio out, the resolution isn't super important, but I'd like to try and use something that can take samples from mass storage and play them, so I'm not spending a lot of time emulating "wakka-wakka" in waveforms, although one that can do both would be awesome
And finally, I'd like to retain some GPIO for future use, and keep it as modular as possible

So, with all that in mind, I have a few ramblings on how I think things will work:

LCD:

I originally wanted a 256x256 LCD with 8 bit color, although it seems impossible to find, so all my calculations are according to this spec
depending on frame rate, updating all pixels on this display would require 2-8M operations, which is obviously way out of range of the '02 unless I clock it super fast, which I don't want to do to start with. the '816 may possibly do a little better, especially if I use all 16 bits of the data bus to do 2 pixels at once but it's still pushing it
It also requires 64k memory just for the LCD, so poof goes my ram
The solution I came up with was to have dedicated SRAM for the display and some sort of "frame ready" line that I pull high/low when the CPU is done writing to the SRAM. This fixes losing all my ram, but it doesn't fix the ridiculous amount of operations I need to do to update all the pixels. To solve that issue, I decided to treat the display video somewhat like a GIF, that is, only update the pixels that are changing in the next frame. This lets us have a very slow first frame, but the following frames can be relatively fast (if PAC-MAN is 32x32 and so are all the ghosts, that's 1,280 pixels total that need to be updated, and if they're only allowed to move one pixel each frame, that gives us only an additional (32x5) for a total of 1,440 pixels to update each frame)
I'm not sure how many cycles it will take to update a single byte of the SRAM I'm using for video, I seem to remember it was fairly fast for normal memory, but at only 1,440 pixels updated per frame there's a bit of headroom to play with and still achieve a decent FPS (my goal is about 30) even at 1Mhz system clock.
I realize I've left out a few pixels for the score display, but I'm also hoping I can get some text generation going on so I can do one ascii value write for each character, rather than having to bit bang letters onto the screen (bit banging pacman will be hard enough)
With all this in mind, I'm aiming to keep the draw subroutine at about 10% of the cycles of the CPU, leaving 90% for game logic

Now, the above rambling about the LCD may be waaaaaaaaaay off base, because I've not dealt with drawing to LCDs much even with my arduino projects, so there may be way better ways of achieving this result (I read something about scanline rendering, but I'm not sure how to use it or how it would play in here). If there's a video chip that can do all this on its own, that would be great, although I would like to keep the project sort of "pure" and not put something arm based running at a couple hundred Mhz on it. I also don't want to do VGA (right now) because I'd like to put this all in a 3D printed enclosure, and my printer doesn't print large enough to mount any VGA panels out there.

Game Logic:

I know this is a little off topic but it's related to the project in general, so I'd like to see if I'm on the right track when thinking about this in a memory sensitive and stack based context. I think the hardest part is managing the map, and the different entities (pacman and ghosts) moving around it. If I simplify the map to a 256x256 pixel area, and use single bits as walls/ghosts/pacman/dots I think I can get away with doing it with only about 9,600 bytes for the map itself, and then some bytes to store locations of pacman and the ghosts and walls (walls I'm going to try and use some bitmasking to save more memory, and if none of these items are in a location that has a 1 in the map, I'm assuming its a dot, I'll need to also save locations of the powerup dots). Doing it this way also allows me to move pacman smoothly, since I have a 1:1 backing of pixels to the map in memory

Board Design:

So, I'm still a bit green with board design, but I've put together a few working boards (with some 27016 I2C I/O expanders and a few other misc chips) that I made in Eagle (and now KiCad) and then milled on my CNC. I don't know a whole lot about protecting lines other than to use a ground plane and power plane (which, with only 2 sides is impossible) but the primer had a lot of good info on this, as far as keeping chips very close together, making connections as short as possible, using bypass capacitors, and making fat power lines in a star configuration (which I'm not familiar with but I'm sure it's not incredibly complex). Past this, I'm pretty clueless (chip placement, port placement, etc)

Component selection:

I've looked at the 74xx logic chips before, I added one in a project I never actually built (it was really just a joke making it) that was a 3 in 8 out mux iirc. (I used it to mux CS on some 23s17s so I could have 64 chips on the same board and same SPI lines, turning 7 IO pins into 1,024 IO pins) but I honestly only know how they work in theory, and even then I don't know a lot about certain types of chips. Basically, I can work with boolean logic very well but once it's in hardware I'm a bit lost. I also saw the 6522 (I believe the VIA) and 6521 (I believe the ACIA) mentioned a lot in the primer, and I know that the ACIA gives serial communication, and the VIA gives parallel, but I'm still a bit confused on exactly how I need to use them. For SRAM, although I've not dealt with it before, I'm more knowledgeable, because I've read a lot about it in the past and it's fairly simple to grasp, but I've not looked into specific chips yet. The same goes for (E)EPROM. As far as the SD card goes, once I have some form of SPI I know there's about a billion interfaces out there that will let me access it. For display, see the above notes on the LCD

General Consensus:

I don't think I'm going to finish this in time for valentines day, but I've got a backup gift, so it's ok

TL;DR: OP has no idea what he is doing and needs some guidance on taking on this project

I believe I've touched on everything I have in my notes, except memory mapping (which I've barely started) but if I have more info I'll drop it here, thanks in advance for the help, it is much appreciated.

Welcome.

By "read the primer," do you mean the 6502 primer?

Many of the LCD modules have a fair amount of intelligence built in, and can do things like limited scrolling which would take care of panning without having to re-write all the pixels over the interface. There are also add-on boards for some LCD modules which add things like text capability so you don't have to calculate which pixels to turn on for text. Just tell it where to start and give it the ASCII of what to display. A module (or its add-on board) may hold many pre-formed frames in its own memory so if there are several that you use all the time, you can tell it to just bring up a particular one and then you only change a small amount of it.


The ACIA, for asynchronous serial communications, is the '51. The '21 is similar to the '22, but somewhat less capable.

_________________
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?

Hi,

Welcome to the wonderful world of the 6502 SBC

I embarked on something similar (but not really aiming for a game type system) recently - built a prototype on breadboard, then stripboard, now on a double sided PCB. It run at 16Mhz and I've not done anything overly special to make it run that - that certainly wasn't my aim, but I did use 10ns memory chips. I may just be lucky on the PCB, but it ran at that speed on stripboard too. It wasn't happy on breadboard, but my layout was a bit sloppy, however it did run at 1Mhz OK. So I'd suggest not being to concerned about speed for now - get the thing built, then do what I did and keep trying faster and faster crystals. 16Mhz is 2Mhz over the rated speed of the WDC65C02S and I only tried that because it was the one I was using to drive the ATmega. I just ran a wire from that crystal to the input on the 6502 and was amazed when it worked... (Use can oscillators rather than crystals though - easier to manage, if a few pennies more expensive)

Colour video was (still is) my nemesis too - I cheat and use an Atmega for monochrome composite video output.

I also stuck all the address decoding (which is very minimal) and glue logic between the 6502 and ATmega into a single GAL 22v10.

Mine so-far:

https://unicorn.drogon.net/ruby-pcb0.jpg

So sit-down, sketch out some ideas and do keep us up to date on progress!

(and for inspiration, look-up "chasing the beam" and have a look at how the Atari 2600 managed to run pacman in a 6502 system with virtually no ram at all!)

Cheers

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Graphical output from a shared RAM area is hard. Traditionally accesses from the CPU and video circuitry must be interleaved on alternate clock phases which calls for some complex circuitry or a CPLD/FPGA. Dual ported RAM would make things easier but its rather expensive.

LCD panels like the one you linked to often come with a interface chip the holds the video RAM and have both parallel (8 or 16 bit data + some address + control lines) and serial (SPI or I2C) interfaces. The parallel interface usually offers a better data exchange rate than the serial. I've been working on an open hardware project that uses these modules.

https://www.ebay.co.uk/itm/3-5-TFT-LCD-Screen-Module-Supports-For-Mega2560-HD-320-480-for-Arduino-UK/253686518715?_trkparms=aid%3D555017%26algo%3DPL.CASSINI%26ao%3D1%26asc%3D55149%26meid%3D6c754439dbae4f6484e0709c69cb584b%26pid%3D101006%26rk%3D1%26rkt%3D1%26%26itm%3D253686518715&_trksid=p2045573.c101006.m3226

They include the level convertors for 5V signals and could be attached to a 6502's buses.

Displays like this don't support sprites and higher resolutions often need more data to draw an image which means more cycles to transfer it and more CPU memory to hold icons etc. I'm driving mine from a 70MIP PIC24 and the update is fast but still visible.

You could look at something like the Gameduino which is accessed via SPI. Lower resolution output via VGA but supports sprites. You could bit-bash SPI from a PIA/VIA chip or implement an interface in a CPLD like the Daryl's '65SPI'.

https://www.ebay.co.uk/itm/New-Generic-Gameduino-for-Arduino-BXC4550/183607606842?hash=item2abfddbe3a:g:9-UAAOSwF7lcQ6zt:rk:3:pf:0

I bought an FTDI EVE display a while back to interface to a 65C265/816 at some point. It has a powerful video control chip and a 5" display. You download data that describes what you want display (as a tree of objects with positions, orientation and scale factors) and it converts it on the fly to the display image. Change the data and the image updates on the next frame - like everything is a sprite It seems cheaper clones are now available

http://www.hotmcu.com/5-graphical-lcd-touchscreen-480x272-spi-ft800-p-124.html?cPath=6_16

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Wow, so many replies already, thank you all for your input, I really appreciate it, I'll try and section this out and reply directly to parts of comments to maintain some clarity (hopefully better clarity than I had at 2am before I went to bed last night)


Yes, that's the one, and I may have misunderstood some of the information on the Displays section. From what I was seeing, there were plenty of options for text based panels or monochrome dot matrix panels but I didn't see a lot of info on color panels. I'm worried about using a serial line because the transfer rate for something similar to 256x256 at 8 bit color depth would be about 524,288 kbit per frame, so about 15.7 mbit per second for 30 fps. I would be worried I couldn't achieve this kind of bandwidth but I could use some of the tricks I mentioned above on a serial line to greatly reduce the bandwidth load


I'm not certain how scrolling actually works on a per pixel basis to be honest, without the use of sprites that is. I was actually planning on using an add-on module for the text, because from the primer I seem to remember they were mentioned, and it should make ascii a lot easier, I was only worried that it would be hard to integrate with the type of display I'm trying to use. As far as the pre formed frames, I'm a little confused on this part, do you mean like the map frame I could leave loaded and then draw stuff over top of it without much effort?


Ah, sorry about the mixup there, thanks for correcting me.

Overall, I'm just very cautious about buying parts and putting something together that doesn't work, especially since the only oscilloscope I have was one that my grandfather built in trade school in the 50s that he gifted to me (and the horizontal hold doesn't even work on it). And I'm also very budget oriented on the build presently, as I've been working on setting up a home business that has ate a lot of my additional cash recently. Because of this, I want to know exactly what I'm getting into it before I purchase the first component.

And thanks for writing and providing the primer for people just getting into this like me, it really is a wealth of information

Wow, that's some impressive speed, I would absolutely love to get those kinds of results on this project, but I'm trying to keep my goals as small as possible, since the task ahead is still a big one. As far as using an ATMega on the board, I'd prefer not to, but if I have to I can.


Ya, after reading forum posts about this it seems that a lot of people struggle with it and most people have slightly different requirements


I'm going to look this up and read about it, thanks for the tip, if I can simplify the glue logic for address decode it makes things way easier


Very nice! I like the simplicity of the layout and the board, the boards I make look way less professional (haven't made solder masks yet as I'm unsure where to get the chemicals for it). Also, I don't have a good way of plating through holes, so I'm thinking it may cause slight performance losses.


I definitely will, this is a project I've wanted to start for a long time, and I'd like to make something that's pretty slick.

I figured there would be a kicker to sharing video ram with normal ram, my hope was to have a "busy" line from whatever mechanism I used to stream the VRAM into the display and then only update the next frame after that line is low, but if the timing is too complex, I should probably step back and re-evaluate


Thanks for this, I'll look at it in just a bit and see if it's what I want to go with.


Well, I'm trying to stay away from VGA right now and do a fully integrated display, but I'll look into this as well, and keep it noted


This looks pretty interesting, I'll have to read on it as well

thanks for all the links!

I've not made a PCB at home for a very long time now... That board was laid out in Fritzing and made by Seeed in Chinashire. I think it cost me < $25 for 10 boards and took 2 weeks to deliver. I might have paid a few $ more for the red solder mask (Red because it's Ruby because last year marked 40 years of my tinkering with the 6502)

The stripboard version is

https://unicorn.drogon.net/ruby-02.jpg
https://unicorn.drogon.net/ruby-03.jpg
https://unicorn.drogon.net/IMG_20181115_164041.jpg

which might be a cheaper build if you like that material.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I've dealt with stripboard before, and I honestly don't like it, the projects I built on it always ended up messy, and (since they were analog projects) normally noisy and out of spec. This is part of the reason I got the CNC, so I could quickly prototype PCBs for components without having to use stripboard. If it comes down to it, I'll use it, but I'm really hoping to have a working PCB.

I'll be very interested in seeing your results - last time I saw some CNC routed PCBs the quality was somewhat lacking and trying to get a track between 2 IC pins was not possible...

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

There is some effort that has to be put into the setup of every PCB (levelling with a software that will edit GCode on the fly) if you put in the effort, and use the correct bit and feed rate, you can get very high precision results. Generally, since my machine is sort of cheap, 0.2mm is about as low as I can go, and for most boards I shoot for 0.4-0.6mm. It works great with through hole components like DIP sockets, the only issues I've had so far are with SMT devices. I've attached a picture that I just took of a failed board I had laying around (this was early in the process of making PCBs, I keep the failed ones around though to remind me of particular failures) so you can see the resolution



EDIT:
I forgot to mention, this was also with a previous CAD/CAM combo that got a bit lower resolution. Getting tracks between ICs is difficult, but I have a board laying around somewhere showing it can be done, if I find it I'll take a picture.

Additional EDIT: I meant between IC pins, rather than between ICs, ultimately though, I do try and avoid going between pins unless necessary, because the difficulty is fairly high and the yield of good boards is low even with good setup. Same for putting vias under chips, because soldering small wire to connect both sides can cause the chip to not seat.

Yea, the color display is a real problem.

It's kind of surprising given the retro hobby world that someone has not created a modern "graphic chip" FPGA that works well with 8 bit CPUs.

As I understand it (which doesn't necessarily mean anything), there's nothing stopping someone from doing "low res VGA". Where the output is, indeed, 640x480 VGA, but the pixels are down sampled, so 320x240 or 160x120 so as to not crush the memory requirements on the host machine.

I just think targeting VGA is the way to go simply because monitors that accept VGA are ubiquitous in contrast to pretty much anything else, even RGB.

All of the common solutions for color graphics are little more than smart terminals, where you send data using some high level protocol to the machine and it displays it. These solutions solve lots of issues, but not really great for games, where you want to dual buffer and use sprites.

I know the talent is out there to do it. We have the fellow here laying out 12,000 TLL chips to put in what's akin to a supercharged 12 cylinder motor graphics sub system and bolting it in to the Mini Cooper of computing, a VIC-20.

But, demonstrably, this is a Hard Problem simply by the fact that such devices don't seem to exist.

The best we have is things like the Propeller, but that's not a great pairing with the 6502 save as a smart host to stream serial data too.

A game wants to fill a block of memory and then tweak it and/or use sprites on top of it. A 6502 can't afford to repaint the entire screen in RAM each frame. It simply doesn't have the bandwidth.

Similarly, the shared RAM aspect. Naturally this has performance ramifications. All of the older machines suffered from cycle stealing by the graphics subsystem. Most basic games did the bulk of their logic during VBLANK. A) it was a natural place to do the work, B) is was "fast enough" (30-60 times per second) C) it was fastest, no real cycle stealing during VBLANK as there's nothing to show, so no need to read the RAM. More sophisticated games would "race the beam" so to speak, doing work during the actual screen refresh.

So, yea, it would be nice if someone was able to cook up a FPGA Antic or VIC style chip that plays well with others and interfaces to a VGA monitor. I don't think the market is big enough for a manufacturer to do something like this, but there's a large enough hobbyist scene that could sell a bunch of those I'd think.

Well, I can't fault the ambition - but the chances of getting such a complex machine working as a first project are slim. The single most important advice I would give here is to plan for a modular build, so that if you make a big design error in one part, you don't have to scrap and rebuild the whole machine to fix it.

Your first I/O devices are likely to be a serial port, or some simple buttons and lights, not a full-blown keyboard and video display. You'll want the serial port to load new code onto your machine without constantly unplugging your EEPROM chips, so I'd consider making that part of the core machine - and I'd suggest a 28L92 to replace both the 6551 and 6522 in one superior package. Everything else should be on daughterboards.

The next advice I'd give is to forget any notions of redrawing the whole screen every frame. You cannot effectively do that with a 6502 - even at today's higher clock speeds - unless you limit your graphical ambitions to the level of the Atari 2600, or possibly if you implement a "text plus attributes" display. You can still do some interesting things with the latter, but understand that this is made possible by only 1KB of data being needed to generate the Teletext display, versus the 64KB you need for a 256x256x8b display. With an 8MHz CPU, you could conceivably achieve similar performance with a 4KB display which would be slightly more capable. But a full-colour bitmap display will only update far more slowly.

You may well have seen C64 demos doing incredible things at 1MHz and full framerate. The C64 can do those things mostly because it has a display system with hardware sprite support. It's very easy to move a sprite around every frame, or even every scanline, compared to updating a full-screen bitmap. Experienced democoders have many tricks up their sleeve from an extremely deep understanding of the C64's hardware. This isn't a C64, but most of the effects likewise come from reprogramming the video hardware every scanline.

Or you could use an intelligent display module, which will tie your graphical capabilities inextricably to those the module provides. You can't decide on a resolution and colour depth in advance, then look for hardware that matches; you must look at what hardware is available, and choose from the options available. They are many, but they are not infinite.

When it comes to hardware, some of your first decisions will be: What voltage will you be running at - 3.3V or 5V - as each will make a different set of hardware easily available to you? Are your soldering skills up to handling modern surface-mount devices, or should you stick purely to traditional through-hole stuff? Will you use a custom PCB, wirewrap, stripboard - each of which has their own advantages and problems? PCBs can be very capable, but need a lot of careful planning and usually a wait for fabrication. Breadboard is *not* an option except for very straightforward experiments, and won't allow you to achieve high performance reliably.

Thanks for that. I have worked in very high precision CNC mill, etc. environments in years past where it might have been relatively easy, (with mills costing a 6-digit sum) but I just wasn't sure about the "home" type of mills that seem abundant these days.

As for vias under chips, well... On that board of mine there are resistors and decoupling capacitors under some of the ICs. You just need sockets without too many internal webs to make sure there is space... And note the memory ICs are vertically stacked too - just need to get a bit creative...

You might find issues connecting the chips up without going between IC pins though - especially going 6502 to 6522 - the 6522 is just ... hard, or designed to be mounted on a pcb vertically rather than horizontally as mine is. So on mine, the output pins are on the left of the chip, so have to go through (or round) the 6522 and the data/address lines are on the right, so again through or round....

Do read Garths stuff here though - but you might know some anyway - in particular you don't actually have to wire d0 on the 6502 to d0 in the ram chip, same for the address lines into the ram - that can make routing easier sometimes. My board puts this to good use.

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

(Hijacking this thread a little)

So my plans, starting last summer to get back into 6502 and on to the 816 was to start with simple video then colour... I know Zilch about programming FPGAs (and no real desire to learn right now), So Phase 1 is complete - 6502, monochrome graphics and IO done via an ATmega - that I'm not doing much with right now. My plan was to treat it not as a block of ram you poke pixels at but as slightly higher level thing, so give it high level commands like plot, line, move sprite A to X,Y, did sprite collide and so on... That takes the "heavy lifting" off the 6502 and pushes it to the graphics processor - which is a bit like the way a modern PC might work via a GPU or like the old TI99...

Phase 2 is to use a $5 Raspberry Pi zero as the graphics (and IO) processor. I have a lot of experience with 2D graphics on the Pi and already have the above functions in C to use as the back-end (as part of a BASIC interpreter I wrote) - the key, as you mention is limiting the frame size but even at qvga you still need 2 byts for the X coordinate. The physical interface being something not a million miles different from the PiTube project (of which I have a couple) although if I can run my '816 system at 3.3v then the interfacing is slightly easier and I could probably lever a 16-bit interface to/from the Pi although the level shifters do work well. (data, strobe, ack style rather than some sort of bus snooping)



It depends on the game to a degree. My benchmark was Space Invaders, but Pacman - with the above scenario I think it might be relatively easy - static background, sprites for the player, ghosts, dots and super-dots, then it's really just a set of arrays to keep track of their locations (and map type data) and off you go... (famous last words!)



There is the Foenix project - a 65c816, a few MB RAM, FPGAs, sound chips, video, hardware DMA, sprites, etc. it's an impressive system, but right now, still with the creator, little software and possibly a small but enthusiastic market. Who knows.

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/