System Architecture

The figure below shows a high-level view of how the emulator is organized.

The emulator is actually a system of device emulators, tightly integrated into one package. It's emulating an 8080A microprocessor, the I/O hardware and interrupt handlers wrapped around that processor, a visual front panel, a full-featured editing terminal, a floppy disk system and printer.

You can click a link to the far left or a section of the figure to explore each of these topics in more detail. This page provides a higher-level orientation to the H8 emulation system.

There are actually three major control flows in operation within the emulator. Understanding these control flows will help you understand how the pieces fit together and why it works as it does.

All three flows originate at the scheduling loop in the event handler. They are:

1. Instruction Flow — When it's not doing anything else, the emulator is repeatedly running 8080A instructions.

2. Time Distribution — The scheduling loop provides millisecond timing information to various components of the emulator. It provides higher-level timing to certain functions as well.

3. Macintosh Events — The scheduling loop periodically checks for Macintosh events and dispatches their processing when necessary. Events are required for key clicks and mouse clicks on the PAM/8 keypad, as well as to access menus, switch to other applications, etc.

Each of these flows is described in more detail below.

go to top

Instruction Flow

On each pass through the scheduling loop, the event handler calls H8 Processing to dispatch one instruction. H8 Processing checks for pending interrupts and develops an interrupt vector if one is found. It then calls 8080A Emulation to execute the next instruction (or first instruction of the interrupt service routine).

If the instruction is an IN or OUT, the I/O Package is called to classify the port address and dispatch processing to a device-specific handler:

• PAM/8 port handling is all done inside the I/O Package;
• H-17 port handling is sent directly to the H-17 Disk System with no further processing in the I/O Package;
• Tape I/O requests will cause a call to a read or write routine inside Tape I/O;
• 8250 port I/O is handled, for the most part, inside the I/O Package, though it will generally call a status function or an output function inside Serial I/O or H-19 Emulation to push the data out to the device.

I/O, if called, returns to the 8080A emulator. The 8080A emulator returns the processor state — RUN and interrupt enabled status — to H8 Processing, which, if necessary, updates the front panel status lamps with calls to the PAM/8 GUI drawing package.

H8 Processing returns to the scheduling loop. The scheduling loop maintains an instruction "pacing" count which is updated with the number of machine cycles that would have been consumed by a real 8080A to execute the last instruction. This pacing mechanism helps to provide accurate emulation speed when set to a 2 mhz clock rate.

We stay in the scheduling loop until the "done" flag is set using the File -> Quit item or via a high-level message from the Finder.

go to top

Time Distribution

Before starting the scheduling loop, we schedule a 1ms system timer which provides a stable source of timing to the emulator. At the top of the scheduling loop, we check to see whether this timer has expired, or whether the pacing count has been exhausted (ref. Instruction Flow above). If not, we go on to call H8 Processing as described above.

If the timer or pacing count has expired, we do time-dependent processing. This part of the scheduling loop is described in detail in Time. But in general:

• the loop determines whether it's time to call the Macintosh Event Handler, and calls it if so;
• the loop determines whether it's time to update the front panel display and calls the panel drawing package if so;
• the loop determines whether it's time to remove any key value placed on the PAM/8 input port by the keyboard, and removes it if so;
• the loop then calls "clock" routines in the H-19, H-17, Serial I/O, I/O Package and H8 Processing, all of which require timing notification to the millisecond level.

At the end of this portion of the loop, we wait until the timer has expired (if it has not already expired), then reset the timer and dispatch another instruction.

The amount of time spent in this part of the loop is highly variable. It's generally quite short — around 22 microseconds on average when running on the author's G3 — but can extend to near "infinity" (in microprocessor terms) depending on what the user might be up to the next time we poll the Mac event queue. For example, the emulator gets no time while the user is browsing the menu tree, or while a dialog box is open.

These variable moments of time when the 1ms timer is not running are not a part of the H8 time "universe." Everything freezes inside the H8 — time comes to a standstill, if you will. The disks don't spin, instructions don't process, and the whole thing sits in stasis until we complete all time-related processing. For this reason, the H8's clock may appear, from the viewpoint of an external observer, to run a little slow.

go to top

Macintosh Events

The Macintosh function WaitNextEvent is called once every 25ms when we are the foreground application and once every 10ms when we're in the background. On each call, we will accept one event, if present, and process it. We'll then return to the scheduling loop so it can complete time-based processing and get back to running the 8080A.

Amid the suspend and activate events, window dragging, mouse-down's in the menu system, etc., events will occur that will drive data through the emulator:

mouse-down on the GUI window

If the mouse-down hit a keypad key, a value will be placed on PAM/8's input port. At some point in the future, a clock interrupt will be scheduled during an instruction cycle, causing PAM/8 to be entered.

Some number of instruction cycles later, an IN will cause the I/O package to be called to read the value off the input port. Some time later, a mouse-up event will cause the no-key value to be placed on the input port.

As noted above, the PAM/8 ports are managed entirely in the I/O package.

mouse-down on the H-17 Management window

If the mouse-down hits a control, that control will be tracked until the corresponding mouse-up event is received. The emulator will be frozen until this occurs.

If the control hit causes an open-file dialog, the emulator will be frozen until that dialog is dispatched by clicking Cancel or Ok.

Changes made in the H-17 Management window take effect immediately and will have various effects on the emulator. For example, clicking the Reset button or mounting a disk on a drive will suppress hole detection for 300ms. This shows up on the H-17's input status port.

key-down in the GUI window

If the keystroke is one of those mapped to a PAM/8 keypad key, a value will be placed on PAM/8's input port. A timer will be scheduled to remove the key value in a short period of time. Processing continues as above.

key-down or auto-key in the H-19 window

The key value is sent to H-19 Emulation for inbound translation. This will likely result in one or more characters being placed into the inbound data queue.

Inbound data from the H-19 is paced at a rate of 500cps. At some point in the near future, the 1ms timer will expire and the H-19's clock function will be called. On every other call, a byte is removed from the queue and sent to the I/O package to be placed on the 8250 data port.

This will cause an interrupt to be scheduled. The I/O Package will call H8 Processing to set a mask bit. On the next instruction cycle when interrupts are enabled, H8 Processing will develop interrupt vector 3 and will pass this to 8080A emulation, which will start the associated interrupt service routine. Eventually, HDOS will read the data port and process the keystroke.

In all cases, the event handler eventually returns to the time-distribution section of the scheduling loop, and instruction processing continues.

go to top