Need to find a microcontroller with these capabilities

I've been looking at the NES documents and I see how everything is so weak, just 3 CPU registers, just 2kB RAM with stack trapped in one page. Mustn't do stuff while PPU is busy rendering the screen...

I then thought of some ATMEGA or XMEGA consoles and saw that many people overclocked their MCUs because of the lack of time. I think they didn't get more resolution or more colors than NES.

The reason why I don't want to use AVR microcontrollers (ATMEGAs and ATXMEGAs) for retro consoles with TV is because they have 2 separate address spaces. One for program memory and the other for data memory. It's stupid that CPU cannot execute code from RAM or anywhere outside its Flash meaning that I must flash a game into Flash every single time I want to play a new game (which causes the Flash memory to lose its lifetime).

I'm looking for a microcontroller that can have its own BIOS for loading stuff off of an SD card or USB or its own cartridges into RAM or using some kind of mappers like NES does. What kind of microcontroller would that be?

If needed for APU and PPU, I might use more microcontrollers, that's not a problem. Maybe I can use an already existing APU and PPU if they're not over $15. But these requirements must be satisfied:

• Von Neumann architecture (24-bit address space prefered)
• Must be C friendly and have free C compilers for it
• Minimum 8kB of internal SRAM and an ability for external RAM (which will be used for the loading of the game)
• Minimum 128kB for BIOS (a Flash or EEPROM memory)
• Minimum 32MHz of CPU speed
• Must be able to have minimum 16 8xX or 8 16xX sprites on screen
• Must be able to render from a minimum 256 color pallette
• Nametable must be 8x8 pixel tile-based with minimum 2 layers and each at least 2x2 screens
• Background attributes must be per each tile
• Each tile must have at least 8 colors (7+transparent)
• There must be at least 8 pallette entries for the sprites and for the background.
• Must have support for USART, USB, SPI, I/O ports, waveform generating DAC (like PCM or DPCM)
• Must have a configuration change protection so that the game doesn't mess with the system stuff like overwriting the BIOS or I/O peripherals. I don't want to have viruses on embedded software!

I might update this if I feel like something is missing.

The reason I'm doing this is to enjoy making retro consoles and retro games without legal issues, expensive hardware or hardware restrictions.

Sorta by definition, microcontrollers usually execute code from ROM; microprocessors usually execute code from RAM.

That's not a hard-and-fast rule, but you may simply be barking up the wrong tree.

Genesis/Megadrive.
What exactly do you think a console is going to be doing with GPIO other than reading controllers?
Basically the same time that CPUs got that fast, consoles stopped using tile-based graphics and went to 3d rasterizing instead.

GPIO is for USB loading, SD card, audio chip (that plays MP3, WAV, WMA, OGG, MIDI and real time MIDI!), AV picture, USART debugging.

And are you sure that Genesis doesn't have legal issues like if I'm using the BIOS or if the BIOS is required to run my game and it's copyrighted? Are there homebrew BIOSes that have no legal issues?

The Genesis doesn't have a BIOS/bootloader, but that's what the Everdrive is for.

"Has a bootloader and loads into RAM" strongly implies "is a general-purpose computer" or "is a flashcart" (Exception: GBA multiboot)

Reproduction is a bridge you can cross when you get there. Note that said reproductions cannot, for cost reasons, have much RAM.

Then what writes the "PRODUCED BY OR UNDER LICENSE FROM SEGA ENTERPRISES LTD." message?

Well, ok, not all Megadrives had a boot ROM. http://segaretro.org/BIOS
But it's not really a BIOS; no part of it is usable by a game for it does not provide any useful subroutines nor would you include any part of it (other than the TMSS circumvention) in a cartridge.

All legal issues related to the Trademark Security System (TMSS), at least under U.S. law, were decided in homebrewers' favor decades ago in Sega v. Accolade, and the principles were affirmed by the Supreme Court in Lexmark v. Static Control Components.

At this point, you might want to go buy a Genesis and an EverDrive-MD. Which Genesis dev forum is active?

