[LocalH]

No. The author is saying that, in order to run the demo on MartyPC, the emulator previously required a small "hack" (in this context, that means a slight inaccuracy in emulation) to get the effect started. The post then covers the process of fixing multiple bugs such that the "hack" is no longer needed to match behavior on hardware, and thus MartyPC's behavior now more accurately models hardware.

Offtopic: in recent years, I've stopped saying "real hardware" unless also using the term "emulated hardware". To me, it's either "hardware" vs "emulator", or "real hardware" vs "emulated hardware".

[perching_aix]

Not really sure I see the benefit to the linguistic choices there. It makes sense, but I just don't see the point. Doesn't help that you can implement emulators in hardware (e.g. FPGA-based emulation), and that the "emulated hardware" phrase can be misinterpreted as a reference to the real device in question.

[lscharen]

I can see the point of trying to make a distinction, but it is muddy.

An emulator can operate on many different levels of trying to match the behavior of the underlying hardware. CPU emulators can emulate at the opcode level (easier) or try to increase accuracy by emulating the CPU pipeline cycle by cycle (harder).

In this particular case, the distinction between an "emulator" and a "hardware emulator" seem apt because the article discusses that the required fixes needed to start tracking the state of individual pins of the hardware chips. This, to me, represents that the emulation needed to "go down another level" and model the physical hardware to a certain degree to gain the needed accuracy.

Having a way to mark that difference is useful.