Simplest system to create an emulator for











up vote
30
down vote

favorite
14












Next year I'm going to teach a 2-semester microprocessors class to third-year undergraduate EE students. In order to sign up for the class, students need to have completed programming and digital systems classes.



In order to motivate the students with a real-world application of the concepts taught in class, I am considering the possibility of tasking the students with creating an emulator for an older system from scratch, as a group project to be completed until the end of the class (which is, as pointed out, 2 semesters long).



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. 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., and not necessarily the trickery required for rendering sprites quickly enough to make an interesting videogame with the semiconductor technology that was available in the 1980s at acceptable cost. I understand this was necessary at the time; I'm just trying to find a system that didn't abuse these tricks too much. Ideally the system in question shouldn't require cycle-accurate emulation or tricks like chasing the scanline.



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



Finally, I don't think the students would find the emulator interesting if it, say, just displayed register values after the execution of a toy program (although this would make the project much much simpler). 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.



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?






hardware emulation gaming







share|improve this question







New contributor




swineone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 1




    Interesting question. It might be important to add a plea for answers to stay off of the usual fights about the better system/cpu/vdu/etc. and focus on the didactic part.
    – Raffzahn
    Nov 16 at 13:57






  • 1




    There is apparent contradiction in the question. From the one point, the author wants to concentrate on CPU emulation, from the other point, he wants to have also pictures and sound outputting by the whole emulated system. While the request for the latter is understandable, it leads to the equally hard work on emulating the peripherals, showing pictures and playing sound tasks.
    – lvd
    Nov 16 at 15:01






  • 1




    Possibly helpful resource supposing it ends up being a Z80 machine rather than a 6502: z80.info/decoding.htm on algorithmic decoding of Z80 instructions (subject to a bunch of special cases, but there it is). Requiring an emulator actually decode algorithmically rather than by lookup would restrict the ability of students to copy and paste, as well as being relevant to a microprocessors course?
    – Tommy
    Nov 16 at 15:25






  • 1




    This may not be what you are looking for, but perhaps rather than writing an emulator (which I'm assuming they will run on their PC), they might be able to demonstrate the same conceptual knowledge by working with actual hardware. Have them get an ARM Cortex M4 based dev board, learn to work with the bare metal.
    – selectstriker2
    2 days ago






  • 1




    maybe TI-83...?
    – Jack Kasbrack
    yesterday















up vote
30
down vote

favorite
14












Next year I'm going to teach a 2-semester microprocessors class to third-year undergraduate EE students. In order to sign up for the class, students need to have completed programming and digital systems classes.



In order to motivate the students with a real-world application of the concepts taught in class, I am considering the possibility of tasking the students with creating an emulator for an older system from scratch, as a group project to be completed until the end of the class (which is, as pointed out, 2 semesters long).



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. 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., and not necessarily the trickery required for rendering sprites quickly enough to make an interesting videogame with the semiconductor technology that was available in the 1980s at acceptable cost. I understand this was necessary at the time; I'm just trying to find a system that didn't abuse these tricks too much. Ideally the system in question shouldn't require cycle-accurate emulation or tricks like chasing the scanline.



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



Finally, I don't think the students would find the emulator interesting if it, say, just displayed register values after the execution of a toy program (although this would make the project much much simpler). 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.



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?






hardware emulation gaming







share|improve this question







New contributor




swineone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 1




    Interesting question. It might be important to add a plea for answers to stay off of the usual fights about the better system/cpu/vdu/etc. and focus on the didactic part.
    – Raffzahn
    Nov 16 at 13:57






  • 1




    There is apparent contradiction in the question. From the one point, the author wants to concentrate on CPU emulation, from the other point, he wants to have also pictures and sound outputting by the whole emulated system. While the request for the latter is understandable, it leads to the equally hard work on emulating the peripherals, showing pictures and playing sound tasks.
    – lvd
    Nov 16 at 15:01






  • 1




    Possibly helpful resource supposing it ends up being a Z80 machine rather than a 6502: z80.info/decoding.htm on algorithmic decoding of Z80 instructions (subject to a bunch of special cases, but there it is). Requiring an emulator actually decode algorithmically rather than by lookup would restrict the ability of students to copy and paste, as well as being relevant to a microprocessors course?
    – Tommy
    Nov 16 at 15:25






  • 1




    This may not be what you are looking for, but perhaps rather than writing an emulator (which I'm assuming they will run on their PC), they might be able to demonstrate the same conceptual knowledge by working with actual hardware. Have them get an ARM Cortex M4 based dev board, learn to work with the bare metal.
    – selectstriker2
    2 days ago






  • 1




    maybe TI-83...?
    – Jack Kasbrack
    yesterday













up vote
30
down vote

favorite
14









up vote
30
down vote

favorite
14






14





Next year I'm going to teach a 2-semester microprocessors class to third-year undergraduate EE students. In order to sign up for the class, students need to have completed programming and digital systems classes.



In order to motivate the students with a real-world application of the concepts taught in class, I am considering the possibility of tasking the students with creating an emulator for an older system from scratch, as a group project to be completed until the end of the class (which is, as pointed out, 2 semesters long).



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. 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., and not necessarily the trickery required for rendering sprites quickly enough to make an interesting videogame with the semiconductor technology that was available in the 1980s at acceptable cost. I understand this was necessary at the time; I'm just trying to find a system that didn't abuse these tricks too much. Ideally the system in question shouldn't require cycle-accurate emulation or tricks like chasing the scanline.



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



Finally, I don't think the students would find the emulator interesting if it, say, just displayed register values after the execution of a toy program (although this would make the project much much simpler). 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.



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?






hardware emulation gaming







share|improve this question







New contributor




swineone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











Next year I'm going to teach a 2-semester microprocessors class to third-year undergraduate EE students. In order to sign up for the class, students need to have completed programming and digital systems classes.



In order to motivate the students with a real-world application of the concepts taught in class, I am considering the possibility of tasking the students with creating an emulator for an older system from scratch, as a group project to be completed until the end of the class (which is, as pointed out, 2 semesters long).



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. 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., and not necessarily the trickery required for rendering sprites quickly enough to make an interesting videogame with the semiconductor technology that was available in the 1980s at acceptable cost. I understand this was necessary at the time; I'm just trying to find a system that didn't abuse these tricks too much. Ideally the system in question shouldn't require cycle-accurate emulation or tricks like chasing the scanline.



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



Finally, I don't think the students would find the emulator interesting if it, say, just displayed register values after the execution of a toy program (although this would make the project much much simpler). 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.



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?






hardware emulation gaming




hardware emulation gaming






share|improve this question







New contributor




swineone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question







New contributor




swineone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question






New contributor




swineone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Nov 16 at 13:40









swineone

25724




25724




New contributor




swineone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





swineone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






swineone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 1




    Interesting question. It might be important to add a plea for answers to stay off of the usual fights about the better system/cpu/vdu/etc. and focus on the didactic part.
    – Raffzahn
    Nov 16 at 13:57






  • 1




    There is apparent contradiction in the question. From the one point, the author wants to concentrate on CPU emulation, from the other point, he wants to have also pictures and sound outputting by the whole emulated system. While the request for the latter is understandable, it leads to the equally hard work on emulating the peripherals, showing pictures and playing sound tasks.
    – lvd
    Nov 16 at 15:01






  • 1




    Possibly helpful resource supposing it ends up being a Z80 machine rather than a 6502: z80.info/decoding.htm on algorithmic decoding of Z80 instructions (subject to a bunch of special cases, but there it is). Requiring an emulator actually decode algorithmically rather than by lookup would restrict the ability of students to copy and paste, as well as being relevant to a microprocessors course?
    – Tommy
    Nov 16 at 15:25






  • 1




    This may not be what you are looking for, but perhaps rather than writing an emulator (which I'm assuming they will run on their PC), they might be able to demonstrate the same conceptual knowledge by working with actual hardware. Have them get an ARM Cortex M4 based dev board, learn to work with the bare metal.
    – selectstriker2
    2 days ago






  • 1




    maybe TI-83...?
    – Jack Kasbrack
    yesterday














  • 1




    Interesting question. It might be important to add a plea for answers to stay off of the usual fights about the better system/cpu/vdu/etc. and focus on the didactic part.
    – Raffzahn
    Nov 16 at 13:57






  • 1




    There is apparent contradiction in the question. From the one point, the author wants to concentrate on CPU emulation, from the other point, he wants to have also pictures and sound outputting by the whole emulated system. While the request for the latter is understandable, it leads to the equally hard work on emulating the peripherals, showing pictures and playing sound tasks.
    – lvd
    Nov 16 at 15:01






  • 1




    Possibly helpful resource supposing it ends up being a Z80 machine rather than a 6502: z80.info/decoding.htm on algorithmic decoding of Z80 instructions (subject to a bunch of special cases, but there it is). Requiring an emulator actually decode algorithmically rather than by lookup would restrict the ability of students to copy and paste, as well as being relevant to a microprocessors course?
    – Tommy
    Nov 16 at 15:25






  • 1




    This may not be what you are looking for, but perhaps rather than writing an emulator (which I'm assuming they will run on their PC), they might be able to demonstrate the same conceptual knowledge by working with actual hardware. Have them get an ARM Cortex M4 based dev board, learn to work with the bare metal.
    – selectstriker2
    2 days ago






  • 1




    maybe TI-83...?
    – Jack Kasbrack
    yesterday








1




1




Interesting question. It might be important to add a plea for answers to stay off of the usual fights about the better system/cpu/vdu/etc. and focus on the didactic part.
– Raffzahn
Nov 16 at 13:57




Interesting question. It might be important to add a plea for answers to stay off of the usual fights about the better system/cpu/vdu/etc. and focus on the didactic part.
– Raffzahn
Nov 16 at 13:57




1




1




There is apparent contradiction in the question. From the one point, the author wants to concentrate on CPU emulation, from the other point, he wants to have also pictures and sound outputting by the whole emulated system. While the request for the latter is understandable, it leads to the equally hard work on emulating the peripherals, showing pictures and playing sound tasks.
– lvd
Nov 16 at 15:01




There is apparent contradiction in the question. From the one point, the author wants to concentrate on CPU emulation, from the other point, he wants to have also pictures and sound outputting by the whole emulated system. While the request for the latter is understandable, it leads to the equally hard work on emulating the peripherals, showing pictures and playing sound tasks.
– lvd
Nov 16 at 15:01




1




1




Possibly helpful resource supposing it ends up being a Z80 machine rather than a 6502: z80.info/decoding.htm on algorithmic decoding of Z80 instructions (subject to a bunch of special cases, but there it is). Requiring an emulator actually decode algorithmically rather than by lookup would restrict the ability of students to copy and paste, as well as being relevant to a microprocessors course?
– Tommy
Nov 16 at 15:25




Possibly helpful resource supposing it ends up being a Z80 machine rather than a 6502: z80.info/decoding.htm on algorithmic decoding of Z80 instructions (subject to a bunch of special cases, but there it is). Requiring an emulator actually decode algorithmically rather than by lookup would restrict the ability of students to copy and paste, as well as being relevant to a microprocessors course?
– Tommy
Nov 16 at 15:25




1




1




This may not be what you are looking for, but perhaps rather than writing an emulator (which I'm assuming they will run on their PC), they might be able to demonstrate the same conceptual knowledge by working with actual hardware. Have them get an ARM Cortex M4 based dev board, learn to work with the bare metal.
– selectstriker2
2 days ago




This may not be what you are looking for, but perhaps rather than writing an emulator (which I'm assuming they will run on their PC), they might be able to demonstrate the same conceptual knowledge by working with actual hardware. Have them get an ARM Cortex M4 based dev board, learn to work with the bare metal.
– selectstriker2
2 days ago




1




1




maybe TI-83...?
– Jack Kasbrack
yesterday




maybe TI-83...?
– Jack Kasbrack
yesterday










14 Answers
14






active

oldest

votes

















up vote
25
down vote













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.






share|improve this answer



















  • 2




    Ayy for Chip 8. It's easy to find implementations in many languages and the architecture is simple.
    – Filipe Nicoli
    2 days ago






  • 5




    CHIP-8 is a great idea for an introduction to emulation because of its simplicity. Having written a NES emulator before, I can tell you that writing the CPU was extremely time-consuming and tedious — and the 6502 is simple as far as CPUs go. In contrast, CHIP-8 only has 35 very simple instructions. Additionally, many systems relied on precise timing behaviors between the CPU and the rest of the hardware, while CHIP-8 has no such requirement.
    – NobodyNada
    2 days ago










  • This reminds me a bit of BPF. It's even simpler than CHIP-8.
    – forest
    yesterday


















up vote
13
down vote













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.






share|improve this answer























  • On the Z80, FUSE provides tests though not all of them are generic or necessarily correct as to exact cycle timing; they're also in an ad hoc text format but I've transcribed them into JSON: github.com/TomHarte/CLK/tree/master/OSBindings/Mac/… — use tests.in.json to set initial states and find out how long you should run for, then tests.expected.json to verify results. There's also zexall and zexdoc, originally CP/M files but widely adapted and very slow. Passing the former requires a bunch of undocumented things to be correct, passing the latter doesn't.
    – Tommy
    Nov 16 at 16:39










  • ... and the only thing I've ever found for the 6809, supposing anybody were thinking to suggest a Vectrex or Coco/Dragon, is contained within a wider Williams arcade machine test suite at seanriddle.com/wetsold.html . For the 6502 I am very much on board with the tests of Klaus Dormann, Wolfgang Lorenz, and AllSuiteA, all of which seem to be much more prominent than the Z80 or 6809 tests.
    – Tommy
    Nov 16 at 16:40










  • @Tommy As far as I'm aware, every one of Fuse's tests are cycle accurate. Please file bugs if they're not :-)
    – Philip Kendall
    2 days ago










  • @PhilipKendall see my email of 29/5/2017 to fuse-emulator-devel re: DJNZ and whether the offset is read on a final iteration. Conclusion from Alan Cox on whether FUSE's tested behaviour is correct was that it's "open to interpretation" based on the available sources. So I thought "not necessarily correct" was fair. I should probably have been clear though: I found only a handful of deviations in your team's interpretation of evidence and my own. Apologies for poor form on that.
    – Tommy
    2 days ago










  • @Tommy - "Conclusion from Alan Cox on whether FUSE's tested behaviour is correct was that it's "open to interpretation" based on the available sources" ... while I have a lot of respect for a lot of what Alan does, it's pretty easy to verify whether the tested behaviour is the same as an actual Z80 CPU (particularly for CMOS versions that can be run on breadboard with low clock speeds in order to set up detailed tests very simply), so this is definitely a case where if he thinks there's something wrong he should be able to demonstrate it very easily.
    – Jules
    18 hours ago


















up vote
13
down vote













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






share|improve this answer



















  • 2




    @Tommy Well, I would love to avoide this, as there is no easy answer. Most important here might be, that, while the Z80 is somewhat "quirky", the 68k is anything but simple. With all the extension words (up to CPU32), a single instruction can have up to 11 words (22 byte) and decoding them is a serious mess. Then again, it all depends on the way the emulator is made up. The Z80 is a rather straight foreward 8080, easy to emulate, with a few modifiers, which can easy be handled. For the 68k , even only the original one, it will be way more work.
    – Raffzahn
    2 days ago






  • 2




    "task fit for freshmen in such a limited time." He said these are 3rd year students, not freshmen, and they've already completed several prerequisites.
    – Barmar
    2 days ago






  • 2




    @wizzwizz4 Well, no matter what what our personal opinion is, JS is the legal heir to BASIC. Serious and in every way! Just think about it. It not only runs n next to every actual computer, it's even installed by default, and there is next to no way to get rid of it without loosing much functionality. Even more, just think about how much bad and incredible slow software is writen in JS - the perfect proof, isn't it?
    – Raffzahn
    2 days ago






  • 2




    @Raffzahn It's completely different For one, BASIC had several incompatible implemen... Ohhh! It is the successor to BASIC!
    – wizzwizz4♦
    2 days ago






  • 2




    They're still not freshmen, which are first-year students. And I think you should give the OP the benefit of the doubt that he wouldn't assign the project if the students don't have the required background.
    – Barmar
    2 days ago


















up vote
11
down vote













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.






share|improve this answer










New contributor




Kamsof is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.


















  • ... and, for the record, the ColecoVision is the exact same collection of components, with different connecting logic and very slightly more complicated joypads. So an SG-1000 emulator is usually easy to extend to support both.
    – Tommy
    Nov 16 at 14:39






  • 2




    Also noteworthy that the 9918 is a complex chip, with sprites, complex modi and data, like he didn't want to use. Isn'T it?
    – Raffzahn
    Nov 16 at 16:45


















up vote
7
down vote













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.






share|improve this answer

















  • 1




    I had the same instinct, but would extend by suggesting that SNA and Z80 and well-defined-enough snapshot formats that you needn't even worry about the tape emulation. And, let's be honest, TZX is a bit of a miasma at this point.
    – Tommy
    Nov 16 at 14:48






  • 3




    I believe the Spectrum ROM is now in the public domain, which may help (or make things too easy)
    – Stormcloud
    Nov 16 at 16:34










  • The ZX Spectrum is a great example of simple hardware, but also one of quite complex, cycle counting (Racing the Beam) programming to get out useable game effects.
    – Raffzahn
    Nov 16 at 16:46






  • 1




    @Tommy Oh, I would never suggest the ZX80/81 for the same reason. And while not a true Spectrum buff, I have seen some good timing dependant code for it. Most prominet screen manipulations after that part has been displayed, but before it runs once around. It's a very simple issue found on a whole lot of systems . No big issue, but timing dependant. For example simple emulation schemes that only throtle speed on a frame level will produce crap on faster emulation hosts ... and so on.
    – Raffzahn
    2 days ago






  • 2




    @Stormcloud The Spectrum ROM is not in the public domain, though permission has been granted to distribute it for use with emulators. The ZX80 and ZX81 ROMs have been released under the GPL.
    – john_e
    2 days ago




















up vote
7
down vote













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.



enter image description here



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.






share|improve this answer























  • Except, the vectrex also fots well the 'Racing the Beam' cathegory, doesn't it?
    – Raffzahn
    2 days ago






  • 1




    @Raffzahn, as I understand it, the Vectrex CPU controls the electron beam -- exactly the opposite of a "racing the beam" situation where software needs to make precisely-timed state changes to keep up with an externally-timed raster scan display.
    – Mark
    2 days ago










  • @Mark It's the same with the VCS. Here as well the beam is controlled by the CPU. Without the CPU accessing WSYNC every line and before the line is done, the screen will falter. And as far as I understand the OP, it's exactly about not recreating a system with strict timing requirements - which are essential for the Vectrex.
    – Raffzahn
    2 days ago










  • @Raffzahn: The CPU in the VCS controls the vertical, but it does not control the horizontal. It's not unusual for a game to output dozens or even hundreds of scan lines without an intervening WSYNC. In the absence of a WSYNC, the beam will be at the same horizontal position every 76th cycle. Storing WSYNC is often the easiest way to wait for the beam to reach the right side of the displayed region, but it's hardly the only way. A programmer who was so inclined could exploit the intricate details of sprite motion and behaviors to write a game that never used WSYNC at all.
    – supercat
    2 days ago










  • Um, folks, we are talking about an emulator here. There is not going to be a problem with the phosphors fading while the emulated CPU takes too long to draw the next frame. There is no "beam" and there is certainly no reason the emulator would need to "race" since the emulator display will remain quite static as long as necessary between frames.
    – Brian H
    2 days ago


















up vote
6
down vote













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,






share|improve this answer























  • I'd argue that the Oric architecture discourages raster racing by not having a side channel of video control registers and not being set up so that racing could conceivably increase your colour resolution (contrasted with a Spectrum). If it only had two HIRES buffers though, I'd state that more confidently. Would you agree with that?
    – Tommy
    2 days ago










  • @Tommy I'm not too familiar with the Oric video circuitry. What I would state in any case is that the Oric had such a short life and such a limited user base that sophisticated techniques to tweak the video like we know from the ZX Spectrum weren't developed (at least not during the active life of the computer, there's a number of interesting demos here demozoo.org/platforms/49)
    – tofro
    2 days ago












  • Oh, then I'll provide better reasoning: the Oric video chip has modal state, including text or graphics mode, but no exposed registers. Everything is set by control bytes within the video stream — including foreground and background attributes. People tend to complain about that because it means that if you want gapless graphics you're limited to four colours per line, two of them being the bitwise complements of the other two. Some of the modern games still look really good though — e.g. Stormlord youtube.com/watch?v=QSDy-BC580M
    – Tommy
    2 days ago










  • @Tommy The serial attributes make the programming a bit more tricky, I'd guess, but the amount of attribute clash is even better than on the ZX Spectrum, I reckon.
    – tofro
    2 days ago


















up vote
5
down vote













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?






share|improve this answer






























    up vote
    4
    down vote













    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.






    share|improve this answer





















    • Yes, all three (PET, TRS, Superboard (I totally forgot about the later one) ) are great simple machines and great for emulations. But also missing a good selection of ready to use games. Not to mention colour and alike eople may expect today.
      – Raffzahn
      2 days ago


















    up vote
    4
    down vote













    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.






    share|improve this answer





















    • For what it's worth, I think Space Invaders is an inspired suggestion. If memory serves it's just an 8080 with a 1bpp bitmapped screen, some port IO for the controls, no attempt to race the raster, audio that is just of the form "trigger noise X now", very relaxed accuracy requirements, and it produces a game that they still occasionally try to sell now. It's only the legality issue that might give pause, though I'm always fuzzy on academic exceptions.
      – Tommy
      3 hours ago


















    up vote
    3
    down vote













    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.






    share|improve this answer



















    • 1




      With a potential advantage of a CP/M machine being that there's bound to be at least one for which a mere 8080 emulation will do?
      – Tommy
      Nov 16 at 15:21










    • Nice, but then again, there are not raly many games for the IBM in text mode, are there?
      – Raffzahn
      Nov 16 at 16:46










    • @Raffzahn - there only needs to be one.
      – Jules
      18 hours ago










    • @Jules Hehehe ... yeah right. But then I'd say a minimum 8080 will do the trick
      – Raffzahn
      18 hours ago


















    up vote
    3
    down vote













    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.






    share|improve this answer



















    • 3




      The CPU might be simple, but emulating peripherals (display etc) would probably still be a considerable task
      – Igor Skochinsky
      2 days ago


















    up vote
    3
    down vote













    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.






    share|improve this answer





















    • An interesting point is that most of the systems mentioned above have either Z80 or 6502 CPUs, both of which are somewhat lacking in terms of their supported addressing modes. If coverage of addressing modes is important, the PDP-8 has a much better selection of them to demonstrate.
      – Jules
      18 hours ago


















    up vote
    2
    down vote













    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.






    share|improve this answer




















      protected by wizzwizz4♦ 2 days ago



      Thank you for your interest in this question.
      Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



      Would you like to answer one of these unanswered questions instead?














      14 Answers
      14






      active

      oldest

      votes








      14 Answers
      14






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      25
      down vote













      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.






      share|improve this answer



















      • 2




        Ayy for Chip 8. It's easy to find implementations in many languages and the architecture is simple.
        – Filipe Nicoli
        2 days ago






      • 5




        CHIP-8 is a great idea for an introduction to emulation because of its simplicity. Having written a NES emulator before, I can tell you that writing the CPU was extremely time-consuming and tedious — and the 6502 is simple as far as CPUs go. In contrast, CHIP-8 only has 35 very simple instructions. Additionally, many systems relied on precise timing behaviors between the CPU and the rest of the hardware, while CHIP-8 has no such requirement.
        – NobodyNada
        2 days ago










      • This reminds me a bit of BPF. It's even simpler than CHIP-8.
        – forest
        yesterday















      up vote
      25
      down vote













      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.






      share|improve this answer



















      • 2




        Ayy for Chip 8. It's easy to find implementations in many languages and the architecture is simple.
        – Filipe Nicoli
        2 days ago






      • 5




        CHIP-8 is a great idea for an introduction to emulation because of its simplicity. Having written a NES emulator before, I can tell you that writing the CPU was extremely time-consuming and tedious — and the 6502 is simple as far as CPUs go. In contrast, CHIP-8 only has 35 very simple instructions. Additionally, many systems relied on precise timing behaviors between the CPU and the rest of the hardware, while CHIP-8 has no such requirement.
        – NobodyNada
        2 days ago










      • This reminds me a bit of BPF. It's even simpler than CHIP-8.
        – forest
        yesterday













      up vote
      25
      down vote










      up vote
      25
      down vote









      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.






      share|improve this answer














      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.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited yesterday

























      answered Nov 16 at 14:19









      Wilson

      10.1k545122




      10.1k545122








      • 2




        Ayy for Chip 8. It's easy to find implementations in many languages and the architecture is simple.
        – Filipe Nicoli
        2 days ago






      • 5




        CHIP-8 is a great idea for an introduction to emulation because of its simplicity. Having written a NES emulator before, I can tell you that writing the CPU was extremely time-consuming and tedious — and the 6502 is simple as far as CPUs go. In contrast, CHIP-8 only has 35 very simple instructions. Additionally, many systems relied on precise timing behaviors between the CPU and the rest of the hardware, while CHIP-8 has no such requirement.
        – NobodyNada
        2 days ago










      • This reminds me a bit of BPF. It's even simpler than CHIP-8.
        – forest
        yesterday














      • 2




        Ayy for Chip 8. It's easy to find implementations in many languages and the architecture is simple.
        – Filipe Nicoli
        2 days ago






      • 5




        CHIP-8 is a great idea for an introduction to emulation because of its simplicity. Having written a NES emulator before, I can tell you that writing the CPU was extremely time-consuming and tedious — and the 6502 is simple as far as CPUs go. In contrast, CHIP-8 only has 35 very simple instructions. Additionally, many systems relied on precise timing behaviors between the CPU and the rest of the hardware, while CHIP-8 has no such requirement.
        – NobodyNada
        2 days ago










      • This reminds me a bit of BPF. It's even simpler than CHIP-8.
        – forest
        yesterday








      2




      2




      Ayy for Chip 8. It's easy to find implementations in many languages and the architecture is simple.
      – Filipe Nicoli
      2 days ago




      Ayy for Chip 8. It's easy to find implementations in many languages and the architecture is simple.
      – Filipe Nicoli
      2 days ago




      5




      5




      CHIP-8 is a great idea for an introduction to emulation because of its simplicity. Having written a NES emulator before, I can tell you that writing the CPU was extremely time-consuming and tedious — and the 6502 is simple as far as CPUs go. In contrast, CHIP-8 only has 35 very simple instructions. Additionally, many systems relied on precise timing behaviors between the CPU and the rest of the hardware, while CHIP-8 has no such requirement.
      – NobodyNada
      2 days ago




      CHIP-8 is a great idea for an introduction to emulation because of its simplicity. Having written a NES emulator before, I can tell you that writing the CPU was extremely time-consuming and tedious — and the 6502 is simple as far as CPUs go. In contrast, CHIP-8 only has 35 very simple instructions. Additionally, many systems relied on precise timing behaviors between the CPU and the rest of the hardware, while CHIP-8 has no such requirement.
      – NobodyNada
      2 days ago












      This reminds me a bit of BPF. It's even simpler than CHIP-8.
      – forest
      yesterday




      This reminds me a bit of BPF. It's even simpler than CHIP-8.
      – forest
      yesterday










      up vote
      13
      down vote













      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.






      share|improve this answer























      • On the Z80, FUSE provides tests though not all of them are generic or necessarily correct as to exact cycle timing; they're also in an ad hoc text format but I've transcribed them into JSON: github.com/TomHarte/CLK/tree/master/OSBindings/Mac/… — use tests.in.json to set initial states and find out how long you should run for, then tests.expected.json to verify results. There's also zexall and zexdoc, originally CP/M files but widely adapted and very slow. Passing the former requires a bunch of undocumented things to be correct, passing the latter doesn't.
        – Tommy
        Nov 16 at 16:39










      • ... and the only thing I've ever found for the 6809, supposing anybody were thinking to suggest a Vectrex or Coco/Dragon, is contained within a wider Williams arcade machine test suite at seanriddle.com/wetsold.html . For the 6502 I am very much on board with the tests of Klaus Dormann, Wolfgang Lorenz, and AllSuiteA, all of which seem to be much more prominent than the Z80 or 6809 tests.
        – Tommy
        Nov 16 at 16:40










      • @Tommy As far as I'm aware, every one of Fuse's tests are cycle accurate. Please file bugs if they're not :-)
        – Philip Kendall
        2 days ago










      • @PhilipKendall see my email of 29/5/2017 to fuse-emulator-devel re: DJNZ and whether the offset is read on a final iteration. Conclusion from Alan Cox on whether FUSE's tested behaviour is correct was that it's "open to interpretation" based on the available sources. So I thought "not necessarily correct" was fair. I should probably have been clear though: I found only a handful of deviations in your team's interpretation of evidence and my own. Apologies for poor form on that.
        – Tommy
        2 days ago










      • @Tommy - "Conclusion from Alan Cox on whether FUSE's tested behaviour is correct was that it's "open to interpretation" based on the available sources" ... while I have a lot of respect for a lot of what Alan does, it's pretty easy to verify whether the tested behaviour is the same as an actual Z80 CPU (particularly for CMOS versions that can be run on breadboard with low clock speeds in order to set up detailed tests very simply), so this is definitely a case where if he thinks there's something wrong he should be able to demonstrate it very easily.
        – Jules
        18 hours ago















      up vote
      13
      down vote













      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.






      share|improve this answer























      • On the Z80, FUSE provides tests though not all of them are generic or necessarily correct as to exact cycle timing; they're also in an ad hoc text format but I've transcribed them into JSON: github.com/TomHarte/CLK/tree/master/OSBindings/Mac/… — use tests.in.json to set initial states and find out how long you should run for, then tests.expected.json to verify results. There's also zexall and zexdoc, originally CP/M files but widely adapted and very slow. Passing the former requires a bunch of undocumented things to be correct, passing the latter doesn't.
        – Tommy
        Nov 16 at 16:39










      • ... and the only thing I've ever found for the 6809, supposing anybody were thinking to suggest a Vectrex or Coco/Dragon, is contained within a wider Williams arcade machine test suite at seanriddle.com/wetsold.html . For the 6502 I am very much on board with the tests of Klaus Dormann, Wolfgang Lorenz, and AllSuiteA, all of which seem to be much more prominent than the Z80 or 6809 tests.
        – Tommy
        Nov 16 at 16:40










      • @Tommy As far as I'm aware, every one of Fuse's tests are cycle accurate. Please file bugs if they're not :-)
        – Philip Kendall
        2 days ago










      • @PhilipKendall see my email of 29/5/2017 to fuse-emulator-devel re: DJNZ and whether the offset is read on a final iteration. Conclusion from Alan Cox on whether FUSE's tested behaviour is correct was that it's "open to interpretation" based on the available sources. So I thought "not necessarily correct" was fair. I should probably have been clear though: I found only a handful of deviations in your team's interpretation of evidence and my own. Apologies for poor form on that.
        – Tommy
        2 days ago










      • @Tommy - "Conclusion from Alan Cox on whether FUSE's tested behaviour is correct was that it's "open to interpretation" based on the available sources" ... while I have a lot of respect for a lot of what Alan does, it's pretty easy to verify whether the tested behaviour is the same as an actual Z80 CPU (particularly for CMOS versions that can be run on breadboard with low clock speeds in order to set up detailed tests very simply), so this is definitely a case where if he thinks there's something wrong he should be able to demonstrate it very easily.
        – Jules
        18 hours ago













      up vote
      13
      down vote










      up vote
      13
      down vote









      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.






      share|improve this answer














      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.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Nov 16 at 17:30

























      answered Nov 16 at 16:16









      Will Hartung

      3,283719




      3,283719












      • On the Z80, FUSE provides tests though not all of them are generic or necessarily correct as to exact cycle timing; they're also in an ad hoc text format but I've transcribed them into JSON: github.com/TomHarte/CLK/tree/master/OSBindings/Mac/… — use tests.in.json to set initial states and find out how long you should run for, then tests.expected.json to verify results. There's also zexall and zexdoc, originally CP/M files but widely adapted and very slow. Passing the former requires a bunch of undocumented things to be correct, passing the latter doesn't.
        – Tommy
        Nov 16 at 16:39










      • ... and the only thing I've ever found for the 6809, supposing anybody were thinking to suggest a Vectrex or Coco/Dragon, is contained within a wider Williams arcade machine test suite at seanriddle.com/wetsold.html . For the 6502 I am very much on board with the tests of Klaus Dormann, Wolfgang Lorenz, and AllSuiteA, all of which seem to be much more prominent than the Z80 or 6809 tests.
        – Tommy
        Nov 16 at 16:40










      • @Tommy As far as I'm aware, every one of Fuse's tests are cycle accurate. Please file bugs if they're not :-)
        – Philip Kendall
        2 days ago










      • @PhilipKendall see my email of 29/5/2017 to fuse-emulator-devel re: DJNZ and whether the offset is read on a final iteration. Conclusion from Alan Cox on whether FUSE's tested behaviour is correct was that it's "open to interpretation" based on the available sources. So I thought "not necessarily correct" was fair. I should probably have been clear though: I found only a handful of deviations in your team's interpretation of evidence and my own. Apologies for poor form on that.
        – Tommy
        2 days ago










      • @Tommy - "Conclusion from Alan Cox on whether FUSE's tested behaviour is correct was that it's "open to interpretation" based on the available sources" ... while I have a lot of respect for a lot of what Alan does, it's pretty easy to verify whether the tested behaviour is the same as an actual Z80 CPU (particularly for CMOS versions that can be run on breadboard with low clock speeds in order to set up detailed tests very simply), so this is definitely a case where if he thinks there's something wrong he should be able to demonstrate it very easily.
        – Jules
        18 hours ago


















      • On the Z80, FUSE provides tests though not all of them are generic or necessarily correct as to exact cycle timing; they're also in an ad hoc text format but I've transcribed them into JSON: github.com/TomHarte/CLK/tree/master/OSBindings/Mac/… — use tests.in.json to set initial states and find out how long you should run for, then tests.expected.json to verify results. There's also zexall and zexdoc, originally CP/M files but widely adapted and very slow. Passing the former requires a bunch of undocumented things to be correct, passing the latter doesn't.
        – Tommy
        Nov 16 at 16:39










      • ... and the only thing I've ever found for the 6809, supposing anybody were thinking to suggest a Vectrex or Coco/Dragon, is contained within a wider Williams arcade machine test suite at seanriddle.com/wetsold.html . For the 6502 I am very much on board with the tests of Klaus Dormann, Wolfgang Lorenz, and AllSuiteA, all of which seem to be much more prominent than the Z80 or 6809 tests.
        – Tommy
        Nov 16 at 16:40










      • @Tommy As far as I'm aware, every one of Fuse's tests are cycle accurate. Please file bugs if they're not :-)
        – Philip Kendall
        2 days ago










      • @PhilipKendall see my email of 29/5/2017 to fuse-emulator-devel re: DJNZ and whether the offset is read on a final iteration. Conclusion from Alan Cox on whether FUSE's tested behaviour is correct was that it's "open to interpretation" based on the available sources. So I thought "not necessarily correct" was fair. I should probably have been clear though: I found only a handful of deviations in your team's interpretation of evidence and my own. Apologies for poor form on that.
        – Tommy
        2 days ago










      • @Tommy - "Conclusion from Alan Cox on whether FUSE's tested behaviour is correct was that it's "open to interpretation" based on the available sources" ... while I have a lot of respect for a lot of what Alan does, it's pretty easy to verify whether the tested behaviour is the same as an actual Z80 CPU (particularly for CMOS versions that can be run on breadboard with low clock speeds in order to set up detailed tests very simply), so this is definitely a case where if he thinks there's something wrong he should be able to demonstrate it very easily.
        – Jules
        18 hours ago
















      On the Z80, FUSE provides tests though not all of them are generic or necessarily correct as to exact cycle timing; they're also in an ad hoc text format but I've transcribed them into JSON: github.com/TomHarte/CLK/tree/master/OSBindings/Mac/… — use tests.in.json to set initial states and find out how long you should run for, then tests.expected.json to verify results. There's also zexall and zexdoc, originally CP/M files but widely adapted and very slow. Passing the former requires a bunch of undocumented things to be correct, passing the latter doesn't.
      – Tommy
      Nov 16 at 16:39




      On the Z80, FUSE provides tests though not all of them are generic or necessarily correct as to exact cycle timing; they're also in an ad hoc text format but I've transcribed them into JSON: github.com/TomHarte/CLK/tree/master/OSBindings/Mac/… — use tests.in.json to set initial states and find out how long you should run for, then tests.expected.json to verify results. There's also zexall and zexdoc, originally CP/M files but widely adapted and very slow. Passing the former requires a bunch of undocumented things to be correct, passing the latter doesn't.
      – Tommy
      Nov 16 at 16:39












      ... and the only thing I've ever found for the 6809, supposing anybody were thinking to suggest a Vectrex or Coco/Dragon, is contained within a wider Williams arcade machine test suite at seanriddle.com/wetsold.html . For the 6502 I am very much on board with the tests of Klaus Dormann, Wolfgang Lorenz, and AllSuiteA, all of which seem to be much more prominent than the Z80 or 6809 tests.
      – Tommy
      Nov 16 at 16:40




      ... and the only thing I've ever found for the 6809, supposing anybody were thinking to suggest a Vectrex or Coco/Dragon, is contained within a wider Williams arcade machine test suite at seanriddle.com/wetsold.html . For the 6502 I am very much on board with the tests of Klaus Dormann, Wolfgang Lorenz, and AllSuiteA, all of which seem to be much more prominent than the Z80 or 6809 tests.
      – Tommy
      Nov 16 at 16:40












      @Tommy As far as I'm aware, every one of Fuse's tests are cycle accurate. Please file bugs if they're not :-)
      – Philip Kendall
      2 days ago




      @Tommy As far as I'm aware, every one of Fuse's tests are cycle accurate. Please file bugs if they're not :-)
      – Philip Kendall
      2 days ago












      @PhilipKendall see my email of 29/5/2017 to fuse-emulator-devel re: DJNZ and whether the offset is read on a final iteration. Conclusion from Alan Cox on whether FUSE's tested behaviour is correct was that it's "open to interpretation" based on the available sources. So I thought "not necessarily correct" was fair. I should probably have been clear though: I found only a handful of deviations in your team's interpretation of evidence and my own. Apologies for poor form on that.
      – Tommy
      2 days ago




      @PhilipKendall see my email of 29/5/2017 to fuse-emulator-devel re: DJNZ and whether the offset is read on a final iteration. Conclusion from Alan Cox on whether FUSE's tested behaviour is correct was that it's "open to interpretation" based on the available sources. So I thought "not necessarily correct" was fair. I should probably have been clear though: I found only a handful of deviations in your team's interpretation of evidence and my own. Apologies for poor form on that.
      – Tommy
      2 days ago












      @Tommy - "Conclusion from Alan Cox on whether FUSE's tested behaviour is correct was that it's "open to interpretation" based on the available sources" ... while I have a lot of respect for a lot of what Alan does, it's pretty easy to verify whether the tested behaviour is the same as an actual Z80 CPU (particularly for CMOS versions that can be run on breadboard with low clock speeds in order to set up detailed tests very simply), so this is definitely a case where if he thinks there's something wrong he should be able to demonstrate it very easily.
      – Jules
      18 hours ago




      @Tommy - "Conclusion from Alan Cox on whether FUSE's tested behaviour is correct was that it's "open to interpretation" based on the available sources" ... while I have a lot of respect for a lot of what Alan does, it's pretty easy to verify whether the tested behaviour is the same as an actual Z80 CPU (particularly for CMOS versions that can be run on breadboard with low clock speeds in order to set up detailed tests very simply), so this is definitely a case where if he thinks there's something wrong he should be able to demonstrate it very easily.
      – Jules
      18 hours ago










      up vote
      13
      down vote













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






      share|improve this answer



















      • 2




        @Tommy Well, I would love to avoide this, as there is no easy answer. Most important here might be, that, while the Z80 is somewhat "quirky", the 68k is anything but simple. With all the extension words (up to CPU32), a single instruction can have up to 11 words (22 byte) and decoding them is a serious mess. Then again, it all depends on the way the emulator is made up. The Z80 is a rather straight foreward 8080, easy to emulate, with a few modifiers, which can easy be handled. For the 68k , even only the original one, it will be way more work.
        – Raffzahn
        2 days ago






      • 2




        "task fit for freshmen in such a limited time." He said these are 3rd year students, not freshmen, and they've already completed several prerequisites.
        – Barmar
        2 days ago






      • 2




        @wizzwizz4 Well, no matter what what our personal opinion is, JS is the legal heir to BASIC. Serious and in every way! Just think about it. It not only runs n next to every actual computer, it's even installed by default, and there is next to no way to get rid of it without loosing much functionality. Even more, just think about how much bad and incredible slow software is writen in JS - the perfect proof, isn't it?
        – Raffzahn
        2 days ago






      • 2




        @Raffzahn It's completely different For one, BASIC had several incompatible implemen... Ohhh! It is the successor to BASIC!
        – wizzwizz4♦
        2 days ago






      • 2




        They're still not freshmen, which are first-year students. And I think you should give the OP the benefit of the doubt that he wouldn't assign the project if the students don't have the required background.
        – Barmar
        2 days ago















      up vote
      13
      down vote













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






      share|improve this answer



















      • 2




        @Tommy Well, I would love to avoide this, as there is no easy answer. Most important here might be, that, while the Z80 is somewhat "quirky", the 68k is anything but simple. With all the extension words (up to CPU32), a single instruction can have up to 11 words (22 byte) and decoding them is a serious mess. Then again, it all depends on the way the emulator is made up. The Z80 is a rather straight foreward 8080, easy to emulate, with a few modifiers, which can easy be handled. For the 68k , even only the original one, it will be way more work.
        – Raffzahn
        2 days ago






      • 2




        "task fit for freshmen in such a limited time." He said these are 3rd year students, not freshmen, and they've already completed several prerequisites.
        – Barmar
        2 days ago






      • 2




        @wizzwizz4 Well, no matter what what our personal opinion is, JS is the legal heir to BASIC. Serious and in every way! Just think about it. It not only runs n next to every actual computer, it's even installed by default, and there is next to no way to get rid of it without loosing much functionality. Even more, just think about how much bad and incredible slow software is writen in JS - the perfect proof, isn't it?
        – Raffzahn
        2 days ago






      • 2




        @Raffzahn It's completely different For one, BASIC had several incompatible implemen... Ohhh! It is the successor to BASIC!
        – wizzwizz4♦
        2 days ago






      • 2




        They're still not freshmen, which are first-year students. And I think you should give the OP the benefit of the doubt that he wouldn't assign the project if the students don't have the required background.
        – Barmar
        2 days ago













      up vote
      13
      down vote










      up vote
      13
      down vote









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






      share|improve this answer














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







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited 2 days ago









      LangLangC

      187118




      187118










      answered Nov 16 at 16:43









      Raffzahn

      42k595171




      42k595171








      • 2




        @Tommy Well, I would love to avoide this, as there is no easy answer. Most important here might be, that, while the Z80 is somewhat "quirky", the 68k is anything but simple. With all the extension words (up to CPU32), a single instruction can have up to 11 words (22 byte) and decoding them is a serious mess. Then again, it all depends on the way the emulator is made up. The Z80 is a rather straight foreward 8080, easy to emulate, with a few modifiers, which can easy be handled. For the 68k , even only the original one, it will be way more work.
        – Raffzahn
        2 days ago






      • 2




        "task fit for freshmen in such a limited time." He said these are 3rd year students, not freshmen, and they've already completed several prerequisites.
        – Barmar
        2 days ago






      • 2




        @wizzwizz4 Well, no matter what what our personal opinion is, JS is the legal heir to BASIC. Serious and in every way! Just think about it. It not only runs n next to every actual computer, it's even installed by default, and there is next to no way to get rid of it without loosing much functionality. Even more, just think about how much bad and incredible slow software is writen in JS - the perfect proof, isn't it?
        – Raffzahn
        2 days ago






      • 2




        @Raffzahn It's completely different For one, BASIC had several incompatible implemen... Ohhh! It is the successor to BASIC!
        – wizzwizz4♦
        2 days ago






      • 2




        They're still not freshmen, which are first-year students. And I think you should give the OP the benefit of the doubt that he wouldn't assign the project if the students don't have the required background.
        – Barmar
        2 days ago














      • 2




        @Tommy Well, I would love to avoide this, as there is no easy answer. Most important here might be, that, while the Z80 is somewhat "quirky", the 68k is anything but simple. With all the extension words (up to CPU32), a single instruction can have up to 11 words (22 byte) and decoding them is a serious mess. Then again, it all depends on the way the emulator is made up. The Z80 is a rather straight foreward 8080, easy to emulate, with a few modifiers, which can easy be handled. For the 68k , even only the original one, it will be way more work.
        – Raffzahn
        2 days ago






      • 2




        "task fit for freshmen in such a limited time." He said these are 3rd year students, not freshmen, and they've already completed several prerequisites.
        – Barmar
        2 days ago






      • 2




        @wizzwizz4 Well, no matter what what our personal opinion is, JS is the legal heir to BASIC. Serious and in every way! Just think about it. It not only runs n next to every actual computer, it's even installed by default, and there is next to no way to get rid of it without loosing much functionality. Even more, just think about how much bad and incredible slow software is writen in JS - the perfect proof, isn't it?
        – Raffzahn
        2 days ago






      • 2




        @Raffzahn It's completely different For one, BASIC had several incompatible implemen... Ohhh! It is the successor to BASIC!
        – wizzwizz4♦
        2 days ago






      • 2




        They're still not freshmen, which are first-year students. And I think you should give the OP the benefit of the doubt that he wouldn't assign the project if the students don't have the required background.
        – Barmar
        2 days ago








      2




      2




      @Tommy Well, I would love to avoide this, as there is no easy answer. Most important here might be, that, while the Z80 is somewhat "quirky", the 68k is anything but simple. With all the extension words (up to CPU32), a single instruction can have up to 11 words (22 byte) and decoding them is a serious mess. Then again, it all depends on the way the emulator is made up. The Z80 is a rather straight foreward 8080, easy to emulate, with a few modifiers, which can easy be handled. For the 68k , even only the original one, it will be way more work.
      – Raffzahn
      2 days ago




      @Tommy Well, I would love to avoide this, as there is no easy answer. Most important here might be, that, while the Z80 is somewhat "quirky", the 68k is anything but simple. With all the extension words (up to CPU32), a single instruction can have up to 11 words (22 byte) and decoding them is a serious mess. Then again, it all depends on the way the emulator is made up. The Z80 is a rather straight foreward 8080, easy to emulate, with a few modifiers, which can easy be handled. For the 68k , even only the original one, it will be way more work.
      – Raffzahn
      2 days ago




      2




      2




      "task fit for freshmen in such a limited time." He said these are 3rd year students, not freshmen, and they've already completed several prerequisites.
      – Barmar
      2 days ago




      "task fit for freshmen in such a limited time." He said these are 3rd year students, not freshmen, and they've already completed several prerequisites.
      – Barmar
      2 days ago




      2




      2




      @wizzwizz4 Well, no matter what what our personal opinion is, JS is the legal heir to BASIC. Serious and in every way! Just think about it. It not only runs n next to every actual computer, it's even installed by default, and there is next to no way to get rid of it without loosing much functionality. Even more, just think about how much bad and incredible slow software is writen in JS - the perfect proof, isn't it?
      – Raffzahn
      2 days ago




      @wizzwizz4 Well, no matter what what our personal opinion is, JS is the legal heir to BASIC. Serious and in every way! Just think about it. It not only runs n next to every actual computer, it's even installed by default, and there is next to no way to get rid of it without loosing much functionality. Even more, just think about how much bad and incredible slow software is writen in JS - the perfect proof, isn't it?
      – Raffzahn
      2 days ago




      2




      2




      @Raffzahn It's completely different For one, BASIC had several incompatible implemen... Ohhh! It is the successor to BASIC!
      – wizzwizz4♦
      2 days ago




      @Raffzahn It's completely different For one, BASIC had several incompatible implemen... Ohhh! It is the successor to BASIC!
      – wizzwizz4♦
      2 days ago




      2




      2




      They're still not freshmen, which are first-year students. And I think you should give the OP the benefit of the doubt that he wouldn't assign the project if the students don't have the required background.
      – Barmar
      2 days ago




      They're still not freshmen, which are first-year students. And I think you should give the OP the benefit of the doubt that he wouldn't assign the project if the students don't have the required background.
      – Barmar
      2 days ago










      up vote
      11
      down vote













      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.






      share|improve this answer










      New contributor




      Kamsof is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.


















      • ... and, for the record, the ColecoVision is the exact same collection of components, with different connecting logic and very slightly more complicated joypads. So an SG-1000 emulator is usually easy to extend to support both.
        – Tommy
        Nov 16 at 14:39






      • 2




        Also noteworthy that the 9918 is a complex chip, with sprites, complex modi and data, like he didn't want to use. Isn'T it?
        – Raffzahn
        Nov 16 at 16:45















      up vote
      11
      down vote













      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.






      share|improve this answer










      New contributor




      Kamsof is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.


















      • ... and, for the record, the ColecoVision is the exact same collection of components, with different connecting logic and very slightly more complicated joypads. So an SG-1000 emulator is usually easy to extend to support both.
        – Tommy
        Nov 16 at 14:39






      • 2




        Also noteworthy that the 9918 is a complex chip, with sprites, complex modi and data, like he didn't want to use. Isn'T it?
        – Raffzahn
        Nov 16 at 16:45













      up vote
      11
      down vote










      up vote
      11
      down vote









      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.






      share|improve this answer










      New contributor




      Kamsof is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      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.







      share|improve this answer










      New contributor




      Kamsof is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this answer



      share|improve this answer








      edited yesterday









      wizzwizz4♦

      8,081635102




      8,081635102






      New contributor




      Kamsof is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      answered Nov 16 at 14:01









      Kamsof

      1112




      1112




      New contributor




      Kamsof is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      Kamsof is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      Kamsof is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.












      • ... and, for the record, the ColecoVision is the exact same collection of components, with different connecting logic and very slightly more complicated joypads. So an SG-1000 emulator is usually easy to extend to support both.
        – Tommy
        Nov 16 at 14:39






      • 2




        Also noteworthy that the 9918 is a complex chip, with sprites, complex modi and data, like he didn't want to use. Isn'T it?
        – Raffzahn
        Nov 16 at 16:45


















      • ... and, for the record, the ColecoVision is the exact same collection of components, with different connecting logic and very slightly more complicated joypads. So an SG-1000 emulator is usually easy to extend to support both.
        – Tommy
        Nov 16 at 14:39






      • 2




        Also noteworthy that the 9918 is a complex chip, with sprites, complex modi and data, like he didn't want to use. Isn'T it?
        – Raffzahn
        Nov 16 at 16:45
















      ... and, for the record, the ColecoVision is the exact same collection of components, with different connecting logic and very slightly more complicated joypads. So an SG-1000 emulator is usually easy to extend to support both.
      – Tommy
      Nov 16 at 14:39




      ... and, for the record, the ColecoVision is the exact same collection of components, with different connecting logic and very slightly more complicated joypads. So an SG-1000 emulator is usually easy to extend to support both.
      – Tommy
      Nov 16 at 14:39




      2




      2




      Also noteworthy that the 9918 is a complex chip, with sprites, complex modi and data, like he didn't want to use. Isn'T it?
      – Raffzahn
      Nov 16 at 16:45




      Also noteworthy that the 9918 is a complex chip, with sprites, complex modi and data, like he didn't want to use. Isn'T it?
      – Raffzahn
      Nov 16 at 16:45










      up vote
      7
      down vote













      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.






      share|improve this answer

















      • 1




        I had the same instinct, but would extend by suggesting that SNA and Z80 and well-defined-enough snapshot formats that you needn't even worry about the tape emulation. And, let's be honest, TZX is a bit of a miasma at this point.
        – Tommy
        Nov 16 at 14:48






      • 3




        I believe the Spectrum ROM is now in the public domain, which may help (or make things too easy)
        – Stormcloud
        Nov 16 at 16:34










      • The ZX Spectrum is a great example of simple hardware, but also one of quite complex, cycle counting (Racing the Beam) programming to get out useable game effects.
        – Raffzahn
        Nov 16 at 16:46






      • 1




        @Tommy Oh, I would never suggest the ZX80/81 for the same reason. And while not a true Spectrum buff, I have seen some good timing dependant code for it. Most prominet screen manipulations after that part has been displayed, but before it runs once around. It's a very simple issue found on a whole lot of systems . No big issue, but timing dependant. For example simple emulation schemes that only throtle speed on a frame level will produce crap on faster emulation hosts ... and so on.
        – Raffzahn
        2 days ago






      • 2




        @Stormcloud The Spectrum ROM is not in the public domain, though permission has been granted to distribute it for use with emulators. The ZX80 and ZX81 ROMs have been released under the GPL.
        – john_e
        2 days ago

















      up vote
      7
      down vote













      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.






      share|improve this answer

















      • 1




        I had the same instinct, but would extend by suggesting that SNA and Z80 and well-defined-enough snapshot formats that you needn't even worry about the tape emulation. And, let's be honest, TZX is a bit of a miasma at this point.
        – Tommy
        Nov 16 at 14:48






      • 3




        I believe the Spectrum ROM is now in the public domain, which may help (or make things too easy)
        – Stormcloud
        Nov 16 at 16:34










      • The ZX Spectrum is a great example of simple hardware, but also one of quite complex, cycle counting (Racing the Beam) programming to get out useable game effects.
        – Raffzahn
        Nov 16 at 16:46






      • 1




        @Tommy Oh, I would never suggest the ZX80/81 for the same reason. And while not a true Spectrum buff, I have seen some good timing dependant code for it. Most prominet screen manipulations after that part has been displayed, but before it runs once around. It's a very simple issue found on a whole lot of systems . No big issue, but timing dependant. For example simple emulation schemes that only throtle speed on a frame level will produce crap on faster emulation hosts ... and so on.
        – Raffzahn
        2 days ago






      • 2




        @Stormcloud The Spectrum ROM is not in the public domain, though permission has been granted to distribute it for use with emulators. The ZX80 and ZX81 ROMs have been released under the GPL.
        – john_e
        2 days ago















      up vote
      7
      down vote










      up vote
      7
      down vote









      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.






      share|improve this answer












      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.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Nov 16 at 14:27









      Radovan Garabík

      743410




      743410








      • 1




        I had the same instinct, but would extend by suggesting that SNA and Z80 and well-defined-enough snapshot formats that you needn't even worry about the tape emulation. And, let's be honest, TZX is a bit of a miasma at this point.
        – Tommy
        Nov 16 at 14:48






      • 3




        I believe the Spectrum ROM is now in the public domain, which may help (or make things too easy)
        – Stormcloud
        Nov 16 at 16:34










      • The ZX Spectrum is a great example of simple hardware, but also one of quite complex, cycle counting (Racing the Beam) programming to get out useable game effects.
        – Raffzahn
        Nov 16 at 16:46






      • 1




        @Tommy Oh, I would never suggest the ZX80/81 for the same reason. And while not a true Spectrum buff, I have seen some good timing dependant code for it. Most prominet screen manipulations after that part has been displayed, but before it runs once around. It's a very simple issue found on a whole lot of systems . No big issue, but timing dependant. For example simple emulation schemes that only throtle speed on a frame level will produce crap on faster emulation hosts ... and so on.
        – Raffzahn
        2 days ago






      • 2




        @Stormcloud The Spectrum ROM is not in the public domain, though permission has been granted to distribute it for use with emulators. The ZX80 and ZX81 ROMs have been released under the GPL.
        – john_e
        2 days ago
















      • 1




        I had the same instinct, but would extend by suggesting that SNA and Z80 and well-defined-enough snapshot formats that you needn't even worry about the tape emulation. And, let's be honest, TZX is a bit of a miasma at this point.
        – Tommy
        Nov 16 at 14:48






      • 3




        I believe the Spectrum ROM is now in the public domain, which may help (or make things too easy)
        – Stormcloud
        Nov 16 at 16:34










      • The ZX Spectrum is a great example of simple hardware, but also one of quite complex, cycle counting (Racing the Beam) programming to get out useable game effects.
        – Raffzahn
        Nov 16 at 16:46






      • 1




        @Tommy Oh, I would never suggest the ZX80/81 for the same reason. And while not a true Spectrum buff, I have seen some good timing dependant code for it. Most prominet screen manipulations after that part has been displayed, but before it runs once around. It's a very simple issue found on a whole lot of systems . No big issue, but timing dependant. For example simple emulation schemes that only throtle speed on a frame level will produce crap on faster emulation hosts ... and so on.
        – Raffzahn
        2 days ago






      • 2




        @Stormcloud The Spectrum ROM is not in the public domain, though permission has been granted to distribute it for use with emulators. The ZX80 and ZX81 ROMs have been released under the GPL.
        – john_e
        2 days ago










      1




      1




      I had the same instinct, but would extend by suggesting that SNA and Z80 and well-defined-enough snapshot formats that you needn't even worry about the tape emulation. And, let's be honest, TZX is a bit of a miasma at this point.
      – Tommy
      Nov 16 at 14:48




      I had the same instinct, but would extend by suggesting that SNA and Z80 and well-defined-enough snapshot formats that you needn't even worry about the tape emulation. And, let's be honest, TZX is a bit of a miasma at this point.
      – Tommy
      Nov 16 at 14:48




      3




      3




      I believe the Spectrum ROM is now in the public domain, which may help (or make things too easy)
      – Stormcloud
      Nov 16 at 16:34




      I believe the Spectrum ROM is now in the public domain, which may help (or make things too easy)
      – Stormcloud
      Nov 16 at 16:34












      The ZX Spectrum is a great example of simple hardware, but also one of quite complex, cycle counting (Racing the Beam) programming to get out useable game effects.
      – Raffzahn
      Nov 16 at 16:46




      The ZX Spectrum is a great example of simple hardware, but also one of quite complex, cycle counting (Racing the Beam) programming to get out useable game effects.
      – Raffzahn
      Nov 16 at 16:46




      1




      1




      @Tommy Oh, I would never suggest the ZX80/81 for the same reason. And while not a true Spectrum buff, I have seen some good timing dependant code for it. Most prominet screen manipulations after that part has been displayed, but before it runs once around. It's a very simple issue found on a whole lot of systems . No big issue, but timing dependant. For example simple emulation schemes that only throtle speed on a frame level will produce crap on faster emulation hosts ... and so on.
      – Raffzahn
      2 days ago




      @Tommy Oh, I would never suggest the ZX80/81 for the same reason. And while not a true Spectrum buff, I have seen some good timing dependant code for it. Most prominet screen manipulations after that part has been displayed, but before it runs once around. It's a very simple issue found on a whole lot of systems . No big issue, but timing dependant. For example simple emulation schemes that only throtle speed on a frame level will produce crap on faster emulation hosts ... and so on.
      – Raffzahn
      2 days ago




      2




      2




      @Stormcloud The Spectrum ROM is not in the public domain, though permission has been granted to distribute it for use with emulators. The ZX80 and ZX81 ROMs have been released under the GPL.
      – john_e
      2 days ago






      @Stormcloud The Spectrum ROM is not in the public domain, though permission has been granted to distribute it for use with emulators. The ZX80 and ZX81 ROMs have been released under the GPL.
      – john_e
      2 days ago












      up vote
      7
      down vote













      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.



      enter image description here



      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.






      share|improve this answer























      • Except, the vectrex also fots well the 'Racing the Beam' cathegory, doesn't it?
        – Raffzahn
        2 days ago






      • 1




        @Raffzahn, as I understand it, the Vectrex CPU controls the electron beam -- exactly the opposite of a "racing the beam" situation where software needs to make precisely-timed state changes to keep up with an externally-timed raster scan display.
        – Mark
        2 days ago










      • @Mark It's the same with the VCS. Here as well the beam is controlled by the CPU. Without the CPU accessing WSYNC every line and before the line is done, the screen will falter. And as far as I understand the OP, it's exactly about not recreating a system with strict timing requirements - which are essential for the Vectrex.
        – Raffzahn
        2 days ago










      • @Raffzahn: The CPU in the VCS controls the vertical, but it does not control the horizontal. It's not unusual for a game to output dozens or even hundreds of scan lines without an intervening WSYNC. In the absence of a WSYNC, the beam will be at the same horizontal position every 76th cycle. Storing WSYNC is often the easiest way to wait for the beam to reach the right side of the displayed region, but it's hardly the only way. A programmer who was so inclined could exploit the intricate details of sprite motion and behaviors to write a game that never used WSYNC at all.
        – supercat
        2 days ago










      • Um, folks, we are talking about an emulator here. There is not going to be a problem with the phosphors fading while the emulated CPU takes too long to draw the next frame. There is no "beam" and there is certainly no reason the emulator would need to "race" since the emulator display will remain quite static as long as necessary between frames.
        – Brian H
        2 days ago















      up vote
      7
      down vote













      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.



      enter image description here



      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.






      share|improve this answer























      • Except, the vectrex also fots well the 'Racing the Beam' cathegory, doesn't it?
        – Raffzahn
        2 days ago






      • 1




        @Raffzahn, as I understand it, the Vectrex CPU controls the electron beam -- exactly the opposite of a "racing the beam" situation where software needs to make precisely-timed state changes to keep up with an externally-timed raster scan display.
        – Mark
        2 days ago










      • @Mark It's the same with the VCS. Here as well the beam is controlled by the CPU. Without the CPU accessing WSYNC every line and before the line is done, the screen will falter. And as far as I understand the OP, it's exactly about not recreating a system with strict timing requirements - which are essential for the Vectrex.
        – Raffzahn
        2 days ago










      • @Raffzahn: The CPU in the VCS controls the vertical, but it does not control the horizontal. It's not unusual for a game to output dozens or even hundreds of scan lines without an intervening WSYNC. In the absence of a WSYNC, the beam will be at the same horizontal position every 76th cycle. Storing WSYNC is often the easiest way to wait for the beam to reach the right side of the displayed region, but it's hardly the only way. A programmer who was so inclined could exploit the intricate details of sprite motion and behaviors to write a game that never used WSYNC at all.
        – supercat
        2 days ago










      • Um, folks, we are talking about an emulator here. There is not going to be a problem with the phosphors fading while the emulated CPU takes too long to draw the next frame. There is no "beam" and there is certainly no reason the emulator would need to "race" since the emulator display will remain quite static as long as necessary between frames.
        – Brian H
        2 days ago













      up vote
      7
      down vote










      up vote
      7
      down vote









      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.



      enter image description here



      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.






      share|improve this answer














      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.



      enter image description here



      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.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited 2 days ago

























      answered 2 days ago









      Brian H

      15.7k57135




      15.7k57135












      • Except, the vectrex also fots well the 'Racing the Beam' cathegory, doesn't it?
        – Raffzahn
        2 days ago






      • 1




        @Raffzahn, as I understand it, the Vectrex CPU controls the electron beam -- exactly the opposite of a "racing the beam" situation where software needs to make precisely-timed state changes to keep up with an externally-timed raster scan display.
        – Mark
        2 days ago










      • @Mark It's the same with the VCS. Here as well the beam is controlled by the CPU. Without the CPU accessing WSYNC every line and before the line is done, the screen will falter. And as far as I understand the OP, it's exactly about not recreating a system with strict timing requirements - which are essential for the Vectrex.
        – Raffzahn
        2 days ago










      • @Raffzahn: The CPU in the VCS controls the vertical, but it does not control the horizontal. It's not unusual for a game to output dozens or even hundreds of scan lines without an intervening WSYNC. In the absence of a WSYNC, the beam will be at the same horizontal position every 76th cycle. Storing WSYNC is often the easiest way to wait for the beam to reach the right side of the displayed region, but it's hardly the only way. A programmer who was so inclined could exploit the intricate details of sprite motion and behaviors to write a game that never used WSYNC at all.
        – supercat
        2 days ago










      • Um, folks, we are talking about an emulator here. There is not going to be a problem with the phosphors fading while the emulated CPU takes too long to draw the next frame. There is no "beam" and there is certainly no reason the emulator would need to "race" since the emulator display will remain quite static as long as necessary between frames.
        – Brian H
        2 days ago


















      • Except, the vectrex also fots well the 'Racing the Beam' cathegory, doesn't it?
        – Raffzahn
        2 days ago






      • 1




        @Raffzahn, as I understand it, the Vectrex CPU controls the electron beam -- exactly the opposite of a "racing the beam" situation where software needs to make precisely-timed state changes to keep up with an externally-timed raster scan display.
        – Mark
        2 days ago










      • @Mark It's the same with the VCS. Here as well the beam is controlled by the CPU. Without the CPU accessing WSYNC every line and before the line is done, the screen will falter. And as far as I understand the OP, it's exactly about not recreating a system with strict timing requirements - which are essential for the Vectrex.
        – Raffzahn
        2 days ago










      • @Raffzahn: The CPU in the VCS controls the vertical, but it does not control the horizontal. It's not unusual for a game to output dozens or even hundreds of scan lines without an intervening WSYNC. In the absence of a WSYNC, the beam will be at the same horizontal position every 76th cycle. Storing WSYNC is often the easiest way to wait for the beam to reach the right side of the displayed region, but it's hardly the only way. A programmer who was so inclined could exploit the intricate details of sprite motion and behaviors to write a game that never used WSYNC at all.
        – supercat
        2 days ago










      • Um, folks, we are talking about an emulator here. There is not going to be a problem with the phosphors fading while the emulated CPU takes too long to draw the next frame. There is no "beam" and there is certainly no reason the emulator would need to "race" since the emulator display will remain quite static as long as necessary between frames.
        – Brian H
        2 days ago
















      Except, the vectrex also fots well the 'Racing the Beam' cathegory, doesn't it?
      – Raffzahn
      2 days ago




      Except, the vectrex also fots well the 'Racing the Beam' cathegory, doesn't it?
      – Raffzahn
      2 days ago




      1




      1




      @Raffzahn, as I understand it, the Vectrex CPU controls the electron beam -- exactly the opposite of a "racing the beam" situation where software needs to make precisely-timed state changes to keep up with an externally-timed raster scan display.
      – Mark
      2 days ago




      @Raffzahn, as I understand it, the Vectrex CPU controls the electron beam -- exactly the opposite of a "racing the beam" situation where software needs to make precisely-timed state changes to keep up with an externally-timed raster scan display.
      – Mark
      2 days ago












      @Mark It's the same with the VCS. Here as well the beam is controlled by the CPU. Without the CPU accessing WSYNC every line and before the line is done, the screen will falter. And as far as I understand the OP, it's exactly about not recreating a system with strict timing requirements - which are essential for the Vectrex.
      – Raffzahn
      2 days ago




      @Mark It's the same with the VCS. Here as well the beam is controlled by the CPU. Without the CPU accessing WSYNC every line and before the line is done, the screen will falter. And as far as I understand the OP, it's exactly about not recreating a system with strict timing requirements - which are essential for the Vectrex.
      – Raffzahn
      2 days ago












      @Raffzahn: The CPU in the VCS controls the vertical, but it does not control the horizontal. It's not unusual for a game to output dozens or even hundreds of scan lines without an intervening WSYNC. In the absence of a WSYNC, the beam will be at the same horizontal position every 76th cycle. Storing WSYNC is often the easiest way to wait for the beam to reach the right side of the displayed region, but it's hardly the only way. A programmer who was so inclined could exploit the intricate details of sprite motion and behaviors to write a game that never used WSYNC at all.
      – supercat
      2 days ago




      @Raffzahn: The CPU in the VCS controls the vertical, but it does not control the horizontal. It's not unusual for a game to output dozens or even hundreds of scan lines without an intervening WSYNC. In the absence of a WSYNC, the beam will be at the same horizontal position every 76th cycle. Storing WSYNC is often the easiest way to wait for the beam to reach the right side of the displayed region, but it's hardly the only way. A programmer who was so inclined could exploit the intricate details of sprite motion and behaviors to write a game that never used WSYNC at all.
      – supercat
      2 days ago












      Um, folks, we are talking about an emulator here. There is not going to be a problem with the phosphors fading while the emulated CPU takes too long to draw the next frame. There is no "beam" and there is certainly no reason the emulator would need to "race" since the emulator display will remain quite static as long as necessary between frames.
      – Brian H
      2 days ago




      Um, folks, we are talking about an emulator here. There is not going to be a problem with the phosphors fading while the emulated CPU takes too long to draw the next frame. There is no "beam" and there is certainly no reason the emulator would need to "race" since the emulator display will remain quite static as long as necessary between frames.
      – Brian H
      2 days ago










      up vote
      6
      down vote













      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,






      share|improve this answer























      • I'd argue that the Oric architecture discourages raster racing by not having a side channel of video control registers and not being set up so that racing could conceivably increase your colour resolution (contrasted with a Spectrum). If it only had two HIRES buffers though, I'd state that more confidently. Would you agree with that?
        – Tommy
        2 days ago










      • @Tommy I'm not too familiar with the Oric video circuitry. What I would state in any case is that the Oric had such a short life and such a limited user base that sophisticated techniques to tweak the video like we know from the ZX Spectrum weren't developed (at least not during the active life of the computer, there's a number of interesting demos here demozoo.org/platforms/49)
        – tofro
        2 days ago












      • Oh, then I'll provide better reasoning: the Oric video chip has modal state, including text or graphics mode, but no exposed registers. Everything is set by control bytes within the video stream — including foreground and background attributes. People tend to complain about that because it means that if you want gapless graphics you're limited to four colours per line, two of them being the bitwise complements of the other two. Some of the modern games still look really good though — e.g. Stormlord youtube.com/watch?v=QSDy-BC580M
        – Tommy
        2 days ago










      • @Tommy The serial attributes make the programming a bit more tricky, I'd guess, but the amount of attribute clash is even better than on the ZX Spectrum, I reckon.
        – tofro
        2 days ago















      up vote
      6
      down vote













      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,






      share|improve this answer























      • I'd argue that the Oric architecture discourages raster racing by not having a side channel of video control registers and not being set up so that racing could conceivably increase your colour resolution (contrasted with a Spectrum). If it only had two HIRES buffers though, I'd state that more confidently. Would you agree with that?
        – Tommy
        2 days ago










      • @Tommy I'm not too familiar with the Oric video circuitry. What I would state in any case is that the Oric had such a short life and such a limited user base that sophisticated techniques to tweak the video like we know from the ZX Spectrum weren't developed (at least not during the active life of the computer, there's a number of interesting demos here demozoo.org/platforms/49)
        – tofro
        2 days ago












      • Oh, then I'll provide better reasoning: the Oric video chip has modal state, including text or graphics mode, but no exposed registers. Everything is set by control bytes within the video stream — including foreground and background attributes. People tend to complain about that because it means that if you want gapless graphics you're limited to four colours per line, two of them being the bitwise complements of the other two. Some of the modern games still look really good though — e.g. Stormlord youtube.com/watch?v=QSDy-BC580M
        – Tommy
        2 days ago










      • @Tommy The serial attributes make the programming a bit more tricky, I'd guess, but the amount of attribute clash is even better than on the ZX Spectrum, I reckon.
        – tofro
        2 days ago













      up vote
      6
      down vote










      up vote
      6
      down vote









      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,






      share|improve this answer














      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,







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited 2 days ago

























      answered Nov 16 at 16:30









      tofro

      14.2k32980




      14.2k32980












      • I'd argue that the Oric architecture discourages raster racing by not having a side channel of video control registers and not being set up so that racing could conceivably increase your colour resolution (contrasted with a Spectrum). If it only had two HIRES buffers though, I'd state that more confidently. Would you agree with that?
        – Tommy
        2 days ago










      • @Tommy I'm not too familiar with the Oric video circuitry. What I would state in any case is that the Oric had such a short life and such a limited user base that sophisticated techniques to tweak the video like we know from the ZX Spectrum weren't developed (at least not during the active life of the computer, there's a number of interesting demos here demozoo.org/platforms/49)
        – tofro
        2 days ago












      • Oh, then I'll provide better reasoning: the Oric video chip has modal state, including text or graphics mode, but no exposed registers. Everything is set by control bytes within the video stream — including foreground and background attributes. People tend to complain about that because it means that if you want gapless graphics you're limited to four colours per line, two of them being the bitwise complements of the other two. Some of the modern games still look really good though — e.g. Stormlord youtube.com/watch?v=QSDy-BC580M
        – Tommy
        2 days ago










      • @Tommy The serial attributes make the programming a bit more tricky, I'd guess, but the amount of attribute clash is even better than on the ZX Spectrum, I reckon.
        – tofro
        2 days ago


















      • I'd argue that the Oric architecture discourages raster racing by not having a side channel of video control registers and not being set up so that racing could conceivably increase your colour resolution (contrasted with a Spectrum). If it only had two HIRES buffers though, I'd state that more confidently. Would you agree with that?
        – Tommy
        2 days ago










      • @Tommy I'm not too familiar with the Oric video circuitry. What I would state in any case is that the Oric had such a short life and such a limited user base that sophisticated techniques to tweak the video like we know from the ZX Spectrum weren't developed (at least not during the active life of the computer, there's a number of interesting demos here demozoo.org/platforms/49)
        – tofro
        2 days ago












      • Oh, then I'll provide better reasoning: the Oric video chip has modal state, including text or graphics mode, but no exposed registers. Everything is set by control bytes within the video stream — including foreground and background attributes. People tend to complain about that because it means that if you want gapless graphics you're limited to four colours per line, two of them being the bitwise complements of the other two. Some of the modern games still look really good though — e.g. Stormlord youtube.com/watch?v=QSDy-BC580M
        – Tommy
        2 days ago










      • @Tommy The serial attributes make the programming a bit more tricky, I'd guess, but the amount of attribute clash is even better than on the ZX Spectrum, I reckon.
        – tofro
        2 days ago
















      I'd argue that the Oric architecture discourages raster racing by not having a side channel of video control registers and not being set up so that racing could conceivably increase your colour resolution (contrasted with a Spectrum). If it only had two HIRES buffers though, I'd state that more confidently. Would you agree with that?
      – Tommy
      2 days ago




      I'd argue that the Oric architecture discourages raster racing by not having a side channel of video control registers and not being set up so that racing could conceivably increase your colour resolution (contrasted with a Spectrum). If it only had two HIRES buffers though, I'd state that more confidently. Would you agree with that?
      – Tommy
      2 days ago












      @Tommy I'm not too familiar with the Oric video circuitry. What I would state in any case is that the Oric had such a short life and such a limited user base that sophisticated techniques to tweak the video like we know from the ZX Spectrum weren't developed (at least not during the active life of the computer, there's a number of interesting demos here demozoo.org/platforms/49)
      – tofro
      2 days ago






      @Tommy I'm not too familiar with the Oric video circuitry. What I would state in any case is that the Oric had such a short life and such a limited user base that sophisticated techniques to tweak the video like we know from the ZX Spectrum weren't developed (at least not during the active life of the computer, there's a number of interesting demos here demozoo.org/platforms/49)
      – tofro
      2 days ago














      Oh, then I'll provide better reasoning: the Oric video chip has modal state, including text or graphics mode, but no exposed registers. Everything is set by control bytes within the video stream — including foreground and background attributes. People tend to complain about that because it means that if you want gapless graphics you're limited to four colours per line, two of them being the bitwise complements of the other two. Some of the modern games still look really good though — e.g. Stormlord youtube.com/watch?v=QSDy-BC580M
      – Tommy
      2 days ago




      Oh, then I'll provide better reasoning: the Oric video chip has modal state, including text or graphics mode, but no exposed registers. Everything is set by control bytes within the video stream — including foreground and background attributes. People tend to complain about that because it means that if you want gapless graphics you're limited to four colours per line, two of them being the bitwise complements of the other two. Some of the modern games still look really good though — e.g. Stormlord youtube.com/watch?v=QSDy-BC580M
      – Tommy
      2 days ago












      @Tommy The serial attributes make the programming a bit more tricky, I'd guess, but the amount of attribute clash is even better than on the ZX Spectrum, I reckon.
      – tofro
      2 days ago




      @Tommy The serial attributes make the programming a bit more tricky, I'd guess, but the amount of attribute clash is even better than on the ZX Spectrum, I reckon.
      – tofro
      2 days ago










      up vote
      5
      down vote













      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?






      share|improve this answer



























        up vote
        5
        down vote













        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?






        share|improve this answer

























          up vote
          5
          down vote










          up vote
          5
          down vote









          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?






          share|improve this answer














          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?







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 2 days ago

























          answered 2 days ago









          Spektre

          2,705315




          2,705315






















              up vote
              4
              down vote













              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.






              share|improve this answer





















              • Yes, all three (PET, TRS, Superboard (I totally forgot about the later one) ) are great simple machines and great for emulations. But also missing a good selection of ready to use games. Not to mention colour and alike eople may expect today.
                – Raffzahn
                2 days ago















              up vote
              4
              down vote













              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.






              share|improve this answer





















              • Yes, all three (PET, TRS, Superboard (I totally forgot about the later one) ) are great simple machines and great for emulations. But also missing a good selection of ready to use games. Not to mention colour and alike eople may expect today.
                – Raffzahn
                2 days ago













              up vote
              4
              down vote










              up vote
              4
              down vote









              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.






              share|improve this answer












              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.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered 2 days ago









              PeterI

              3,0231729




              3,0231729












              • Yes, all three (PET, TRS, Superboard (I totally forgot about the later one) ) are great simple machines and great for emulations. But also missing a good selection of ready to use games. Not to mention colour and alike eople may expect today.
                – Raffzahn
                2 days ago


















              • Yes, all three (PET, TRS, Superboard (I totally forgot about the later one) ) are great simple machines and great for emulations. But also missing a good selection of ready to use games. Not to mention colour and alike eople may expect today.
                – Raffzahn
                2 days ago
















              Yes, all three (PET, TRS, Superboard (I totally forgot about the later one) ) are great simple machines and great for emulations. But also missing a good selection of ready to use games. Not to mention colour and alike eople may expect today.
              – Raffzahn
              2 days ago




              Yes, all three (PET, TRS, Superboard (I totally forgot about the later one) ) are great simple machines and great for emulations. But also missing a good selection of ready to use games. Not to mention colour and alike eople may expect today.
              – Raffzahn
              2 days ago










              up vote
              4
              down vote













              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.






              share|improve this answer





















              • For what it's worth, I think Space Invaders is an inspired suggestion. If memory serves it's just an 8080 with a 1bpp bitmapped screen, some port IO for the controls, no attempt to race the raster, audio that is just of the form "trigger noise X now", very relaxed accuracy requirements, and it produces a game that they still occasionally try to sell now. It's only the legality issue that might give pause, though I'm always fuzzy on academic exceptions.
                – Tommy
                3 hours ago















              up vote
              4
              down vote













              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.






              share|improve this answer





















              • For what it's worth, I think Space Invaders is an inspired suggestion. If memory serves it's just an 8080 with a 1bpp bitmapped screen, some port IO for the controls, no attempt to race the raster, audio that is just of the form "trigger noise X now", very relaxed accuracy requirements, and it produces a game that they still occasionally try to sell now. It's only the legality issue that might give pause, though I'm always fuzzy on academic exceptions.
                – Tommy
                3 hours ago













              up vote
              4
              down vote










              up vote
              4
              down vote









              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.






              share|improve this answer












              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.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered 18 hours ago









              8bitworkshop

              39123




              39123












              • For what it's worth, I think Space Invaders is an inspired suggestion. If memory serves it's just an 8080 with a 1bpp bitmapped screen, some port IO for the controls, no attempt to race the raster, audio that is just of the form "trigger noise X now", very relaxed accuracy requirements, and it produces a game that they still occasionally try to sell now. It's only the legality issue that might give pause, though I'm always fuzzy on academic exceptions.
                – Tommy
                3 hours ago


















              • For what it's worth, I think Space Invaders is an inspired suggestion. If memory serves it's just an 8080 with a 1bpp bitmapped screen, some port IO for the controls, no attempt to race the raster, audio that is just of the form "trigger noise X now", very relaxed accuracy requirements, and it produces a game that they still occasionally try to sell now. It's only the legality issue that might give pause, though I'm always fuzzy on academic exceptions.
                – Tommy
                3 hours ago
















              For what it's worth, I think Space Invaders is an inspired suggestion. If memory serves it's just an 8080 with a 1bpp bitmapped screen, some port IO for the controls, no attempt to race the raster, audio that is just of the form "trigger noise X now", very relaxed accuracy requirements, and it produces a game that they still occasionally try to sell now. It's only the legality issue that might give pause, though I'm always fuzzy on academic exceptions.
              – Tommy
              3 hours ago




              For what it's worth, I think Space Invaders is an inspired suggestion. If memory serves it's just an 8080 with a 1bpp bitmapped screen, some port IO for the controls, no attempt to race the raster, audio that is just of the form "trigger noise X now", very relaxed accuracy requirements, and it produces a game that they still occasionally try to sell now. It's only the legality issue that might give pause, though I'm always fuzzy on academic exceptions.
              – Tommy
              3 hours ago










              up vote
              3
              down vote













              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.






              share|improve this answer



















              • 1




                With a potential advantage of a CP/M machine being that there's bound to be at least one for which a mere 8080 emulation will do?
                – Tommy
                Nov 16 at 15:21










              • Nice, but then again, there are not raly many games for the IBM in text mode, are there?
                – Raffzahn
                Nov 16 at 16:46










              • @Raffzahn - there only needs to be one.
                – Jules
                18 hours ago










              • @Jules Hehehe ... yeah right. But then I'd say a minimum 8080 will do the trick
                – Raffzahn
                18 hours ago















              up vote
              3
              down vote













              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.






              share|improve this answer



















              • 1




                With a potential advantage of a CP/M machine being that there's bound to be at least one for which a mere 8080 emulation will do?
                – Tommy
                Nov 16 at 15:21










              • Nice, but then again, there are not raly many games for the IBM in text mode, are there?
                – Raffzahn
                Nov 16 at 16:46










              • @Raffzahn - there only needs to be one.
                – Jules
                18 hours ago










              • @Jules Hehehe ... yeah right. But then I'd say a minimum 8080 will do the trick
                – Raffzahn
                18 hours ago













              up vote
              3
              down vote










              up vote
              3
              down vote









              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.






              share|improve this answer














              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.







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Nov 16 at 15:24

























              answered Nov 16 at 15:16









              lvd

              2,588518




              2,588518








              • 1




                With a potential advantage of a CP/M machine being that there's bound to be at least one for which a mere 8080 emulation will do?
                – Tommy
                Nov 16 at 15:21










              • Nice, but then again, there are not raly many games for the IBM in text mode, are there?
                – Raffzahn
                Nov 16 at 16:46










              • @Raffzahn - there only needs to be one.
                – Jules
                18 hours ago










              • @Jules Hehehe ... yeah right. But then I'd say a minimum 8080 will do the trick
                – Raffzahn
                18 hours ago














              • 1




                With a potential advantage of a CP/M machine being that there's bound to be at least one for which a mere 8080 emulation will do?
                – Tommy
                Nov 16 at 15:21










              • Nice, but then again, there are not raly many games for the IBM in text mode, are there?
                – Raffzahn
                Nov 16 at 16:46










              • @Raffzahn - there only needs to be one.
                – Jules
                18 hours ago










              • @Jules Hehehe ... yeah right. But then I'd say a minimum 8080 will do the trick
                – Raffzahn
                18 hours ago








              1




              1




              With a potential advantage of a CP/M machine being that there's bound to be at least one for which a mere 8080 emulation will do?
              – Tommy
              Nov 16 at 15:21




              With a potential advantage of a CP/M machine being that there's bound to be at least one for which a mere 8080 emulation will do?
              – Tommy
              Nov 16 at 15:21












              Nice, but then again, there are not raly many games for the IBM in text mode, are there?
              – Raffzahn
              Nov 16 at 16:46




              Nice, but then again, there are not raly many games for the IBM in text mode, are there?
              – Raffzahn
              Nov 16 at 16:46












              @Raffzahn - there only needs to be one.
              – Jules
              18 hours ago




              @Raffzahn - there only needs to be one.
              – Jules
              18 hours ago












              @Jules Hehehe ... yeah right. But then I'd say a minimum 8080 will do the trick
              – Raffzahn
              18 hours ago




              @Jules Hehehe ... yeah right. But then I'd say a minimum 8080 will do the trick
              – Raffzahn
              18 hours ago










              up vote
              3
              down vote













              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.






              share|improve this answer



















              • 3




                The CPU might be simple, but emulating peripherals (display etc) would probably still be a considerable task
                – Igor Skochinsky
                2 days ago















              up vote
              3
              down vote













              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.






              share|improve this answer



















              • 3




                The CPU might be simple, but emulating peripherals (display etc) would probably still be a considerable task
                – Igor Skochinsky
                2 days ago













              up vote
              3
              down vote










              up vote
              3
              down vote









              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.






              share|improve this answer














              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.







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited 2 days ago

























              answered Nov 16 at 16:47









              hotpaw2

              2,746522




              2,746522








              • 3




                The CPU might be simple, but emulating peripherals (display etc) would probably still be a considerable task
                – Igor Skochinsky
                2 days ago














              • 3




                The CPU might be simple, but emulating peripherals (display etc) would probably still be a considerable task
                – Igor Skochinsky
                2 days ago








              3




              3




              The CPU might be simple, but emulating peripherals (display etc) would probably still be a considerable task
              – Igor Skochinsky
              2 days ago




              The CPU might be simple, but emulating peripherals (display etc) would probably still be a considerable task
              – Igor Skochinsky
              2 days ago










              up vote
              3
              down vote













              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.






              share|improve this answer





















              • An interesting point is that most of the systems mentioned above have either Z80 or 6502 CPUs, both of which are somewhat lacking in terms of their supported addressing modes. If coverage of addressing modes is important, the PDP-8 has a much better selection of them to demonstrate.
                – Jules
                18 hours ago















              up vote
              3
              down vote













              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.






              share|improve this answer





















              • An interesting point is that most of the systems mentioned above have either Z80 or 6502 CPUs, both of which are somewhat lacking in terms of their supported addressing modes. If coverage of addressing modes is important, the PDP-8 has a much better selection of them to demonstrate.
                – Jules
                18 hours ago













              up vote
              3
              down vote










              up vote
              3
              down vote









              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.






              share|improve this answer












              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.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered 22 hours ago









              Alex Taylor

              813




              813












              • An interesting point is that most of the systems mentioned above have either Z80 or 6502 CPUs, both of which are somewhat lacking in terms of their supported addressing modes. If coverage of addressing modes is important, the PDP-8 has a much better selection of them to demonstrate.
                – Jules
                18 hours ago


















              • An interesting point is that most of the systems mentioned above have either Z80 or 6502 CPUs, both of which are somewhat lacking in terms of their supported addressing modes. If coverage of addressing modes is important, the PDP-8 has a much better selection of them to demonstrate.
                – Jules
                18 hours ago
















              An interesting point is that most of the systems mentioned above have either Z80 or 6502 CPUs, both of which are somewhat lacking in terms of their supported addressing modes. If coverage of addressing modes is important, the PDP-8 has a much better selection of them to demonstrate.
              – Jules
              18 hours ago




              An interesting point is that most of the systems mentioned above have either Z80 or 6502 CPUs, both of which are somewhat lacking in terms of their supported addressing modes. If coverage of addressing modes is important, the PDP-8 has a much better selection of them to demonstrate.
              – Jules
              18 hours ago










              up vote
              2
              down vote













              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.






              share|improve this answer

























                up vote
                2
                down vote













                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.






                share|improve this answer























                  up vote
                  2
                  down vote










                  up vote
                  2
                  down vote









                  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.






                  share|improve this answer












                  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.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered yesterday









                  Jules

                  8,89022347




                  8,89022347

















                      protected by wizzwizz4♦ 2 days ago



                      Thank you for your interest in this question.
                      Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



                      Would you like to answer one of these unanswered questions instead?



                      Popular posts from this blog

                      android studio warns about leanback feature tag usage required on manifest while using Unity exported app?

                      Image
                      .everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box; } 0 This is a simple project showing cubes on Unity, exported to android project and imported on Android studio. On maifest file it showed following warning: Expecting <uses-feature android:name="android.software.leanback" android:required="false" /> tag I have no information about it. And also on default emptyview android project does not use/mention this feature. I know it is required by TV's and such but why its not added by default? Why is this? And Should I concern about it? android unity3d
                      Read more

                      SQL update select statement

                      Image
                      0 I'm trying to update an entry in my database (postgresql). I'm having a problem with updating the query: INSERT INTO prices (price, product_id) SELECT product_price, commn_id FROM products_temp as prod WHERE NOT EXISTS (SELECT * FROM prices od WHERE prod.commn_id = od.product_id) OR prod.product_price != ( SELECT price FROM prices as p WHERE p.product_id = prod.commn_id order by p.end desc LIMIT 1 ) Query works fine when i delete: OR prod.product_price != ( SELECT price FROM prices as p WHERE p.product_id = prod.commn_id order by p.end desc LIMIT 1 ) So it seems to me that it's looping through this operation. My question is, how can I fix it? sql postgresql
                      Read more

                      'app-layout' is not a known element: how to share Component with different Modules

                      Image
                      0 My application was working fine until I decided to go with lazy loading: So, my shared component looks like this: import { Component, Renderer2 } from '@angular/core'; export interface FormModel { captcha?: string; } @Component({ selector: 'app-layout', templateUrl: './app-layout.component.html', styleUrls: ['./app-layout.css'] }) export class FullLayoutComponent { } app-layout.component.ts I am using this component in my Another component say school-home.component.html like this: <app-layout> </app-layout> and it was working fine until I created a Module school-home.module.ts like this: import { NgModule } from '@angular/core'; import { CommonModule } from '@angular/common'; import { SchoolhomeRoutingModule
                      Read more