I have to imagine that this is the purview of embedded 2D microprocessors / OSes like Linux4SAM.

https://www.microchip.com/en-us/development-tool/linux4sam.o...

With well made compute modules: https://www.digikey.com/en/products/detail/microchip-technol...

And open reference designs that fit on 4-layer boards (!!!!) despite using DDR2. Though I think most people would be more comfortable with 6-layer boards (which is possible with OSHPark today).

I would love to see the alternate world in which the z8k or 68k were finished in time for use in the IBM PC. Intel is dominant today almost entirely due to the 8086 being available 6-12 months earlier than competing 16- and 32-bit processors.

I would start with the MIT CADR CPU in an FPGA and add modern hardware round it like Ethernet, USB host, 2d blitter, etc...

Something like an STM32 Discovery board is a good option for recapturing the mid-90s magic. You can get a ~200-MHz Cortex-M4 or M7 with a few MB of flash, external SDRAM, and a display for less than $100. They have really basic hardware 2D accelerators.

The on-chip peripherals are well-documented, but off-chip peripherals require some digging to figure out how to program correctly.

You can debug with GDB surprisingly easily, or find a Forth to throw on there and just start poking registers.

No. Microcontrollers are the improper solution for this problem.

You can run full blown Linux efficiently at 500MHz or 600MHz processors like STM32MP1 processors, powered by AA batteries or other small battery packs.

There's also SAMA5D2, and a few other competitors in this space (both above, and below, the STM32MP1).

When we're talking about "consoles", that's "plug-and-play executables", meaning you now want a proper compile / library -> ELF + loader == Linux kernel, security, etc. etc.

Besides, a DDR2 chip gets you like 512MB of RAM for $4 and easily fits within the power-constraints of AA-batteries. There's very little benefit to going to the microwatt-scale devices like STM32 Discovery.

----------

Microprocessors for the win. Entry-level MPUs exist for a reason, and there's a ton of them well below Rasp. Pi in terms of power / performance.

There's many at the 2D level of graphical performance, but 500MHz is still a bit low for this. You'll probably want to reach into faster 1000MHz / 1GHz MPUs and push into STM32MP2 if you're reaching into 3d levels of performance. (Which is beginning to look like a cut-down cellphone chip really)

I guess it depends on which part you think is fun. Using a big microcontroller is more about pushing the hardware to its limits. Using a small Linux system is about taking advantage of existing libraries. The Playdate has an STM32F7 and it seems to do pretty well as a console.

As there are several available, is there one in particular that you would suggest for this use case?

I liked the 32F746GDISCOVERY which is $56 at Digikey. It has a Cortex-M7 CPU, 1 MB built-in flash, 8 MB of SDRAM, and a 480x272-pixel touchscreen. Games can go on a microSD card. There's a USB OTG port you can use for input.

A low-res screen like this works well because the chip can't rescale its video output.

ST provides libraries for all the peripherals so it's pretty easy to jump in if you know C. I think microPython works on a lot of these boards, too.

it looks like the agon light actually runs an ez80 which runs pretty fast and can address the whole 512k of ram without paging which does give you that sort of late-80s/early-90s headroom

The eZ80 is indeed quite fast, and the 24-bit space is a comfortable size for values as well as addressing - I've been working with it in Forth and haven't felt deeply constrained by that size(occasionally needing the double number operations, but nothing more than that). The graphics spec is a little bit below most 16-bits in terms of color depth, since it's VGA 2-bit per channel, but the screen resolutions also go quite high, so I expect a lot of 640x480x16 or 800x600x4 games.

Meanwhile, the ESP32 acts as an ultimate co-processor through the VDU protocol inherited from the BBC Micro. That's a part of the architecture that I really appreciate, because it positions software design around the serial I/O and how effectively you delegate your tasks to the VDU. Early reactions from people who are used to 8-bit coding were a bit perplexed because they couldn't push a lot of stuff down that pipe, but as the firmware has developed, the ability to define complex, shader-like programs has also built up. Nothing stops you from describing, e.g., a tilemap engine in terms of a program that stores map data, tiles, and sprite assets in VDU buffers, and then launches a program to do all the array processing needed to blit the tiles and display the sprites when given a camera position.

That's cool because it means that your graphics engine is decoupled from the CPU language. The same VDU sequences will work in Basic, assembly, Forth, C, etc.

Mega65 is on FPGA exactly

Enough already with retro hardware that reproduces the early 2d games aesthetic. We need to step up the game and make retro hardware that reproduces the early 3d aesthetic.

This is completely my subjective opinion, but I find "early 3D" ugly. In my opinion, pixel art has aged better. In fact, some of it still looks beautiful to me. But early 3D I find almost completely unappealing.

About the only exceptions I can think of are some flightsims like SSI's Flanker (which had very complex graphics for being simply flat-shaded 3D) and the games that emulate this nowadays, like Tiny Combat Arena.

Early 3d generally hasn't aged as well, probably due to extremely low resolution textures and so forth.

The development cost -- of the tooling and the games, let alone hardware! -- is too high. Additionally, 3D games aren't products of their host hardware as much as (older) pixel art games are/were.

You can run Commodore VIC or IBM PC wigh CP/M, MS-DOS, Windows 3.0, Linux ELKS on ESP32 using FabGL.

I think this is less people who grew up with C64s and more people who didn't trying to capture the magic without having to learn assembly or making sprites with graph paper and a hex editor.

Sure, but there was a whole other magic era that followed that. That also got to work with low-level assembler and direct framebuffer/video access. But wasn't constrained to 320x200x8 screens with pictograph fonts ("petscii") and POKE/PEEK.

It had other limits to explore other than shoving as much as you could into 64k of memory and 1Mhz of processing power.

Maybe check out the Colour Maximite 2 with a Cortex M-7 [1]

Very much in the spirit of the early home computers (inc a decent BASIC) but with a lot more oomph.

[1] https://geoffg.net/maximite.html

I have one of the originals and spent hours messing around with it. It's a great little computer and MMBasic is pretty nice. Thanks for the memory reminder.

I’ve often thought the TMS340X0 series would make a good hobby target.

They were interesting to program for.

I started using a graphics card with a 34010 before there were tools available for it. I did ports of GNU binutils (gas and ld) to target it then wrote some firmware in assembler for an X11 server to call to do basic tasks like filling rectangles, line drawing, copying with colour expansion for displaying fonts.

Still have the ISA card but haven't powered up the machine it is in for a long time.

That’s cool. I’m professionally jealous of all the people that got to program neat chips back in the arcade heyday.