Emulation - Computerphile

This dude taught my CS fundamentals in my first year of uni at Nottingham, great teacher

If an emulator ran a game and Nintendo wasn't around to hear it, would it make a sound?

The breakdown of an instruction opcode into its component bits can be explained by looking at how the CPU hardware decodes and follows instructions. Ben Eater’s “8-bit computer build” series of videos does a great job of this.

Enjoyed the video. I started an Atari2600 emulator about four years ago and it still consumes a lot my time. There's always something new to think about, things you would never imagine touching when you start. For example, in addition to the CPU the RIOT and the TIA the display itself is an important component. The only displays available at that time were CRTs, so games were written with that in mind. So to be a truly accurate emulation, you need to think about how the TV signal works. The cartridges too are full of mystery. Even when the 2600 was in its heyday, cartridges were more becoming more complex; different bank switching methods, additional RAM, etc. Each of these have their own little quirks that need to be accounted for. And that's before we get into the cartridges of today which can include ARM chips and WiFi connections. It's a fascinating hobby but it's a very deep rabbit hole.

Since he mentioned the Apple M1’s capability to emulate x86 towards the end: Apple even built parts of this emulation into the hardware itself (I believe parts of the memory model stuff as well), in order to make this emulation a lot faster than with pure software and thus make the transition from x86 to ARM much smoother.

As soon I saw the title of this video, I had to put a like. I've been following the emulation scene since the very early beginnings and it has always stunned me how they could create a software with such precision that could emulate not just the single instructions of a processor, that's fairly easy, but the whole architecture of a physical electronic object, with such precision. I think that, together with crypthography and data compression, the emulation represents the top peak reached by programming ever.

Timing, as they say, is everything...

A further simplification of the 6502 emulator comes from most opcodes of the form $x2, for example $02 which will simply crash the CPU, hanging it until reset. And all that simplification goes down the drain when having to implement "illegal opcodes" which are instructions that are not documented and were not even intended to be implemented by the creators of the CPU. But the CPU doesn't reject them and many of them actually do more or less useful things. Some are useful to make software a little bit smaller and faster. Others can be used to obscure software, such as copy protections, by making it impossible to disassemble the code with a standard disassembler. One of the details that's making an Amiga emulator hard is a coprocessor named Copper which is crucially important for video output. For purposes of the emulation means there are now two processors, the 680x0 and copper to be emulated and they need to run absolutely in sync. Additional complexity from today's video output working entirely differently at a hardware level and an emulator would be running on top of a giant layer of software of a modern GUI, graphics driver and OS. Doing too much 6502 has strange effects onthe brain. I saw the A9 written on your piece of paper and my brain still immediately said ”:LDA"” like 35 years after learning to program the 6502. Though the 6502 was my first CPU I never got the hang of little endian. My paper notes of numbers are also big endian after all ☺

I haven't been coding for a while or writing programs but I really enjoyed this conversation Steve. It was brilliant! I take so many parallels to other things like music, understanding the times written, those contemporary theories and the techniques then and now. Any how, thank you again, it fired up my brain and that's what I love about Computerphile's.

I can't get enough of the content from this channel. GREAT stuff!

I recall doing this around 1986 for a machine tool firm I worked as a college student. Emulated the 6809 as it was the processor used in their tools. That way, code could be tested in the emulator before being burned to a ROM and loaded into the tools. This brings back some memories indeed.

This takes me back many years to transferring Night Lore from tape to disc for my BBC micro. The tape was in a weird nonstandard format that used a custom loader that was obfusticated to resist reverse engineering by xoring with bytes in the ROM chips and the timers in the 6522s to make single stepping cause failure. What fun. The final emulator was considerably more interesting than the game, especially the switch from 2 megs to 1 meg when the 6522s were accessed and the innovative use of two unsupported op codes that made weird address modes work on the Y register (though only on the chips that the Beeb used - it would fail on something like an M50747 that was used as a simple CPU). Happy days.

Dr. Steve Bagley is a brilliant Computer Scientist. Love the way he explains things simply and elegantly without overloading people at the same time. What a great video on this subject.

Long time ago, when Intel introduced the Pentium II, many Pascal programms crashed because the CPU was "too fast". The "workaround" was to run something in the background to slow the system down! Timing issues are truly nightmares.

Emulating a simple system like the Chip-8/Superchip or emulating a more complex system in a simplified manner like Gameboy/NES is a fun passtime if you're not being worked to death as a coder already.

I used to be involved in some emulation projects in the past, but I mostly did peripheral stuff (in both senses). I started writing an NES emulator which has a cpu based on the 6502, and I could never get all the instructions to work right. Eg. the tests kept saying my subtract was outputting the wrong borrow flag, but I couldn't find any issue in the logic when compared with the documentation. Despite that, I did manage to get a few very simple games to work somewhat! Although they weren't playable because I never implemented the graphics sprites in the PPU.

For the timing stuff I think a simple solution for a quick & dirty implementation would be to just create a configuration file that declares the delay between sending a message for X instruction and continuing execution of the emulated CPU/s, then users of the emulator can tune things for their game and submit the timings they found worked best, finally as the submissions come in the default 0s that were originally used can be replaced with the average value for each - which is the most likely timing of how long each processor took. This in turn tells the developer that maybe they missed something or did the target processor being emulated more efficiently than the actual processor. Since each processor is expected to last the lifetime of emulation one can also use some global variables for io to reduce delays that should not be there

When "buttons" are one of the largest components on the board. Love it!

The internals of the 4-switch Atari VCS/2600 look much more neatly organized and more "modern" than its original 6-switch variety, with the later Atari 2600 Jr (fully compatible) going a few steps further. Each was a year or two apart. It's interesting how quick some processes changed, such as more organized component layout and smaller traces.

Not sure why, but I could listen to this guy for hours.