Build a 6502 Computer(eater.net)
eater.net
Build a 6502 Computer
https://eater.net/6502
51 comments
Checking out all his videos is worth it.
The earliest videos are a bit rough but still very informative.
The earliest videos are a bit rough but still very informative.
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.
[1] https://github.com/commanderx16/x16-emulator
[2] https://www.youtube.com/watch?v=ayh0qebfD2g
[3] https://www.youtube.com/watch?v=sg-6Cjzzg8s
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
[2] https://www.youtube.com/watch?v=ayh0qebfD2g
[3] https://www.youtube.com/watch?v=sg-6Cjzzg8s
He and his brother have independent forums as well, and there's a sub dedicated to the X16.
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.
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.
I think he's gonna hit the sweet spot. Great project. Fan here for sure.
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.
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.
[deleted]
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.
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, 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.
Let me take hougaard's reply first here...
> 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.
> 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.
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.
Constantly copying data to the VERA (chasing the beam/screen), seems unpractical. The 6502@8MHz can never move that much data.
Sweet. That much VRAM will pretty much eliminate the need for the video system to be on the main bus.
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.
Even on the NES the PPU RAM is on a separate bus
Even on the NES the PPU RAM is on a separate bus
What I took exception with was:
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!
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 :)
8 bit computers always have a lot of limitations. And these limitations have sparked a lot of creativity :)
> Using 256 color bitmap, select the 320200 resolution. 64k for one full screenbuffer.
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? :)
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? :)
[deleted]
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 assumed they’d just add more ram to the Vera chip, but I don’t know the details of if that’d be possible.
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?
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!
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!
> It has a tile mode. That's going to be how larger images are handled.
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.
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.
That same documentation shows 320 pixels per line too, in mode 7, depending on tile width.
More than plenty, IMHO.
A simple design will get hacked on, expanded, etc. That is definitely my preference.
More than plenty, IMHO.
A simple design will get hacked on, expanded, etc. That is definitely my preference.
Nice!
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
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 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.)
The Eater 6502 design is using Static RAM so the RAM refresh is a non issue. Look at the schematic. Its just CPU, ROM, RAM, VIA, LCD.
Doesn't get much simpler than that.
Doesn't get much simpler than that.
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?
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:
https://steve.fi/Hardware/Z80/
FWIW this is the high-level overview I've put together:
https://steve.fi/Hardware/Z80/
Ben Eater is simply the best!
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.
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.
One thing I "worry"/question about these "vintage" projects is the choice of processor.
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?
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?
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.
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.
I've never seen one in person, but from the specs, the Fujitsu 8 bit micros were the best and they used the 6809.
My beloved beeb could only really compete in expandability.
My beloved beeb could only really compete in expandability.
The Hitachi 6309 is even better.
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.
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.
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?
This is kinda different from the 8 bit computer series and there's a new video up now, so I'm thinking it will be a new series.
New series [1][2] which will be awesome to watch even without buying the kit.
[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."
[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."
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 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’m currently building Ben’s earlier 8 bit computer. His videos and kits are great. Can’t wait to get started on the 6502.
E progmmer no available though. That double the shipping costs or adding 25+% to the overall cost. Would he have that later?
It is quite popular chinese TL866II, you can search for it anywhere, it just got mine for $37 from aliexpress
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.
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.
Holy crow I'm excited. These are high quality and very accessible.
Fun, but not as much as with a 68000.
The 68008 and the HC models make doing this particularly easy.
The 68008 and the HC models make doing this particularly easy.
When I took an electronics class a couple decades ago, we built a 68k computer based on https://en.wikipedia.org/wiki/The_Art_of_Electronics
>You need to enable JavaScript to view this site.
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 [email protected] 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).
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 [email protected] 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.
Seriously?
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.
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.
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.