Build a 6502 Computer
eater.net
eater.net
He's an absolutely excellent teacher, and his series on building an 8-bit computer from basic logic gates is a super interesting watch that has me on the verge of buying a ton of breadboards and attempting it myself.
The earliest videos are a bit rough but still very informative.
He did some videos about the project [2] [3].
I absolutely hate that he formed the group on Facebook. I'll be missing so much.
[1] https://github.com/commanderx16/x16-emulator
Watching him grow his retro channel has been a lot of fun. Seems like a great guy, and he's got a sense of where retro hits home.
https://murray2.com/forums/commander-x16.9/
It's still primarily on Facebook, unfortunately, but the forum is starting to finally gain some momentum as well. Lots of information on the project in there.
Some good discussions on other retro topics too. Worth a visit.
His current choice for a video co-processor "Vera" excites and concerns me in equal measure. At the top-end, it outputs to VGA with a 640x480 bitmap mode using an an active palette of 256 colors (out of 4096 colors) per pixel. It supports 128 sprites and interrupts (used to indicate sprite collisions, an active video line, or vsync). All that sounds great, doesn't it?
The majority of what I don't like is that the video processor is essentially off of the main bus. The CPU only has access to video through a set of 8 registers (plus interrupt). So it has 128k of private video memory and an additional 16k for video registers, palette, and sprites.
If I'm reading this correctly, its private video memory won't hold a full 640x480 256 color bitmap image, which would be ~300k. So it seems like you'd have to load video memory with the second half while it is drawing the first half (and vice-versa). I'm also wondering if an old-school technical like page-flipping is really going to be possible here.
EDIT: Or to put it another way, because the video co-processor doesn't have enough memory to hold the entire image all at once time, and because the video co-processor cannot access main memory, just to hold a static photo-realistic image on the screen you're going to have to constantly copy ~300K of pixels from main memory into video memory... each and every frame. If I'm doing my math right, that'd be more than 36 million operations per second just to pump the data into the video co-processor? It reads to me like the co-processor isn't doing a great job of offloading work from the CPU here.
All of these concerns might be dismissed simply by saying "the CPU is much faster than those other 8-bit platforms you're used to". Assuming that isn't the case, I'd probably like to see the video co-processor have enough memory to hold two full pages of bitmapped video. I'd also greatly appreciate it if they could arrange for direct CPU access through one of their pre-existing banked memory regions.
Still, I'm eager to see how David's project progresses.
There's this clip https://www.youtube.com/watch?v=sg-6Cjzzg8s&t=2082 from his "Building my Dream Computer - Part 2". I'm kind of wondering if David understands the issue, or if he just had problems communicating it to his audience, or if I'm just plain wrong and this clip is just a coincidence?
No, I think this is incorrect.
The reason only half the bitmap is displayed in the demo on his latest update is that the image has to be loaded into low-RAM before being copied to video RAM. There's only about 40K of low-RAM, so not enough to hold the image.
He even mentioned in the video the need to build a custom loader to load the image into low-RAM a piece at a time, with each piece being copied to video RAM after it's been loaded. Their demo doesn't do this yet, hence only half the image displays.
> No, the half image problem showed in the video, is that the available low memory of the X16 is around 38K, only enough for half a vga image...
No, 38K isn't half of a VGA image. 38K is only an eighth of a VGA screen at 640x480 pixels, 1 byte (256 colors) per pixel. So 38K is only 60 lines tall.
Bartreadm the first part of your reply is essentially the same as the one above. But I like this second part a bit more:
> He even mentioned in the video the need to build a custom loader to load the image into low-RAM a piece at a time, with each piece being copied to video RAM after it's been loaded. Their demo doesn't do this yet, hence only half the image displays.
Can I be honest? I don't think that makes sense either. Here's why:
Every pixel of video data needs to be streamed to the video co-processor one byte at a time. (That's a known hardware limitation of their design.) Even a 6502-based GIF decoder works no more than a handful of lines at a time when decoding a static image.
In this architecture (and with any reasonable image decoder), there just isn't a need for the entire image to be decoded into main memory before streaming it into video memory. In fact, back in the day, it was possible to print full-color images to a printer (Okidata Okimate 10 or 20) that far exceeded what you could do on the screen in terms of color and resolution, and for essentially the same reasons.
Their technical specification clearly attributes the VERA module as only having 128K of video memory. 128K is just enough to display 42.5% of a 640x480 image. That's almost exactly what you see happening on his screen. Almost half.
So this goes back to what you said.
In order to display more, they'll need some more complicated tricks. They'll need to load the image, and while the video co-processor is in the middle of outputting the image and just as or before it exhausts the first half of the screen, it needs to overwrite what's currently in video memory with the rest of the image. And that'll need to be repeated for every video frame, or 60 times per second in the US.
So yes, he'll have to load the image into low-RAM a piece at a time. But it is because their video co-processor can't hold the entire image in memory so they're using main system memory and raw CPU power to work around it. They can work around it with more clever code, but it is a hardware restriction.
This does do a good job of demonstrating the kinds of games we had to play in the 80s to get the most out of our early consumer PCs.
Of course, the X16 already accounts for that with its banked 2Mb RAM. Large RAM effectively means that most software for the platform can be single load, streaming in whatever is needed 8k at a time instead of going to storage media. But even so, a full 640x480 256 color image is so large relative to the RAM size that it's likely to be relegated to splash screens and demo effects.
Even on the NES the PPU RAM is on a separate bus
1. Not enough video memory to contain a full Mode 7 image on the VERA co-processor. 2. All co-processor access (including video memory) has to go through eight registers starting at $9F20.
No problem here with bank switching. I think that's great!
8 bit computers always have a lot of limitations. And these limitations have sparked a lot of creativity :)
Based on what I see here, you've got a good explanation: https://github.com/FrankBuss/x16-demo/tree/master/assembly
Their original image was 64K. They cut it down to 34K (+ 512 bytes) and then they included it in their binary (rather than loading from a file).
So it seems that David was correct in his explanation. They could only display about half of a 320x2X0 image because they ran out of low memory.
But it also seems that VERA doesn't have enough video memory to hold a 640x480 8bpp bitmapped image ("Mode 7"). 128K of private video memory just isn't enough unless they start playing tricks.
> 8 bit computers always have a lot of limitations. And these limitations have sparked a lot of creativity :)
I really am curious to find out if they plan on adding more memory or if this is going to be one of those quirks we'd have to really work to take advantage of? :)
Given robust tiles and sprites, there really isn't a need to hold an entire screen in RAM, and given one does not exceed the sprite / line limits, nor is there a need to double buffer it.
Edit: For a smaller bitmaps, one could just make a buffer anyway. Dedicate X number of tiles to that bitmap, and another set for a buffer. Update one set, switch to display, update the other set. Collections of sprites can do this too. For use cases that involve part of the screen, I would imagine this working fairly well.
And one will need to write a little loader too. Fetch graphics assets, copy to video system, update registers, fetch more graphics, copy to video system, wash, rinse, repeat.
When the final program is running, that cache of graphics can get updates pretty much anytime those assets are not being used directly. (maybe directly too, depending...)
That said, yeah. I hear you. Part of the fun, in the retro scene, is racing the beam to draw more than one would expect. But, this seems well specified in my view.
While it's fun, having to do those tricks shuts out a lot of potential users. And it's those potential users we all, given interest in this sort of thing, want!
Quite some time back, a BASIC compiler for the Atari 2600, AKA VCS, was created. And it was super simple, offering up a basic COMBAT type kernel, with a score and a couple other little options.
Early in the development cycle, I knocked out a BREAKOUT type game, just as proof of concept. Took about an hour.
Once it released, tons of people started making goofy little games. A fair number of these were pretty good fun, and a few of those ended up "published" by some small time retro shops who make carts and media for old systems.
If David hits this just right, a similar thing can happen, and if it does, there will be a lot of fun to be had.
See Batari Basic for Atari 2600. A lot of games got written. It's impressive in that some of the people who wrote them really did not know much at the time. They just jumped in and made do with what few choices were available. That limited set of choices turned out to be very good at focusing people on gameplay. There was not too much else!
Now, as to why it's done the way it's done?
Simplicity. That's also why they didn't go with the 65816, which is a shame, but not a deal breaker. Too bad 65802 chips, which are pin compatible with this and many other computers, offer up the more powerful instructions without also offering up the multiplexed data / address bus. They are hoping to clock at 8Mhz, and that already weeded out AY sound chips.
They want a dev cycle that is sane and a part count that is also sane so they can hit a price people will pay. IMHO, totally fair call.
Putting the video on the main bus is an order more complex than the path they are taking right now. I'm pretty sure I saw an 8 bit parallel interface there too.
That means the same video system can be used on a number of older computers, not just this machine. Honestly, I doubt that will see too much use, but who knows? It could!
Perhaps. But in the video, he said mode 7, and the VERA module documentation https://github.com/commanderx16/x16-docs/raw/master/vera-mod... lists that as a bitmapped mode, 8 bits per pixel.
However, I do have some experience creating complex images on an 8-bit machine using tile mode (using interrupts to progressively load new character sets while the image is being rendered by the video chip). There is a place for each. (I believe it might have been used in Super Mario type image they demonstrated?)
> Now, as to why it's done the way it's done? Simplicity.
Yup. Hopefully I've made that design decision clear for those who might have missed it, and I'd certainly like to encourage them to see if they can improve upon this one particular architectural decision.
More than plenty, IMHO.
A simple design will get hacked on, expanded, etc. That is definitely my preference.
Constantly copying data to the VERA (chasing the beam/screen), seems unpractical. The 6502@8MHz can never move that much data.
6502's are fun to play with and relatively easy to put together a system with one.
There's still quite a community of us building new systems with the 6502 on the 6502.org forums if anyone is looking for more info re: programming/hardware, hints and tips etc
When I started my goal was to write some simple code, hosted on the arduino, then put together a "real" system with EPROM for ROM and proper RAM chips.
Instead I got distracted porting BASIC, FORTH, and similar things to the working processor. I should get back to it!
I think the Z80 is simpler to get started with than the 6502, when it comes to physical circuits, as it needs fewer components. (Having RAM refresh built-in, for example.)
Do you know if there is a forum for Z80 homebrew systems?
FWIW this is the high-level overview I've put together:
Doesn't get much simpler than that.
One of the best teachers I have come across. If you are interested in hardware internals, I would highly recommend him.
I am ecstatic this is a thing and hope it is a massive hit.
The 6502 wasn't great. The Z80 wasn't great neither but I'be heard it might be slightly better in some ways
I wonder what would be the best 8bit processor available (or even ditch the 8 bit stuff and go 16bit). Maybe the 8031 series? Maybe a modern one?
My beloved beeb could only really compete in expandability.
But the problem with the 6809/6309 is that they max out at a clock rate of 3-4mhz and there's no new chips being made.
Whereas WDC & Zilog still manufacture brand new 6502 and Z80 chips, and they clock way higher. A brand new 6502 can do 20mhz.
So probably for retro projects that want a little more oomph, you're better off picking a 65816 clocked at 15mhz or so, than a 6809 at 4mhz. The 816 has relocatable direct page and stack like the 6809, too.
6809 would be just fine.
I keep a Color Computer 3, which has the 6809 stock, just because it's so much fun to program. Best of the 8 bit chips, if you ask me.
You know, when David gets done with this system, it's not a big stretch to make one with a 6809. Maybe someone will.
The 6502 was used because the Commodore kernel can be reused, or something like it can. It's not a total rewrite and that gets the project somewhere useful and familiar quickly. I don't blame 'em, and the 6502 is fun too.
I also suspect a rewrite of those components, BASIC, etc... in 6809 would end up smaller, faster and more feature rich too. Big project though.
[1] "This series is in progress and more videos are on the way soon!"
[2] "I expect all of the videos will be released by the end of 2019 or sooner."
I have a suite of Oric-1/Atmos machines that are in use for precisely this purpose. Its wonderful to return to a simpler era of tooling and methodology, and the feeling once you get it all up and running and building new apps .. for 30 year old computers .. is quite rewarding. Feels good to have done something productive with what would otherwise have become landfill ..
But if you're looking to build a 6502 single board computer, it's actually a great preparatory project!
I should share the schematics and code, but I'd have to spend some time polishing them for publication - I built it on a breadboard, so I'm not even sure if the schematic is accurate.
The 68008 and the HC models make doing this particularly easy.
Build a 6502 computer Learn how computers work by building and programming a computer with the classic 6502 microprocessor. This was the first truly low-cost microprocessor that started the personal-computing revolution. Versions of 6502 found their way into the Atari 2600, Apple II, Nintendo Entertainment System, Commodore 64, Atari Lynx, BBC Micro and many other computers and game consoles of the era.
In this video series, I'll build a basic 6502 computer with an LCD display and a few buttons, explain how to program it in assembly, and write a game or two.
Videos This series is in progress and more videos are on the way soon!
27:24 “Hello, world” from scratch on a 6502 Kits If you’re interested in following along with the videos and building your own 6502 computer, I provide a kit that includes all of the components.
Please note: In addition to the base kit, you will need:
A 5-volt power supply An EEPROM programmer Also, if you want to follow all of the experiments and debugging in the videos, I recommend the clock module kit and an Arduino Mega. The clock module kit also happens to include a 5-volt power supply.
Note: This kit is designed to go with the video series above which is not yet complete. The videos are the only instructions for the kit. So if you buy the kit now, you will need to wait for me to finish producing the rest of the videos. I expect all of the videos will be released by the end of 2019 or sooner.
Please see the fine print below, particularly for non-US customers.
Schematics Here's the schematic for the final computer—or at least as far as I plan to go with the initial series of videos. The kit above includes all the parts to build this (plus a few extra buttons and LEDs to give you some options for I/O.)
Schematic of the 6502 computer Data sheets W65C02 W65C22 HD44780 74HC00 Quad 2-input NAND gate 28C256 256K Parallel EEPROM 62256 256K SRAM Parts list Here are all the parts for the 6502 computer. This list is roughly the same as what's included in the kit above, in case you only need individual parts or want to source them from elsewhere.
Qty. Description Sources 3 Breadboard Jameco, Amazon 1 22 AWG Solid Tinned-Copper Hook-Up Wire Jameco, Amazon 1 W65C02 CPU Jameco 1 W65C22S6TPG-14 Versatile Interface Adapter Jameco 1 AT28C256 EEPROM Jameco 1 AS6C62256 32k SRAM Jameco 1 16x2 Character LCD Display - White on Blue Jameco 1 74HC00 (Quad 2-input NAND gate) Jameco 1 1Mhz Crystal Oscillator Can Jameco 8 Tact pushbutton switch Jameco 10 Red LED Jameco 1 10kΩ potentiometer (for LCD panel contrast) Jameco 10 220Ω resistor Jameco 10 1kΩ resistor Jameco 10 0.1µF capacitor Jameco You’ll also want to have some way to program the EEPROM. In the videos I use a TL866II Plus programmer.
The fine print Unless otherwise noted, most orders will ship within a week, often much sooner.
If you have questions about an order, payment, or shipping, please contact support@eater.net and include your order number. For technical help assembling or troubleshooting the kits, please post a question at reddit.com/r/beneater since it’s difficult for me to answer these individually. I do try to stay active there.
Non-US customers: Note that all kits ship from California. I’m willing to ship a box anywhere you want, but the buyer—that’s you—is responsible for any applicable import duties and local taxes. Please verify with your customs and taxing authorities before making a purchase to understand what else you may be required to pay.
Finally, the power supply in kit 1 has a North American style plug. It will work worldwide because it supports 100-240 volts, but if your country uses a different type of electrical outlet, you will need to provide a plug adapter (e.g., something like this).
A good kit, with video content and community for under $100 is a steal!
I want one like yesterday. 6502 programming is fun.
Ben is an excellent teacher.