Here's my situation:

As a personal project, I am looking to write a emulator for the Sega Megadrive (Sega Genesis) that runs on AVR. So I have been searching for a Micro-controller that has similar characteristics to the Motorola 68k that shipped with the MegaDrive. However, I have noticed that the specs for the 68k compared to most hobbyist micros. I'm choosing AVR as opposed to ARM because I like the architecture, and thought it would be a good challenge.

32-bit CPU
16-bit data bus
Up to 20 MHz
No I/O ports

Here is the specs for an Arduino Leonardo:

Input Voltage (recommended) 7-12V
Input Voltage (limits)  6-20V
Digital I/O Pins    20
PWM Channels    7
Analog Input Channels   12
DC Current per I/O Pin  40 mA
DC Current for 3.3V Pin 50 mA
Flash Memory    32 KB (ATmega32u4) of which 4 KB used by bootloader
SRAM    2.5 KB (ATmega32u4)
EEPROM  1 KB (ATmega32u4)
Clock Speed 16 MHz
Length  68.6 mm
Width   53.3 mm
Weight  20g

This seems fairly typical for lower end modern micros. I never see the ram get much into the mbs.

Now, I'm sure modern SRAM is not nearly the same as whatever the 68k had, but is it possible for me to get an AVR micro that matches the power of a 68k, am I looking at this problem wrong? Do I need to change my design to accommodate modern micros?

