I'm putting CHIP-8 forward.

This system is essentially a virtual machine developed for some reason. There are games written for the CHIP-8. It has a few opcodes, a stack, a couple of timers, and a low resolution bitmapped display, but it's simple enough that the first few emulators fit in a few kilobytes on early 8-bit computers.

There are more than a few reference implementations you could use.

There are games and so on which are in the public domain already, like here so that you needn't provide your own games.

There are some good ideas so far.

But something to consider.

If you do something like a CP/M machine, they're really quite basic and simple, especially since everything is isolated by not just the BIOS, but also the IN/OUT nature of the 8080/Z80 family.

It does not seem untoward to me to have a CP/M machine be the goal of the first semester. (I don't know your syllabus)

But, for example, a basic CP/M machine doesn't need cycle accuracy, it doesn't need interrupts, the most complicated thing it has to do is poll the keyboard to see if a key has been pressed. (In contrast to monitoring keydown and keyup or anything else.)

Then, in the second semester, you can add the requirements such as interfacing to a graphics chip. The instance above of the SG-1000 could easily be a CP/M machine in the first semester, and then readily transformed in to the SG-1000 in the second (since you've got the Z80 part all done in the first semester).

Finally, I think it behooves your class to have an acceptance program that students can run to verify their CPU. Few things more exciting than debugging a bad CPU, especially with machine language you may not be familiar with.

The 6502 community has test programs that can check that a CPU executes all of the instructions properly, I'm not sure what's available to the other CPUs.

And if it's any consolation to scope, I wrote both a simulator and an associated assembler off and on over a 2 week Christmas holiday, if that gives you any help on how big the actual projects are. Basic CPUs are pretty simple.

Oh. Nice question. I'll try to give a few hints, but I would consider the issue way to broad to be answered here instead of a more meaningful conversation. Nonetheless:

[...]tasking the students with creating an emulator for an older system

Quite cool.

from scratch,

If this is supposed to be really from scratch and in software, it would not really consider it a task fit for freshmen in such a limited time. Unless there's a way to take out real time requirements (which are even more relevant to games), I would rather be careful.

In fact, since it's about EE, why not do real hardware? It's still easy to get (some) classic CPUs and related devices. Combined with like a modern LCD the hardware effort is quite doable in a few weeks in great detail.

as a group project to be completed until the end of the class (which is, as pointed out, 2 semesters long).

Which might be the most tight condition.

I'm trying to choose a good target system for this project, with the main goal being that it should be fairly simple to emulate. The less peripherals to be emulated, the better. The less quirks and bugs that need to be replicated, also the better.

Sounds like a good attempt. And more important it removes some seemingly simple systems (like singleboarders) from the list, as they rely on complex handling of I/O devices (like real time access to ports to drive LED segments in seemingly continuous way).

I'm looking to expose the students to the important concepts of assembly language, instruction encoding, addressing modes, CPU registers, memory-mapped hardware registers, etc.,

Something that can be done with a real hardware as well as an emulation, isn't it?

Ideally the system in question shouldn't require cycle-accurate emulation or tricks like chasing the scanline.

Together with the implied requirement for a video output, this calls for a simple non accelerated bitmap logic.

A second requirement pertains to performance. The students certainly aren't familiar with software optimization techniques, so trying to emulate even the first Playstation or the Nintendo 64 will probably run into performance issues (perhaps even the SNES and Genesis).

I wouldn't fear much here, as actual PC hardware is quite fast. The real issues here are not speed of emulation, but real time aspects - synchronizing various emulation parts - which require a very careful and fine tuned software design. Not to be expected here. Quite the 'racing the beam' part you mentioned.

At this point the students only need to be worried with implementing the emulator correctly, not efficiently. CPU emulation will certainly be implemented by an interpreter, not a translator/recompiler.

Still, even for the most primitive ones, real time synchronisation is necessary to play a game. At least a screen retrace synchronisation is a must - not at least to speed toggle the simulation itself.

The inherent need of games to use timing effects - and synchronized screen manipulation on a finer level than frames - is something that will make running any real world game on the proposed emulator a challenge.

I'd like to choose a system for which games were made, even if said system wasn't a dedicated video game console. I feel that being able to run games on the emulator would be very motivational for the students.

I wholeheartedly agree here. Much of the success of Andre LaMothe's experiment and learning systems is based on the foremost ability to do games.

For instance, right now I'm looking at the NES, but it still feels a little bit complicated, especially the PPU. Are there simpler options?

It gets hard as the basic requirements are contradicting each other. Only successful consoles/computers got a large selection of games, but these are also such having a more complex hardware structure allowing great games.

Let's check some well known systems. I would like to separate them in 'simple' and 'complex' systems along the complexity of their video logic (*1)

Simple Systems

In first iteration these are all systems without a dedicated VDC/CRTC.

• 
  

  Atari VCS - eventually the ultimate system to be used to learn assembler, work on an extreme basic level with no in-between and not much to take care of. At the same time it's the namesake for the 'racing the beam' term.

  
  
  

  Having said that, it may still be a system to look for, as the timing dependant parts are well defined and (compared to any other video) extreme simple and easy to emulate - except it's not freshmen stuff. Also, it's extremely well documented on general available sources.

  
  


• 
  

  Commodore PET - A rather simple system, especially since the whole video part can be emulated quite abstract, still the VIAs need to be, at least in part, emulated. Most important it contains only two timing sources (beside clock).

  
  
  

  A great plus for the PET (and follow ups) is the good documentation (also due its simplicity). Also, while it features a CRTC, almost no game (or other software) made use of reprogramming it at all, making a way simple and an incomplete (abstract) emulation possible.

  
  
  

  On the backside, there is only a rather small number of games and most of them are written in BASIC, which may require some research to find the amount of abstraction vs. detail in emulation.

  
  


• 
  

  Apple II - Again, an incredible well documented system with lots of software. Much of it Assembly based. While the Hardware is fully documented and build from only TTL, it's workings aren't really simple and since some games heavily rely on quirks and counting loops for exact timing, emulation may get way more complicated then assumed at first sight.

  
  
  

  A plus for you might be that the Apple II was quite popular in Brazil (well back then).

  
  



• TRS-80 - Here as well the video logic is build up from TTL but way more simple than on the Apple. Similar other I/O is quite simple. On the negative side is again a rather small number of games.

So far the real ancients, but also some later systems can be classified as simple:

• 
  

  Sinclair Spectrum - While the logic does offer a few tricks, bells & whistles, it is a straight forward tiled bitmap design. So far, chances are good for an emulation, except , as usual, games did rely very much on timing, something complicating emulation again.

  
  
  

  As well as with the Apple II, there where quite some clones in Brazil.

  
  



• A similar case can be made for the ORIC family




• Atari ST - It may be a surprise from todays point of view, but the Atari ST did not feature any sophisticated video hardware. Merely 3 graphics resolutions and a 9 bit CLUT for up to 16 concurrent colours. A few synchronisation points and a single timer. Plus a more modern CPU and a dedicated sound chip. Sounds like a match made in heaven, if, well if it wouldn't be for the programmers of games again. Here as well, software did imply a whole plethora of tricks to create awesome games (*2).

A first conclusion for 'simple' systems is, that while the hardware may be less complex, software did go a great length to overcome this. In consequence it may be said that less complex systems don't necessary make an emulation less complex, as not more different hardware is to be emulated, but the simple hardware needs to be followed very close timing wise to make existing game code run.

Complex Systems

These are in general all systems with a sophisticated VDC

• 
  

  9918 ff. - This isn't so much about a single system, but eventually the most common used VDC (TI called it VDP). While conceived for the TI 99/4, TI did sell it to anyone who was interested. It resulted in the majority of all systems (*3) using a 9918 or one of its follow up designs (9928/38/58/...).

  
  
  

  Game consoles like Coleco Vision, Sega SG-1000 all the way to the Master System a well as computers from TI 99/4 or Memotech MTX all the way to the whole world of MSX machines did use this family.

  
  
  

  Sounds great, doesn't it? Well, for sure there is a lot of games to be used. Further, such a VDP does help to simplify emulation as it offers a clear separation between CPU and display and limits what 'tricks' a game can use to what the VDP offers, which in turn is clearly defined. And again, it's the existing software that makes emulation hard, as, again of course, programmers did use timing tricks to manipulate the screen at the right time. Did anyone mention 'Racing the Beam'?

  
  



• Commodore VC20, C64, C16, etc. - The same is true for all of Commodores home computers. While they differ in complexity by having sprites or not, offering timers or not and sound or not, the basic issue is the same as with the 9918 family: Software using certain timing situations to create game effects.




• 6847 Systems - Tandy CoCo, Matra Alice and alike feature the same issue.

I could go on with game systems like NES or MegaDrive, but I'll end that list here, as the principle should be clear by now: While some systems may seam like more complex to be emulated, the real issue is not the complexity of video hardware, but whenever a programmer 'improves' what can be done by clever programming (*4). So the real issue for your project isn't (so much) the hardware (*5), as it's the software, especially the tricks and tools used in real existing games.

That's especially bad, as you want to use (as I read it) existing games as motivation. There won't be many running on a less hard real time emulation.

Reducing this dependance will reduce the number of games that run correct. Reducing it to a level that allows it to be handled in a time constrained course, will make it almost impossible to find suitable games.

Conclusion: Finding the right tradeoff is a way, but one that will take considerable research while still limiting the usability.

Now, maybe it's possible to attack this from a slightly different angle. Lets try some:

• 
  

  Use of existing old hardware:

  
  
  

  While this is proven (*6) to work, offers highest compatibility and ease of use due open development environments, it may miss the 'build' appeal for EE students.

  
  


• 
  

  Use existing educational games systems:

  
  
  

  Systems like Andre LaMothe's XGS are great tools to dive into detailed hardware build and programming. Sure, some soldering required (there are ready build available), they are almost complete software defined systems, throughout documented and offer a huge library of Games. Not to mention his books about game programming.

  
  
  

  A great bonus is that students may be able to take the system home and play even after the course has ended.

  
  


• 
  

  Build your own simple system:

  
  
  

  Take a classic CPU (6502 for example), some RAM, FLASH and a VIA plus an FPGA to implement a very basic CRTC and done. Students will solder it, can learn about the components and their interaction, including FPGA usage (which might be a must anyway today) and then run their software on real hardware. Even with small numbers it should be possible to produce such a board around 50 Euro or less. Like the XGS idea it'll work after the course has ended - including the feeling of ownership as being their system.

  
  
  

  Of course students will have to write their own games, but simple games can be done in a rather short time - not to mention that follow up courses may as well use games the prior class did write.

  
  


• 
  

  Do an emulation of 'your own' system

  
  
  

  Much like before, except everything is virtual. It got the advantage of being a well defined and closes system, especially one where there are no limitations of due a less 'perfect' emulation - the Emulation is perfect by definition and all its quirks are the one the system has. Disadvantage is again the Software part.

  
  


• 
  

  Use 'soft' hardware:

  
  
  

  There is a project by Neil Franklin creating a number of generalized system components much like classic computers had, but using micro controllers instead of dedicated chips. It combines emulation with real hardware. While components are still developed as emulation, these are meant to run in a micro controller and be used much like 'real' chips. One system might be set up by using a SoftCPU module emulating for example a 6502 with some RAM and ROM, combined with a SoftVGA delivering a terminal like video interface and a SoftPS2 emulating Keyboard and Mouse. All are connected via a parallel or serial (SPI) bus allowing the addition of other components that can be presented to the emulation as well.

  
  
  

  Beside being all about emulation, it does feature a limited amount of hardware that can be done on a breadboard (Still, it's never to early to start soldering), it also shows a quite typical task of todays engineering — replacing traditional logic by micro controllers - in practical use.

  
  
  

  The result is a system offering the touch and feel of a real (old) computer while being build with modern hardware running parallel emulations.

  
  


• 
  

  Use of a configurable emulator:

  
  
  

  No, this is not about MAME or alike, but an emulator framework written in JavaScript, that handles the generic parts (including timing), where your students will add their emulations (which was a goal, wasn't it?) to form a whole system. Since JS is delivered in source, even the Framework itself can be modified.

  
  
  

  Depending on the quality of each emulation, this may be usable for anything from a simple demonstration system up to a full figured recreation of a 1980s computer.

  
  

So, maybe some of the above variations may be a good start?

*1 - I will focus only on video (and CPU) to keep it simple. Also video alone will already work well to weed out to complete systems. Sound will add another dimension and may complicate it way beyond the scope of this.

*2 - Just take a look at Xenon. A groundbreaking vertical scroller with multiple shifting layers many animated objects, all running super smooth in software. In fact, it was so fine tuned, that porting it to the (usually) more capable Amiga (graphics wise) took quite some time and resulted in a somewhat lesser game.

*3 - Systems designed not necessary units sold. Then again, some game consoles where more than just successful, so it may even get the majority in numbers.

*4 - The blogposts of the main developer of the Glide64 renderer plugin for N64 emulators has written a multi part series (Intro, P.1, P.2, P.3) of blogposts about the hurdles he had to climb to make the video emulation part work - all of them not about the complexity of emulating the hardware, but all due ways the CPU did modify and tweak the output beside the video logic. This is even more remarkable considering the N64 is already a rather absract and closed system.

*5 - In fact, I would consider more complex video hardware as a great lesson for EE students, as it well shows what can be done with a few gate instead of piles of software - even more so as they are about to do hardware later on, isn't it?

*6 - Stefan Höltgen at FU Berlin for example uses old game systems in his classes to introduce (non-EE) students to real hardware and real programming and their implication for every day tasks (and games).

Can I suggest the SG-1000?

The system is little more than a grouping of three off the shelf chips - the Z80, the TMS9928A for graphics and the SN76489 for sound, with the controllers as dumb groups of NO (normally open) switches.

In software or hardware you could simulate or emulate any part of this in isolation or all together to produce the complete system.

The system uses simple non bankswitched ROMs for its games, and they usually don't rely on any tricks such as mid screen interrupts or cycle counting to produce their effects. Just a single tile map and a number of sprites on top. I suggest that this is much more straightforward than a system containing many interacting internal components and intelligent cartridges like the NES.

You ought to provide your own games to emulate rather than distributing unlicensed copyrighted material of course.

Based on your criteria, and the need to keep the project interesting for your students, I'd recommend seriously considering the Vectrex Arcade System, which was sold by Milton Bradley in the early 1980s.

Because the Vectrex is unique in using a vector display, rather than a raster display, it does not require any complicated video hardware to be emulated. The display is managed by the CPU, and the display itself is simple to emulate on a modern system and with good performance.

Besides emulating the vector display, the CPU (Motorola 6809), and the I/O chip (MOS 6522), don't represent too much of a challenge as they are simple 8-bit parts that are very well documented.

The memory model is also very simple with no banking schemes that I'm aware of. There is a common PSG sound chip in the Vectrex, but emulating it could be considered as "Extra Credit".

Unlike other simple game consoles of the early 1980s, the Vectrex games have held up rather well, given its ability to render smooth monochrome graphics including 3D wire-frame. This is farther evidenced by the popularity of the modern "home brew" development, in which developers continue to create new Vectrex games.

One final advantage for the Vectrex is that the original system ROM is freely distributable.

Are you looking for a system that has not been emulated much? I suggest to stay within 8-bit computers (or early simple 16/32 bit ones), ZX Spectrum 48k is such a relatively simple system - very well documented, no sprites, no audio chip, no RAM banks, simple I/O, simple graphics (though with a weird layout), no cycle perfect emulation required, well known CPU, easy cassette handling (could be made even easier by ROM traps). There is tons of games, many of them with permissive licensing.

The disadvantage: there is an enormous amount of available emulators, many themselves the retro category, and many with source code available, so the danger of cheating and copying other code is high.

And of course, working on an emulator of a previously not emulated system would provide additional benefit of the feeling of accomplishment.

A simple, straightforward computer like the ZX Spectrum sounds reasonable - But there are simply too many good emulators around already to make this a useful option. I also think the 6502 is more easy to emulate.

So, a possible option could be the Oric-1 or Atmos by Tangerine systems, that used a 6502, non-banked memory, no custom chips except simple video, and a relatively straightforward frame buffer. It is also by far not as well-known as the Spectrum, still, there is software (games) available to bring along some simple compatibility tests (I think, some "sense of achievement" is extremely important for students). There are a number of emulators already available for the Atmos (three, to my knowledge), but their number is limited, which makes it easy to find out if someone cheated and simply copied code.

None of the Oric games were so sophisticated to my knowledge that you would need a 100% cycle-exact emulation to run the games,

Creating an Emulator from scratch is relatively huge task especially for inexperienced students and might prove problematic. So you really have to be careful about what platform to emulate and what info to share/use. For me the best choice is a ZX 48K platform as I was growing on it and am familiar with its inner workings so the answer will be biased by that... But we must take in mind that nowadays students usually did not see/use/know it as much as we do... What you need to achieve is:

1. 
   

   correct CPU iset emulation

   
   
   

   even if there are tons of instruction sets docs out there You have to be careful as for example on Z80 the 99.99% of them are containing mistakes. So you should chose some tested reference iset for them you now its correct (or at least basicaly functional).

   
   
   

   For example here is mine Z80 iset passing ZEXAL with 100% success:

   
   
   
   
   
   • my Zilog Z80A complete instruction set with machine cycle timing
   
   
   
   

   
   Z80 platform has one major advantage and that is there are extensive testers for it like ZEXALL Exerciser which can help debug the emulator a lot.

   
   
   

   I think there where also versions for i8080 but I do not know of any such testers for different CPU family.

   
   


2. 
   

   Timing

   
   
   

   well for basic emulation the clock tics method (or throttling) is enough which is well known and used... I see no problem here. Nowadays computers have relatively good resolution for timing (on PC: RDTSC, on Windows PerformanceCounter, ...).

   
   
   

   The basic emulator can ignore the CONTENTION of the emulated platform but beware some OS/games/apps could be rendered unusable if not emulated properly. This goes not just for demos. The usual timing on old computers was derived from some interrupt (usually video refresh) and limited number of cycles where able to execute before it. But with contention the number of instructions executed for the same time can be very different and some programs might overflow and damage them self or freeze. The CONTENTION is the hardest thing to implement with clock tics so You should avoid it at all costs... On the other hand with MC level timings its really easy and just a few lines of code.

   
   


3. 
   

   Sound

   
   
   

   this is platform dependent problem and you should chose the API used for sound input/output correctly. For example on windows the only usable option is WAvEIN/WAVEOUT due to low latency and easy usage. DirectX is unusable (at least was at time I was trying to use it for such task) due HIGH latencies and not working callbacks.

   
   
   

   I would used buffered approach instead of direct speaker driving so your emulation can be bursting the execution time instead of MC level correct execution (which I do anyway but I doubt students would be able to do it in the time at hand).

   
   


4. 
   

   Video

   
   
   

   This one is also platform dependent ... and you should use API your students are familiar with. Even beam tracing is relatively easy to implement with simple bitmap ... On computers like ZX the Scanline order has special meaning and can be very distracting for newbie coders so its better to use translation LUT tables converting between address and y coordinate back and forward.

   
   
   

   Most older platforms used 50Hz/60Hz refresh rate and relatively small resolution so nowadays computers even with not well optimized emulation should still be fast enough for it. If not Skipping frames is an option too...

   
   


5. 
   

   other HW and peripherials

   
   
   

   The absolute minimum is RAM/ROM memory and keyboard. Memory is usually very easy just static array and or some page switching stuff... The keyboard can be emulated by setting I/O according to keys pressed. The I/O can be also memory mapped to some array just like memory. Trapping ISR routine is also an option but that make keyboard unusable for custom key handlers.

   
   
   

   I would not bother with FDC,AY,etc peripherials as the emulator should be kept as simple as posible. But if you're lucky there might be some students that will be way ahead of others with this project. For those you might suggest to implement exciting features like FDC, DMA, even real soundcard sound (for real tapes or any audio players) which enables much nice features for example see:

   
   
   
   
   
   • Z8410 DMA chip as GPU?
   
   
   
   


6. 
   

   Files

   
   
   

   I would go for Z80/SNA file formats at start. Using TAP/TZX is nice but from start the emulator would be quite buggy hence loading routines may not work properly making using and debugging very hard.

   
   


7. 
   

   ROM

   
   
   

   this is the most problematic part as many platform ROMs are still not free and by extracting/downloading/using them for emulation you might risk legal issues.

   
   
   

   From some comments here it looks like ZX ROMs are public domain now... and there are also Commented ROM prints out there making it much easier to debug the first steps of the emulator (when nothing yet works).

   
   
   

   But you should always consider Emulation and legal stuff especially if the emulators will be placed somewhere on the internet

   
   

Here some related QA links of mine:

• How to obtain CPU and other hardware specs for emulator development


• 
  Writing a graphical Z80 emulator in C or C++ I strongly recommend to read this one (especialy for your students) will save them a lot of time and nerves


• What's the proper implementation for hardware emulation?

May I suggest taking a look at some early arcade games? Specifically these two 8080/Z80 platforms:

• Midway 8080 - Developed in 1975 and powers Space Invaders. Uses a 256x224x1 bit black-and-white frame buffer in RAM.




• VIC Dual - Sega/Gremlin's platform designed in 1977 -- the best known game is Carnival. The video is a 32x28 array of 8x8 characters (all in RAM) and can support a simple color palette, mapped to a PROM.

These are very simple to emulate once you get the Z80 emulation working. There are no funny scanline tricks or weird CPU wait states. Player controls are available via bitmapped I/O ports.

You can play with these platforms interactively on http://8bitworkshop.com/ (Full disclosure: I run this site and am the author of the books linked on the site which describe these platforms)

The Apple ][ is also a good choice for a 6502-based platform, although the video subsystem is more complicated than in the two arcade platforms.

PET or TRS80 might work well. Simple hardware with text on screen so they could be emulated with straight text ouput initially adding code for their odd character sets later and unlikely to contain much in the way of exact cycle counting code.

Bonus idea after if you go for a PET adding C64 support would give graphics.

The 6502 is probably simpler to emulate.

Final thought might be the Ohio Scientific Superboard II or in it's UK incarnation the UK101 as I don't think it has reprogrammable video hardware.

The Digital PDP-8 is a very simple architecture that can be easy to write an emulator for. Some reasons for this include:

• Only 8 basic instructions


• No video interface etc. to emulate, only terminal I/O


• No need for cycle accuracy, the actual series of machines themselves didn't guarantee the same behaviour across the different implementations


• Can start with a simple setup (e.g. a 4Kword machine running FOCAL-69), and gradually make the emulator more complex (e.g. a 32Kword machine with extended arithmetic, running OS/8 from an RK05 disk)


• Lots of manuals available online


• The MAINDEC diagnostics and their instructions are available online, which can be used to test that the emulation is working correctly

This might not cover all your requirements, e.g. memory-mapped I/O, but it certainly includes things like instruction decoding and addressing modes. Much of the documentation goes right down to the basic hardware level which might be appropriate for an EE course.

The ZX Spectrum option has beed already told: its strength is the utterly simplistic IO hardware and the fact that many existing games do NOT require precise, cycle-correct emulation of all the quirks with the only exception of sound (no anything near to correct sound without cycle-exact emulation of the CPU and correct downsampling of the intermediate 1-bit sound stream produced by the CPU).

Any other option of gaming hardware like NES, Genesis and all the similar sprite-based machines is not an option, obviously, as lots of time needed to learn the complex hardware, develop ways to emulate it, work around deficiences in the emulation etc. For example, even "simple" Super Mario game on NES won't work unless sprite collision bit in PPU is correctly emulated.

The remaining options IMHO are the following:

1. early text-mode based IBM PC


2. any one of the existing CP/M machines


3. (not including any "big" machines before "micro" era)

The key point here is text-mode display, that is not that hard to emulate and much simpler to show on the host machine (even no need to display pixelled graphics, work with windowing system/SDL/etc.!).

However, some investigation is still needed as to collect proper programs to work with, including games. There are some text-mode games in CP/M, and equally should be some for IBM PC.

A system with the least amount of custom chips would probably be a cleaner target to emulate.

An Apple II is one of the simplest systems (no LSI except for the 6502 CPU) for which vast amounts of (easily available) games were written.

There have also been tons of (vintage) books and articles published on the system architecture of the Apple II and the 6502 CPU. Thus the system has been fairly well documented by multiple (cite-able) sources.

Emulators for an Apple II can be on the order of 10K lines of C code, possibly slightly less, which might fit within your course time frame.

Supposing it's any contribution, these are my direct notes on the machines for which I have written emulators, in approximate launch chronological order, hopefully to offer some colour on file formats, etc:

Atari 2600

The distinguishing feature of the Atari 2600 is the synergy between processor and graphics output; games are implemented a real-time function that supplies graphical components to the video output as the raster runs. So I think this is a bad choice for the purpose stated — the real hard work of writing a 2600 emulator is the timing and interplay outside the microprocessor.

Apple II

Relatively simple hardware, but very nuanced, with multiple graphics modes, and you need to edge towards teaching NTSC video to be able to decode its colour output. Emulating the Disk II is also pretty much a must, but that's a bit of a quest in itself as the most common file formats expect you to provide an Apple GCR encoder.

ZX80/81

Also probably overly-complicated for the stated purpose, the central conceit is repurposing the CPU's refresh cycle and a subset of instruction fetches in order to scan video. If you chose not to reimplement that mechanism like the original, you'd end up with only the ROM-default text mode.

Commodore Vic-20

This is a plain bitmapped machine with a simple processor in the 6502 and a decent quantity of games, some of which were supplied on cartridge, absolving you from the need to emulate a tape or disk drive. The only fly in the ointment is its 6522s; these are combination timer/shifter/input/output chips with a whole bunch of quirks. But a neat advantage of the Vic-20 is that it will boot as far as the BASIC prompt without functioning 6522s, and BASIC itself will function with only the timers of the 6522 implemented, even inexactly.

Its short time as the market leader before the arrival of the C64 also limits the number of titles that make advanced use of the hardware — there are contemporaneous examples of raster racing such as the Imagic titles, but they're in the minority.

The file formats that data is preserved in are a mess, but limiting yourself to cartridge support and being careful to use only those titles that were supplied on cartridge should obviate that problem.

ZX Spectrum

Covered elsewhere; I think a good choice. Especially if you stick to the snapshot file formats.

Oric 1/Atmos

Covered elsewhere; a decent choice, but there's another of those pesky 6522s in there. Most games are available on tape, you'll need to support all that.

Acorn Electron

Bitmapped, a 6502 plus relatively simple external logic, but six different graphics modes and timing would be a hassle — the cost of each cycle is a function of the area being accessed (ROM versus RAM), the graphics mode (40-column versus 80-column modes) and possibly the current graphics output state (80-column modes block RAM accesses during the pixel region; 40-column modes don't). But you can just model it as a 1Mhz machine for most games, and mostly get away with a line-centric version of graphics output.

There are a slender number of games available on ROM but luckily the tape hardware will mostly permit a very low-quality emulation: it's of the ilk that raises an interrupt upon byte receipt, with only two titles that I can think of doing deeper introspection than that.

Amstrad CPC

Probably one to avoid for the stated purpose — it has a 6845 CRTC, which makes for very configurable graphics output and therefore lots of titles that race the raster. Disk usage was also fairly pervasive, but its 8272 disk controller is a whole additional level of headaches compared to the WD1770 you'll often see elsewhere.

MSX and/or ColecoVision/SG1000

Different sound chips, same CPU and video. I actually think you can get pretty far ignoring timing interplay because the video chip keeps its own RAM at arm's length. But it's tiles and sprites, and four different graphics modes, for probably too substantial an undertaking for a microprocessing course.

Master System

Technically an enhanced SG1000, being everything that machine does plus an extra graphics mode, but the extra graphics mode is so much better than the others that only one title uses anything else. So it actually simplifies things somewhat if you're happy within the realm of mostly ignoring timing.

But you're still talking about factoring in sprite priorities, checking for per-pixel collisions, etc. Probably too much.

Footnote: cheating with tape access

For a bunch of the home computers mentioned above, you can actually skip tape emulation for anything that is encoded in the default ROM format by just inserting an appropriate trap into the system ROM and spooling in from the source file. Many, but not all, titles rely entirely on the built-in ROM for tape IO so that can get many titles loaded with no real attempt at hardware.

In every case it's a bodge-job hack, but it'll do if that side of emulation isn't important to you — you'd rather just remove it from the equation and ignore what doesn't work.

Specifically:

Vic-20:

• if the program counter gets to 0xf7b2, copy the next tape header to the location indicated by b3:b2, zero out 0x90 and 0x93, and continue from 0xf7b5 (as you're avoid a JSR);


• trap 0xf90b, check for X = 0xe, if so then get the next tape data body and write to emulated memory from c2:c1 but no further than af:ae regardless of the size of the body, then set bit 6 at 0x90, clear the carry and interrupt flags, and continue from 0xfccf.

Oric:

For ROM 1.0, trap the PC at address 0xe630. For 1.1, watch for address 0xe6c9.

Upon catching that, load A with the next byte from the tape, and set the zero flag according to its value.

Then RTS.

There's also a flag at 0x67 on the original ROM, or 0x24d which discerns between the machine's fast and slow tape encodings, but the usual tape file format just has the decoded bytes so for a quick and dirty emulation don't worry about it.

Electron:

Install NOPs at 0xf4e5, 0xf6de, 0xf6fa and 0xfa51 to disable the tape branches. The OS will now try to load tape data as if it were on a serial ROM.

Cat the PC at 0xf0a8 and check that the X register is equal to 14 and the value at address 0x247 is zero. Then you'll know that the ROM is trying to fetch the next byte from tape.

Put the next byte in Y, set A to 0 and RTS.

The primary tape file format mostly allows you to spool bytes directly from the file (after some trivial chunk navigation, and via ZLib or another GZ decompressor, though you could just gunzip in advance).

ZX Spectrum:

(This one is transcribed from very old notes; it might be worth confirming against a ROM disassembly)

Trap the PC reaching 0x056c in the 48kb ROM. Grab the next block from tape (if you use a TAP file, you'll be directly given it; I'd argue you shouldn't bother trying to support TZX in this sort of project).

If its length is less than the value in DE, reset carry and return.

Compare the first byte of the block to the value of B. If they don't match, reset carry and return.

Otherwise spool the first DE bytes you did get to the address pointed to by IX and set the low bit of C and set carry.

Then either directly perform a RET or else just skip the PC ahead to 0x05e2, which is the RET that normally ends tape loading.

The 128kb machines segue into the 48kb ROM for tape loading so the same hack applies subject to checking what's paged.

I think using graphical games as a target is possibly stretching your students too far. Running a game generally requires good emulation not only of the majority of the processor's functions but also a lot of hardware, not least the video circuits (which are often quite complex and in many cases introduce a lot of fiddly timing issues). If anything doesn't work quite right, the results are likely to be very disappointing. I'd suggest starting with an easier target.

I'd aim for a system that has a text mode interface, rather than graphical, because such interfaces are usually much simpler, and may have no particular timing requirements that need to be satisfied (i.e. they often work entirely in parallel to the processor's access to memory without affecting the processor at all). I would also recommend a system that has an integrated machine level monitor program, because this will help debugging programs running on the machine without needing to implement a debugger at the emulation level.

A suggestion based on my current personal research project is the Nascom 2 computer. This is a relatively simple Z80 based machine with text mode hardware that doesn't interact with the CPU (if there is contention, it's resolved in favour of the CPU, meaning that theoretically a handful of pixels in each frame may not be shown if the screen is being accessed at the same time as refresh is occuring, but this is not likely to be particularly noticeable or even frequent, so gives a usable result with very simple hardware). Precise timing is therefore not likely to be especially difficult or important for this machine. The machine hardware is both simple and well documented. Integrated peripherals are a UART (which can be used either for a remote terminal/printer or for cassette loading and saving .... which means no need to actually emulate cassette handling at the audio level, thus saving a good deal of implementation time) and a parallel IO module. The available tools also encourage experimentation in assembly language, which I imagine is a desirable goal for your course.

One interesting thing about this machine is that there is a gap in the available emulation options: the best known web page about the machine has requested a javascript-based emulator that they can embed on the page, but as yet nobody has provided one.

I have done two and a bit from scratch emulations for the Mac using Swift. These are my personal observations based on my experience.

None of my emulations are completely cycle accurate which leads to a few problems.

Commodore PET

This was the first emulation I wrote. You need, at a minimum a 6502 emulation, a PIA emulation, a VIA emulation and a video emulation.

The 6502 is really simple and an excellent processor to start with. It's also pretty well documented. The Visual6502 site was invaluable for working out the exact behaviour of instructions where documentation was ambiguous. As an aside, I wrote an emulation of a slightly later processor (I forget which one) that filled in some of the gaps in the instruction set. This made writing 6502 test code a lot easier (even just PHX and PHY make some things simpler. On the other hand, any software that used the "undocumented instructions" of the original 6502 will break on my emulation.

The PIA and VIA are relatively simple IO chips to emulate. The video driver can be as simple as reading the screen RAM, translating to ASCII or a close approximation and drawing the resulting text in a window. Eventually, I created a set of bitmaps that were accurate copies of the PET character set.

My chief resource for the PET was "Programming the PET/CBM" by Raeto West. I have an original copy, but there are PDF versions on line. Also, important is the availability of BASIC and KERNAL ROMS. You don't want to be rewriting the operating system.

Emulating the tape drive was a PITA. My software version was less reliable than the real one, which PET owners will know is really saying something. The main problem, i thought, is that it relies on cycle accurate timing pulses and, although my emulator counts clock pulses, it didn't necessarily invoke the timer interrupt at exactly the right time.

I had more success writing an emulation of the dual disk drives. This required a robust IEEE 488 emulation as well, but the disk drive emulation was quite easy. It's not a hardware emulation, it just takes the commands sent by the PET and executes them using flat files on the Mac's hard disk.

In the end, I wrote some code that would stop the emulator, directly inject a program file into memory and then start the emulator again. This turned out to be so much more convenient than emulating disks or tapes that I quit working on them.

My emulator works well enough with most PET code. Unfortunately, there is an issue with PET Space Invaders - probably caused by the keyboard code - so it doesn't recognise key presses properly. Also, I didn't try to address sound generation.

Sinclair ZX Spectrum

In some ways, this is even easier than the PET. You need to write a Z80 emulator which is more complex than the 6502 but there is a CPM test suite that you can use for verifying a lot of its functionality, you just need to emulate CPM's character output subroutine to make it workable.

The only other chips you need to emulate are the ULA and you don't need to do much of that if you are prepared to forgo a tape drive. Also, the video generator, which is a bit weird in the way it addresses the Screen RAM.

The really nice thing about the Spectrum is that the screen is always in bitmap mode and the OS creates characters by directly writing the write pixel patterns. You don't have to worry about a character set because it is magically there when you boot up the emulator with the Spectrum ROMs loaded.

I got the Spectrum to the point where I could load and run Manic Miner and it was playable, albeit without sound. It took about three months working perhaps eight hours a week from start to finish.

Commodore 64

This is a work in progress. Obviously, I already had a 6502, which I modified to give me the IO port of the 6510. So far, it does the bank switching correctly, some of the CIA functionality is implemented and enough VIC II functionality is emulated to give me a PET equivalent i.e. the normal text mode is working. Also the border and character colour memory are working.

I still have the more complicated graphics modes to emulate and sprites and I should be able to do something with the sound because that is a separate chip, I'm not reliant on accurate CPU timing.

TL;DR

The easiest emulation, apart form the CPU was the Spectrum. I'd probably start with that, although an old CP/M 8080 based computer might be even easier if you can get hold of CP/M.

Further Observations

You'll probably need a good cross assembler for your target platform. It gets very tedious hand assembling code for unit tests.

Also, a disassembler will be useful. I didn't have to disassemble the Commodore BASIC ROMs because disassemblies are freely available on the Internet. But when I was trying to get Space Invaders to work, it didn't work at first and the disassembler was invaluable for trouble shooting.

For this reason, cc65 suite makes a strong case for starting with a 6502 based machine. It's got a good assembler and an excellent disassembler included. The Z80 situation wasn't so good, but I did find a reasonable assembler in the end called z80asm. I think I had to compile it from source though.

Also, you'll need good solid documentation. Again the 6502 documentation is online is virtually unparalleled. Docs are less forthcoming for the Spectrum, but it's so simple, you can get away with quite a shoddy ULA emulation.

Along with all the other fine suggestions, as an alternative to Z-80 and CP/M, you might consider a generic Motorola 6809 system to run FLEX or possibly OS-9, both Unix-inspired. As a CLI-based system there's no need to get any timing accurate.

Also, if you're building the simulator, it's rather like building the hardware; porting the operating system was a real task -- which I did in the 1980s -- as opposed to a clone-something-for-education task. "Does it boot the operating system and run the programs?" is a very realistic target.

As it's running a portable operating system which ran on many different manufacturers' hardware, it means the students don't have just one way of doing it. Student A might build a bit-map display; Student B might make a UART and have a serial interface. Some might try to get every cycle right; some might try just to get every operation correct. Therefore instead of simply trying to copy something without necessarily understanding the original design constraints, the students are engaged in a proper engineering question: what is a good way to do this?

CPU

• The 6809 was unique at the time in that it was possible to write entirely position-independent code, which would run identically wherever it was in memory.


• The instruction set was almost entirely orthogonal


• As a 8-bit CPU with 16-bit address bus, it's pretty simple


• The exception mechanism and effective-address manipulation are very much like modern processors


• As a Motorola design, it had memory-mapped IO rather than special IO instructions


• Easier to do than Z-80 (many fewer instructions) or 6502 (fewer special cases)


• Material via https://en.wikipedia.org/wiki/Motorola_6809
  

FLEX was designed as a Unix-inspired system for 8-bit CPUs

• It was specifically designed for portability, and to get it to boot required very few system calls to be implemented -- I think just character read/write, floppy block read/write and some kind of boot (read sector and jump to it).


• Hardware-agnostic for these basic functions, which makes simulation much much easier


• It's exhilarating to write just a few functions and boot a whole operating system


• No graphics to fret about (which is positive or negative depending on your view)


• Much available material, find via https://en.wikipedia.org/wiki/FLEX_(operating_system)
  

OS-9 similar in intent

• More Unix-like than FLEX, slightly harder to port, as far as I remember


• Later ported to 68000


• Much available material, find via https://en.wikipedia.org/wiki/OS-9