§ 14 - Virtual Front Panel

§ 14.1 - Overview

The VFP shows the processor registers, as well as the 6809 system address and data busses. There is a set of 8 user LED's which may be controlled directly from software running under the emulator, some dip switches, and some emulator step capability. Details are provided in the follwoing sections. The VFP is fairly simple to operate. You open or close it using the Modes/Panel menu items.

When the VFP is open, it allows you to let the emulator run (when Run is checked) or to be stopped, and subsequently single stepped on a per-instruction basis, using the Step control. When single-stepping, the next instruction to be executed is displayed at the bottom of the panel.

§ 14.2 - Details

When the panel is open, a number of displays are active.

At the left are a series of (emulated) LED's that represent the address and data bus activity of the emulator. These are of general interest, and can be utilized to good effect when single-stepping the emulator — they show all bus read & write cycles (including instruction fetches), for instance, which aren't always immediately evident from the register display.

Just underneath the address LED's on the left are the disk drive LED activity indicators. They act almost like real ones, the primary difference being they'll continue indicating access for a moment even when another drive is accessed. The disk indicators are red when the drive is being accessed, otherwise green when a "disk is in the drive" but unchanged, yellow if a disk is in the drive and has been changed, and dark if no disk is present.

To the right are all of the processor registers. Underneath the 6809's condition codes are a set of 8 user LED's that can be set by 6809 programs to red, green, yellow, or off. There are two 8-bit user ports (at $E00A and $E00B) that control these LED's.

At the bottom of the VFP is a text region which will update only when the Run box is not checked, in other words, it will update when the emulator is in step mode. This area (the EM-ICE) will show the instruction that is next to be executed in disassembled form. Addresses are in hexadecimal format; offsets from index registers are in decimal, and register lists for PSH, PUL, TFR & EXG are supported. Relative branches are shown as target addresses, rather than signed offsets (although the signed offsets are visible, because the code is also displayed to the left of the disassembly). Even the large number of indexed modes are fully disassembled.

When an indexed instruction is encountered, the effective address (EA) is shown. Indexed, extended, and direct mode instructions also display the data that is present at the EA unless the EA is in the I/O space, in which case that is indicated. I/O space data is not pre-read by the EM-ICE because some I/O is affected simply by reading it, specifically emulation hooks, IRQ acknowledge in the VIA's and so on.

When a LD(r) is used to access I/O space, you'll see the data in the registers when the instruction executes (on the next single-step). When read-modify-write instructions such as INC and DEC, or read-only instructions such as TST are used in the I/O space, you will not be able to see the data being modified or read. You can select the number of instructions to be executed using the entry control to the left of the Step(s) button.

You can expect some degradation of the emulator's performance when the panel is open, though it is not generally severe (at least on a 133 MHz Pentium, it's not). If you experience unacceptable degradation which you cannot compensate for with the update rate controls, simply close the panel and the emulator will perform as it used to prior to the addition of this feature. I have a 486 dx4/75 laptop that simply cannot run the emulation if the panel is set above 4x a second update rate, so I am sure your mileage may vary. Certainly the display hardware (graphics card & chipset) will affect performance in this regard also — there is a lot to draw, and quite often.

The software remembers if the panel is open, and will re-open it when you start the emulator next time, if you quit with the panel open.

§ 14.3 - VFP Display Aliasing

Because of the way Win95 switches tasks, when the Run box is checked and the Execute menu's Chunky option is checked, some register displays may not behave as expected. What is happening is that the emulator is running many instructions before the system can update the display, and the register(s) can appear to be static, unchanging. They're changing and being updated, it's just that they're back to the same state that they were when they were last refreshed on the display. Remember that the emulator is going much faster than the display can follow. Unlike an analog display system, which can follow such changes (and shows them as a blur, usually), the VFP regularly "samples" the registers and so displays a clear, if non-intuitive, value. Also, the updates always occur at integer multiples of instruction executions; that has the effect of making the displays "alias" against the operating rate of various instruction loops.

The faster your computer and its associated display hardware is, the more useful the VFP is during RUN.

You can de-select the Chunky option and the emulator will run one instruction at a time, instead of the large batches it normally does. This has two effects; one, it provides more of a timing window for the display to update, and two, it slows down the emulator to a very noticeable degree. Sometimes you'll want to do this, especially when involved in software development.

You can also single step the emulator, which will result in the expected correct register displays.

§ 14.4 - VFP Display Updates

You can turn the VFP off using the Modes/Panel/Off menu option, or you can control how many times per second the display updates from 1 time to 20 times per second with the other choices in the Modes/Panel submenu.

§ 14.5 - VFP Display User LED's and Dip-Switches

§ 14.5.1 - LED's

The user LED's are controlled by two addresses. The LED's are intended to function like actual red and green bi-state LED's, which have two light sources, one red, one green. The LED can be either red or green, and also will appear yellow if both light sources are on.

Ones written to $E00A turn on the red light sources, and ones written to $E00B turn on the green light sources. If ones are written to both addresses, the LED's appear yellow.

To use the LED's as red LED's, initially write a zero byte to $E00B and write your data to $E00A. To use the LED's as green LED's, initially write a zero byte to $E00A and write your data to $E00B. To use the LED's as yellow LED's, write your data to both addresses: $E00A and $E00B.

You can use each LED independently for on, off and color based on the bits written to the two control addresses.

Because the control bytes are memory (you can read them back) you can use AND and OR operations to individually control LED's with ease.

§ 14.5.2 - Dip-Switches

The DIP switches appear in the 6809's memory space in DATB and DATA of VIA3, at $E050 and $E051.

Reading the DATB and DATA ports of VIA3 results in a byte which has one bit set or reset for each of the DIP switches. The DATB port is the top set of 8 DIP switches, and the DATA port is the bottom set. When a switch is up, the bit will be a one; if down, a zero.

You can preset the DIP switches by storing a byte to the appropriate port with the bits set the way you want them.

There is a coding example called DSTEST.TXT and the command generated from it (DSTEST.CMD) on the release disks. The DIP switches are very easy to deal with. The command example shows both presetting and reading.