I don't know if some external source of memory will be fast enough.

  • 6
    \$\begingroup\$ According to Wikipedia, the Sega Genesis ran at 7.6 MHz and had only 72KB of RAM, not 16 MB, plus 64KB of additional video memory. \$\endgroup\$
    – tcrosley
    Sep 28 '15 at 23:43
  • 2
    \$\begingroup\$ Use an applications processor or an FPGA. \$\endgroup\$ Sep 29 '15 at 0:19
  • 12
    \$\begingroup\$ Furthermore, you're completely missing the overhead of emulating. Properly emulating a SNES (which uses a ~21 MHz CPU) faithfully requires a 3+ GHz computer (see here). At minimum, to emulate a Megadrive/genesis, which uses a 7.6 MHz and 3.58 MHz CPU, you should expect to require a 100+ MHz host device. \$\endgroup\$ Sep 29 '15 at 3:34
  • 13
    \$\begingroup\$ Frankly, you really should write the emulator first, ideally in portable C. Then look at porting it to ARM, and then look at designing a board for the ARM MCU of your choice, once you have some numbers for required performance. Frankly, I think you do not realize how amazingly involved proper, faithful emulators are. Properly modeling and emulating even simple older consoles is really, really hard, because none of them are entirely digital, they all have lots of analog quirks. \$\endgroup\$ Sep 29 '15 at 3:40
  • 3
    \$\begingroup\$ @ConnorWolf Worth noting: It's essentially impossible to implement dynamic recompilation on AVR, as you can't run code from data memory. (You can store to program memory, but that's slow and eats flash cycles!) \$\endgroup\$
    – user39382
    Sep 29 '15 at 6:55

Even though the Motorola 68000 and the Sega Genesis are quite old (early 1980's), you are not going to find a low-end (i.e. 8-bit) AVR that can emulate the entire game machine.

The Sega Genesis ran at 7.61 MHz and had 72KB of RAM (plus an additional 64KB of video RAM). However the game programs resided in ROM, so you will need additional RAM to hold them (unless you plan on being able to plug in the original cartridges somehow). Most game cartridges were under 4 MB, but there is at least one game (Pier Solar, released in 2010) that has a 8 MB ROM.

In addition, the system certainly must have included a system ROM which acted as some sort of executive and also would have provided a common I/O library for the cartridges (I can't find any reference to how large this was). You are going to have to find the ROM's (or ROM images) for those and copy them into your RAM also (or add a section of ROM to your system).

IMO you are going to want to use a 32-bit microcontroller. If you are going to use the original cartridges plus a program ROM, and don't need MB's of RAM, than you can use most any 32-bit microcontroller that has enough space for your emulator. If you are going to download the cartridges and the system ROM image into RAM, then in order to get 8 MB or more of RAM, you are going to need a microcontroller that has an external memory bus (you can't get 8 MB on the same chip as the microcontroller).

Given that you want to stick with AVR, I suggest a processor like the AT32UC3A3256, which has 256 KB of Flash, 128 KB of RAM, and runs at 84 MHz. The gotcha is that it is a 144 pin surface mount device, which is going to be difficult to solder.

However, there is an evaluation kit for this processor from Element 14 for only $31.25. So you don't have to worry about soldering. Plus, the board has 8 MB of external RAM, so you can load a cartridge into RAM.

enter image description here

Just for the record, I still think you should consider the Raspberry Pi, running at 700 MHz with 512 MB of RAM for slightly less than the cost of development board above. Running at that speed, you would have no issues with emulating the 68000 code and performing I/O at the correct speed.

Whether you go the AVR or Raspberry Pi route, in addition to the 68000 the Sega Genesis also included a Zilog Z80 and several special purpose chips, including the Yamaha YM2612 and Texas Instruments SN76489A. The Z80 was used to control the sound and also provide backwards compatibility with the earlier Sega Master System. The Yamaha chip was an FM sound synthesizer and the TI chip was a Programmable Sound Generator (this machine had a lot of sound options). There was also a Virtual Display Processor (VDP). You can probably skip the sound (which means you don't need to worry about the Z80 or the Yamaha or TI chips) but you will have to emulate the graphics hardware.

A couple of resources:

EASy68K -- Editor/Assembler/Simulator for the 68000. Open source so you should be able to dig out the 68K simulation code

Cyclone 68000 -- emulator for the 68000 microprocessor, written in ARM 32-bit assembly. Only useful if you decide to use the Raspberry Pi

Finally, if you aren't already familiar with the 68000 instruction set, plan on spending weeks (or more) to become an expert. A lot of your debugging will be down at the emulator level, trying to figure out why a section of 68000 code in the game cartridge isn't executing properly. (Which means you probably will want to be able to set up a virtual breakpoint facility in the cartridge code.) You'll also need a disassembler, so you won't have to deal with machine code; here's the source for one.

  • 1
    \$\begingroup\$ I'd considered that but I do want to restrict myself to avr. \$\endgroup\$
    – baordog
    Sep 28 '15 at 23:37
  • 1
    \$\begingroup\$ @baordog I have updated my answer with two suggested AVR chips. \$\endgroup\$
    – tcrosley
    Sep 29 '15 at 0:01
  • 4
    \$\begingroup\$ Note that the two processors you mentioned are both AVR32 parts. These are almost completely different from the AVR architecture parts the OP is familiar with, beyond that they're both made by Atmel. \$\endgroup\$
    – user39382
    Sep 29 '15 at 0:21
  • 2
    \$\begingroup\$ @duskwuff He's not going to be able to get by with anything less powerful than these, and AVR processors are made by Atmel. \$\endgroup\$
    – tcrosley
    Sep 29 '15 at 0:28
  • 3
    \$\begingroup\$ @baordog Modified my answer again -- I found a development board with a 32-bit AVR which includes 8 MB of external RAM for $31. \$\endgroup\$
    – tcrosley
    Sep 29 '15 at 0:29

Not going to happen.

The largest microcontroller in the ATmega line with support for external memory is the ATmega1284, but this only which has 8 KB of internal SRAM, and can address up to 64 KB of external memory. This isn't going to be sufficient to emulate the Genesis, which had 72 KB of RAM and another 64 KB of video memory. It might be possible to implement access to additional memory through bank-switching, but this would make accessing memory from the AVR very costly.

There are some parts in the ATmega line with more internal SRAM, like the ATmega1284 (16 KB), but these don't support external memory at all. Long story, short, addressing over 64 KB of RAM from an ATmega is rather difficult.

(I'm not sure where you got the figure of 16 MB from. The 68000 doesn't have any internal memory at all, besides registers; the amount of memory on a 68000 system can vary dramatically.)

Additionally, the 68000 CPU in the Genesis runs at 7.6 MHz. Emulating this on a 16 MHz AVR is not going to be possible -- while the AVR's clock rate is admittedly a bit higher, the 68000 is a 32-bit CPU, so emulating one of its instructions will frequently require much more than one instruction on the AVR. (Even a simple addition will likely require a few dozen instructions.)

If you'd like to emulate the Genesis, I'd recommend you look instead at ARM microcontrollers.

  • \$\begingroup\$ A couple of minor nitpicks:- the 68000 takes at least 4 clocks to do anything (and most instructions take 8 clocks or more) so an AVR running at 16MHz is ~9 times faster (Still not fast enough to emulate a 7.16MHz 68000 in real time though). Also the biggest ATmega is the 1284 - which has 16k RAM, 128K ROM, and runs at 20MHz. \$\endgroup\$ Sep 29 '15 at 1:06
  • 2
    \$\begingroup\$ @BruceAbbott As noted in my answer, the AVR can only operate on one 8-bit register (or sometimes a pair) at once, which blows up the instruction count pretty severely - not to mention instruction load, decode, etc. The ATmega1284 has slightly more SRAM, but doesn't support external memory, so it's no use here. Updated my answer to reflect this criterion. \$\endgroup\$
    – user39382
    Sep 29 '15 at 2:35
  • \$\begingroup\$ Would a Parallax micro-controller be able to pull such task? It is 32-bit, may have a bit more RAM and they are much faster! They are fairly ok for VGA output as well. \$\endgroup\$ Sep 29 '15 at 7:34
  • \$\begingroup\$ @IsmaelMiguel No. Still nowhere near enough RAM (32 KB, and code eats into that), and the weird Propeller architecture isn't well suited for emulation. \$\endgroup\$
    – user39382
    Sep 29 '15 at 8:30
  • \$\begingroup\$ @duskwuff That makes sense. It would be interesting to see something powerful running on it. What about using a Propeller for output and output AND an Arduino for processing? \$\endgroup\$ Sep 29 '15 at 8:39

Is there a Microcontroller with 16MB of Ram?

Yes. The only one I'm aware of, though, is in the Renesas SuperH family, and doesn't include ROM - so you have to have external flash, but it has 16MBytes of onboard SRAM.

I am looking to write a emulator for the Sega Megadrive (Sega Genesis) that runs on AVR.

There are no 16MByte SRAM microcontrolers in the Atmel AVR family. Or anywhere in the Atmel product line.

However, several devices in the Atmel AVR lineup have External Bus Interface which will allow you to connect additional memory. Specifically, the ATxmega128A1U can support up to 16MBytes of external SRAM.

So I have been searching for a Micro-controller that has similar characteristics to the Motorola 68k that shipped with the MegaDrive.


I'm sure modern SRAM is not nearly the same as whatever the 68k had, but is it possible for me to get an AVR micro that matches the power of a 68k, am I looking at this problem wrong? Do I need to change my design to accommodate modern micros?

I don't know if some external source of memory will be fast enough.

Ah, here's the problem you're having.

The 68k processor (ie, Motorola 68000) is NOT a microcontroller and does NOT have 16MBytes of internal SRAM.

While the processor is 32 bits internally, due to pin limitations it can only address up to 16MBytes of external memory, including flash, sram, and any memory mapped devices.

You don't need a microcontroller with 16MBytes of internal SRAM to emulate the 68k processor.

Is there an Atmel AVR 8-bit microcontroller that can emulate the Motorolla 68000 processor?

I think so. The ATxmega128A1U has an external memory bus as big as the 68k processor's bus, and has plenty of flash and RAM that would allow it to run a microcode version of the 68k processor.

It can run up to 32MHz, and many instructions take one cycle, but even the worst case takes 5 cycles in the internal memory. The external interface is slower, but if you choose fast memory it will still be a lot faster than the 68k.

The 68k processor not only runs 4 times slower, but the fastest operations it has takes at least 4 clock cycles, and many take 2-4 times longer, particularly memory accesses.

So with even slow (by today's standards) SRAM (say, a 70nS 8MByte part for under $10) you can use 0 wait states on the 32MHz processor and run circles around the 68k running at 7MHz. For instance, a simple move instruction on the 68k that would take 4 cycles at 7.61 MHz takes 525 nS. A similar simple move instruction on the ATxmega128A1U running at 32MHz takes 31nS. So the AVR could execute 16 moves by the time the 68K was done with one. The 68k takes 50 cycles for some interrupt types, while the AVR jumps to the interrupt in 3 cycles - so the AVR could handle a handful of interrupts in the time it takes the 68k to simply jump into one.

I expect you could run it cycle accurate with careful effort if you accept some jitter, though you might be able to get it to run perfectly cycle accurate with no jitter if you were meticulous. The AVR processors run fine with moderate overclocking, so you could probably run it at 38.35MHz and have 5 AVR cycles per 68k clock cycle.

This is not to say it would be easy, and there may be a few very tricky instructions that would take longer on the AVR than otherwise - but even these can be accounted for with careful design.

Can I emulate a Sega Genesis with an Atmel 8 bit AVR?

No. The Sega Genesis has, at its heart, a 68k processor, but it also has a sound processor (Z80) and a video processor that you would need significantly more resources to emulate. In the diagram below, you'll find the 68k processor in the upper left - note that it's one small portion of everything needed to emulate a full Sega Genesis system.

enter image description here

So while you could readily emulate the 68k core of the Sega Genesis, you wouldn't be able to run games made for the Genesis with just the one AVR microcontroller. Emulating the 68k alone on one chip would be hard enough- even if you simplified things I doubt you could fit all three processors into a single 32MHz AVR chip.

However, you could probably emulate those two chips with two more AVRs. If you targeted a simpler graphic LCD that didn't require weird NTSC timings and generation, you might be able to simplify things a little bit, and perhaps could even put both functions onto one separate chip.

This is a huge project, though, certainly not a weekend project. If you are at the stage where you are only comfortable with Arduino development boards, then it might be interesting to create a simple 68k processor emulator and connect a little external ROM and RAM for memory accesses. The Arduino ATMega doesn't have an external memory interface, but you can twiddle I/O lines and emulate that as well. If you get far enough along in the project to where you can emulate simple 68k programs, then it might be worth ditching arduino, using the Atmel development environment, and a better AVR chip with an external bus interface, and you can start reading and executing cartridges. You might even be able to pipe video and sound data to the computer and interpret them in processing - it'll still be too slow (the Arduino Mega is only 16MHz) but it'll at least give you a good idea of the amount of work you'd have to do to have full speed emulation, and you can start tinkering with how much effort it would be to emulate the VDP and sound processors.

Make sure your emulation routines are portable and you'll be able to switch to a better processor easily enough that you won't be stuck.

If the simple Arduino Mega project never gets very far, you haven't wasted many resources on this project. If you find yourself driven to completing it, moving to a more capable Atmel chip will not be so overwhelming.

I say give it a try. Some of what I've said and others have said may seem like this is insurmountable, but don't let us get in your way. Keep asking questions each time you run into an obstacle and you'll find that most engineers enjoy a challenge and will give you the understanding and help you need to go far down this path.

Emulation is a lot of fun.

  • \$\begingroup\$ Do you think it would be easier to emulate the video / sound processors with fpga? \$\endgroup\$
    – baordog
    Sep 29 '15 at 14:55
  • \$\begingroup\$ I think the challenges writing the emulator will be dealing with 68000 instructions like: ADD.L (A0)+,D3. Now the ATxmega128A1U has a similar addressing format using the X, Y, or Z registers. Those of course are 16-bit, but supposedly the Sega only used 72 KB of RAM, so that might work, depending on what those extra 8 KB are used for. A problem occurs because the AVR has three address registers, and the 68000 has eight. All of a sudden the emulated register A0 is not loaded into X, Y or Z. So things have to be shuffled around. One address register will probably need to be dedicated to a SP. \$\endgroup\$
    – tcrosley
    Sep 29 '15 at 15:35
  • \$\begingroup\$ The FPGA approach has been done successfully: code.google.com/p/fpgagen \$\endgroup\$
    – pjc50
    Sep 29 '15 at 15:39
  • \$\begingroup\$ @baordog I don't know. The sound processor is a Z80 processor. I haven't looked at the video processor. You should do some more research to find out what's involved - the video processor has its own memory, but it also generated complex PAL or NTSC signals. If you were to integrate a graphical LCD display you may find that a lot of the complexity of the video processor goes away - but again I'm not sure how complex it is. I'm certain you can do it in an FPGA, but you might not need to if you prefer microcontrollers. \$\endgroup\$
    – Adam Davis
    Sep 29 '15 at 15:45
  • 1
    \$\begingroup\$ @davidcary found it on Digikey but don't see it on the Renesas website either. R8J73540BGZV - digikey.com/product-search/… \$\endgroup\$
    – Adam Davis
    Sep 29 '15 at 23:26

None of the other answers have mentioned that you could just get a chip which runs the m86k instruction set natively: the Coldfire series. A number of instructions have been removed; if they aren't too frequently used they could be emulated by trapping the "invalid instruction" interrupt.

However, you'd still need to emulate the Yamaha YM7101 video processor and Yamaha YM2612 sound processor. You could either try to build software emulations in a much faster DSP, or build an FPGA version of them. Possibly based on existing FPGA emulations of the Megadrive.


Is there a Microcontroller with 16MB of Ram?

I'm pretty sure there are no processors with 16 MB of on-chip RAM.

The "16 MB RAM" mentioned in some descriptions of the 68000 allude to the 24-bit external address bus that could, in theory, address a maximum of up to 2^24 bytes = 16 MB of external RAM. My understanding is that the vast majority of systems that use the 68000 connect far less than 16 MB of external RAM.

In particular, the Sega Mega Drive (aka the Sega Genesis) has 72kB of RAM and 64 kB of video RAM. That is external RAM. Neither its Motorola 68000 nor its Zilog Z80 have any on-chip RAM or cache.

I suggest you create a second, independent question with a title that describes what you really want to know, but leave this question as a canonical question about microcontroller RAM to help the many, many people who are mislead by "16 MB RAM" meaning theoretical maximum external DRAM in some processors, while "2.5 KB RAM" meaning actual physical on-chip SRAM included in other processors.

(*) A few very high-end processors produced after 2006 have 16 MB or more of on-chip cache memory, but those processors require even more external RAM -- so if you really need 16 MB of RAM, you're going to need 16 MB of external RAM one way or another.


You can USE a CORTEX -M4 from STMF432 board... very powerfull with lots of megs of RAM and peripherals

enter image description here

  • \$\begingroup\$ Since when 256 KB of RAM is "lots of megs of ram" ? \$\endgroup\$ Oct 28 '15 at 23:37
  • \$\begingroup\$ And in any case, the OP was pretty specific that they wanted to use an AVR microcontroller, not ARM. \$\endgroup\$
    – user39382
    Oct 29 '15 at 3:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.