This file type includes high-resolution graphics and schematics when applicable.
It has been a long time since I worked on minicomputers like the Data General Nova (see figure). I remember entering boot sequences using the front-panel switches to load a paper tape-based loader that finally loaded an operating system. The process was not too involved, and it kept the OS running (which was a good idea, because rebooting was not fun).
I also dabbled with a number of minis, including DEC LSI-11s and Burroughs B1700s. I recently decided to see if there was a simulator or emulator for the Nova. Sure enough, I found a couple of them, along with ones for most of the other platforms I remember using. Some are limited simulations of the processor, while others emulate peripherals.
Most of these were put together for nostalgic purposes. It continues with latter-day platforms like the 6502 that drove the original Apple II and Atari game consoles. There’s actually a Javascript emulator that probably runs faster than any 6502 ever made on most browsers.
Emulators and simulators are often overlooked when developing applications. They’re heavily used for high-end system-on-chip (SoC) platforms these days because of the cost and timing. Misconceptions still persist about this type of emulation (see “11 Myths About Hardware Emulation”), but it has many advantages.
For instance, such emulators allow software developers to get started before hardware is available, simulating and debugging using hooks that can only come from software. A wide range of options exists between these high-end, high-resolution simulators and the nostalgic implementations that are often overlooked by developers, who typically assume they have to develop on their target hardware.
My favorite implementations are emulators for low- to mid-range microcontrollers. The emulators often run applications faster on a PC than on the actual hardware. They can be ideal for software regression or unit testing. The systems are often available from the hardware vendors and integrated with the development tools. I have used Microchip’s in the past to good effect.
Another option is the QEMU system emulator. It’s integrated with most Linux distributions and runs on a range of hardware to emulate a similar range of hardware. For example, it’s possible to run an ARM Cortex-A environment on top of an x86 version of Linux. Hardware virtualization can be used when emulating similar hardware such as x86 on an x86 system.
Emulating or simulating architectures that differ from the host can be done in a number of ways. Two methods are interpretation and dynamic translation of machine code. The latter is essentially just-in-time (JIT) compilation of one machine code to another. The requirements placed on simulation often determine how these tasks are performed. For example, does execution have to replicate a chip’s timing and, if so, to what level of accuracy? At the other end, just the functionality may need replication.
Emulating multiple systems can be very useful in debugging communication scenarios for the Internet of Things (IoT). Often, the debug hooks are more sophisticated and less expensive to implement than using real hardware for tracing and replication of test scenarios. Using real hardware will still be required, but doing more with only software can reduce development and debugging time.
I’m always amazed by developers who don’t know about debuggers or trace tools. I should probably add emulators and simulators to that list. Make sure you don’t overlook any of these tools.
This file type includes high-resolution graphics and schematics when applicable.