The most difficult aspect of emulation programming?

[Keatah]

Emulator programmers are like magicians - pulling sleight of hand and making illusion at every clock cycle. So I ask the experts, what is the most difficult aspect of programming these little gems?

 

I would think the following, in rising order of difficulty. 1 being the easiest.

1- Host GUI and disk image loading

2- Memory map

3- CPU

4- Custom chip sound

5- Custom chip GLU

6- Custom chip DSP

7- Custom chip graphics

8- bringing it all together

 

So what do the experts think?

 

[+nanochess]

It depends strongly on the emulated platform.

 

At least for Colecovision the most difficult thing to implement is when someone discovers a Video Display Processor (VDP) trick that depends on exact timing of pixel processing or an undocumented feature.

 

I passed months trying to figure why the radar in Defender didn't appeared in my Colecovision emulator or why some games failed grossly because depended on exactly the contrary of what datasheet said (the collision bit when sprites are outside of screen)

 

I've heard the NES VDP is a real nightmare for software emulation and I've seen the Atari's TIA still gives some surprises for very special cases.

[+CyranoJ]

255: Bus contention

256: Dealing with assholes on forums.

[+stephena]

Cycle-exact timing and no/wrong hardware documentation. Already in Stella we've added code that goes against what the hardware docs say should happen, but actually does happen. It's bad enough having to emulate a complex system with working docs; when you're following incorrect info it's even worse.

[Trebor]

Stephen nailed it in the head.

 

The subject of timing and (in)correct hardware documentation has been a *huge* factor with all the work done concerning Atari 7800 emulation under MAME/MESS.

The 7800 8bitDev site hosts a revised 7800 Software Guide which is: "An updated version of the documentation originally produced by Atari and GCC. Several inaccuracies have been discovered and corrected, and new sections have been added."

Reviewing the 7800 hardware facts thread, many of the highlights are discussed and even demonstrated.

[DirtyHairy]

Some aspects:

• Timing. I second Stephen and Trebor, this is very hard to get accurate. The 2600 is particularily nasty here, TIA emulation lives and dies with proper timing.

• Edge cases and undocumented behavior of hardware components. Again, the VCS is nasty, because about everything out there depends on undocumented TIA "features"

• Debugging failures. Especially during the bootstrap phase of the emulator, it is hard to debug why something fails to execute correctly. You basically have to create a set of debugging tools alongside your emulator to trace execution, and combine that with educated guesses what might be off In particular, for the CPU, tests that check idividual instructions can help alot --- I used this approach in 6502.ts.

[phaeron]

Yup, lack of precise hardware documentation is the biggest problem. The official hardware manuals never go into enough detail to emulate everything. It's the reason I started writing my Hardware Manual -- in the process of writing Altirra I kept needing answers to questions that couldn't be found anywhere. Often it'd eventually emerge that the precise behavior was known to some people, but they'd never bothered to investigate it further or never wrote it down. That's assuming there is even an official manual, vs. something like the Happy 1050 expansion where the makers deliberately didn't document how their hardware worked.

 

Another annoyance is dealing with bug reports due to actual hardware issues. Horizontal scrolling routine breaks in the emulator? Does that on real hardware too, just older emulators didn't emulate it. Yes, channels 3+4 really are silent on real hardware unless you reset the serial port mode. No, you can't read disk sectors with a 16ms timeout and expect it to work on any real disk drive. Part of the problem is that these devices are old enough that some of the people using the emulators don't have the original computers anymore or perhaps never used them at all.

 

The analog hardware side of the computer can also be aggravating. Reverse drive firmware to get drive timings? No problem. Reverse digital logic to get a memory map? No problem. Need to know the behavior of the A/V output circuitry? I can spend all day staring at a schematic full of transistors, resistors, and diodes and get absolutely nowhere. I'm indebted to helpful people on this board who actually know how to use a soldering iron.

[+nanochess]

Once I wrote a private Gameboy emulator and saw the sound was poorly documented, because my brother used to play Pokemon Blue, I played Pokemon Blue and the sound wasn't the same in emulation.

 

I passed months tuning, locating more docs (some even conflictive) and filling the voids (it's so similar to SN76489) and et voila! I got a very nice emulation.

 

I still feel the emotion when the intro tune played the correct way and finally the digitized voice, later the synth music of Donkey Kong Country.

[DanBoris]

One of the most frustrating situations I remember running into when writing and emulator was this:

 

- Game A doesn't work, game B does.

- Troubleshoot the problem with A, implement fix

- Game A now works, but game B no longer works!

 

I specifically remember having this come up in both my 2600 and 5200 emulators. I also remember back when we didn't have a full understanding of how BCD math was supposed to work in the 6502, until some eventually documented the exact behavior of the CPU flags.

 

As for one specific emulation challenge, the mathbox processor in I-Robot!

Edited February 2, 2017 by DanBoris