To somewhat answer the question, look at any decent MCU with Cortex-M core (Cortex-M3, Cortex-M4(F)), they can execute from RAM (internal and external), can have all the peripherals you want (USB, SPI, etc) and you can cross-compile for any Cortex-M device with gcc, which basically means "free C compiler". Take for example the STM32F429 series: all the features you want, 180MHz, FPU, MMU (handy for your OS, or at least protecting registers you don't want "users" to tamper with), can interface directly into a TFT LCD, hardware support for 2 layers plus basic hardware blitting (you could simulate multiple layers by software if you want to quite easily), support for external RAM (I think up to 1GB), >=512kB internal flash, etc.

Frankly, go to digikey and go "choose" your MCU. You can see the features and price.

If speed does not matter, you could always interpret bytecode that is outside of the flash memory. Something like FORTH or Pascal.

Cool! Are there any dev boards for that with external Flash and external RAM? I don't think I can find any with those externals.

And how am I supposed to do the rendering to TV via AV output jacks? I don't think I would should use interrupts during that time, but I'll have to for USB interrupts and Internet interrupts and other things.

Are there any libraries for this?



Maybe BASIC, but that would be for my XMEGA microcontroller rather than the ARM one.

Something that always bugs me with microcontroller is that you need to chase the beam. If you have a 32Mhz chip, you have to update the pixel every 5 or 6 cycles.

Anything with enough RAM and an appropriate DMA unit could have a framebuffer, not unlike "real" graphics cards.

But once you do that, why aren't you using a "real" computer? Programming for a dumb framebuffer on an embedded system will be almost identical to using SDL on a PC.

(Actually, modern graphics cards don't use flat linear framebuffers anymore. Apparently. So pedantically we might say "not unlike graphics cards in PCs from 1980 to 2005 or so" instead)

Because I want this to be a retro tile-based TV game console.

Framebuffer != tile-based

Then how am I supposed to have a NES-like rendering engine that renders the sprites very fast and where the capabilities are bigger(no 8 sprite limit, more attribute colors, bigger pallette, etc.)?

My point is simply: If you're programming ... in C ... for a framebuffer ... using abstractions because implementing a USB stack sucks ... downloading code over the network ... the only thing you achieve by using an embedded processor instead of some abstraction like SDL is tying the game to a physical hard-to-redistribute item. You won't learn anything different on this kind of rather-high-level embedded system, other than how to implement a framebuffer.

On the other hand, if you implement a just-in-time tile-based or line-buffer-based renderer, yes, you will have overdraw limitation, but the constraints actually now make it meaningfully different from a libSDL program.

Ultimately, the question underlying this is "If I run out of processor time, should FPS drop, or should visible features drop?" The first is what ≈every general-purpose computer/game does.

But there's no SDL for STM32F429 or even an OS for it or SDL for that OS.

Well, you can have a touchscreen, SDRAM and USB on this eval board: 32F429IDISCOVERY


I don't know any MCU that generate analog video signal, but I didn't search that either. You could do like the Uzebox, that is, use an external RGB to composite converter, and then run the game logic as well as video generatiing inside one microcontroller. You can simulate tile-based rendering in software, thus the game will "see" an tile-based GPU.

Note: I'm mentionning STmicro MCUs but that's because I'm more familiar with them.

But why does (libSDL's absence) matter? libSDL is an API for getting something that looks like a framebuffer on a modern machine. Plus a little glue for audio, input, window management, compact disc audio (really), and openGL stuff. If you want to write code that uses a bunch of abstractions (framebuffer, USB stack, ethernet TCP/IP stack, &c) ... how is that different from e.g. a RasPi running linux?

Because Linux is GPL and GPL is cancer: I can't profit from it and neither can anyone and those who hack my game must have their hacks subject to GPL. Sopa, sopa, sue-happy sopa... I hate that!
I'm however using SDL for a real and serious game for multiple modern platforms. That's a thing letter A.
But making a retro TV console is a thing letter B. These two can't mix! The thing letter B and the NES development is just because of my minimalistic fascination of how little pixels move with little RAM and embedded hardware. I don't know what's it called. Pixelophilia, maybe?

... It's a fractal of misconceptions and lies based on other misconceptions and lies. Nifty, albeit sad.

1- GPL(2, anyway, which is the only relevant version) says ONLY that the recipient must be allowed the source if they have the binary.
2- libSDL isn't licensed under the GPL, and there are literally thousands of commercial games released using the libSDL and they do not have to comply with the GPL just because they've been distributed on linux.
3- Because libSDL isn't GPL, the GPL-ness or not of linux is completely irrelevant.

But that's not the argument I'm trying to make, so fine. Replace "linux" with your choice of "NetBSD", "Windows", "QNX", or whatever. The point is, libSDL provides the same interface as the hardware.

My point is only that if you use a framebuffer, and if you use someone else's abstractions, you're not making a retro TV console, you're just making an SDL program for specific hardware.

Use a Genesis or a SNES. Better than keep chasing for something that doesn't exist.

There might be something a little bit easier to program. I find the SNES PPU a sloppy mess.

What you would need in a microcontroller to have 8-bit or 16-bit style graphics is something with a DMA scanline buffer, and a fast enough CPU speed to render the tiles and sprites in real time. I'm pretty sure game logic can be done during vblank with something like 30+ Mhz.

Uzebox can't get me 64 sprites like NES and the resolution like NES. It was with an ATMEGA. I'm not sure if a 32MHz XMEGA would be enough fast to render things.

... so use an ARM device (LPC*, STM32*, EFM32*, ATSAM* .....) instead?

Okay, but if it will be 100% dedicated to rendering outside of VBlank, will it be a problem if it doesn't respond to other chips and memories (SD card, MIDI chip, USB)? Is there a dual core processor on a microcontroller with low cost and little specs so I can simply run the rendering on one core and the rest on the other?

There are multicore MCUs but they begin to get costy. The first results are ROMless so you'll need to know how the internal bootloader ("BIOS") works and if it can fit for your purposes. I never fiddled with that kind of multicore device so I can't help further there. As of if it'll cause problem whenever you use a single core for rendering, sound, "disk" and game tasks, it'll depend highly of the performance of the chip you use and proper usage of peripherals at your disposal, especially DMAs. At this point, if you want to know if it's feasible you basically have to try to do it, which I hope you can do at least to some extend because otherwise this entire thread is a waste of time.

Thanks for the link. Links are the answers to my topics. So don't worry, it's not a waste of time