<story><title>LaiNES – Cycle-accurate NES emulator in around 1000 lines of code</title><url>https://github.com/AndreaOrru/LaiNES</url></story><parent_chain><item><author>raldi</author><text>What does &amp;quot;cycle-accurate&amp;quot; mean? The README assumes the reader already knows; Wikipedia via Google is totally unhelpful: &amp;quot;A cycle-accurate simulator is a computer program that simulates a microarchitecture on a cycle-by-cycle basis.&amp;quot;</text></item></parent_chain><comment><author>0xcde4c3db</author><text>The traditional way of coding a console emulator was to figure out the time interval to the next interrupt in units of CPU cycles, emulate enough instructions to cross that threshold, then emulate the interrupt and hook other routines (redrawing the screen, filling sound output buffers, reading input, etc.) off of those events (see e.g. Marat Fayzullin&amp;#x27;s classic Emulator HOWTO [1]). This approach runs a lot of stuff just fine because it does synchronize to the most important events, but can cause problems. For example, &amp;quot;well-behaved&amp;quot; code generally only writes to graphics registers or sprite tables during blanking periods, as writing during active display is usually undefined behavior. Some code breaks the rules. Sometimes this is done intentionally to do cool effects with the hardware. Other times it&amp;#x27;s a side effect of a bug that wasn&amp;#x27;t caught because there are coincidentally no symptoms with the timing of the actual hardware. But then you plug it into an emulator with only roughly accurate timing and it blows up.&lt;p&gt;In reality, the clocks for the various components don&amp;#x27;t necessarily run at the same rate, or even at integer multiples of the CPU clock. You can have a situation where, for example, there are 3.5 clock cycles on the graphics hardware for every one CPU clock cycle. For a lot of the classic systems, this happened because a single higher master clock is divided down for each component.&lt;p&gt;A &amp;quot;cycle-accurate&amp;quot; emulator is one that operates as if the emulated state of all hardware were updated on every tick of the master clock. This wasn&amp;#x27;t generally done in the past because it was far too slow ~20 years ago when emulation of classic consoles and computers really took off.&lt;p&gt;More sophisticated hardware doesn&amp;#x27;t necessarily have any single master clock in this sense, so it doesn&amp;#x27;t make much sense to talk about a &amp;quot;cycle-accurate&amp;quot; emulator of a modern PC, for example.&lt;p&gt;[1] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;fms.komkon.org&amp;#x2F;EMUL8&amp;#x2F;HOWTO.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;fms.komkon.org&amp;#x2F;EMUL8&amp;#x2F;HOWTO.html&lt;/a&gt;</text></comment>
<story><title>LaiNES – Cycle-accurate NES emulator in around 1000 lines of code</title><url>https://github.com/AndreaOrru/LaiNES</url></story><parent_chain><item><author>raldi</author><text>What does &amp;quot;cycle-accurate&amp;quot; mean? The README assumes the reader already knows; Wikipedia via Google is totally unhelpful: &amp;quot;A cycle-accurate simulator is a computer program that simulates a microarchitecture on a cycle-by-cycle basis.&amp;quot;</text></item></parent_chain><comment><author>throwbsidbdk</author><text>TLDR: each CPU instruction takes the exact amount of time it does on the real cpu.&lt;p&gt;You generally only care about cycles in real-time stuff. In simpler CPUs like those used for microwaves and such, each CPU instruction takes constant time. You can count the number of instructions in your assembler loop and know how long the loop will take. Mind you sometimes each instruction takes constant time but some can take more time than others. A cpu cycle is defined as 1&amp;#x2F;clockspeed . A fast instruction can take 1 cycle, others 3 or more.&lt;p&gt;Usually there&amp;#x27;s multiple cpu instructions for GOTO and loading from memory, a fast set for things &amp;quot;close by&amp;quot; and a slow set for far away code or data. Loops and conditional instructions even on simple cpus can take different amounts of time depending on the outcome, so it gets pretty complicated to time things sometimes.&lt;p&gt;So when doing really low level timing critical code, you can use a super accurate signal generator to drive your CPU clock, then count your instructions to time things. Common uses include generating audio from bit banging and similar.&lt;p&gt;In more complex CPUs a number of things made it difficult or impossible to figure out exactly how long an instruction will take. None of the software for these CPUs is written to depend on exact cycle timings. Because nothing depends on cycle accuracy you don&amp;#x27;t have to worry about the timings when emulating these kinds of CPU&amp;#x27;s.</text></comment>