If you haven't already, I highly suggest checking out the rest of Ben Eater's videos.
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.
David Murray (aka the 8-bit guy) has a plan to build the "Commander X16", a new 6502 based computer that is philosophically similar to a VIC-20 but has more RAM (2MB), a higher clock (probably 8 MHz) and an FPGA to do VGA video. It might not be on the radar of people here because of some odd choices, like using a Facebook group as the primary discussion forum.
I really can't wait for that to happen. I'm going to be throwing money at that project like crazy. There's already an emulator for the OS [1]. I had never done any C64 programming, but I was able to do some BASIC tutorials using it with the exception of any video stuff, since that will be different on the X16.
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.
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 project certainly has my attention! Only two things have me concerned right now: cost (the question of if it can reach scale) and video.
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.
> 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).
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.
As restrictions go, I'm OK with this. I looked into doing some Atari 800(XL/XE) coding and for most any graphics application, you're bottlenecked by what you can keep around in main RAM, plus the limits of what you can program ANTIC/GTIA to do per scanline. Programming the scanline interrupts, you can manage to do quite a lot, and similar tricks with VERA are likely(fingers crossed). A lot of the latter day demoscene work on Atari relies on aftermarket RAM upgrades to unleash more of the raw power of the graphics hardware.
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.
Last night a new version of the vera documentation was uploaded (https://github.com/commanderx16/x16-docs/blob/master/vera-mo...). It looks like the changes will allow for more memory, up to 1mb. Of which the last 64kb seem to be reserved for the registers, so max 960kb.
Constantly copying data to the VERA (chasing the beam/screen), seems unpractical. The 6502@8MHz can never move that much data.
The problem is that the 6502 can only address 64K which includes ROM and IO Space so for any acceptable resolution you need tricks like bank switching and/or a seperate memory 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!
Using 256 color bitmap, select the 320200 resolution. 64k for one full screenbuffer. The 640480 is still useful for sprites and tiles, but I think it will mostly be used for text.
8 bit computers always have a lot of limitations. And these limitations have sparked a lot of creativity :)
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? :)
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 and "streaming" to the video chip from a storage device or the high memory is not supported yet.
I'd hope so. Or they could leave it in as an old-school quirk that you have to hack around in order to get the most out of a bleeding-edge vintage home computer. I'm not sure of their intent here?
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?
It has a tile mode. That's going to be how many larger images are handled.
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!
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.
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
It is nice to see this kind of thing still going on. I've been doing something similar with a Z80 recently; currently I have a Z80 hooked up to an arduino-mega, which is faking port-based I/O and RAM read/writes.
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.)
When I started with the 6502 it took a while to get a working, stable system due to a couple of weird circuit issues (like forgetting to qualify R/W by PHI2) which wouldn't have been the case if I was using a Z80
Do you know if there is a forum for Z80 homebrew systems?
http://www.z80.info/ has a lot of information, but it's not a forum as such. I've found a couple of groups on reddit, for retro building and z80 systems, but nothing really large.
FWIW this is the high-level overview I've put together:
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.
Strongly seconded, along with the Hitachi 6309. But the latter is hard to source.
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.
Oh this is fantastic! I'm excited to order this.
Does anyone know if this kit will be a new Ben Eater video series or does this kit go along with an existing set of videos?
Another great way to learn 6502 computing: get a retro-computer back up and running.
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 ..
I built my own using an ardino clone and a couple of shift registers to provide enough i/o pins. It probably cost less than £5 in parts, offset by 5 or more hours designing and fabricating the thing.
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.
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).
Holy crap the linked kits are expensive. Seems to be because certain components are unavailable for less than ~4x the price of fully integrated modules containing modern MCUs.
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.