That's an incorrect definition of a 'simulator' when compared to an emulator:
"Basically what happened is that people created their own implementation (clones) of the game Pong. In this case they simulated the looks and game behavior of Pong."
The term "instruction set simulator" has a long tradition especially in the academic circles.
Emulation is the act of fooling something (software) to think that something actually exists (processor executing an instruction set). Emulation can be achieved by simulation (that is, looking at the structure and operation of the thing being emulated and replicating that to a necessary level of detail by the process of simulation) or by other means (e.g. translation).
An emulator therefore can be a simulator. But it doesn't necessarily have to be.
CHIP-8 is by far the easiest emulator project you can start with, but be wary - chances are it won't work perfectly from the get go and you'll end up writing an assembler, disassembler and debugger. There are tons of documentation and implementations out there to help you out.
I wrote one[1] some time ago and it's very rewarding to pop in random games and see how badly they perform on your faulty/incomplete "machine" (ex: tetrominoes not dropping in tetris because the hardware timer was not implemented).
> it won't work perfectly from the get go and you'll end up writing an assembler, disassembler and debugger. There are tons of documentation and implementations out there to help you out.
It's really interesting, but I found some bits of the "end game" frustrating, I didn't finish mine because I was never sure how keyboard events had to be handled in the face of cycles coalescing (the emulator's rendering loop works at 60fps and the timers are 60Hz, but IIRC most programs which are are written assuming 500~1000Hz, this causes issues when a key is pressed over an entire frame — or more — and the program uses SKP or SKNP rather than the better-behaved LDxK).
Then there's the weird stuff like the SYS opcode which kinda exists but should not be implemented but has two sub-opcodes which should be.
I wonder if there's a "test harness" for chip8 emulators somewhere (hook in a chip8 emulator somehow and it tells you what you fucked up).
* SVision-8, an emulator (CHIP8 and SCHIP), various links (possibly dead) and a few chip8 and schip games for testing: http://devernay.free.fr/hacks/chip8/
I went ahead and wrote one in Golang (the graphics instructions are still incomplete because I don't want to deal with SDL's Golang port that's not using my mac's hardware acceleration for some reason) a few months back -- following a fantastic screencast on doing the same in C++. It taught me a lot about the innards of how any machine executes instructions, what can be done using those instructions, the layout of memory, registers and how to use them, so on and so forth.
I'm still a newbie to Virtual Machines but I would highly recommend anyone to try their hand at writing a Chip8 VM.
I wrote a CHIP-8 emulator as a warm up to writing a NES emulator. Then I decided I didn't want to write an NES emulator.
I do recommend this as a starting point, though. You'll learn a ton.
"Basically what happened is that people created their own implementation (clones) of the game Pong. In this case they simulated the looks and game behavior of Pong."
The term "instruction set simulator" has a long tradition especially in the academic circles.
Emulation is the act of fooling something (software) to think that something actually exists (processor executing an instruction set). Emulation can be achieved by simulation (that is, looking at the structure and operation of the thing being emulated and replicating that to a necessary level of detail by the process of simulation) or by other means (e.g. translation).
An emulator therefore can be a simulator. But it doesn't necessarily have to be.