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!
Please let’s do this, with an open standard and free schematics so evertbody can build it!
You stole my dream!!
No, no. The two of you *share* a dream!
I have a Dream….))
You are dreaming of the commodore 65
I hope this indeed comes to life somewhere and I think it is…
Commodore 64.1
The Commodore 74.
*Runs ARM with 6502 emulation
*Supports HDMI (AV/VGA with multi-out)
*128kb Static RAM
*Supports SD, USB, and original cartridges
*User port included
*USB power
*16GB flash memory
*Commodore BASIC, Applesoft BASIC, or C74AL (Commodore 74 Assembly Language)
*Portable version planned
*Retail Price: $40-100 (US Dollars)
Coming Soon
(This is a planned concept. It may or may not be available.)
Since the Commodore 64 was named after how much RAM it had, shouldn’t it be called the Commodore 256?
Commodore 64 Fixed
C64 Mini?
https://www.androidcentral.com/c64-mini-review
an Open Expansion bus Standard, proper IO and Address Decoding, maybe even differentiation between Expansion Slots (always a good thing as it allows people to use multiple of the same Epxansion card/Device, or different Cards/Devices with the same Address range without any kind of Address clashing.)
i think i would be interesting to make some kind of backplane board with some slots for cards that have the usual components on it that you need for a computer. it would be awesome to make that kind of a backplane compatible with different computers.
so that it is possible to implement a VIC-20, a C-64, an Atari 2600 etc.
so one card with the cpu on it. one card with the memory, one with the video chip, one with the audio chip, one with the I/Os for keyboard, joystick, datasette, floppy drive, sd-card, etc.
putting the voltage supply on that motherboard (or back plane), putting some connectors on it, maybe a DAC for the audio. a video part with some analog electronic that makes PAL/NTSC from RBG etc. having a common pin part on the slots like address but, data bus etc. and having individual parts depending on the slot like pins for rgb or s-video and hdmi for the video card. analog stereo out and in for the audio slot and I2S for an external DAC or S/P-DIF etc. and some pins for the IO-board.
I have a question: You say Video resolution between 320*200 and 640*480. Now, this is only half of the information needed. I want to know which colors you will be using, whether it should really be 8 bits per color or rather just 2. That makes a HUGE difference for the architecture needed for your display.
More precise, you could use some dual-port ram and write to that from the cpu while reading for vga-output. Ben Eater on youtube recently uploaded a video of is homemade vga-video card (https://www.youtube.com/watch?v=uqY3FMuMuRo), and i think you should be able to replace the eeprom with some dual-port ram and speed up the clock for higher resolution. Then you would at least have a functioning graphics module WITHOUT microprocessor and modern parts.
You could use chips like this one as vram: https://www.idt.com/document/dst/7026-data-sheet. but i dont know whether you want smd in your computer. another downside would be the need for a very LARGE video system as Ben Eaters setup is not really small.
I hope I could help 8 bit
Best regards Grimmauld
Challenge accepted…
Great to hear, Matt. When will you ship it? 🙂
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
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.
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????
The interface for PS2 is way easier to meet. Building USB-able devices is damn hard, and believe me, I tried already when I wanted to build a device that could achieve privacy against Keytrack-mechanisms. Therefore, I would also recomend using SD-cards with SPI for data transfer and not USB flash drives. USB is HARD!!!
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.
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.
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?
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.
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…
(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
“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.
I recently found this. Could it be useful?
CRT controller chip
http://bitsavers.trailing-edge.com/components/motorola/_dataSheets/6845.pdf
The C-One! https://en.wikipedia.org/wiki/C-One
Unfortunately I don’t think they’re available nowadays.
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.
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.
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.
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.
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.
@Daniel, you should really do some research instead of relying on hear-say or some comments you have read about what other uninformed people have said about FPGAs.
FPGA’s are not that expensive for this kind of design. For $20 you can get a Xilinx Spartan-6 LX9 (or Spartan-7 with similar gate density) which has enough gates to do an entire classic 80’s coin-op system (for example something like the William’s boards that run Joust, Robotron 2084, etc.), including VGA and HDMI output. You could even go down to the LX4 if you don’t need multiple CPU’s and just do VGA. You can certainly spend $1000 on a single FPGA, but you can also spend $10, and those lower-end FPGAs have plenty of punch.
Sure, the main FPGA manufactures (Xilinx, Altera, and Lattice) have closed-source tools, but they all make them available for free for the lower-end FPGAs, which is perfect since those are the ones we can afford anyway. And as for being at the mercy of the manufacturer for the life of your project, I trust a manufacturer more than and open source project. A manufacturer has a responsibility to other companies using their FPGAs in products, so they are not going to just drop support on a whim or because they are tired of it.
You don’t need to be in a university, lab, or commercial environment to work with FPGAs, they are very accessible to hobbyists.
I have been making hobbyist projects with FPGAs since 2011 and they are very fun, easy to work with, and allow you to do things in the retro-computer space that you would not otherwise be able to do.
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! 🙂
Looks great.. pity it does only composite video.
Panu also has THIS: http://www.vlsi.fi/en/products/vs23s040.html on his site. vs23s040 also supports RGB out, which can be paired with another chip for component video, vga, s-video, SCART, DVI, or even HDMI
I’m currently working on an idea (though it’s modified from this post to fit with the parts I can find and what my brain decided to be a good idea), and I’m going with a 16-bit PIC micro-controller for the video chip. It has 512 kilobytes of program ROM that I can use for the graphics routines and the color palette, and then it has 48 kilobytes of data RAM that can be used for the character set and the color cells (yes, I’m using the color cells. deal with it). Sound good?
David, check out these cool concept computers:
http://androidarts.com/Amiga/SBC.htm
Sounds like a great system to me. I’d buy one.
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.
ZIP = Z80 munged by my tablet…
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. 🙂
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.
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_.
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.
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.
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 😀
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.)?
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.
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.
But can it run Crisis?
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.
yep I was thinking the same thing. apart from the custom video chip, he has described the C128 almost exactly.
The C128 does not fit the requirement of being made with 100% off-the-shelf components that are available today.
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?
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.
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.
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.
You should take a look at the Maximite line of computers, I think they would meet all your requirements except that thy run on a Pic32 cpu.
Details here
http://geoffg.net/maximite.html
rgdss.,
I guess you didn’t see the whole episode I did on the Maximite? I think it comes very close to what I’m looking for, but has a few shortcomings!
perhaps an advanced version might be worth a look?
https://www.olimex.com/Products/Duino/Duinomite/
also, these guys should be able to design and produce what you need, open source and hardware, if only motivated properly.
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
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.
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!
Check out the mega65
http://mega65.org/
Seems like a neat little beast. Perhaps a bit too powerful, but still interesting.
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?
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.
Have y’all seen this one? https://rc2014.co.uk/
Lots of add-on boards for it too https://www.tindie.com/search/?q=RC2014
Challenge Accepted…
Call it the 8BG Kitty.
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.
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.
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
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.
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.
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.
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)
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 🙂 )
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.
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.
@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.
Have you talked with Ben Heck@Youtube about doing a collaboration video on this? This is your guy!
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.
So you never heared of RC2014? https://rc2014.co.uk
Yes.. but it runs on Z80.
Interestingly, it seems there is a 6502 CPU board available for the RC2014.
https://www.tindie.com/products/ancientcomputing/6502-cpu-board-for-rc2014
Not that I think this would necessarily be a good way to go. 🙂
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.
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
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.
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!
So then why have the 6502 in the first place? 😉
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. 🙂
“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. 😉
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.
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.
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). 🙂
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.
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.
Isnt there a company making a Commodore 65 clone?
the C=one would have been close to what you want. Got one, and loving it…
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)
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.
There is, it’s called a “PC”… 😉
Haven’t you just spec’ed the BBC computer of the 80’s?
https://en.wikipedia.org/wiki/BBC_Micro
A big requirement for any “Dream Hobby Computer” for me is a robust and easy to use expansion interface of some kind.
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.
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…
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).
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.
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.
I agree that the FPGA is the solution.
The solution for all our dream computers is to have a board based on an FPGA with the same philosophy of the raspberry pi. Once you acquire this board:
Step 1 is to program the VHDL code. For example:
a) a modern Commodore 64 with the 6502 processor, but with SD card reader, USB, HDMI video, etc.
b) David´s dream computer as he specified.
c) the successor of the Commodore 64 (which is my dream). A Commodore 64 like computer that is ready immediately after i energize it, but with a command that allows you to start a different OS from the C64 environment.
In an open source philosophy, different computers could be available to download.
Step 2: such as you do in most microprocessors based computers, you will need to install an OS such as a Linux distribution.This is valid if you programmed in VHDL a more powerful microprocessor.
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.
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.
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.
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
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.
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
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… 😀
Happy I read the replies before posting 😉 I ended up thinking the Arduino simulator was a good place to look.
Then thought, hey, all cpu-rom-eprom-ram-gpu specs… “copy” a vic board… then I thought in-out… VM-emulator(ish). The VM is already 100% interfaced with a modern PC so in-out is solved (screen, keyboard, mouse…) plus it has compatibility mode (if it’s even useful in this case). You can create ISO images of pretty much anything so mount and plug in VM. Then the machine. At first I thought emulator but this is no sport since it’s just to take a rom and output an interfaced result (usually a game) to to the screen, meeeh. Than I thought LabView but at 7kUSD/year… Arduino and the such on the other hand. To be able to run a fully customizable board simulation of whatever board config and output it like an emulator in a VM… Also, VMs already have compatibility modes… If I was better at all these things o.o It’s all I can see, because of obsolesence of parts and long term unreliability of old boards… To have fun and learn, a very “real” simulation could be cheaper than cheap and very satisfying. The PICSimLab is also quite nice but the goal isn’t the same; still it runs LED screens.
What would it take to get a couple of arduinos to simulate a VIC20 or C64?
Could each specialist chip on the boards be simulated by an arduino, either an Atmel or one of the faster variants? Starting to think that this would be an interesting project to do. Even if it takes more than one to do it, memory mapped functions would be the hardest to do, either dual port ram or a processor chip fast enough to respond like it was memory on an interrupt. Could that be done?
Needs a very fast interrupt, read the address, get the value from it’s own memory and place it on a port. The same for I/O access.
Could this be done or is it just too quick?
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!
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.
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).
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!
Absolutely agree with ya!! I think instead of wasting countless hours to develop a brand new 8-bit computer from scratch, just go with the new C64-Mini, it’s ready built unit, has a distribution channel, it runs pretty much all the “old classics”, and all we need now is just to develop new software for it. The most important thing in any product development is to be ubiquitous, accepted by the masses, and not some new custom gadget of which nobody has heard about or knows how to use, etc.
Sure a niche product “will work”, but will never be popular with the masses.
Just my 2 cents. 🙂
The C64 mini is just an emulator, and it has terrible lag-time. It’s actually worse than the real hardware. And it totally lacks anything that would make it interesting to program for.
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?
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.
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.
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. ]
You should look at http://mega65.org/ it seems to meet your specs.
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
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 🙂
Hi there!
Well I saw you are kinda not looking for a C128, but maybe is something…
https://www.forum64.de/index.php?thread/81460-the128rm-the-128-remastered/
Cheers,
Peter
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)
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?
Hey. 🙂 I got inspired by this article and the discussion, and wrote a rather lengthy followup and thought excursion on my Medium channel. I hope it doesn’t count as spamming if I invite everyone to read.
https://medium.com/@daniel.jozsef/rebuilding-the-80s-55102cb89643
Dave, if you find it useful or worthwhile, I’d be flattered if you added a link.
Daniel
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. 🙂
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?
Could we design the board so it is broken up so hardware must exist for each base sections. All of the complex bits for a section could go into a FPGA but state that the internal FPGA design must be available to everyone, and at least one or maybe two other chips (not the same series) available that can do the job (someone has taken the design and ported it to another FPGA and got it to work). I feel people don’t want to be stuck and unable to make them if parts become unavailable.
Complex things like graphics and sprites are hard to do in straight logic, but maybe the rules about how it works, it’s interface and internal registers could be set. I could see some people using really fast embedded processors running code to simulate the chips as well. Does it matter how, as long as existing code runs on the machine without mods, patches or different driver files.
I could imagine a board as follows:
Processor – Select one 6502, 6809, Z80 whatever.
Memory – Amount needed no-paged and minimum amount paged.
Sound – Channels, buffered, non-buffered, resolution, DMA or not.
Video – Composite and HDMI. If you select less than HDMI, not all of those other interfaces are going away.
Serial – Make keyboard and mouse interfaces ansi serial, allow for 4 or more ansi serial ports, 3 or more I2C ports, 3 or more SPI ports. Set maximum baud rates to reasonable values. Allow for interrupt responses from the ports.
Parallel – Allow for a simulated 8 bit bus with a minimum 256 byte latched address scheme.
Status leds – Put a row of them on the board (make a bit of a WOPR look), memory mapped to the processor or a register that is clocked out and latched automatically at set intervals. The clocking should allow for ganging more leds onto the end of it.
On-Board IDE and code interporater with software code debug pause and investigation.
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).
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. 🙂
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.
MicroPython is actually a thing, it’s an implementation of Python for MCUs. 😉 http://www.micropython.org
Anyway… If you have BASIC on a modern system, I guess you can also use it to do stuff like that. In fact, that’s how the .NET ecosystem started, with Visual BASIC, which started out as a lot cuter and less serious than what it grew up to be. 🙂
Personally, I think kids should start coding before they start sending e-mails. I’d be wary to give a six-year-old a tablet or an Internet-connected computer. Those have software designed specifically to fuck humans up, playing on psychological exploits. I’d want them to start on a platform that has no Facebook, Google, Musically, or modern games with microtransactions. 😀
Quote: “I’d want them to start on a platform that has no Facebook, Google, Musically, or modern games with microtransactions.”
Ahh.. Yes! Back in the days when doing productive things on our computer was the actual uninterrupted focus of our attention!
For most people nowadays, a computer is now just their centre of distraction!
Sitting down at your computer to do some coding (or anything else productive), nowadays involves avoiding a constant flow of “focus breaking” distractions!
eg. Like responding to online discussion comments. LOL
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.
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
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
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.
This sounds pretty interesting, is there any progress in the meantime?
Very nice !! I think the specs are in the sweet spot. Maybe the audio is a bit too much tho (16 PCM channels is a lot for 320×240 graphics, and falls more in the 32bit era).
I would be nice if people manage to agree, so they join your project (or another one) instead of reinventing the wheel and not agreeing all time, ending with nothing…
How about the Kiwi?
https://www.ist-schlau.de/hardware.html
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?
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 🙂
Hi Greg,
Rog the Fellow Kiwi here… a bit irritated with people naming foreign items after our National Bird… it started with the shoe polish, IIRC :-/
Where are you based? I’m in Welly – Lower Hutt… occasionally venture to AKL though.
I have a 68008 which is possibly the most expensive ($NZ138 from VSI WLG in ~1983) LED flasher in the world so far :-/
Well actually I have (IIRC) had it bit-bashing serial (to 9600 baud?) with my own scratch-written monitor.
Perhaps we could get in touch F2F over a beverage or 3?
🙂
Cheers
Roger B
Greetings Roger, fellow Kiwi! I’m Auckland based, but spent my early years in Upper Hutt.
I’d have been shopping for Motorola parts at VSI in Auckland in the 80’s. Memories also of MC68HC11 and MC68HC705 MCU’s.
I vividly remember this was back when one LSI chip could cost several weeks pay! NZ$138 was about 3 weeks pay for me (in total!) back then.
I recall traveling to Professional Electronics to buy a Nat Semi Digitalker chipset costing around 2.5 weeks pay (which I still have somewhere).
Perhaps these memories contribute to our retro fascination, when we should probably be focusing our spare time on being more productive (and relevant) working with modern systems & micro-controllers!
But, I still find myself often tempted to buy an old Amiga 500, just so I can actually explore that awesome 64 pin DIP MC68000 that I never could afford way back then! LOL
Good luck finding your dream. I embarked on a similar project a couple of years ago building a replacement Tangerine Microtan 65 from scratch using readily available components and new PCBs, details here:
http://www.microtan.ukpc.net/pageMicrotan-R.html
It doesn’t quite meet your spec but the beauty is it can be built in stages and tailored to meet the users need (just like the original).
8-bit guy,
I bought an FPGA development kit specifically for the purpose of picking up this gauntlet. (Yeah, I’m nerdy like that, but also a firmware/embedded engineer.) After doing a little research, there are already several platforms that may be better fits than some guy, or a small team of people doing a new design from scratch. The Mega65, and MIST FPGA computers are notable examples. I realize there is a hesitance towards using an all-in-one device like this to implement a retro machine, but let me argue the case.
Immortality
The first (and greatest) advantage is immortality. Once your machine is described in VHDL it can be instantiated on any programmable logic device for all eternity. The machine will never go obsolete. A particular part may, you might not be able to buy a Spartan-6 in 20 years, but you’ll be able to buy a Spartan-26 (or whatever is out then.)
Performance
I spent some time looking for some high speed 65C816s, but it looks like the best available are in the 14MHz variety. While that’s fantastic in comparison to the humble ~1MHz 6510 in the C64, lets be honest… Why settle for less in a dream machine? A design based around FPGAs could do 50 maybe 100MHz.
Customization
Ever wish your C64 had four joystick ports? Two USARTs? Stereo sound? More RAM? A different color palette? Trivial changes using FPGAs.
Off-the-shelf-ish-ness
I’m not entirely clear what the “limits” of “off the shelf” are. An FPGA is an off-the-shelf-part. I can go to Digi-key and order them and have them in my hands tomorrow if need be. I assume that the only REAL limit would be that a custom ASIC wouldn’t be used, but this thing would never have the volume to rationalize using an ASIC. In your description, you said the graphics would probably be FPGA, well if you have one FPGA, might as well do it all in FPGA.
I will still probably mock up a prototype 8-bit machine, if for nothing else just the experience of it (and to pad my résumé). If enough people were serious about being involved (and by serious, I mean have relevant skills) it could become a semi-public project. I’ll stick around and see if anyone steps up.
Actually, the customization part is exactly what I want to get away from. In order for the system to be a standard design, it needs to have a design set it stone, much like a C64 does now. With an FPGA, people will be constantly wanting to add this or that feature to it, until the point it no longer resembles the original machine.
Such is the problem with an open source/open architecture, people will branch new designs off the main line. (edit : I went back and looked, and “open” was not your requirement.)
I think my idea was more like the architecture could be extended in the same way that a cartridge, or a modem in the user port is just an extension of the base system. As long as it complies with the operating system, any addition just becomes a peripheral. We all know there were plenty of hardware modifications made to the C64, such as RAM expanders, and CPU speed boosters, even operating system extensions like Fast Load cartridges and Simon’s BASIC (which may not be good examples.) They didn’t break the C64 because development would always target the fattest part of the bell curve, so to speak, and people with customized hardware generally (albeit begrudgingly) accept that they will have less than 100% compatibility with such modifications.
It seems like a fun project, and I’d love to take it on. I get the sneaking suspicion that it might end up being only me and/or a couple other people interested in it enough to actually do some development on it.
It would be cool to see your game ported to it.
I still feel like MIST or Mega 65 are almost exactly what you’re looking for. Although, just about every Mega 65 video starts with them doing a “GO64” instead of running the machine in native mode. :-/ You probably don’t need suggestions from the peanut gallery, but I’d love to see your take on both machines in a video.
I’ve been following the Mega65 project with great interest. And indeed I do think it fits many of the requirements I have. But I have a feeling it will never come to market, and if it does it will be pretty expensive. Plus, like I said, it depends greatly on FPGA. Now, if we could get a custom low-cost ASIC produced in high enough quantities, then a project like this could certainly become far more interesting as it would open up the market to quite a few more people. And that’s the issue. in order to make it a success you need a lot of people coding for it.
“Actually, the customization part is exactly what I want to get away from. In order for the system to be a standard design, it needs to have a design set it stone, much like a C64 does now.”
In so far as avoiding the proliferation of forks is a factor in the desire for real hardware, an alternative way of addressing this might be to set up an on-line portal for developing and sharing programs that adhere to a particular standard. Scratch has been quite successful in this regard.
It seems to me that Geoff’s Micromite (one off) could meet your expectations 🙂
http://geoffg.net/Explore100.html
At least, I would like to see your review of Micromite series
I’ve already reviewed the Maximite, which is far closer to what I desire than the Micromite.
You have mostly described what has been bouncing around in my head for 5-6 years as my ‘MSX Model 6502’ which was basically taking the MSX standard and rebuilding it around a 6502 with an option to upgrade to the 65816.
A recent different 6502 project has my obsessed me for about a week (S360/6502 based on the fact that the S360/30 used an 8-bit processor microprogrammed to provide the S360 architecture) but the MSX idea is more realisitic.
As people have stated previously, off-the-shelf 6502 and 65816s aren’t very fast. And one of your requirements was that your dream computer had to run BASIC fast enough for it to be useful. I’m just guessing here, but I’d say this would require at least a 25-MHz CPU. Those speeds are much easier to get on more modern microcontrollers. So I was thinking, instead of using a 6502-compatible processor, what if I used a modern ARM processor, and wrote a program to transpile the 6502 machine code into RISC? Would that be acceptable? (I could probably even get the transpiler to recompile Commodore 64 programs – graphics, sound, and all – for my system!)
I believe we could do a 14 Mhz 6502. However, it would be easier to implement an 8 Mhz 6502. That would literally speed up BASIC by 8 times. I think that would be fast enough to write a lot of games. Obviously not everything, but certainly a lot of things.
Here’s my problem with that. Every computer system made by a company seems to go through a “if it were faster, it’d be better” and this tends to leave the originators and followers behind. People don’t want to have to buy or upgrade constantly to keep up. I hate the fact that a 3 or 5 year old iPad won’t load current stuff. Questions like “which version of Pi have I got” irks me greatly. Always there’s a better one around the corner with more memory and speed, and if you don’t have it, then you cannot participate in the community.
I’t be way better to have an expandable system based around a set standard processor where the software and peripherals just got better and better. An 8 year old version being just as good as a current one to learn on, play on and use.
It’s why this group is discussing 6502’s. It’s a very old processor, but 6502s were nice to program on and simple enough to understand. No they don’t have USB and 4 gig of ram or HDMI outputs, but is this a concern? Do you want to chase the PC market forever? Can I add an interface for USB, some serial ram or a HDMI interface when required?
“But it’s not fast enough to draw X, Y or Z type of graphics”. Well, maybe you should look at having more than one to distribute the load, or get the community to design a better interface that accepts higher level commands. That is, add or improve the peripherals or software. That’s the fun part of using it.
I didn’t like the Pi when it came out, not because of the price or the performance. I didn’t like it because I asked what was in it and the response was “$XXX and you can have the internals manual as well as us. Trust us, just load up XYZ linux and you’ll be fine”. Say what? I’d like to tinker with it and you don’t want me to see the low level bits. No thanks, I’ll learn some Arduino. Even when I relented and got one to try, the code was buggy, the audio noisey and the power connector, wonky. Things I could do little about.
Reading the comments here, people are looking for a simple, reliable base to learn and play on, don’t fall into the upgrade needed trap.
Someone made an FPGA Amiga 2000 graphics card. It’s open-source, too!
https://github.com/mntmn/amiga2000-gfxcard
And the 65c816 is still available for sale for the over-the-top price of $9 USD.
I have started looking into this and so far this is what I have:
The design is implemented on a Terasic DE1 FPGA development board.
Processor: 65186 soft core running at 8MHz-ish. The “ish” allows for hidden SDRAM refresh cycles so the processor is running at about 7.8MHz. If the SDRAM can handle a slightly higher frequency clock, I can get an honest 8MHz out of the beast.
Main memory: 512K static RAM so far. I have implemented an SDRAM controller but have not checked it out yet since I want to concentrate on other things. There will be 8MB of RAM when the SDRAM controller is working a which time I plan to rework the video to use the SRAM for that purpose.
Flash: 4MB
PS2 keyboard
Video: 640X400. Font (4kB), palette (512 byte) and 16kB of video memory are in FPGA block RAM configured for true dual port mode with the VGA and the processor having simultaneous access. The video currently runs in a standard text mode with an attribute byte for each character cell, (2 colors per cell), 512 characters in the font.
A second mode (“tile” mode) reduces the the resolution to 320X400, four colors per character cell. The tiles use the font ram for their bit maps, but with 512 characters available I don’t think it is too much of a limitation. The “tile mode” has its own palette. The mode is selected on a character cell basis.
Future video:
I plan to have a 320X200 four color bit map mode.
I will be including sprites, but have not starting work on that. I figure 16 8X8 sprites would be useful. I like the horizontal and vertical expansion on the 64 and will include that.
I am not sure what to use for sound and would like some ideas on that.
Still early days, but at least I have something on the tube now.
It has nothing to do with commodore, but Nedo-PC did something like this fo the zx-spectrum/pentagon. They did it right too. There is a real z80 and yamaha chip on the board. They have 4mb of ram, which is way more than enough. Someone could port SymbOS to it. All of the logic chip are replaced by fpga. The z80 is a newer packaging of the cpu, so it is faster (up to 14Mhz no wait state). They are making a wifi module for it right now. I would only suggest making the rom some kind of fixed uboot loader. That way no one has to flash it ever, and the rest of your sdcard could be your drive space. And surely include hdmi support. That way everyone can enjoy it.
It’s not commodore basic, but there is a basic enviornment for the RPI.
https://ichigojam.github.io/RPi/
Screenshot : https://ichigojam.github.io/RPi/image/basic1.jpg
While I don’t have a dream retro computer kit myself as I am not that tech-savvy, one thing I always wanted to do was built one of the early systems using off the shelf parts. However, it turns out most systems have some form of proprietary hardware. Even the Atari 2600 had proprietary chips. That said I have found two projects that I would like to try, I just have to work up the courage and funds.
The first is a CP/M machine. There are a few kits and schematics out there. Grant Searle has a 9 chip design that can run CP/M 2.2 and there is the RC2014 with upgrades to run CP/M, which can be costly, and the Zeta SBC Mk2 which when you figure in the ParPorProp board to allow for composite video and a keyboard, can be equally pricy but you have to source your own chips. My stepfather worked for Xerox, which means we had a 820 (I suspect Xerox gave employees serious incentives to take their unsold stock home). I don’t recall using it all that much, but I am sort of nostalgic for it.
The second project is the Superflo Harlequin Rev g. This is another kit that can be purchased, but the board is a ZX Spectrum compatable. The Speccy had a proprietary chip in the ULA (Uncommited Logic Array. Ben Heck says it was similar to an FPGA) But the ULA has been reverse engineered and the Harlequin replaces it with logic chips. It’s supposed to be mostly hardware compatible with both software and peripherals, but I haven’t been able to find much on this claim.
Both of these projects would set me back about $200 or so, with additional costs (like 3D printing a case) and time involvement figuring out how to put the bloody thing together.
I am also not sure which I would get the most use out of. the Speccy has more games which I could play but I have an emulator on my computer if I want to experience that. CP/M is more a business OS. One thing I wanted to do was make a portable computer and then use it to write a book, just for the novelty of doing that. I’m sure the Speccy has a word processor, but I think the CP/M would be a better choice. (A Raspberry Pi portable would be an even better choice, but that’s outside of our scope here)
I’m not sure which I’d rather have. The Harlequin would be easiest if I buy the full kit as it comes with instructions and such. But I feel more nostalgia for CP/M as I’m not British. I’ll likely build both at some point and then they’ll sit in a box with my Pi’s and Uzebox.
Would it be possible to build a base machine with an FPGA such that it could boot into a type of BIOS, and offer a choice of computers, such as 64, vic, trs, etc., and a default choice with a timeout, then program the FPGA with the correct circuit to perfectly emulate any of the machines offered? Menus on each machine could offer the possibility of altering RAM and clock speed (like 16MB/100Mhz).
This way, a custom computer (think of it as a ROM) could be refined and rebuilt over and over until perfect (the “8BG computer” in honour of David), and not limited by any one particular set of chips, yet all of the popular machines could be hardware emulated, including peripherals.
A dedicated video driver circuit with VGA, composite, HDMI, DP would complete the board, along with a USB keyboard decoder of sorts. What I mean by that is, it would allow any modern keyboard to be plugged in (wireless too!) and the keys could be redefined by the version of computer it’s running. For example, if I chose a C64, I could add a sticker kit to a PC keyboard and mimic the Commodore keys. The stickers would include all the characters the C64 uses, but some keys may be in different locations.
I’m thinking minimal cost, with maximal usage cases. Emulation at hardware level and virtual expansion by updating programming for FPGA.
The keyboard decoder could also handle some custom software interface that would allow a modern laser printer to be connected, yet have the computer think it’s any one of many ancient versions, and a general purpose “user port” that would allow custom hardware to be attached in the future.
Would it be possible to build a base machine such that it could **boot into a type of BIOS, and offer a choice of computers**, such as 64, vic, trs, Amiga etc., and a default choice with a timeout, then program the FPGA with the correct circuit to perfectly emulate any of the machines offered? Menus on each machine could offer the possibility of altering RAM and clock speed (like 16MB/100Mhz).
I know David wants a computer that is somewhat unalterable to encourage a community to develop for it, but I think this version would offer the best of both worlds: you could use a circuit image (whatever the language is called for FPGAs) that is the hardware-exact stock machine(s) and that is what people play with for new games etc., as well as develop the new machine (the “8BG computer” in honour of David). Eventually this new machine could be ported to an actual ASIC; something that could encompass an entire system on a chip and be really cheap, even including the ROMs and memory, but that would be part-2 of the project.
A dedicated video driver circuit with VGA, composite, HDMI, DP would complete the part-1 board, along with a USB keyboard decoder of sorts. What I mean by that is, it would allow any modern keyboard to be plugged in (wireless too!) and the keys could be redefined by the version of computer it’s running. For example, if I chose a C64, I could add a sticker kit to a PC keyboard and mimic the Commodore keys. The stickers would include all the characters the C64 uses, but some keys may be in different locations. Part-2 would include new key caps.
I’m thinking minimal cost, with maximal usage cases. Emulation at hardware level and virtual expansion by updating programming for FPGA.
The keyboard decoder could also handle some custom software interface that would allow a modern laser printer to be connected, yet have the computer think it’s any one of many ancient versions, and a general purpose “user port” that would allow custom hardware to be attached in the future.
I think, most ppl here are too young to understand that Dream.
No Emulation, No FPGA. Only true real hardware, at best in TTL.
Maybe for the SD Interface there is a microcotroller usefull, or TTL too.
Hey!! Maby you could use a reverse emulator https://m.youtube.com/watch?v=ar9WRwCiSr0&t=397s
I think that you are really going to like this one:
https://basicengine.org/
In any case, I would love to see you do a build and review video for the Basic Engine.
I’ve seen this.. and it’s kind of cool, but not exactly what I’m looking for.
Haha, it even handles PETSCII!
Well, it’s clearly not your dream computer, but it’s interesting. I’d love to hear from someone about just how difficult that SMD soldering is. The site talks about how easy it is if you have a heat gun – but I don’t, and I’m not sure I want to buy a $90 tool to build an $11 kit. (Yes I know I could then use the heat gun for other projects and I should probably buy one eventually.) I’d love to hear more about the pin headers, too. Would the user have direct access to them like the user port on a C64?
I guess what I’m saying is, I agree that it’d make a fun topic for an 8-Bity Guy video. But I don’t want to pressure you into covering something you’re not otherwise interested in.
Could you review it and tell us what it does right and wrong compared to your ideal? It sounds like a very cool item, especially for learning by way of retrocomputing.
Hi David,
some time ago I found a project made with all TTL logic, it’s called Vulkan-74
This video https://www.youtube.com/watch?v=chACO3WNtg0 shows a 400×300 pixels screen with 256 colors at 60Hz (with sprites!! :O )
I think this could be more than suitable for your dream computer. The negative part is the large chip amount… but it could be shrinked if using an FPGA or ASIC
On the same youtube channel there are also other videos with some microcontrollers used as vga video generator. They are impressive..
Here are some of them:
https://www.youtube.com/watch?v=HQs7GKT593w
https://www.youtube.com/watch?v=UnQIppe2ip0
Thanks for posting my project!
Here is the latest on Vulcan-74…
https://www.atomiczombie.com/vulcan-74/
Radical Brad
This isnt an area I’m really familiar with…at all; however, looking at sbc’s, I keep encountering sites that will let you design a pcb entirely from scratch to your spec with a large library of components, have a fixed quantity built (usually starts at qty. 5-10 min.), and shipped to you. Albeit, most components I’ve messed around with are much more substantial than 8-bit, but again, not normally my thing & the libraries are fairly large. I’ll look for an example site, but am I way off the mark here? Are these components just not readily available enough to make it worth a company’s while…?
I love the concept but I definitely want HDMI. I don’t want to rely on dead or dying technologies for the video out, nor do I want adapters.
I might use a mos CPU on
my dream computer because my
commadorre 64 is missing its power supply and its floppy drive is gone ?
For video, I has this idea based on the MC6845 and some dual-port SRAM: replace the character ROM of the 6845 with a dual-port SRAM chip, so it becomes much more flexible while still being compatible with the standard graphics hardware.
One idea I am building is a CGA-compatible graphics card with both character SRAM and a flexible output mapper, mapping two neighboring 16-color CGA pixels into two RGB888 pixels, allowing for displaying using HDMI or DisplayPort links. That card is called Flexible Graphics Array.
I’ve been working on a computer much like this, which I call the Kestrel-3, but with very different specifications. I call it the Kestrel-3 (since it’s my 3rd major homebrew computer design). By way of analogy, I like to think of my long-term vision for the computer as a “neo-retro” computer, with something like an Atari ST 1040ST hardware foundation, and a Commodore-like user experience. Briefly and quickly:
* 64-bit RISC-V homebrew processor (RV64I or RV64IM instruction set only, so NOT able to run Linux),
* 1MB of RAM (since that’s what comes on the icoBoard Gamma)
* 1MB of ROM (the vast majority of which will go unused, but again, that’s what’s on the FPGA board)
* PS/2 keyboard and mouse
* Boots into Forth.
* VGA display with 640×480 resolution
* Completely open source — built with Yosys open-source toolchain, schematics for FPGA board wide open, FPGA chips cost $5 in quantity.
* Intelligent secondary storage — my Kestrel-2DX used to have built-in SD card, never again. What a pain in the @$$ that protocol and hardware is.
It’s still under development, but I have a “headless” emulator built (meaning, CPU, RAM, and ROM with serial interfaces to a separate terminal; no graphics or audio). This is just enough to confirm that I have working (even if incomplete) system software working. I just ported by homebrew Forth environment to it. I still have to publish the code online though, but work and family obligations have interfered with that. Looking to publish it in the next week or so.
I chose Forth because it’s a powerful programming language, and very easy to get running compared to any alternatives. There’s no fundamental reason why it couldn’t run BASIC though if someone took the time and effort to port a version to it.
Like I said, this is still in development, and I’m the sole developer at the moment, so it’s taking some time. But just wanted to get the word out. If interested, you can check out the following sites:
* https://kestrelcomputer.github.io/kestrel — original motivations; this is an old site no longer maintained, but it gives good background, I think.
* https://chiselapp.user/kc5tja/repository/kestrel-3/index — current development repository, and has the latest technical specs and development plans. I’ll be publishing my headless emulator here when I get the two seconds to just do it.
* https://hackaday.io/project/10035-kestrel-computer-project — My Hackaday.io project page for it, which I frequently forget I have at all. Heh.
Here’s my dream computer 🙂
http://mega65.org/
A 1986 vintage 128k Acorn BBC Master computer upgraded with a modernish 16MHz 65C102 co-processor and SD flash storage could fit the bill. It runs BBC BASIC, arguably the best 8-bit BASIC written, and can be fitted with the ‘BeebSID’ sound chip.
Alternatively, a RaspberryPi running the RISCOS operating system is programmable in BBC BASIC which has a built in ARM Assembler. The heritage of ARM goes back to the 6502 based Acorn machines, RISCOS can also give you a BBC Micro style command prompt.
https://en.wikipedia.org/wiki/BBC_Master
https://www.riscosopen.org/content/sales/risc-os-pihttp://zeridajh.org/hardware/gosdc/index.htm
http://zeridajh.org/hardware/reco6502mini/index.htm
https://www.retro-kit.co.uk/page.cfm/content/BeebSID/
Links that work !
http://zeridajh.org/hardware/gosdc/index.htm
https://www.riscosopen.org/content/sales/risc-os-pi
CPU: Espressif Systems ESP8266 – reasonably cheap and we get WiFi + SDCard.
VDU: VLSI Solution VS23S040 – four times as much memory as the VS23S040 and can output RGB using 3 of the 4 outputs. Can interface with the ESP8266 via SPI.
Sound: VLSI Solution VS1053 – AAC, MP3, WMA, MIDI, Ogg-vorbis, has some software patches that allow using as a soundcard (imediate MIDI and WAV). Can interface with the ESP8266 via SPI.
Internal HDMI Converter: Lontium Semiconductor LT8522X. Allows taking the VGA + Sound output of the previous ics and output HDMI to modern tvs.
Lattice ICE40HX FPGA programmed as PS/2 Keyboard/Mouse controller (This is a $1 dollar device). Can interface with the ESP8266 via SPI.
SDCard socket, PS/2 sockets, power supply. etc
Base software from “BASIC Engine” and you get a reasonable computer. The VS23S040 is four VS23S010 on the same IC. If you use 3 of them to generate video, you get 128kb * 3 bytes of video RAM (384KB) but the device holds 512KB, so you have spare 128KB to use in basic programs (Increasing total RAM size to ~192KB in basic – store strings, program source etc). Sound IC has aditional 96kb ram for sound samples or whatever, it depends on developing patches for the DSP to allow it to do more than the default. Maybe VLSI Solutions itself can help. That would result in a reasonable retrocomputer with a lot of power.
From calculations it can do 320×240 in 18bits color, or 720×480 in 6bits color (2 bit per color plane X 3 color planes = 64 colors). All this with HDMI output.
I researched this a lot but I dont have the resources to pull this out.
If instead you plan to use a 6502 computer, you might need something like a modernized 65spi (http://www.6502.org/users/andre/spi65b/index.html) that can sit on a 6502 bus and spit out SPI. In the case of a eZ80 based computer (That I much prefer) it has dual SPI buses internally and can handle the VS23S040 directly, but at slower speed. I never understood VS23S010/040 QSPI protocol, nor the Parallel 8Bit one. But I believe a small ICE40HX FPGA might serve as glue logic to put the video IC directly into the 6502/Z80 bus without serial lines.
What I mean is that the basic structure -> VS23S040 + VS1053 + LT8522X can generate Composite + VGA + HDMI + Sound into a 3 CHIP design, plus ICE40HX glue logic and it can sit on the bus of ANY computer.
One of my ideas was to find a way to map the 512kb RAM space of the VS23S040 directly into a 8086 memory bus (128kb with plane shifts between each of the 3 color planes + 128kb of additional RAM when not in graphics mode), with some timer software you can draw the $B800 text buffer into that memory mapped space and simulate a PC with something similar to a EGA card – All with HDMI output. Possibilities are endless.
What’s the status of your project?
It shouldn’t be that complicated to combine a W65C816 with some SRAM, ROM and other peripherals.
The MCU could run up to 14 MHz and has a total 16M address space (16 bit bus + 8 bit banking).
Even if you’d use 64KB of dual port SRAM, this could give you 8bit color on 320×200.
The only thing that seems challenging to me, it to choose the desired components (Graphics, Sound, PIA) – plugging them together should be an easy task.
Did I miss here something?
Chris, the C256 Foenix is doing just that.
The problem with the 65816 is that it has some interesting quirks.
Stefany has been educating me on things she has to do to make the CPU interface with the various devices she’s put on the motherboard (2 SIDS, Yamaha OPL 3 synthesizer, two VIAs, Flash, SRAM, and DDR memory), and she basically has had to build a custom MMU in FPGA to handle all of this. On the 64, this was called the PLA and was just a simple set of gates. On the Foenix, the MMU is doing buffering, managing wait states, and doing a lot of work to make it possible to access the different devices.
Getting stuff out to SRAM is actually the only thing she doesn’t need to manipulate in some way. Everything else is going to need wait states, buffering, or caching.
I must be missing something.
That amount of work would be needed regardless of processor choice, particularly if you’re bridging a high-speed and low-speed device.
I’m not seeing why you need an MMU though; latching the bank address byte during phi2 low should be a simple matter in a CPLD or FPGA, especially if the CPU is physically adjacent to the FPGA to minimize lead inductance and capacitance. You should be able to decode the full address space (IIRC, the SuperCPU does exactly this at 20MHz, 6MHz faster than the rated speed of the processor). The only time you’d ever need an MMU is if you are ignoring upper address bits for some reason, or if you’re expanding the physical address space beyond 16MB.
Can you go into further details as to what’s happening with the C256’s FPGA logic and why you’re running into difficulty?
I actually don’t want to go into the technical details too much further, because it’s not my story to tell. I’m just working on some of the software.
In a nutshell – yes, you’re right. You’d need to do that work on any CPU of that era. However, modern CPUs are loading more functionality into the CPU package, and microcontrollers are even better for that, since the entire CPU and memory are all self-contained.
Look at something like the Arduino hardware, especially the Mega and Due. The ARM Cortex M3 has all the I/O built into the CPU package, and you can talk to I/O devices without needing a gatekeeper (like the PLA, MMU, or whatever you want to call the logic chip that does that job.)
Instead of building in buffering and wait state logic into an FGPA, I could interface to slow hardware on an M3 by simply setting an address on one set of GPIO pins, then either sleep the CPU or just come back by later to check the value on the data pins. Either way, all of the work is done in the CPU, rather than needing a bunch of FPGA programming.
The 65816 is one of the requested cpus and I found the W65C816. The datasheet for that chip has the example circuit using a 573/373 (latch) and a 245 (bus driver) for the banking and data lines. So that would be no problem at all to get the full 24bit address lines.
As FPGA should be avoided, you could use some 154s (4-to-16 line decoder) to generate the chip selects for RAM, ROM, peripherals…
And for interfacing slow peripherals, is there any reason not to use the IRQ? It might even work if the CPU polls some kind of status address.
I would actually prefer using a FPGA or CPLD like EPM7128 as the central glue logic. The programming logic concentrates multiple features into one chip:
* Bus latch
* Address decoder
* Vectored Interrupt Controller
* DRAM controller (if you need it)
* etc
The DRAM controller might be the most important feature here since that opens the door of high capacity RAM for cheap. If you have fast RAM like SDRAM or DDR1, the FPGA DRAM controller can even do some caching and bus sharing allowing the graphics subsystem and the processor share the same DRAM.
Would love to build that. And maybe turn it into a modern version of one of my 2 favorite computers: The Commodore VIC-20 and Commodore 64 ( if it wasn’t for your channel, I would have never discovered the classic computers)
Here is one I designed a few years back to be a retro Atari system, but thinking of it, it could be made to use an FPGA and include Commodore goodness in it too. It could have all the best parts of Atari and Commodore computers from the 8 bit era. ahttps://www.youtube.com/watch?v=HFHLxpdGhao
I AM working in something like that, but my cpu option was a z80 because is better than 6502 and have memory autorefresh my idea is 1 EPROM 27c512, 64k of RAM, 8 tones multiv. As audio interfase, and video interface with MC1377P this Will besos the first proto. I need to make tests.
If the processor speed wasn’t too high, could an eprom simulator 28/32pin board be built with a fast processor from someone like microchip so that code loading could be done dynamically? Code could be as simple as read 2 ports, look up the value, write to a port. Have a single direction gate do the output enable.
@Saddle – What you are describing is effectively what L-Star have done with their “Software Defined 6502 Computer”. But instead of just simulating the EPROM address space, it is simulating the entered memory map so you can dynamically define the whole computer.
Instead of a Microchip MCU, they are using a nice retro 40 pin DIP Propellor multi-processor MCU.
As the Propellor has multiple independent processors, each can be dedicated to simulating different I/O peripherals. eg. Video, SID etc. with one processor dedicated to handling the 6502’s Address / Data bus interface to determine how the 6502 CPU see’s the world.
Take a look here: https://www.l-star.org
For a year or so now I’m designing a super simple Z80 based retro home computer called RhoCoCo (RetroHOmeColorComputer) that has graphics and sound capabilities resembling a C64.
It comes with a 48-key keyboard, 128K RAM, and VGA 320 x 200 64 color graphics, a speaker, and an SD-card slot for storage, BASIC, oh and it has a joystick port.
It uses a Parallax Propeller for all the I/O, video and sound.
I chose a (real) Z80, because unlike the 6502 you can still buy one cheaply, from places like Farnell, and I expect that you can still buy one in the next decade(s).
Its tiny (the “main PCB” is just 10 x 10 cm, just like my previous design, a ZX81 clone). The keyboard is larger, and uses relatively large keys. A bit like a Sinclair QL, the RhoCoCo has an internal expansion port bay.
You can follow my work on my makerspace website “revelation space”, see the provided URL.
Just so you know, you certainly can still buy the 65C02 and 65C816 CPUs. The 65C02 and 65C816 are both evolved versions of the original chip.
Both CPUs are compatible with the 6502’s documented ISA, and when you switch to 16-bit mode, the 65C816 has a whole new set of 16-bit instructions, new address modes, and the ability to access 16MB of RAM. With a 65C816, you don’t need MMUs, page swapping, or any other trick to get past 64K. You just add more memory. =)
Of course, there are good reason to pick the Z80, regardless. I prefer the Intel instruction set, and there’s certainly a wider variety of hardware and software out there.
And when I think about it, perhaps the best computer for this project is really an 80286 running DOS and booting straight to a custom BASIC interpreter.
Hi martin.
I had read through your maker space, which I think is here: https://revspace.nl/RhoCoCo_Retro_Home_COlor_COmputer
Sounds like a really awesome project, and I love how you have posted regular updates on your progress. But, is there any way to post comments / discussion feedback (on your posts)?
I see in your last update you are thinking of a second Propeller chip, to use as an emulator for the CPU.
Although this would add flexibility (I’d love a MC6809 based system), it does greatly detract from the “retro” preference of code actually running on a real 8-bit CPU chip.
What I’m saying is that although I’m fully onboard with using a Propellor for retro computer I/O peripheral simulation (transparent to the actual CPU), going on to the further step of emulating the CPU is (I believe) a step too far.
You may as well just be using an FPGA for the whole system, or just running a system emulator on a RaspberryPi etc.
In other words, I believe that having an actual original 8 bit CPU chip in the design is necessary for “Retro” appeal.
Hi Greg,
yes, that’s the page, my project page is a Wiki, so members can use the comments tab, but no for non members there is no other way, except perhaps by posting here.
I have to think about it, I could start a thread on the raspberry PI forums off topic section. I am a moderator there, but I still have to see how the other moderators react. I posted about my earlier ZX81 clone “ZX81+34” there too, but low profile.
I understand and appreciate that having a real 8-bit CPU is more “purely retro”, but in fact the ability to use old 8-bit code is more important to me than on what hardware it runs. I dislike an FPGA solution not because it is not pure, but because it adds significant complexity for any person who tries to re-create my design.
I don’t think it’s non retro because it doesn’t run on a real old CPU, by that thinking neither the NES mini, nor the new mini commodore 64would be considered Retro, I just want a design that is easy to understand and build.
I already started the re-design, and it is more complicated and involved (have to redo most of the layout work) than I first thought. as always I report the progress on my wiki page.
As promised I started a thread about RhoCoCo in the off-topic section of the raspberry PI forum here: https://www.raspberrypi.org/forums/viewtopic.php?f=62&t=226889
Dream Computer would be some kind of c128 with VIC-II and 8543 in one chip so that all resolutions can go through VGA cable. That chip should support 1MHz (for c64 mode) and as many MHz as needed (2MHz for c128 GEOS 2.0 included).
-All interfaces should be commodore compatible. Main external memory would be SD2IEC.
-CPU would be 65816 on 1,2 and MHz as possible for full c64, c128 and cCrazySpeed variants.
-Memory: 256Kb RAM for c128 all banks full mode and 512 GeoRAM with DMA support.
-Basic would be perfect commodore 7.0. What else does human need?
I also want something that is C64 (maybe C128) compatible.
I think it would be an interesting start to just “copy” an C64/128 with a kind of slot based bus system. so that you have a cpu-card, a graphics card, a memory card and an i/o card or something like this.
this way it would be a very interesting device that would be perfect for upgrades in the future. in the first version that would simply be something with the original chipset of the c64/c128.
with the motherboard concept similar to personal computers it would be an interesting device. if it is not too high (with an external keyboard), then some kind of case similar to an atari 2600 would be so cool.
i don’t own an atari 2600 but i think it is the most beautiful design for a game console and with an external keyboard that would be suitable for developing or doing serious work also.
If Z80 was an option instead of 6502, then the Sam Coupe from MGT was probably the ultimate 8-bit machine, or as close to, released in 1989 to compete with 16-bit machines like the Amiga and Atari ST. It was basically a Spectrum clone running at 6Mhz, with 256k RAM upgradable to 4 and a half MB.
Wikipedia has the specs in detail
“The machine is based around a Z80B CPU clocked at 6 MHz and a 10,000-gate ASIC. The ASIC performs a similar role in the computer to the ULA in the ZX Spectrum. The Z80B CPU accesses selected parts of the large memory space in its 64 KB address space by slicing it into 16 KB banks and using I/O ports to select the particular blocks appearing in each 16 KB bank. The basic SAM Coupé model has 256 KB of RAM, upgradable internally to 512 KB and externally with an additional 4 MB (added in 1 MB packs). The computer has a direct connection for a cassette recorder for data storage but two 3.5 inch floppy disk drives can be installed within the case as well. Six channels of 8-octave stereo sound are provided by a Philips SAA1099 sound generator chip. The ASIC also includes a screen line interrupt, allowing video effects to be synchronised to specific display lines with little effort. ”
The computer wasn’t fully compatible with the Spectrum (certainly not the 128), which limited the upgrade path, and besides why buy an 8-bit machine in 1989 when the standard was then 16-bit?
But it’s worth searching for SAM Coupe and Prince of Persia in Youtube to see what an 8-but machine could do. But the machine obviously never had the chance to be stretched…
“Today, most software exists, not to solve a problem, but to interface with other software.” I. O. ANGELL
Not only “nostalgia” but also “simplicity” are the feelings that let me dream with a new 8 bit computer.
Requirement 1)
Energise = the computer is ready
De-energise = the computer is not corrupted
Requirement 2)
It shall be compatible with Commodore 64
I would buy one only if it had cassette player access to load and save stuff to, as I cannot afford a 1541 and lets face floppies die from just sitting around (what they call bit rot)
But with a tape interface you could use modern things like cellphones or cheap 4gb mp3 players and since the hardware can be speced up why not have it load from source @ say 2400 bps baud rate. Just my 2 cents
But how much are you prepared to pay? One cannot live on love alone.. I’ve done all the things you describe, from a simple OS with real-world application to the Basic cmd line you describe, but where there is no money..
I would pay as much as 300.00 to start and see where that goes, Donations to fund this stuff is fine with me that way the engineers / programmers get thier pay and the community gets access to the hardware they build every one wins
It sounds like an awesome idea.
Please do it. I’d buy / build one.
I’d like to see one small software ask, By all means add basic, but it would be great if there was an assembled built in as well so those who wanted to could program in machine code straight off the bat.
Ideally a method of mixing basic and MC instructions within one program, like the BBC did, would be great!
Have you ever tried out TempleOs? it’s basically a C64. You can write code in the terminal and execute it like a C64.
I just saw this article on Hackaday by Brian Benchoff: https://hackaday.com/tag/65816/
why not use a YM2612 (yamaha) and a SN76489 (texas instruments). Those are very easy to program for, are built for 8-bit processors, like that of the 6502 as well as 16 bit ones not unlike 65816. The Megadrive uses them, and most games use a Z80 to control the sound engine, but it can also in the megadrive be directly addressed by a MC68000. Older consoles like the SG1000, Master System, Game Gear, and Colecovision are all z80 based and are able to address those chips rather easily, only a dozen bytes needed to send data to their registers, as for addressing space for music and sound effects, that is up to the programmer. Oh and I saw plenty of hardware VGM players out there too, so these chips should be rather easy to get your hands on. You should have 10 voices, FPGA free with them.
Further more I will outline the choices of voices:
* 6 FM voices (4 sine operators, similar to adlib, just a little clearer)
the 6th FM voice can be converted to DAC mode and play stereo sound raw pcm.
* 3rd and 6th FM voice can be placed in a “special” mode which allows raw frequency handling. (This also is supposed by the Sonic 3 sound driver, but is rather unused)
* each voice supports stereo panning
* there is an undocumented feature that uses the SSG-EG bit for each FM voice.
* you get 3 Tone voices (complete with ADSR, square, triangle, or saw as far as I remember)
* you get one noise voice (can be combined with the 3rd tone voice for jet engine type sounds)
https://segaretro.org/YM2612
https://segaretro.org/SN76489
https://segaretro.org/TMS9918 – this should be plenty good enough for a retro computer, read the page for more info.
but why a 6502/10? why not a Z80 or similar?
not only is the Z80 still being produced and available as 10-20 MHz chips.
but also doesn’t require a strange 2 phase clock and seperates the Memory and IO Space, which is always useful.
overall the Z80 seems like a better choice for such a project.
I would just like an 8 slot caged machine with a CPU, memory card and 5 to 10 standard cards that could plug in offering a variety of useful functions and interfaces (serial, parallel, flash drive, RS485, video, sound etc) plus the chance to roll my own in a couple of slots. I can imagine each card has an spi interface or parallel interface on the same connector, some sort of DB25 connection to also provide physical stability. Like the old CPM card computers, but with more higher level or dedicated wiring of the interface.
Hola:
Primero siento que el texto este en español, pero es para mi mas facil de expresarme.
En cuanto a tu idea de hacer un computador de 8-16 bits, te comento que apoyo tu idea, ya que siempre pense en hacer algo parecido.
En cuanto a las prestaciones que explicabas, siempre me quedo la tentacion de hacer un sistema de hardware, libre, tipo linux, pero que fuera posible de usar, sin emuladores. Explico un poco mejor.
Como la mayoria de nosotros, disfrutamos maquinas como C-64, MSX, y las europeas Amstrad CPC, Sinclair Spectrum, entre otras. Todas ellas eran basadas en 6502 o Z80.
En su dia, cuando pensaba en hacer un “computador” completo, pensaba en usar un procesador, lo suficientemente poderoso, como para con un pequeño software en rom, pudiese reporducir codio maquina de procesadores de 8 y 16 bits, sin tener que emular, y asi, ademas de tener software propio, que pudiese reproducir software de terceros de otras plataformas o incluso ya de programadores expertos en otros sistemas. si usamos ese planteamiento, ya de por si, habria una comunidad de programadores amateur y profesionales, porque este computador, podria tambien tener cabida en sistemas conocidos.
Asi, que mi idea, seria aglutinar, la mayoria de partes, procedientes de sistemas pasados y crear una maquina “libre” de hardware.
Sin FPGA, ni rasberry pi. Hardawre puro, como a la vieja escuela…
Esa era mi idea. Un nuevo estandar de 8-16 bits, para todos
Saludos
Not to be a wet blanket, but wouldn’t the most practical solution be a virtual machine with specs about 4x as powerful as C64 in every respect but W/ Basic from plus4/c16. (With subset of python 3 as alternative as well as assm.) This should get ported to as many architectures as possible. Give it a gui front end with taskbar and an editor like C64. It’s not really about hardware. It’s about everyone having the shared experience of working within the same limited Dev environment and overcoming challenges together imho.
Ok
This could be interesting
But What About the ULTIMATE 8 BIT GAME CONSOLE?
Inclouding her easy game engine to create easily infinite powerful games with no effort?
How about mass storage? Floppy or cassette drive? Something like Chuck Peddle’s constant-density 1541 or his later similar drives for the Victor 9000?
Have you hear about the project Oberon? https://www.youtube.com/watch?v=EXY78gPMvl0
Have you read Code? http://charlespetzold.com/code/
I think the Spectrum Next is the computer to go for. Even if it is not the *exact* requirements you put up (6502, character set) – it is in spirit exactly the type of philosophy and ambition! Providing a new modern old retro computing platform to develop for and play with! 🙂
Now I just wait for the next wave of sales (missed the original funding)…
https://www.specnext.com/
Perhaps you could modify an Apple IIGS to make your dream machine? 6502/65816, with lots of ram, well documented hardware, lots of expansion come to mind. The Apple IIGS has socketed ROMs which could be replaced though you might be able to disable some of the onboard ROM on an expansion card. Considering the modest cost of a used IIGS at this time it wouldn’t break the bank either.