Nsryjdtyk

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.

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.

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).

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,

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.

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.

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.

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?

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.

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.