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.
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. Commander X16's official site has community downloads section 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.
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).
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.
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 ended up a programmer :)
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.
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.
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
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".
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.
On a $5 computer.
Very interesting machines nevertheless, and fun to play with for retro fans.
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.
- 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.
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.
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? ;)
A game that might interest some here is Tunnels of Doom
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.
What it should have been able to grow into was the Geneve 9640.
I'd love to see an FPGA re-implementation of one of those.
It used the same CPU. That's one of the reasons it has so little RAM - it only supported static RAM.
Personally, I'd be put off the X16 by its weird form factor, which I guess is intended to avoid the need to commission of custom keyboard design.
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 ;)
I hope they don't clash with each-other as they both look awesome!
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.
Sadly, the IIgs was not really an upgrade to the II line, but rather a 65816-based "MacAmiga ST" with an Apple IIe inside, screaming to come out.
And we all know the III would have been a good computer, if it weren't designed by the marketing team.
She made mention of a youtube comment about "why not just make an emulator, it's so much easier".
Really really sad that SO many people think that their comments just go into the void and don't affect people :(
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.
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.
Although it is focused mainly on games
Just opinion of course. Retro is whatever it means to you.
- WDC 65C02S @ 8 MHz
- 40-pin DIP package
It does use an fpga for graphics. That’s kinda surprising I would have thought there’d be a suitable graphics chip off the shelf.
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.
But from the features it sounds like it’s really just a frame buffer/RAMDAC, no sprites or other fancy features.
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.
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.
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.
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.
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.