I was originally interested in this, but I recently found a seemingly good alternative in the Color Maximite 2 (http://geoffg.net/maximite.html) which sits somewhere between 8bit (feel) and 16bit (graphics).
You can get a similar feel, very inexpensively, with an ESP32. Tiny Basic[1] and the FabGL vga library[2] turn an ESP32 into a reasonable retro clone. You can even find an ESP32 that already has PS/2 and VGA connectors for $11[3].
I think that for such modern retro style systems is very important to have a huge community and because of this a legacy compatible systems like ZX Spectrum Next[1] or MEGA65[2] or systems designed from persons with a huge audience like David Murray[3] are clear winners.
ESP32, TinyBasic and FabGL look cool, but it seems that there is not enough people knowing about them and wanting to develop software for/with them. Unfortunately the same can also be said for the Maximite series of machines. I wasn't able to find any dedicated FabGL or Maximite community sites.
The same cannot be said for the upper mentioned computers which apparently already have significant community and some people actively developing games and other software for them. ZX Spectrum Next even have a dedicated distribution site[4]. Commander X16's official site has community downloads section[5] which looks similar.
If someone wants only to have some fun programming a retro like machine in Basic or in C++ with FabGL, ESP32 is really a cheep alternative, but most probably what he does with it, will stay only his own personal experience and he will not have a huge chance to find some audience or community.
Something I found frustrating - the Maximite repl goes out of its way to prevent the user from writing machine code. This is not in the spirit of classic systems.
Maximite lacks memory protection, and does allow direct writes to memory. There will be a way to over-write a basic function in order to hijack initiative into machine code.
I was going to post a similar thing. I know the 8 bit guy reviewed it positively, and for me the CM2 is a better bet as it can run BASIC code about as fast as a 6505 can run assembler.
I know it's not as legitimately retro (in terms of chips), but that doesn't matter to me; what does matter is having an accessible system to play about with and hopefully show my son that programming can be fun and he can make games without an impossibly step learning curve (ie how I felt about my ZX spectrum back in the day).
I hope it works out. I was excited to get my kids interested in programming like I was in the early 80s. What I discovered was some combo of my kids are their own people and not my clones, but I think more importantly, the bar for computer magic has risen. When I was 8-12 just making a computer do anything was magic. Computers were mysterious and still a bit rare. Today my kids are growing up in a world of total computer saturation from phones to pads to laptops to the cloud. Much as I wished programming would capture fire for them like it did for me, there is no magic for them in making the computer do a few simple things. The world still sort of awaits the next paradigm to spark the next generation of inventors and creators.
Yep I briefly had my 10 year old snagged on Pico-8 last week -- he immediately and intuitively seemed to understand what was going on as we kind of pair programmed together -- until I left the room. Then he just started playing other people's Pico-8 games and described the whole thing as boring.
He's got potential as a programmer. Maybe someday someone will pay him to do it. But you're right, computers now can do everything so easily, there's no glory in doing simple things for the sake of it.
First, wow! I didn't know about the Pico-8. Seems fun! I like that its limitations can foster creativity.
Second, maybe your son needs more time. Back when I was a kid, I played a bit with BASIC on my C64 but it was very frustrating and I gave up trying to do something complex, and ended up just playing games, much to my parents' chagrin.
> I know it's not as legitimately retro (in terms of chips), but .. what does matter is having an accessible system to play about with ... (ie how I felt about my ZX spectrum back in the day).
Hopefully we'll see more focus on RISC-V chips in the future. A RISC-V based, maximite-like system would bring assembly-level programming that's as simple and accessible as it could feasibly be, and quite comparable to the ease of writing assembly for the old 8-bit chips.
I had started on a project like this, which I was calling "Retro V" (retro 5... is alive! for the 80s movie reference...)
It's a PicoRV32 core + a simple 'retro' style video display processor (sprites, character generator, and 640x480 8 bit palette indexed bitmap graphics) that outputs on HDMI/DVI, plus 512KB of SRAM that runs on the CMod A35t board (Artix 7 35t FPGA + SRAM on DIP friendly package), which I intended on making a simple daughterboard for (to hook up PS/2 keyboard & mouse, add some extra RAM etc.)
The "OS" was to be mid-80s style -- boot to a REPL, either a BASIC or something like Lua, with simple DOS commands and an assembly language monitor.
I got pretty far but stalled out around Christmas when things got a bit busy personally for me, and I ran into the complications of getting the QSPI flash chip interfaced for storing programs.
I might pick this project back up again. I think it has potential.
BTW I don't actually think RISC-V assembly is all that great for beginners. It's a bit awkward to write directly. For example, to set a 32-bit register with an immediate value requires setting the upper 20 bits followed by the lower 12. Similar with PC jumps, etc.
In general RISC architecture assembly language is meant to be written by C compilers, not humans.
I actually think beginners might be better off with a CISC instruction set (like the 68k or similar).
EDIT: Thinking more about this, out of all the architectures that GCC currently supports, 68k seems to be the most "retro" and easiest/most enjoyable to write by hand.
Any project that will only be programmed in BASIC, C or something will make the processor it uses irrelevant. Only if there is some assembly will the processor matter.
One fun pseudo-retro project would be an incremental BASIC compiler which allows simple inline assembly. That is: any given line can be either a BASIC statement or an assembly instruction. The "incremental" part would be that every time a new line is entered the program is patched to include it. The program would be stored in machine language with two helper tables: line number to address mapping and variable name to address mapping. When you LIST it would decompile each line as it goes to the screen (easy to do since the compiler wouldn't have any optimizations). BASIC already has to include a garbage collector to deal with strings so this would not add too much complexity.
I agree that the 68000 is nicer to program in assembly than the RISC-V. I started a simple RISC (only a short presentation so far) with the goal of having nice assembly code: https://github.com/jeceljr/baby42
> It's a bit awkward to write directly. For example, to set a 32-bit register with an immediate value requires setting the upper 20 bits followed by the lower 12. Similar with PC jumps, etc.
Yes, IIRC the standard description of the RISC-V ISA includes assembly macro-instructions that can be programmatically expanded into sequences for things like those. Similar to how "mov" is actually implemented as a special case of "add immediate".
Oh for sure, that's great for writing, but when disasembling or looking at the asm listing for a C program you don't get that. Which happens a lot while working on a low level machine like this, especially when building it :-)
Why not just boot up the vice emulator and give them a true c64 experience? The CM is a neat project but if you're going for retro seems the worst of both worlds: modern, under-utilized hardware with artificial limitations. To me the later is the goal to force creativity; the hardware in this case seems superfluous.
Because previously we've spent a bit of time using an arduino to do something, and he enjoyed learning to solder and connect LEDs up. So I think that the experience of building the computer will have him more invested in it.
If you want a modern BASIC experience, Risc OS Pico on a RasPi Zero is a very good one.
1GB flat memory space, a blindingly-fast 32-bit structured BASIC with local variables, named procedures, IF...THEN...ELSE and DO loops and so on, and it supports inline ARM assembly. You can enter ARM assembly language directly into your BASIC listing in the same editor, and it will be assembled and run when you type RUN.
The main pusher behind Commander X16 talked a bit about this alternative. It does feel like an 8-bit machine but IMO is closer to an emulator than 8-bit hardware. It's super overpowered compared to what it represents with the most intriguing aspect being it runs reegular old basic faster than a C64 runs machine code. Some of the creations are pretty amazing, but mostly because of today's hardware. It's also been pretty difficult to get a maximite (though this might clear up)
He reviewed the other computers in the Maximite series in the past. He considered the Maximites as possible candidates for what he was looking for in a "modern" retro style computer, but decided to pass on them as they weren't quite what he wanted.
Very interesting machines nevertheless, and fun to play with for retro fans.
People should really get retro crazy about the TI-99/4A, now hear me out..
It's generally the cheapest retro computer you can buy, and it's really weird, not some easy computer like the C64 or Atari 800:
The TI-99/4A BASIC interpreter is written in another byte-code interpreted language. This is because the BASIC ROM is not directly accessible to the CPU, you have to read it indirectly through a port. Likewise, the 16K of dedicated video RAM is also only accessible through a port. Now keep in mind this is a 16 KB computer, so your BASIC program is stored in the video RAM. It only has 256 bytes of 16-bit native RAM (unless you have the PEB...)
Now it uses a pretty good 16-bit CPU (but weird mind you- its registers are kept in external RAM), but massively crippled like this to keep the cost down, but also to prevent the home computer from competing with TI's minicomputer line. TI made millions of them.
While there are many reasons why people should be retro crazy for the TI-99/4A, the Commander X16 is unique for a bunch of reasons that would make it difficult to recreate for other systems:
- Some of the hardware reflects 1980's designs. For example, it uses a CPU that was used back then and is still available. (Edit: or rather a variation of the CPU.)
- Some of the software is from the 1980's. That requires rights holders who are willing to license that software.
Those two criteria alone would limit the systems this type of project could reimagine. Then you have to consider:
- The people behind this project. Creating your dream computer in hardware takes skill and determination. The people following through decided to use the Commoder 64 as their model.
- A large part of the rationale is that it is "easy" and lacks weirdness. Many of the people interested in retro computers are looking for something more engaging than games. They want hardware that is simple enough for them to understand and develop software for at a low level.
Yet I suspect that the biggest reason why the C=64 was reimagined has to do with the community around it today. For whatever reason, Commodore computers have attracted a following of hardware and software tinkerers (this goes for the Amiga as well). I haven't seen quite the same thing to a similar degree of dedication on other platforms, aside from some particularly dedicated 68k Macintosh hardware presevationists and 8-bit Atari software developers.
I basically agree with you, just trying to get people interested in something other than C64. It's impressive that they got permission to use Commodore BASIC (and Kernal?).
That is a great thing in the sense that many of the less popular systems encapsulate ideas that are mostly forgotten, presents a more balanced view of the early personal computer industry, and represents a greater cross section of society.
On the other hand, we are also dealing with limited resources so we have to pick our battles. It seems as though society views Apple, IBM, and Microsoft as the creators of the computer industry. At best, that is a partial truth. In a sense, this perhaps disproportionate interest in Commodore offers an opportunity to demonstrate that these nearly forgotten companies played a significant role in the development of computers rather than being simple failures.
If we go beyond that handful of companies, there are other factors that we should consider. The computer industry is usually painted in very American terms. It's understandable. American firms were, by in large, the winners. At the same time it neglects what was happening in Europe, the eastern bloc, and Asia. While those regions receive some attention, Africa, Australia, and South America seem to be nearly ignored.
Pretty interesting thread you two. The history of computers is fascinating.
The thing with my own interest is this: I owned a C64 when I was a kid. I had a friend with a Spectrum. A friend of my dad (a grown up) had a C128. That's it. I can't feel nostalgic about computers I never saw as a kid. For example, I never knew anyone who owned an Amiga, so -- fabulous as that machine is reported to have been -- it means nothing to me.
... Though the relatively recent post here on HN about someone who picked up an Apple II from the trash and repaired it did get my some weird nostalgic vibes. Is there a word for nostalgia of something you never experienced? ;)
I had one as kid and picked up one a few years ago. Would have been interesting to see what TI could have done in early computer market if they hadn't crippled the machine (intentionally or not) and not fought third party development.
> People should really get retro crazy about the TI-99/4A
As someone who grew up with one, I'd advise against it. It's not that they're bad, it's just that everything else from the same era was a lot better.
There's some real perversity about the hardware, and that sounds fun, but I wonder if there's anything about it that would actually be fun to program today in C or assembly. It seems more like needless difficulty than adventure. And if you're feeling nostalgic about TI BASIC or Extended BASIC you're suffering from a head injury and should seek medical attention immediately.
On the other hand... it would be amusing to use one of the modern embedded SOCs that people are recommending here and set it up to talk to one of the TI's wacky peripherals, like the speech synthesizer. Some amount of bit banging would probably result in something interesting happening.
I really dig the looks of the ZX Spectrum Next. I never had a Speccie as a kid, so it lacks the nostalgia factor for me, but it looks like a great product.
I ended up buying TheC64: a C64 lookalike that has the looks but none of the hassle of the real old hardware. I don't care for the games carousel (I know where to get games anyway) and I wish it booted up faster, like the BMC64 emulator does, but other than that I'm sure I'll love it. I can't wait to write petscii graphics with a C64-like keyboard ;)
Odd to see "a real CPU, not an ... FPGA". For perspective, the first "real" SPARC processor was implemented in a Fujitsu gate array (though not, I think, field programmed). https://en.wikipedia.org/wiki/MB86900
Been eagerly anticipating this thing for a while now.
Originally it looked like it was gonna come out before the MEGA65 (because they had been dragging their butts for like 6 years) but now it looks like THAT's gonna be coming out first! How times change!
I hope they don't clash with each-other as they both look awesome!
What I'm really curious to know is at what effective screen resolution it will have sufficient power to update every pixel on the screen in a single frame (assuming you are using assembly language and true graphics, not a character mode), with enough CPU cycles left over to do some computation.
With an 8 MHz 6502? It's around 15 cycles per byte for memcpy, so 500KB/s of data. At 60 Hz frame rate, that's 8KB- so 64x128 for byte per pixel, or 256x256 for a bit per pixel.
The GPU supports multiple tile layers and has 128 individual sprites so updating every pixel on the screen in a single frame is unlikely to be how you use it.
This is in style of 8-bit machines that had hardware sprite support and tiles graphics rather than treating the display as a flat framebuffer.
Sure. It's just nice to know what the limitations are in that regard. Some demos for the Atari 8 bit machines for example did use them that way by lowering the resolution sufficiently far and then writing really tight assembly language. So I was just interested in comparing on that basis.
I'd probably use a 65816 and a direct progression of the II and /// feature sets. Maybe place the frame buffer on dual-ported RAM so it wouldn't be locked to main system timings. Or add a palette that would merge 2 or 4 pixels into 4 or 16 color entries. Maybe linearize the HGR and DHGR modes too.
I made an emulator for some aspects of her machine early on. Not to displace her project, which I thought was great (she's insanely talented), but to bootstrap development of software and demos for when the machine came out. I was on the list to get one of the boards. What she was working on was a far better machine than this 8-bit guy project.
But I pulled myself off the list and stopped working on it when she started making ad hominem personal attacks on me. I don't think she ever liked the emulator project, which is fine, but she made some rather paranoid false accusations against me. So I walked.
It's a shame her project is gone. But there's a similar machine, the Neon816, that is also really interesting.
But after having working with the 65c816 for that period of time I've decided it's a processor I don't really want to play with. It's really unpleasant to code for.
Thanks for providing more information. It’s too bad, but I’m glad there’s a similar project. The true desire to follow the C128 made that a bit more interesting to me than the Neon816, but I’ll give that another look.
One question:
But after having working with the 65c816 for that period
of time I've decided it's a processor I don't really want
to play with. It's really unpleasant to code for.
I’d love to hear a bit more. I hate coding for the SNES, but mostly because doing it properly feels like nothing but DMA. What about the 65816 makes it painful in general, if you don’t mind my asking? I find the 6502 very pleasant, if understandably limited.
I've got comments elsewhere in this threat on this topic. Basically, the opcode space wasn't big enough to add new 16-bit addressing modes properly, so they bolted on a 'mode' flag and it's super awkward. It's hacky.
The problem is that there are no off the shelf chips that feel anything like the video chips of the late 8bit or 16bit eras.
You can do a bitmapped or character displays with just a bit discrete logic.
The graphics chips that do exist these days are all focused at driving LCD touchscreen interfaces with the cheapest microcontroller possible. They communicate over quad spi (not an interface that works with classic 8bit CPUs) and support 24bit color with complex modern drawing primitives like "draw line, draw box, draw circle and decode jpeg".
Sadly, if you want a sprite and tilemap video chip for your modern 8bit computer without resorting to old stock, an FPGA is about your only option.
Which isn't that inaccurate. Most video chips of that era were custom designs themselves, and FPGAs can be though of as just a simple way to achieve custom chip design on a hobbyist budget.
If you can find a suitable graphics chip, please let me know, but I've been casually looking for the past few years for a chip that can connect to a parallel bus, and output VGA and/or composite. There http://www.vlsi.fi/en/products/vs23s040.html, but it requires SPI to configure video, on the same pins used for the parallel bus.
He’s looked at a few on his YouRube channel and discussed what his issues were with them. Basically, the existing ones made trade-offs he’s wasn’t super excited about, and he needs some modern chip due to HDMI and the like.
The 816 is really not a great processor. In some ways I'd rather just have an MMU bolted on the side rather then the uncomfortable way that the 816 makes 24-bits memory available.
The segmented architecture is one thing, but the painful way it was hacked into the instruction set is not at all enjoyable to code for.
a) You're constantly having to flip modes between 16 and 8 bit for various registers, and keep track of which mode you're in.
b) There's no register that can hold a full 24 bit address. So imagine doing bitmap graphics in, say, a 640x480 display when you can only directly address the first 64k of it before having to futz with segments.
c) The thing sucks to interface. Many people have solved this problem but having to demultiplex the bus is not fun, especially when the 65xx already does so much in a single cycle.
The 816 was a hack, but not a particularly brilliant one. It does add some nice things (relocatable base page, etc.), but the 6502's instruction set didn't really have room for doing it right. So they didn't.
This is very interesting. Thanks for the insight. You go into more depth than I've seen before.
Have you ever looked at the 65C832? It never made it to production but there are detailed specs and a datasheet; probably enough for someone to implement one on FPGA or something. I'm curious if it would have fixed some of the issues you report.
I have read about it, but never read the actual datasheet til now. In some ways it looks like it fixes some of the 816's problems in that there would be 32-bit accumulator and index registers, so you could put a full address and do pointer arithmetic in there etc.
But it still has the problem of futzing around between modes for the registers, modal instruction set... terrifying. And the program counter is still inexplicably 16-bits, so have fun writing a compiler for programs bigger than 64k, you have to manually manage the bank register when you move between banks.
And looks like direct page and stack still stuck in the bottom bank? At least I think I read that?
And for god's sake, why multiplex the databus still, like the 816?! Why wouldn't they just make a 64-pin DIP version like Motorola did with the 68000?
Anyways, it never made it to production. But basically looks like an 816 x 2, which isn't terrible in that having double the size on those registers makes doing a lot of things a lot easier.
A '816 would indeed be much better suited to access 512K of banked memory rather than banking through an 8K window but perhaps they don't think 65816 counts as retro enough, or maybe they're just masochists
I briefly somewhat followed this project until it became obvious it was going a direction I wasn't interested in. Originally they were going to use a 65816 but then switched to the 6502. I believe it had to do with the increased complexity of implemention caused by the 65816 sharing data and address lines which requires the lines to be multiplexed.
Part of the decision was that there aren't as many good tools available to compile/assemble/disassemble. Also, the length of some instructions depends on the current state of flags in the processor, which is a pain for disassembly.
It's not segmented, it's banked. And due to instructions that can use far pointers, you can directly access the entire memory. The main annoying part for me is that the stack and zero page are stuck within the first bank, limiting usability for a multitasking system.
Can't you still have 128 tasks even without sharing pages between tasks? That is, one direct page and one stack page for each task, with 256 pages total in bank 0.
With sharing I mean, when you have two or more tasks of which only one instance will run, they can use the same direct page. Similar if you can statically limit the stack size of the tasks to a fraction of 256 bytes, you can fit multiple stacks on the same page with some work.
Said far pointers are only for certain instructions, and there's no register which can hold a full 24-bit address, so there's always a bunch of hassle when dealing with addresses. They should have added a "pointer" register, which could hold both a 16 bit value and a bank value.
Program counter is 16 bit, with a separate bank byte; it'll wrap when it hits the bank boundary.
Constantly having to flip between register modes is a hassle. And makes it very difficult to write compilers and high level languages. Many common patterns require flipping back and forth a few times.
Either they needed to have a whole new set of addressing modes, or they should have just added 3 new registers -- 16 bit versions of X Y and A -- and let the two co-exist.
Honestly, this is an era when a 68000 could be had with a full 16 register set of 32-bit registers. The 65816 doesn't look so hot in that light, though it certainly was faster at interrupt handling.
I guess Nintendo made do with their modified 816, but it really is not a nice architecture.
