The TS68020 uses instruction continuation to support virtual memory. In order for the
TS68020 to use instruction continuation, it stores its internal state on the supervisor
stack when a bus cycle is terminated with a bus error signal. It then loads the program
counter with the address of the virtual memory bus error handler from the exception vec-
tor table (entry number two) and resumes program execution to that new address. When
the bus error exception handler routine has completed execution, an RTE instruction is
executed which reloads the TS68020 with the internal state stored on the stack, reruns
the faulted bus cycle (when required), and continues the suspended instruction.
Instruction continuation is crucial to the support of virtual I/O devices in memory-
mapped input/output systems. Since the registers of a virtual device may be simulated
in the memory map, an access to such a register will cause a fault and the function of
the register can be emulated by software.
A typical use for a virtual machine system is the development of software, such as an
operating system, for a new machine also under development and not yet available for
programming use. In such a system, a governing operating system emulates the hard-
ware of the prototype system and allows the new operating system to be executed and
debugged as though it were running on the new hardware. Since the new operating sys-
tem is controlled by the governing operating system, it is executed at a lower privilege
level than the governing operating system. Thus, any attempts by the new operating
system to use virtual resources that are not physically present (and should be emulated)
are trapped to the governing system and handled by its software. In the TS68020, a vir-
tual machine is fully supported by running the new operating system in the user mode.
The governing operating system executes in the supervisor mode and any attempt by
the new operating system to access supervisor resources or execute privileged instruc-
tions will cause a trap to the governing operating system.
Though the TS68020 has a full 32-bit data bus, it offers the ability to automatically and
dynamically downsize its bus to 8- or 16-bit if peripheral devices are unable to accom-
modate the entire 32-bit. This feature allows the programmer the ability to write code
that is not bus-width specific. For example, long word (32-bit) accesses to peripherals
may be used in the code, yet the TS68020 will transfer only the amount of data that the
peripheral can manage. This feature allows the peripheral to define its port size as 8-,
16-, or 32-bit wide and the TS68020 will dynamically size the data transfer accordingly,
using multiple bus cycles when necessary. Hence, programmers are not required to pro-
gram for each device port size or know the specific port size before coding; hardware
designers have flexibility to choose implementations independent of software
This is accomplished through the use of the DSACK pins and occurs on a cycle-by-cycle
basis. For example, if the processor is executing an instruction that requires the reading
of a long word operand, it will attempt to read 32-bit during the first bus cycle to a long
word address boundary. If the port responds that it is 32-bit wide, the TS68020 latches
all 32-bit of data and continues. If the port responds that it is 16-bit wide, the TS68020
latches 16 valid bits of data and runs another cycle to obtain the other 16-bit of data. An
8-bit port is handled similarly by with four bus read cycles. Each port is fixed in assign-
ment to particular sections of the data bus.
Justification of data on the bus is handled automatically by dynamic bus sizing. When
reading 16-bit data from a 32-bit port, the data may appear on the top or bottom half of
the bus, depending on the address of the data. The TS68020 determines which portion
of the bus is needed to support the transfer and dynamically adjusts to read or write the
data on those data lines.