Adventures in PC Emulation

In my last article , I dodged the issue of writing a custom decoder for the 5150's bus signals to use in DSView, instead just processing the exported CSV with the pandas Python library.    This had the advantage of familiarity, but we're leaving some powerful tools on the table. Turning Excel into a logic analyzer display may be a cute trick, but it comes with a few limitations. Zooming out and scrolling is a bit awkward and slow, and of course, there's that 1M row limit staring us in the face. Ultimately, our goal is to eventually compare execution results between our logic analyzer and our emulator. How are we going to accomplish that? A simple CSV diff goes off the rails the moment an interrupt occurs at a different time, even though that timing difference may or may not represent an accuracy problem. Diffing cycle logs is no trivial task. In contrast, a competent logic analyzer program scrolls through massive numbers of samples and zooms in and out with ease. What's

Writing a cycle-accurate emulator for a computer system is more than just understanding all the CPU instruction timings. A computer is a complete system with peripherals, interrupts, IO bus signals, and DMA. All this comes with an array of different timings and quirks. When software like Area 5150 is written that requires perfect cycle timing, it can be a challenge to provide the level of accuracy needed for the software to function. Area 5150 in particular requires precise coordination with the CGA's CRTC chip and timer interrupts to begin the end credits demo effect at precisely the right time. Getting this right is crucial to whether the demo effect produces this: Artwork by VileR Or this: It would be very handy then if we could somehow peek into the operation of the system while it was running and understand how all these parts interact.  As it turns out, we can! This process is typically referred to as 'bus sniffing', and there's a lot of a technical information ou