There are a lot of 8 and 16-bit single-board hobbyist computers available these days.  But every one of them falls short in some way or another from what I dream of.  I’d just design one myself, but I’m not really good enough with electronics to do that.  So, I’m hoping somebody else will make my dream come true.  So I’ve compiled a list of things I think it should have.

Off the Shelf Components

So, basically I would not want the computer to use any old components that cannot be purchased anymore.  That includes custom chips from Atari or Commodore or whatever.  I would hope that the system would eventually get a larger user base and I wouldn’t want to see any shortage of parts arise preventing mass production.  However, I prefer to avoid any FPGA or microcontrollers if possible, but that’s not a deal-breaker.

CPU

I would want the CPU to be 6502 or compatible, such as 65816.  However, I’d be fine with the traditional 6502.  I would prefer a faster clock speed, such as 8 Mhz or better.  That way people could write code in BASIC and it would actually run fast enough to be useful.  As long as we aren’t stuck using something like Commodore’s VIC or VIC-2 chips, then this shouldn’t be a problem.

Memory

I would want 128K or 256 of static RAM, with possibly the ability to upgrade it.  If using 6502 then there will need to be some sort of banking, but with 65816 it should be able to access all of it directly.

Video

The video chip would be the hardest thing, I believe.  Being that I want off-the-shelf components only, there aren’t a lot of video options.  I’d definitely want the computer to be able to output Composite or VGA.  HDMI would be okay as well, as long as it wasn’t the only option available.   Resolution isn’t all that important.  I’d want it to be similar to 8-bit machines of the era, possibly with different modes.  640×480 would be fine for a maximum resolution.  I don’t plan on doing any desktop publishing or photoshop on the machine. 320×200 would be good for games.  I could see this chip being an FPGA or microcontroller if need be.

Sound

I’m pretty flexible with this.  I’d be okay with using some off-the-shelf Yamaha FM chips.  But I’d also be okay with having a socket for a SID chip or one of the off-the-shelf replacements such as the SwinSID.  Ideally some sort of DAC would be nice, some of the Yamaha chips have that built in.

Storage

ideally, it would use an SD-Card.  However, to make things easier, I’d be okay with it using standard Commodore IEC connections and then I could use a SD-2-IEC adapter in order to get the SD-card.

Operating System

Here’s where things get interesting.  I want it to be able to run Commodore BASIC.  I want the friendly screen editor and feel of a Commodore machine. However, it doesn’t have to be compatible with any specific Commodore machine.  In fact, I’d like to think of this machine as being the true successor to the C64.  Just like the C64 was not compatible with the VIC-20 or the PET or the Plus/4, total compatibility is not required.  It just needs the feel.  Also, it needs to use PETSCII characters.

If the machine is close enough to a Commodore machine, it should make it easy to code for using existing assembly tools and cross-compilers that are used with the C64.  Hopefully somebody would even write emulator support for it so that we could code and test on a PC.  I’d love to see this system become a de-facto standard for 8-bit hobby computers and see a community build around it where games and other software are developed for fun.

I want the machine to have some of the conveniences of the modern world, such as SD storage and modern keyboard and video standards.  But, at the same time.. I don’t want it to be “too powerful” because then you begin to lose the magic of an 8-bit system.   Somebody please build this for me!

Related Posts

131 Responses

  1. Nicola

    Please let’s do this, with an open standard and free schematics so evertbody can build it!

    Reply
  2. MyUsernameIsVeryInteresting

    What about a line of LEDs that can tell you of an error that a monitor couldn’t show? that would be pretty cool to see a blinking orange LED that means lets say CPU is overheating and such

    Reply
  3. Justin Wilson

    As you mentioned, the video chip could be difficult. Despite your initial aversion to an FPGA/CPLD, I’d say that may be one of the best courses of action (but I’m also biased as an electrical engineer with an emphasis on embedded design and digital logic systems). Plus it has the added benefit of potentially being open source, and with a JTAG header the video chip could be upgraded (in conjunction with making the OS/etc open source this could prove to be powerful, users who know what they want in terms of video could add custom instructions), further this would open it up a bit more in terms of having multiple video output options, pure digital for things like HDMI, and if you throw in a DAC you can have VGA.

    Reply
    • Manuel

      Maybe the video system would be like that of Gameduino 1, but including more RAM memory and bitmap modes. I was thinking years ago to build a 65816 computer with Gameduino and FPGA-sound and IO controller as base ICs. But I think it would be really good to upgrade the 65816 to something that has plain-memory access with 24 address bus but without segments. The sound could have 8 or 16 channels with multiple wave types and with a MIDI and/or additive sound synthesis internal design. SD card would be a must; PS/2 or USB keyboard and a mouse. Expansion ports, and Ethernet or Wi-Fi as an add-on. Maybe a 10” or 7” sized-LCD screen and make it portable.

      This could compite with Raspberry Pi or any other of the computers. And the chips could be bought in AliExpress or Ebay for saving money. But, the great problem, I think, it’s the community. Would people (hackers, hobbists, etc.) develop software for this computer and support this system for many years????

      Reply
    • Paul Bruner

      Honestly the video chip isn’t that hard. you could just have it buffered in ram. Its how the space invaders display is made. Problem is that its a memory hog if you want to store colors.

      Reply
      • Dave Mullen

        As Dave is looking for something reminiscent of the 8-bit era (albeit with a more 16-bit memory space), 640x480x12 bit color would only need 450k of memory. In fact, I’d personally go along the route of the Sega Genesis/Megadrive and do 2 sets i.e. foreground and background, with the other 124k of memory dedicated to as many hardware sprites as you could fit in there, for a round 1M of video memory. As the 65816 can address up to 16M, that still leaves a massive chunk for O/S, BASIC interpreter and workspace RAM.

        So essentially a CBM-64 with 4096 on-screen colors, crapton of sprites and the two layers of drawing surfaces. You could even expand further along the genesis route and use their tiling systems for larger play areas, and probably only eat another 1M of memory for that.

      • Daniel

        My first thought was, why not give it a full 16 megs by default.

        My second thought, that system would be too easy to develop for. Like a magical excalibur game machine, something people dreamed about back then.

        Wouldn’t it be too easy, though? Dunno.

        Part of me likes the idea of a “perfect” retro machine, unbound by the practicalities of the day.

        Part of me feels like you might as well use an RPi then.

        Any thoughts?

      • The 8Bit Guy

        I think the Raspberry Pi loses a lot of the magic because you have to run some sort of Linux or other modern operating system core on the machine. Thus you never really get to interact with the hardware itself.

      • Matt Jenkins

        You don’t *have* to run Linux. You can program the bare metal. It’s not easy, but you can do it. The lack of datasheets (Thank’s Broadcum!) doesn’t help matters though.

        You could, of course, fit an entire computer including the VGA emulation into a single PIC32MZ2064DAA169 chip though… A 6502 emulator would be easy enough to knock up (or port, or I think there already is one ported). In fact I think there’s an entire C64 emulator ported to the PIC32 somewhere. No VGA though, but possibly TFT…

      • Urmas Lipso

        (i do hope, that i clicked correct reply button)

        a “bare metal” raspberry might be the way to go.
        if this can be done https://github.com/fbergama/pigfx
        then a reasonable BASIC environment could also be done.
        i have read about one such distro, but that was closed source and absurdly limited.
        something with oldschool feel but without artificial limitations should be the way to go.
        unfortunately it’s not the field of coding i have worked with. if someone started the project, i think i should try to help, it would be nice to code something not work related

      • cturner

        “The video chip would be the hardest thing”

        Clever video choices could be the selling point of the system. RAM and CPUs are a lot cheaper now than in the 80s, and give us options to create a “Shovel Knight” system: feels 8-bit, but with extra awesomeness.

        I believe you could do cool stuff with a “discrete graphics” arrangement on the motherboard.

        Here is a design. Assume static RAM. A quick google suggests it could be had for USD 7 / MB. Main CPU: 1x W65C816S (USD 30). Graphics CPUs: 10x 6502 (USD 6 each).

        The system has 1MB of RAM. The first 512k would be ‘application RAM’ (accessed only by the main CPU).

        The next 512k would be video RAM. If my sums are right, you could have 8-bit colour with 640×480, with room to spare.

        Video RAM is broken up like this. The first 200k is a special area of discrete-graphics RAM (covered below). The final 300k would hold pixels. Wire the 10x 6502 chips to have parallel access to second 512k of RAM, with each having reach into a bank of the discrete-graphics RAM, and a bank of the video RAM.

        Here are some ideas for video modes for such a system.

        In mode 0, the main CPU is entirely responsible for pixels in the video RAM.

        In mode 1, you could have the main CPU put a character grid into the discrete area, with the discrete CPUs converting that into the pixel area. (You could have a selection of possible “fonts” stored in ROM.)

        In mode 2 you could have the main CPU place 6502 machine code or forth into RAM, with the discrete chips then processing that into pixels in other parts of RAM.

        You could have other video modes where you farmed parallel processing out to the discrete 6502s, with each being able to send an interrupt back to the original CPU.

        You could offer a similar setup for audio processing. In particular, having discrete chips doing a fourier transform.

    • James

      I repair old arcade boards for a living, we could easily implement something cool in about 20-30 TTL chips but i’ with you on compressing this into a CPLD or FPGA. As an actual video chip.

      16-32 sprites would be dead easy with line buffers.

      Reply
      • Tad

        Do you have any designs kicking around for a video implementation like this? It’s been something i’ve been trying to wrap my head around for some time just for fun. Any resources on the matter would be interesting to read.

    • Daniel

      I see how FPGAs may be cool, but they are also ridonculously expensive, and pretty much occult technology for everyone except people like you who are specifically experts in designing ICs

      Most FPGA-containing retro peripherals are near or beyond the cost of a low-end modern computer. They are really cool when you need to reproduce something specific, like a C64, but if we wanted to build a simple, open, hand-replicable system without compatibility requirements, I think an FPGA would be a major hindrance.

      I’d love to see a “kitless” retro computer, that one can easily build from parts you can easily and readily source from Mouser or Digikey. Let’s see, I’d say the ideal system would need the following tools and nothing else:
      – Soldering iron
      – Wire cutters
      – The cheapest, most generic EEPROM burner

      I don’t think we need to replicate the 80s entirely, just capture the feeling… BTW I’d support a real C64 revival project… but that’s something so many have attempted and failed or faded… specifically because of how expensive FPGAs are.

      Reply
      • Max Chan

        Actually the older, lower end FPGA isn’t that expensive, although you may need to pair it with an external MCU for data processing.

        An example setup would be an Intel EP4CE6E22C5N Cyclone IV FPGA + STMicroelectronics STM32F407ZGT6 Arm Cortex-M4F microcontroller + Micron MT48V16M8A5P DDR SDRAM combo. The FPGA implements just a DRAM controller, a bus matrix and a parallel slave to SPI master bridge. The SDRAM chip provides 16MB VRAM, the 168MHz Arm microcontroller implements a GPU, and the FPGA provides the glue logic that combines all the above together.

      • Daniel

        My other, and actually much, much bigger issue with FPGAs and CPLDs (beyond the latter being essentially lost technology) is that they all require proprietary tools to develop. Older chips need older tools often (which means Windows XP).

        Unless one has access to a lab at a university or company with all the tooling, it’s essentially closed tech, and the entire design has its life at the mercy of the FPGA manufacturer.

        With FPGA, it would be “just another FPGA retro machine”. Without, it’d be THE fully open, replicable, FPGA-less retro machine.

        The board may be bigger, but who cares. Large boards are cool.

    • Panu

      I designed a video chip based on my fond experiences with 8 bit computers in the 1980’s. It’s called vs23s010, it’s available and doesn’t cost much, a couple of dollars in quantities. It’s actually a 128KB SRAM with a few additional programmable counters and other logic and a NTSC/PAL modulator to draw composite video. It can do up to a million colors, but it’s most comfortable in a 256 color mode ( in my opinion ). Check it out at the VSDSP Forum website if you like. I made it because the world needs more TV hookable computers! 🙂

      Reply
  4. Matt Jenkins

    I have been contemplating doing something along these lines for a while. Build something based (loosely) around the PC/104 standard to make it modular. I’m a ZIP fanboy, so was originally thinking of using that, but 6502 or 6510 or similar could be doable too. I wanted to make it so you could use your host CPU of choice and add RAM and EPROM boards, IO boards, a VGA board, etc to it to make whatever you wanted.

    Reply
      • GregC

        lol. I’d just finished reading your initial post, and was really perplexed by how being an “archive file format” fanboy had anything to do with hardware design. 🙂

    • EVKnucklehead

      The main problem with having multiple CPU options is that different families have different instruction sets, so you’d need to either have an abstraction layer for each processor type, making the firmware more complex and requiring more storage space, or there would have to be separate firmwares for each CPU family, complicating the build process.

      That doesn’t mean it’s not worth doing, just that it wouldn’t be easy to do.

      Reply
    • cturner

      I am not an expert, so don’t place much weight against the opinion below.

      My impression is that 6502 is a more fun starting point than Z80. The Z80 design offered lots of hooks to help manage your DRAM, but at a cost that it is quite prescriptive in describing how your motherboard architecture will look. This might explain why there z80 systems all looked quite familiar to one another (e.g. amstrad, spectrum), more so than 6502 (c64, acorn, apple 2) systems.

      If you are interested in working from z80, recommend reading _The ZX Spectrum Ula: How to Design a Microcomputer_.

      Reply
  5. Bob Rivard

    Although I spent many hours with a C64, I was partial to my Apple ][. So the test for me would be if this computer was theoretically capable of running a rebuilt Ultima V including the Mockingboard/Phasor soundtrack.

    Reply
    • Matt Jenkins

      Indeed. The latter is what I was expecting to be doing. Yes, it complicates things somewhat, but it would be down to whoever creates a host CPU board to write the firmware for it. A Z80 board could have CP/M or Sinclair BASIC.

      My main concern with making an entire computer of this complexity out of jellybean parts is the cost. Not just components, but the sheer size of it to fit all the glue logic in would mean the PCB would be quite large. Using a CPLD (I’m an Altera MAX series fan, but flexible I guess) would get round that issue somewhat but at the cost of build simplicity. This is exactly why you have the likes of the PLA in the C64, the ULA in the spectrum, etc. By making it modular you can use smaller boards and interchange them. The end cost for your specific build would be higher though I guess, but that cost could be spread over time as you add more to the computer. Start basic with the CPU board and a UART interface, for example, and add VGA later.

      As far as VGA output goes there are many options. I have done other with PIC32 before now, and the recent introduction of the PIC32MZ/DA chips (which themselves would dwarf the rest of the computer in where power and memory) with the same GPU in them as the PIC24/DA chips, could create a VGA compatible signal (I have done it with the PIC24/DA chips before now) that works on many monitors (not 100% compatible though). FPGA could be used, but again that breaks the build simplicity: not just programming, but most are BGA that is not good for kit builds.

      A simpler option would be no not have VGA at all, but a 7″ TFT screen. Either driven directly with a PIC32MZ/DA or a dedicated driver chip like the SSD1963 which is commonly built into cheaper eBay displays (though is hard to buy individually).

      Running existing software on a custom system that isn’t essentially a rebuild of an existing architecture just won’t work well. Yes, you can give it a similar feel, but the whole way it works, with things like bank switching differences, would mean so many things would break. For BASIC, as an interpreter, it would to a large extent do similar things, but display access, IO access, etc would all be different.

      Bank switching on the 6502 is complicated by the fact there is no IO address space like the Z80 has. The C64 used the built in IO port of the 6510 at hard-wired address 0/1, but the 6502 doesn’t have that. So the memory page with the memory mapped IO to control the bank switching must itself never be switched out. Add to that one indexed addressing modeessentially locking down the lowest 256 bytes of memory and you have a complex mess.

      I was hoping for an arrangement similar to the later spectrums, with the memory space sliced into regular pages and any combinations of pages of a larger virtual address space could be switched into any of the physical pages, but with no IO address space and the indexed addressing that becomes more limited. Yes it can still be done, as long as you have certain pages locked from being switched out, but it does make mincemeat of your memory map. And the more and smaller page chunks you have the more complex the banking matrix gets, which gets us firmly into CPLD territory for the glue logic.

      Reply
  6. Ashton Scott Snapp

    So many comments! Considering I was born in 2000, after the age of the retro microcomputer, my dream hobbyist PC probably wouldn’t be the same as yours. But you do hit a few good points 😀

    Reply
  7. Oskars Marcroft

    Does it have to be pure Commodore BASIC, or can we write our own BASIC interpreter that is compatible with Commodore BASIC, but has extra commands or features (such as longer variable names, graphics commands, labels, etc.)?

    Reply
    • The 8Bit Guy

      I’m not that picky. If it’s a 6502 machine then it could run Commodore BASIC standard. You could always add extensions to it for new commands.

      Reply
  8. fluffy

    I think it’d be fun to have a hardware implementation of PICO-8, which was designed along the lines of a retro computer (albeit programmed in Lua rather than BASIC). There’s some folks who have built PICO-8 microconsoles from Raspberry Pi and the like but that’s not quite the same as a hardware implementation – ideally the PICO-8 interpreter would be the OS, and it would actually have the hard limit on memory and clock cycles and so on that the runtime imposes.

    Obviously there’s some concessions which would have to be made but it’s at least a fun idea for a starting point.

    Reply
  9. Jim

    Hi. It seems to me that the C128 would do what you need. Particularly if you wrote the development and control software for the Z80 as a doorway into the C64 6502 mode. A “Sweet16” style emulator would also be easy to implement. Two screens, extra video modes, keyboard etc. all built in and available. I’m sure you must have considered this so I would be interested in your comments for and against.

    Reply
    • Guru

      yep I was thinking the same thing. apart from the custom video chip, he has described the C128 almost exactly.

      Reply
      • Doug

        Can you go into a little more detail on what you mean exactly by 100% off-the-shelf components?

        Does this mean literally must be found in a frys or radio shack? I’m assuming online orders are okay here (even the 65816 can only be found online). If online counts as off-the-shelf then what does not?

      • The 8Bit Guy

        Yes.. I simply mean that the components are available today and still being manufactured. It also means that there is no need to get a special ASIC or other specialty chips manufactured.

      • Tom W

        Looking at things like the Commodore 64 reloaded, I think you generally could build a C=128 today, with the possible exception of the video chips (the VDC and VIC-II).

        There are several 65816 accelerators for the 128 and 64, including the Super CPU, Flash 8, and Turbo Master.

        There’s also the Ultimate 64 (I really, really hope you get an early board when it starts shipping, so we can all see how it performs), which is darn near my ideal PC, excepting that it’s still limited to 64K.

        I’m still stumped on the GPU… but I’m sure there are some viable options out there.

  10. Vince

    I’d like to see you post about your Dream Modern Computer and what you’d want in it. Kind of like how you listed in The Dell UltraSharp Monitor video about the stuff you enjoyed about the monitor but not like reviewing a product.

    Reply
  11. Matt

    Is the best solution “real” hardware though, or an emulation constructed around an ARM based host, with maybe a fork of the Vice emulator – maybe creating a C256 as an extension of the C128

    Reply
  12. Jacob Ortiz

    I like your ideas that you get here, except only one thing is the regards to output. And that is, I would have the display output be a Mini DisplayPort (or some other universal output) so people can easily choose what kind of display output type they want. The only thing is that there would be a limitation on what the output type could be. Meaning that the computer would have to know (by defat) at lest the most common display output types, but wouldn’t probably know how to handle SCART in the US Version as that would have to be programmed in by the user.

    Reply
  13. Jason A

    I would love to try making this! If i can find the time i might even do it, but it will take me awhile. But i accept your challenge!

    Reply
    • GregC

      The Mega65 actually does look like a good match to David’s description of his Dream Computer. Also, being an open project fits with the building a community dream.
      An issue is possibly the level of FPGA that the Mega65 is being implemented with, which is not particularly an inexpensive part! But, on the other hand, when thinking of ensuring a longer term sustainable modern 8 bit CPU core system design, then FPGA prices are coming down. 🙂
      So I wonder what David’s views of the Mega65 project are?

      Reply
    • SparkyNZ

      Yeah I’m waiting to see the day when you’re given a free Mega65 and asked to do a review! I’ve had my eyes on the Mega65 for quite some time.

      Reply
  14. Techokami

    Mmmm, while the 65816 does support using a 24-bit address bus, it is multiplexed over the data bus because it only has 16 address pins. As such, it is extremely tricky to handle the multiplexing at higher speeds. This is why the SNES was clocked at much lower speeds than the competition: it was the only way to keep the system stable.

    Also, what exactly is wrong with using a processor like the Z80? Like the 6502, the Z80 has a lot of love in the homebrew micro scene, many notable uses (all those CP/M machines, a bunch of british micros, SEGA Master System, and arcade games like Pac-Man!), a rich library of software, and is still manufactured and sold today. In fact, there is a newer version called the eZ80 that has a 24-bit address bus, thus not needing a MMU to go up to 16MB of memory space… though it’s only available as LQFP so it’d be much harder for a novice to use instead of through-hole DIP.

    Reply
    • The 8Bit Guy

      Well, chiefly because this is MY dream computer, and I happen to already like coding for the 6502. Also, because what I’m really looking for is a modern successor to the C64 made from modern off-the-shelf parts. A Z80 would hardly qualify.

      Reply
      • Han

        I programmed quite some stuff on the C64 in assembly language and later on the x86. Switching to another CPU is not much of a deal. I would even prefer a different CPU with a more flexible register handling on a ‘new’ retro-platform.

        But I’m surprised that you have no requirements for the video chip. It wasn’t the 6502 but the VIC that made the C64 great. It provided hardware soft scrolling, user defined character sets, raster interrupts and an insane amount of hardware sprites (by multiplexing).

        A 8Mhz C64 _without_ the VIC could not compete with the original one in the field of (2D) games

      • The 8Bit Guy

        I disagree. I think an 8 Mhz 6502 could easily compete with a VIC-chip assuming whatever video display used does not have any limitations on where you can place different colors of pixels. After all, an 8 Mhz 6502 would have about the same performance as a 32 mhz X86 chip, and so I think there would be no issues.

      • Matt Jenkins

        The problem with CPU-generated graphics is, as you saw on that kit build, is that it is done at the cost of all other programming. Generating a VGA signal takes very precise timing, so it takes priority over everything. Your main program can only actually do anything during the blanking periods (front/back “porch”, etc), which is why it had the compromise of skipping a scan line to allow more processing to happen.

        To use CPU generated graphics and still keep some semblance of speed you’d want a *dedicated* CPU just for the graphics. That would, essentially, emulate a VIC chip (or something like a VIC chip). Yes it can be done with a CPU, and if you already have a 6502 as the main CPU, economy of scale (and “reducing BOM cost”) would say use another 6502 CPU for that. However that then adds its own problems: you have 64kB address space (Note: you do *not* want to use banking for VGA generation, unless you want to implement double-buffering, which could be cool). Given a chunk will need to be ROM, that would give you maybe 48kB of display memory. At 8-bit depth (e.g., RGB332) that would give you just 240×180 resolution.

        And of course you have timing problems. The pixel clock for 640×480@60Hz (standard VGA) is 25.175 MHz. There is no way an 8MHz CPU can generate that. You could double-clock or quadrupal-clock the pixels to double or quadruple the width of them (320×480 or 160×480), the latter of which would require a 6.29375MHz pixel clock. Not an easy clock to generate from 8MHz… Ideally you’d want your CPU running at an exact multiple of the pixel clock in order to get good timing. So a CPU that runs at 25.175MHz would be ideal (or even a higher multiple) – and only then if there is an efficient way of streaming the data out – through DMA, for example.

        And then of course you have the issue of dual-porting the RAM. Dual-port static RAM is wildly expensive, so you would need to either create some of peripheral interface to the video controller CPU or emulate dual-port RAM with double-clocking and signal multiplexing (RAM clock runs at 2x the speed of the system and the two CPUs have a 50% offset in clock phase, with suitable latches and buffers to compensate). And for that we’re back in the CPLD arena.

        So really you need:

        * A dedicated CPU to generate the VGA signal with more than 64kB address bus (At least 300kB for 640×480)
        * Dual port RAM or bus multiplexing to emulate Dual port RAM

        So while it could be done with a *dedicated* 6502 (or the main 6502 with almost zero processing time left over) you’d end up with at best 160×120 pixels (if you wanted to keep them square) and a big chunk of your memory space taken up with the display RAM.

      • The 8Bit Guy

        I never said I wanted the computer to do CPU generated graphics. However, one project I’m following proposes to do just that by using a separate 6502 just for graphics generation. I’m simply saying that the biggest advantage the sprites had for the C64 was giving it the ability to overcome color-cell limitations and easily move things around on the screen. However, if the video is slightly more modern and can display 4bpp or 8bpp then there would be no color cells and thus the CPU could handle moving things around on the screen much more easily.

      • Han

        Just a simple calculation: to perform scrolling on an 8bpp screen you’d need at least 1 LDA + 1 STA per pixel. That’s 8 cycles (in an unrolled loop!). At a resolution of 160×200 @ 50 fps that sums up to >12 million cycles. So a 6502 @ 8Mhz could not even scroll the full screen.
        With a bitplane-layout (like the 16 color VGA-modes) one would have to use the bit-shift-opcodes (ROR/ROL). That’s 6 cycles per byte (8 pixel). So at the said resolution that would sum up to 1.2 million cycles per plane. 16 colors=4 planes=5 million cycles just for the scrolling.

        About the sprites-advantage: the VIC handles not only the hassle with the memory layout. It also handles transparency, per-pixel-collision detection and sprite/background-priority. One could even place a sprite behind some pixels but in front of others. A CPU would need a lot of cycles/pixel to handle all this.

        But of course other type of games would benefit very much from your machine, like 3D games or adventures (or probably kind of not-scrolling-games)

      • Han

        I’d suggest a simple solution: the machine needs a graphics chip that supports a definable memory-address of the screen. To support double buffering something like that is required anyway and if that address can be defined in byte-steps you get hardware-scrolling cheaply. Additionally you need to define a virtual screen-width. And for bitplane-graphics-modes it would be useful to have a horizontal-scroll feature like in $d016 on the VIC.
        Those simple features would make scrolling very inexpensive (in terms of CPU time) and the processor could then spend most of its time on software-sprites.

        VGA-cards supported exactly those features… (And thinking about it, now all this is very similar to an overclocked 8086 PC with VGA and Adlib-Card 🙂 )

      • Daniel

        Could you give me an idea how a second 6502 would be wired and programmed to do graphics?

        What I came up with was to have discrete circuitry that uses registers to store color values, and two shift registers for each 8-pixel segment.

        The 6502 reads a byte from video ram, potentially applies a sprite part, and writes it to the inactive register, mapped into the zero page.

        On segment boundary, the registers are switched, an nmi is triggered, restarting the process.

        Now, my intuition is that this wouldn’t fit into the time available, even on a 10Mhz clock.

        In the c64, one 8-pixel segment is drawn over one cycle. Even at 10 cycles, it doesn’t look feasible. (Especially with sprites and all that, but even a single lda / sta plus nmi boilerplate would be pushing it.

      • GregC

        I think the key point on the graphics capability, is that some relatively fast / relatively complex hardware is required to handle all that is desired in the graphics, with sprites, collision detection, and smooth scrolling capabilities.

        Whether this is implemented in a VIC chip, or a large board of discrete logic chips, or in a seperate graphics processor (of some sort), is not really that relevant to the system programmer!

        What is relevant, is that the programmer interface to the graphics hardware, is fully described, documented and open!

        One example is the “Gameduino”. As a programmer, it provides a clearly documented hardware interface, for the programmer to access all the graphics modes, sprites, collision detection, and smooth scrolling capabilities. The fact that it is implemented in an FPGA is only relevant to the impact on build cost and potential for kitset assembly.

        In terms of hardware cost and ease of assembly, a cheaper co-processor or MCU implementation would perhaps make sense.
        But I don’t really think a second 6502 CPU is best suited to this task (or likely powerful enough for all that needs to be done in real-time video).

        But a cheap MCU, or something like the Propellor chip (which is cheap and even available in a 40 pin DIP), that already has video interface capabilities and graphics co-processor code developed, would probably be a better graphics hardware candidate. And, as mentioned elsewhere, the same single propellor chip could also do the sound interface (“SIDcog” for example).

        But again, it is only the detailed and documented programmer accessible hardware interface to the graphics “co-processor”, that is relevant to the programmer.

      • Gert

        @Jenkings: having the CPU manually time video signals? Really?

        I know it takes little bit of sleuthing on mouser but Seiko-Epson makes graphic controllers that interface as a direct 8-bit Intel80 bus as control and framebuffer. They even sell a specialized tv encoder that interfaces with them. A simple of-the-shelf part for around €18 combined I think. Handles all the dirty stuff like transposing your graphics resolution to pal/ntsc resolution.

  15. Nicolas Alvargonzalez

    Have you talked with Ben Heck@Youtube about doing a collaboration video on this? This is your guy!

    Reply
  16. Jose A Medina Jr

    The best starting point for building a computer is to use the Z80 CPU that is available in https://www.jameco.com website. They also sell part that are the 7400 hounded numbers that are available. I am already assembling a Z80 computer bit by bit using prototype PCB and ISA boards.

    Reply
  17. Wombat

    I think there should be two models 1 all the chips are just plugged in the other full of more advanced people who can solder.

    Reply
  18. Richard

    Z80 not getting any love 🙁 CP/M anyone?
    Have you seen the Z80 Retro SBC? “Zeta 2”. The YouTube channel smbakeryt played around for it a bit and hooked it up to a few peripherals.

    I toyed around with the idea of designing a 65186 (Western Design Center) Super C64 as well back around 1995. I had by Amiga though and did not really see the appeal. Its a different story today with all of the retro 8-bit fever / revival… it may make some sense.

    Video is messy though.. I would be very tempted just to stuff it into a small FPGA.

    Cheers

    Reply
  19. Allan

    You should totally make this in to a YouTube challenge and get people like Dave from the eev blog or Ben heck to design the main board and the find some software YouTubers to write the “os” etc. and make it a open community project 🙂
    And everyone would be able to make videos on their channels about the process.

    Reply
  20. GregC

    I always thought the L-Star “Software-Defined 6502 Computer” had the potential to evolve into a dream “real 6502 chip” based 8 bit design. With the added benefit of low component count and low parts cost!
    All of the 8 bit code runs on a real native 65C02 chip, just with all the I/O hardware being emulated by the Parallax Propeller chip’s 8 “cog” processors.
    eg. There is already a quite complete C64 SID chip implementation, which runs in one cog (the 6502 thinks it’s talking to a real SID chip). Another cog runs the video “GPU” functionality etc.
    The only issue seems to be that the current “Software-Defined 6502 Computer” is pushing the real-time processing capacity of the current Parrallax Propeller chip, so this could limit the design’s longer term “dream 8 bit computer” potential.
    However, the exciting thing is that the open developed successor chip “Propeller 2” is now looking very close to actual silicon production in 2018!
    This would then enable an updated “Software-Defined 6502 Computer” design, with plenty of added processing power (for implementing more advanced I/O hardware emulation).
    The benefits of this approach (over an FPGA solution), are that you maintain the cool retro design of your 6502 code actually running on a genuine 40 pin 65C02 processor chip, and you have the ideal low parts cost of just a few $10 chips!

    Reply
      • GregC

        Did you mean that you may as well emulate the 6502 in the Propeller?

        That was answered by: “… you maintain the cool retro design of your 6502 code actually running on a genuine 40 pin 65C02 processor chip”

        The Prop is just to allow implementing I/O like Sound (eg. SIDcog) and Graphics, for the real 6502 to talk to! And cheaply, without an expensive FPGA, or a large PCB full of discrete TTL. 🙂

      • Daniel

        “Did you mean that you may as well emulate the 6502 in the Propeller?

        Exactly. 🙂

        “That was answered by: “… you maintain the cool retro design of your 6502 code actually running on a genuine 40 pin 65C02 processor chip”

        I still fail to see the point. 😉 Probably I’m not thinking poetically enough.

        “The Prop is just to allow implementing I/O like Sound (eg. SIDcog)

        There is this saying “rolling the cube and carrying the sphere.” People have spent man-years on getting an okay SID emulation on PC systems with virtually unlimited processing power.

        I guess once we have a modern architecture, why not just use it. 😉

      • GregC

        Hi Daniel, I don’t disagree with your comments! I think we are just differing in our interpretation of David’s “dream computer”.

        In terms of recreating the 80’s retro experience, “SID emulation on PC systems with virtually unlimited processing power”, is not the point here.

        To try and explain where I’m coming from…

        My personal 80’s experience was having an 8-bit computer (eg. the C64) where you basically had to understand the hardware at the register level, and coding “close to the metal” (generally in machine code), utilising every available clock cycle in the challenge to make it do something magical.

        The “fun” aspect which bought this experience to the masses (in the early 80’s), was the advent of graphics chips (like the VIC-II) and sound chips (like the SID), which enabled exciting visual (and audio) capabilities, with only the limited computing power of the 8-bit processors of the time.

        This true retro 80’s “lower level” computing experience has unfortunately been lost on much of the younger generation. These days, I commonly see young software developers who have a profound lack of knowledge of the underlying hardware operation itself.
        Software development is generally done at a very high level. The modern challenge is just learning the API’s available from pre-written libraries.

        This is why my comment focusses on code running on an actual 6502 chip, and replacing unavailable 80’s hardware with emulated I/O.

        The key point being that the emulated I/O appears to the original 8-bit CPU in basically the same way as original 80’s graphics and sound hardware did.
        In this way, a retro enthusiast can re-experience the same register level interaction, and the same challenge to make the available hardware capability do something magical.

      • Daniel

        Hm… Yea I kinda understand, but as the entire architecture is essentially emulated, the developer experience wouldn’t really change with emulating the entire system altogether.

        The way I see it, there are three divergent reasons why old computers are prized by people.

        One is what you mentioned, having to understand the system and code to limitations. It’s a _sport_.
        When we understand it as that, it really doesn’t need the architecture itself anymore. Soccer players don’t have their arms tied down, or cut off. 4k demo competitions on modern x64 architectures is the same type of sport; and coding for old architectures in an emulated environment (say for c64 in VICE) is also the exact same sport.

        Creating a new sport is not easy. It can very easily look like a complete joke. I mean if soccer hadn’t existed, and I came up with it today, people would laugh at me. Or look at kabbadi. I mean if I came up with it, people would ask me if I’m high.

        My idea, designing a new system to new limitations – those of small-scale production without the use of modern MCUs or FPGAs – would result in a naturally-evolved new sport.

        The second reason is the aesthetics. Ready Player One and all that. Plenty of modern games on modern platforms evoking the aesthetic. I consider BASIC itself more part of this than any of the former. To me it wasn’t the language that was the big thing, it was that the computer’s default interface was a programmer’s interface.

        And this ties into the third reason, having a limited environment that can be explored and hacked, without any background processes that connect to the fucking cloud, or vendor-locked peripherals with closed source drivers, or any of that shit… A computer that actually tells its user “hello, I’m your servant, what do you want me to do”, as opposed to “let me watch you and relay what my corporate masters think would be best for you, peasant”. 🙂 MCU-based single chip computers are pretty good on this. Closed ARM architectures where you can’t even run off-the-shelf Linux, less so.

      • GregC

        Hi Daniel. I think we are perhaps not really that far apart in our thinking. 🙂

        I believe you’ve captured it in your comments comparing the challenge we seek to being a sport. With modern equivalents like 4k demo competitions on modern x64 architectures, etc.

        On this thought path, I think you touched on the key point in your third reason… It needs to be a completely open architecture design, so that we have full access to explore (and push) all the capabilities (and limitations) of the system design.

        As you imply, this is likely the key factor in our recollected passion of early 80’s computing. A time when our computers came with a “Programmers Reference Guide” that outlined, in detail, the hardware design and low-level interfaces down to the register level. From which point, the challenge “game” was on!

        But we appear to still differ on the question of using MCU’s (or not). You can still have an open architecture with a MCU replacing a board of TTL logic!

        For comparison, consider that although the 80’s C64 “Programmers Reference Guide” did fully described the register level hardware interface, and everything that the programmer can access / utilise to create the magic. It didn’t go into the detail of the logic circuits that implemented all this functionality inside the VIC-II chip itself, as this was not relevant to the programmer.

        This would be no different to utilising a modern MCU to implement the desired hardware functionality, with the proviso that all of the hardware interfaces accessible to the system programmer are fully described!

        The benefit of utilising an MCU to replace a board full of discrete logic, is simply the cost savings through lower component count, and easier small-scale production.
        The key is that the programmer interface is open and fully described, and not based on “vendor-locked peripherals with closed source drivers, or any of that shit” (as you described). 🙂

      • Daniel

        I’m not against MCUs themselves, I just don’t think it’s very sporting to use one in this specific project. An MCU as an entire computer architecture, with a programmer shell and peripheral connectors added could be a classic-style micro in itself. (Like the Propeller Hydra game console.)

        Using an MCU to emulate a whole computer architecture apart from the CPU, is just emulation. And once we’re doing emulation, why not emulate the CPU too. 😉

        Also, this gives you a free pass to create pretty much any behavior you want. Designing to limitations will result in a system that has naturally evolved quirks and limitations. If you can just program whatever you want, it will be just arbitrary.

  21. Unicorn74

    IMHO gfx & sound possibilities are very important to make users busy and guarantee success of such niche platform.
    So: gfx at last 64 or better 256 colors, at least 8 sprites (more if there wont be possible to use gfx tricks from c64). HDMI is a must, becouse a lot of people dont have vga or composite capable monitors.
    Sound: yamaha FM or sid-based solution would be ok, but should be paired with at list 4 channel digital audio (8 bit is okay). Stereo output.
    Another way is to use a music sintesizer chip used in older mobile phones (basic general midi synth with simple effects on top).

    Ideally if there would be some expansion port allowing use of 3-rd party externals, as bluetooth or wifi connectivity, midi etc.

    I think that such a “powerfull” machine may be a success if done right. People would start to write their own software, demos etc.

    Reply
  22. SparkyNZ

    Yeah I’m waiting to see the day when you’re given a free Mega65 and asked to do a review! I’ve had my eyes on the Mega65 for quite some time.

    (Sorry if this post appears twice – I was trying to enable email notifications)

    Reply
  23. CubicleNate

    I think that sounds fantastic but personally, I would want it to somehow be compatible with all the Commodores 8 bit lines. It would be pretty fantastic to have the ability to have some sort of Commodore convergence hobby machine that would allow me to enjoy my youth as well as explore the future.

    Just my thought.

    Reply
  24. will

    A big requirement for any “Dream Hobby Computer” for me is a robust and easy to use expansion interface of some kind.

    Reply
  25. Max Chan

    I have three plans on designing this type of “retro-style” computers, but none of them involves 6502 or Commodore BASIC sadly.

    The lowest end plan is roughly a modular, fully static semi-clone of the original IBM PC. It uses a 4.77MHz Intel 80C88 (a CMOS version of 8088 for lower power consumption) and an Intel 8087. It has the standard 640kB of static RAM, and 64kB of single-cycle Flash memory to hold both BIOS and a copy of FreeDOS. Development on this, since it is standard x86, uses NASM or older DOS-centric C compilers.

    The middle ground machine is based on a MC68SEC000 at ~12MHz. It has 12MB of DRAM and 1MB of Flash. This machine is less planned out, but I am positive that its development tools will be based on GCC.

    Both machines above contains support for Ethernet and USB through the use of special controller chips: WCH CH395 for Ethernet, WCH CH374 for USB OTG and USB host. Since I have both Ethernet and USB as well as ample amount of memory, I can leave storage out and just program the machine to boot from Flash, USB or PXE. In both plans CPLD devices are used to concentrate glue logic into small footprints. I still have some difficulty planning out the graphics hardware though, since I want to use a more modern processor in it so it can both emulate CGA/EGA/VGA and execute a cut down version of OpenGL ES.

    As of the high end machine, it is based on an NXP i.MX233 chip with an 454MHz ARM926EJ-S core, 64MB of mDDR SDRAM, 8GB or 16GB of NAND Flash, Wi-Fi and Bluetooth for connectivity along with USB OTG, and runs Debian Linux. This is farthest removed from the “retro” of the 80s, but the limitation of that old ARM core still puts a similar restriction on programming on those devices.

    Reply
  26. Gert

    Challenge accepted.

    The most important requirement is off-the-shelf parts that are now and in the foreseeable future easy to acquire. There is no way to get around using SMD parts but we can limit that to packages that are still easy to manually solder.

    I was already working on something 65C816 related and I see no reason to use any other CPU. Now SRAM is a problem, but 512K on-board is still reasonably priced in workable packages.

    When it comes to expandability I’d just leave an so-dimm socket footprint so allow for a custom memory expansion board. Should have some keying so ppl don’t try to use standard so-dimm memory modules but I’ll think of something.

    Still have to pick the best sound ic to use. Definitely something yamaha (compatible). With again, a footprint left for a socket to plug in a SID if wanted.

    ROM is also a problem nowadays. But I found a cost-effective 128K flash rom for less than a buck. It’s PLCC-32 so easy to take out and reflash when needed.

    Personally I like Lattice MachXO2 FPGA’s because they’re cheap and have the configuration memory build in. So they are more or less high density CPLD’s. That could be used for getting the upper 8 address lines from the data lines, two PS/2 ports, two game ports, a dedicated SD (via SPI).

    For an external bus I quite like the SPI65(B) bus, just search the 6502.org forum for more information about that.

    There is no way we can use a VIC(2). I don’t think it’s worth the effort to try to re-implement it. But I remember researching an IC that would be easy to use/program and allow for some quite powerful graphics. (1024×786 max I think). With all the fun stuff like sprites, double buffering etc. As a video output I’d use a DVI-I for analog en digital video out through one connector.

    Seems I have some schematics to design…

    Reply
  27. John

    Reading over the comments, it seems people have as many different desires for an 8-bit dream system as there were actual models of computer back in the 8-bit era.

    As a music guy myself, I’d love to see a system with one standard sound chip built in (for game devs to rely on) but with the ability to add in other sound chips (for musicians like me to experiment with and make chiptunes).

    Reply
  28. Berni

    To cover all of your points i think a FPGA is the only way to do it cheaply.

    70$ is probably about it would cost to build it. Things like Composite video, VGA, Keyboard, SD card, Sound can all be handled by the FPGA internally while a 512KB SRAM chip next to it wouldn’t cost much.

    All the other C64 chips can be emulated perfectly so that the original C64 basic ROM will run in it, but also have a secret sequence of hardware register writes that the software can use to put the machine into “Enhanced C64” mode where it suddenly gets things like 512KB of RAM, dual SID chips, access to special high color video modes, access to registers that increase the CPU clock speed etc. Much like a x86 chip switching into higher modes where the software that’s unaware of the special mode just runs like usual but software that knows about it can jump into it.

    The max CPU speed depends on how well optimized the design is but i would expect it to run at about 20 to 100 MHz.

    For software development you can do something better than an emulator. Its possible to provide a debug connector (COM port or USB) that you can connect to a PC and that lets it talk to a special debug controller. This allows the PC to take over the machine at any time to load code, set breakpoints, single step the CPU, look at all the memory and hardware registers live etc…

    I can design such a board but most of the work here is in the firmware part to program the FPGA for all these things. People have already made FPGA implementations of the C64 so one would likely only need to add the enhanced peripherals on to it, but this is still likely half a year of work.

    Reply
    • Gert

      I disagree. Making it purely an FPGA is not needed and exactly what he specified his dream computer shouldn’t be. He also specified that it doesn’t need to be compatible with the C64.

      If he did want C64 compatibility then yes… FPGA would be the only show in town. But 65C816 cpu’s still roll out of the factory to this day. No need to stuff that into a FPGA.

      Also, someone with low to moderate soldering skills should be able to build it. It’s getting more and more difficult to get high pin count FPGA’s in (relatively) friendly packages like QFP-100/144.

      I’m still missing quite some parts. But cpu, ram, rom, cpld has BOM less than €23 in prices per piece. So that could be lowered significantly in bulk. So FPGA isn’t necessarily cheaper. Each off-the-shelf part you use also cuts down development time spend on implementing it in vhdl.

      Reply
  29. Chris Lasagna

    So many projects of this type have been started and then abandoned.

    Personally the Microbee Color Plus had me drooling for years since it was announced.

    Similarly, the ProPeddle computer which fuses a 65xx processor with the propeller micro controller (for video and I/O) was really cool and would have been a starting point for what you are looking for.

    Sad.

    Reply
  30. Andy

    I can see where you’re coming from, especially with two kids I want to introduce to the *fun* of computing (rather than the interminable pain of modern languages on underpowered linux blobs). But I’d be right in there with a Z80 and the Sinclair school of design, rather than Commodore 🙂

    I work with an electronics design guy, but a project like this needs backing and a solid architecture before it can grow.

    Reply
  31. Greg

    I’d love to take John’s idea and standardize it in such a way that the memory space and CPU are compatible with a C64, or even better, a VIC-20 – i.e. An end-goal of any chip tunes being playable on a real 64/VIC with a cartridge containing one of these other sound chips. The larger cartridge size and unused memory space on the VIC-20 makes it an intriguing candidate, IMO. Could put a SID, one of those Yamaha chips everything used, a DAC, all on the same cartridge. And also have an FPGA version with all the chips simulated if part availability becomes a problem.

    Reply
  32. Mario

    Hello David,
    And what about a clone of the ZX spectrum, there are some of them out there that are close to what you are looking for:
    – 128kb of ram
    – All components (except the AY-8912 sound chip) are still fabricated today
    – It uses basic (the spectrum was very popular here in Europe)
    – There are plug-in accessories to add CF or SD card storage
    – It has a lot of software from the era (all the software from 48kb spectrum and 128k)
    – No fpga (there are version that have it, but look at the links bellow)
    – There are possibilities to add an operating system like TR-DOS or maybe CP/M but i never try this

    Caveats that you should consider:
    – The chip count is elevated (~48 chips depending of the version), this implies that is harder to make and the cost rises.
    – It’s based on Z80, so this is not a caveat for me anyway 😀
    – Low resolution (256×192) and few colors (15 colors but with limitations)
    – It’s basic but not commodore basic
    – The keyboard it’s a little painful to play with compared to a commodore

    I made a 48kb clon two two years ago and it was a fantastic experience, now i’m looking forward to make a 128kb one.

    Here are some useful links:
    http://trastero.speccy.org/cosas/JL/Superfo-Harlequin-128K/128K-i.html (the first 128kb model, schemes and docs)

    https://www.sellmyretro.com/offer/details/Superfo-Harlequin-128k-ZX-Spectrum-128K-clone-PCB-only-13710 (this is one place were you can buy the board, it’s actually unavailable, but there is more information there)

    https://www.sellmyretro.com/offer/details/zx-nuvo-128-%3A-zx-spectrum-128k%2C-%2B2a~~%2B3-clone-pcb-include-divmmc-on-board-25385 (this is the last model, it has a little fpga just to add SD card storage)

    If you want to build one you can add your case and keyboard from here:
    http://www.zxrenew.co.uk/ZX-SPECTRUM-REPLACEMENT-CASES-only-c22752627

    There are more clones out there, and even soviet clones with 4mb of ram, very curious.

    Hope that it likes you and if you are interested i can help you with more information

    Reply
  33. Tad

    Western Design Center makes a modern version of the 6502, the part number is W65C02S6TPG-14. I believe it can run up to 16MHz or down to 1MHz. Off the shelf SRAM is cheap, cheap enough to just design a video circuit that uses another one of those modern 6502’s with enough SRAM for video and such similar to how the NES does (although they added a few instructions). You could probably just use some kind of back plane style design, unless you want it compact like a C64. I guess the problem is developing a standard for hobbyists to adhere to, one suggestion would be a CP/M style OS where the BIOS are written for the hardware you design and has calls that every programmer can rely on to write general purpose software as long as you run it on a compatible processor.

    Reply
  34. tekrat

    I’ve been looking at this Arudino UNO clone that came out. Unlike the UNO It comes with an ESP32 (32 = 32bit) SoC processor that runs by default at 80 mhz, 448kB ROM, 520kB RAM, WiFi, and Bluetooth. If I remember the original UNO ran at 2-4 mhz with an 8 bit processor. I know the much slower Arudino’s can run VGA monitors, B&W RCA out, PS2 keyboard, and run TinyBasic. So in theory we could do what you want with this.

    But that my verbal diarrhea of geekdom.

    http://linuxgizmos.com/esp32-based-banana-pi-boards-mimic-arduino-uno-and-microbit/

    https://github.com/yelvlab/BPI-UNO32

    Reply
  35. Tom Wilson

    I’m also thinking that a dual-microcontroller board is the way to go, here.

    Why two microcontrollers? One to do the video and one to run the user environment.

    I have been playing with Altair simulators lately (I have two, the Altair Clone and the Altairduino), and one of the guys in the Altairduino forum built a working “Dazzler” display from an Arduino microcontroller.

    The Altairduino also runs a perfect 8080 simulation on the Arduino Due, which has a 48MHz clock.

    That and this got me to thinking. We could run the CPU simulation on one board and use the on-board memory for fast RAM. We could use DMA on the GPIO pins to talk to external memory chips as well as to the second Teensy.

    What’s the second Teensy doing? It’s driving a video display via VGA. I’m not sure how fast we can drive the connection between two of these units, but we could easily do something like 430×240 graphics (to fit the 16:9 aspect ratio of a modern TV) in 6 bit color. If we left the extra two bits in there (we could use one for an alpha layer for sprites), then we would need 3.096 megabytes per second of data transfer to update the entire screen at 30FPS.

    Building the actual unit would be fairly simple; the complex part would be the programming: building a kernel ROM that incorporates a new BASIC, a GPU ROM, and communication between the units. We’d also want to incorporate basic WiFi, Ethernet, and joystick and mouse handling.

    It’s actually very doable, but it would be time consuming. I wish I had a year I could take off of work to build one of these things… 😀

    Reply
  36. Andy

    I don’t know anything about assembly programming on those old machines, but I remember making my own stuff in VIC-20 basic back in the day, and I have a definite soft spot for the Yamaha FM chips.

    My dream retro machine would have a fast (80mhz+) CPU, hardware sprites like the C64, though more of them. Multiple video modes, and the ability to do all those raster-tricks they used to do back in the day. Yamaha FM synth chip, though a SID is fine too. All in one box with a built in keyboard, and booting to a modern BASIC interpreter. Or maybe… python?

    Modern conveniences would be an SD card reader, and some sort of Bluetooth input for proper game controllers. As well as the more modern programming language I mentioned before.

    I hope someone makes your dream retro computer soon, 8-bit guy!

    Reply
  37. GregC

    All these comments with awesome thoughts about different hardware design possibilities are inspiring, and indeed exciting to contemplate designing! 🙂

    FPGA… Dual micro controllers… W65C02 etc. etc. And to tekrat: The ESP32 is the microcontroller of choice for 2018 IoT projects. And, yes, it is Arduino supported. And, yes, you can even team it up with an existing retro graphics & sound interface (like the Gameduino), which has an established code base.

    Exciting possibilities!

    BUT… and I repeat: BUT!!! The more you think about all the “cool to make” possibilities, the more you realise the undeniable reality that you must achieve a “critical mass” of community interest, for any “dream computer” platform to actually achieve a sustainable on-going following!

    Without this, any “cool” new platform someone develops, undoubtably goes down the same path as the 100’s (1000’s) of other cool designs that have preceded it!

    The usual timeline is: Initial development excitement -> Group of followers -> Dwindling interest as other “cooler” designs pop-up -> Abandonment! 🙁

    In this regard, you simply cannot understate the importance of popular legacy system compatibility (to capture the interests of the masses), combined with modern enhancements (which retain retro 8 bit simplicity), to re-ignite and retain the interests of the masses, and also inspire interest with the new retro generation.

    With this in mind, the two most “likely to succeed” candidates, at the moment, appear to be: The well progressed “ZX Spectrum Next” (for the Z80 enthusiasts), and the promising looking, but less well progressed, MEGA65 (for the 6502 enthusiasts).

    Let’s face it, one of the key requirements for a true “dream computer” is a critical mass of followers, to ensure the necessary on-going motivation to develop new software and to be able to share with a significant community of fellow enthusiasts! Without this, it will always remain just another “dream” computer.

    Reply
    • Richard Thomas

      Greg, good job on pointing out the Next. I jumped in on the kickstarter and am eagerly awaiting mine. If the 8 bit guy hadn’t picked the dark side, perhaps that would do him. Though the Next is FPGA based so I have heard some rumours that it could be reprogrammed to work as other systems (within external hardware limitations).

      Reply
      • GregC

        I am more a fan of Motorola 6800 & Mostek 6502 architecture (my Z80 experience was a TRS-80 clone), and I never owned a Sinclair computer!

        But, the ZX Spectrum Next project did gain my interest, due to the involvement of Rick Dickinson, the software developers getting involved, and the general thoroughness / completeness of the design.
        Also, with the promising formula of: Popular retro system backward compatibility combined with enhancements to ignite renewed interest, this is looking like it has a good chance of achieving that necessary “critical mass” of enthusiast following.

        Even impressed with the clever idea of supporting the cheap Raspberry Pi Zero as a “standardised” co-accelerator board option, giving software developers a standard config for more advanced possibilities.

        I missed the kickstarter, but I’m definitely keeping an eye on proceedings! 🙂

        For the 6502 enthusiasts, hopefully the MEGA65 project will get itself to a similar level of design completeness and wider involvement!

  38. Rob

    Hi. As a text encoding geek, I’m curious why you specifically want PETSCII support? Do you just want the same repertoire of graphics characters to work with (e.g. the block drawing characters)? Or do you really want it to use the identical byte encodings for the characters, including its really weird way of doing lowercase? Would it be acceptable to have switchable character sets (ala EGA fonts) that could include a PETSCII option? How about ATASCII or Apple MouseText support?

    Reply
    • The 8Bit Guy

      Well, because I’m wanting a successor to the C64 (and no, I don’t mean the C128 or Amiga). And since all other Commodore 8-bit machines used PETSCII, I would want this machine to as well.

      Reply
    • Tom W

      The VDC chip on the 128 did it perfectly. It could display both upper/lower case at the same time as the graphics characters. To switch back and forth, you could send a control character to enable Graphics or Text mode. In fact, PETSCII has plenty of room in the character set for both lower case and graphics characters, but they were left out because the character generator ROM used character codes 128-255 for reverse characters.

      The IBM PC used separate background colors for each character cell, and the EGA added custom code page support (re-defining character codes 128-255) as well as additional attributes. You can’t really do something like full Unicode support, but going to 2 bytes per cell would add the ability to extend the character set with both PETSCII and Code Page 402, the most commonly used character sets on PC’s.

      Reply
  39. Steve

    Many directions are suggested here. I am currently designing a Z80 board. It has an RS-232 to talk to modems and will communicate with a user’s via a PC terminal emulator. It will have a front panel option w/ LEDs and switches and run in a tiny 128 byte RAM and 128 byte ROM mode. This will provide a hands-on-the-bits experience. I am designing a WS2812 controller to light up a 25 LED display with all the colors.
    RAM and ROM are configurable up to 164K, although I have not found a project which would require more that 8K / 8K. The board will accept 32K parts.
    This is the basic starting point. It is basically an embedded system design.
    It is retro. All parts are through-hole w/ a minimum 0,1 inch pin pitch.
    I have plans for an I2C interface, GPIO pins and DAC outputs to drive drive outboard displays such a 7 segment LEDs, Liquid crystal modules, and VU meters.
    From what I am reading here, it seems like (1) video, (2) sound, and native development tools (such as BASIC) would need to be added. If a retro gaming computer is needed, then a keyboard encoder and memory mapped video is needed. This can be done if the video bandwidth is limited.
    But . . It seems to me that these computers already exist. The C64 is the answer, no? So I am not understanding exactly what the dream system would offer that wouldn’t be provided by a C64. Can you explain your dream machine in terms of a C64? If you had a C64 in front of you, what would you change or add to it to bring it up to dream machine specs?
    [ Also, be advised that any new computer would not have the software support of a C64. ]

    Reply
  40. Thomas

    Hello Mr. 8bit guy, sir,

    you might be interested in our little hobby project called “Steckschwein”, which is a 65c02 homebrew computer covering quite a few of your requirements:

    65c02-CPU @ 8MHz
    64k RAM
    32k bankable ROM
    Video chip V9958
    Sound chip YM3812 (OPL2)
    rs232 via UART 16550
    SPI used as main peripheral bus for:

    sd-card based mass storage
    PS/2-peripheral controller (keyboard, mouse) (ATmega8)
    RTC (Maxim DS1306)

    The Steckschwein is a work in progress, so there will be more than 64k RAM at some point.
    http://www.steckschwein.de/

    Cheers,
    Thomas

    Reply
  41. Derek

    Well, I did just finish my embedded systems class so i at least have a bit of schematic / PCB design under my belt. Maybe I’ll pick up this challenge as a hobby once I finish the semester 🙂

    Reply
  42. TheOrangeCat

    Hey, I ran into problems with video system. I cant replicate the VIC chip. I made my own video format for it which is monochrome pixel graphics. I will left a connector on the board for RGBI but that will take some time to make. (If I will find documentation)

    Reply
  43. saddle_au

    Just make it so the CPU and interfaces never get upgraded so earlier ones get tossed because they aren’t up to it. Just keep adding more and more interfaces, sensors and code. The problem with things like the PI to me is there are already 5 or more versions of it around.

    Could you live with a terminal mode instead of on board graphics?

    Reply
    • GregC

      Unfortunately your article lost me on a multitude of points. Not the least of which was saying that sound and graphics all needs to be discrete! This overlooks that successful (and fun) 80’s machines had relatively complex sound and video chips (like the VIC-II). For example, you overlook that Sprites were a key enabler of fun and graphics capability on slower 8-bit machines.
      Yes, you could design this using discrete logic chips, but it wouldn’t be cheap! A large circuit board covered in TTL logic (the VIC-II chip is estimated at 5000 transistors), would be more expensive than a FPGA!

      Also, wanting an educational throwback to the 80’s, but then going on to say we need a C compiler (and Python). Well, you may as well just get a Rpi!
      Even the Maximite, with it’s updated BASIC and speed (allowing game coding without going to assembly code), is more 80’s throwback educational. 🙂

      Reply
      • Daniel

        Yes, a large amount of discrete chips would be more expensive than an FPGA. BUT, buying all the tooling needed to PROGRAM an FPGA would cost quite a lot. As I said, if it’s not cost optimized for batches of _one_, I just don’t see the point. I’m really not against FPGA-based systems, they just seem to be dead after a batch. With a c64 remake or 1541 emulator, that’s okay, people will use it in the scene. With something completely new, it means it’s DEAD-DEAD.

        As for modern languages, hey, the specs do sound kinda more like a 386 than a C64… So why not have the best of both worlds?

    • John

      I enjoyed reading that article; you had a lot of insightful things to add to the discussion. And I agree with most of it, but, like GregC, I disagree about the Python (and C), and here’s why:

      I love Python, and I’m looking forward to teaching it to my kids as well (instead of BASIC). But, Python is useful because it’s so “high-level;” to learn it, you do need to learn logic, but not about the internal workings of a computer. Whereas, learning to program 6502 (or Z80) assembly is so great because it’s so “low-level;” you feel like you’re interacting directly with the hardware/chipset.

      These two goals are not really served by the same hardware, and trying to make a machine that can do both will likely compromise both goals (or raise costs).

      Reply
      • Daniel

        Heya John 🙂

        Well I think the two can totally live side by side. BASIC isn’t exactly low-level either!

        As I mentioned on Medium, I grew up on the Plus4, something most western kids only know from “history of Commodore” videos as this weird curiosity. For us in the East, it was the most ubiquitous microcomputer for several years.

        Now the Plus4 had a vastly improved Commodore BASIC, and it allowed a lot of functionality including sound and graphics without learning about the hardware itself.

        Sure, if you wanted to do “pro level” stuff, you had to learn assembly. And, the Plus4 also had an ML monitor built in! You only needed to execute the MONITOR command, and lo and behold, you had an ML monitor with a rudimentary assembler / disassembler!

        So a MicroPython cartridge would allow this machine to be approachable, as Commodore BASIC was kinda approachable. And if people want to do more, I didn’t suggest for no reason that the built-in ROM should have an ML monitor as its shell.

        Also, I totally think the Micropython implementation should have a module that implements low level memory manipulation… A “peekpoke” module. 🙂

      • John

        Hi Daniel,

        I agree that, as an ‘approachable’ language for beginner programmers, Python beats BASIC hands down. I see your point there.

        And, if you want to make a Python cartridge for an 8-bit system – real or imaginary – I’m sure the Python community would be supportive. (They seem to like getting python to run on various things! There’s even a python implementation for Nintendo DS homebrew, for example.)

        However, I see one of the advantages of Python being its ability to connect to other aspects of modern software. For example, when I was teaching classes, I wrote a little python script that pulled data from my grading spreadsheet and e-mailed each student their grade so far, and in my research I use python then generate .svg graphics that highlight the manuscripts I analyze.

        When teaching Python, then, I’d also want to teach how it can connect to modern things like spreadsheets, e-mail, and .svg; thus emphasizing how Python is an actual tool to use in real world activities and not merely an educational toy. Indeed, that’s part of *why* I find it better than BASIC. And to do all that, I’d teach it on a modern system.

        In any case I think a “micropython” as you say would probably be fun to play around with, as long as it getting it to fit doesn’t compromise the “knowability” of our imaginary 8-bit dream system. In the end, my ‘dream system’ might be different form yours and both might be different from the 8-Bit Guy’s. It all makes for a good conversation, though! Thanks again for your thoughtful comments.

  44. Kenneth

    I’ve totally wanted to build a similar machine to what’s outlined here, and this has got my interest stirred up again. Hopefully my project will see the light of day.

    Reply
  45. Cynthia C.

    I’m a big fan of the Commodore 64 myself. I really had to beg my parents to get me one, as it was not a cheap purchase for my family at the time. I spent MANY hours on it though, including buying a book that had code (BASIC data statements that got POKEd into memory) for assembly language programming. It took a few tries to find all my typing errors and get the checksum to match, but when I was done I had a working assembler!

    The first game I tried writing was called “Typo Beast,” and the idea was to type in the words that appeared on the screen to get the Typo Beast sprite to “eat” them. I planned to use it to teach myself typing.

    I did the intro screen, which cleared all the text on the splash screen by decrementing the ASCII value of each character until it got to a “space.” I think it was one of your videos where I saw this effect not too long ago!

    The greatest part about it was how much faster it was than BASIC. With BASIC, you could watch as it went line by line, character by character, decrementing each ASCII value. It was only slightly more exciting than watching paint dry. In assembler though, it was a zippy little effect!

    Don’t even get me started on how many hours I wasted on Telengard!

    “A level 34 dragon appears!”

    Doh! I’m dead again!

    I even programmed my 64 to do 4 kinds of curve fits for data from my physics labs in college. It saved me numerous trips in the cold to the computer center where many of my colleagues had to log onto the VAX to do the same thing.

    I can go on, but I’ll spare you the gratuitous nostalgia. I got rid of my C64 at the end of college. I had to move across country for my new job, and really had to fit everything I owned into my ’76 Malibu. I have often regretted that.

    But I’ve had a lot of those “computer nerd” fun feelings come back with the Raspberry Pi. I’m breaking in my new 3B+ right now! Am I playing with the bare metal? Not at the moment. But I’ve been teaching myself Python with Raspberries and I get that same sense of accomplishment I did back in the early ’80s when I got stuff working.

    The big plus now is that I can write code and build stuff that is actually useful and usable by people now, and it doesn’t take forever to run! (Well, there are still things I do that can slam a core, but most things occur in real time.)

    I often find myself thinking “I haven’t had this much fun with a computer since my C64!” As an engineer, I have to give the designers real credit for their trade-off choices and building what I refer to as an “elegant” an extremely power efficient design.

    I’ve enjoyed a lot of your videos, and with my FPGA and analog design experience, I could certainly design all the electronics necessary to build a functioning “C64” successor. But I can’t find a good enough reason for “why???” Nostalgia simply isn’t enough for me. I need more modern day utility.

    Thanks for all the nostalgia on your YouTube channel! It has brought back some great memories.

    Cynthia

    Reply
  46. AlexCL

    The Ultimate64 FPGA based Commodore 64 motherboard just came out and pre-orders are already going out. Seeing as it is FPGA based, you might be able to modify the code to create whatever machine enhancements you wanted in software.

    https://ultimate64.com/Ultimate-64

    Reply
  47. Jeremy

    I’ve been working on a 65816 computer, it does use an FPGA.

    It has 16 sound channels, each supporting PCM samples, square, triangle, and sine waves.
    The PPU is 320×240, has 4 layers, 64 sprites, 256 color extended color, and HDMA effects.
    I have 8 MB of RAM and 4 MB of ROM mapped, and a little for the IO.
    It has multiple high speed DMA channels.

    It does do a little Basic at the moment.

    Right now I have a working emulator, I am currently working on the FPGA part.

    Here are a few videos of the emulator.
    https://youtu.be/6W2OyAhUB8A
    https://youtu.be/_15KJB4UGEs
    https://youtu.be/BWHlmzFxWYA

    I’ll eventually put this up on Hackaday.

    Reply
    • GregC

      Thanks for posting the link @jollyroger, I’d never seen the “Kiwi” before.
      Interesting it’s called the Kiwi but comes from Germany, not New Zealand? (yep, I’m a Kiwi) 🙂
      It’s definitely targeted at 80’s hardware enthusiasts / hackers. So it will likely only ever achieve a small following.
      I’d be tempted to play with this retro LSI & discrete TTL based MC68008 design, as my late 70’s self-built designs were all Motorola MC6800, then MC6809 based.
      Although originally a Motorola fan, I never did build a 68K system. I did draw up a plan to build one way back then (as my 6809 follow-up), but the parts needed were out of my price range back then!
      However, this Kiwi design has a couple of negatives that would rule it for me:
      1. Expensive! Euro 333 for just a short-form kit. By the time you add the remaining necessary parts you’re looking upwards of Euro 400 / US$500.
      2. I never did like the MSX Yamaha V99xx VDP (or their predecessor Texas Instruments TMS9918). Perhaps just me, but the images they generated always seemed to be noisy looking, with murky colors. Or perhaps that just affected us in the PAL world?

      Reply
      • Jollyroger

        I very much agree with you about the price, it is very steep indeed.
        Having said that, I am an old C64 and Amiga enthusiast (and ex-games developer), and I have a huge soft spot for machines of the 80s.
        The Yamaha V9990 is supposed to have solved many of the problems and limitations that were present in the previous MSX VDPs, having said that its DAC has never been a strong point. I come from a PAL Country too and was never impressed with the MSX colors…
        Having never seen the Kiwi in person, I am just intrigued by it and thought it was worth mentioning 🙂

Leave a Reply

Your email address will not be published.