I/O structure of the June87 machine
- IOBus versus DynaBus
- PC/AT I/O channel as IOBus
- The IOBridge chip
- Future developments
IOBus versus DynaBus
- DynaBus is fast but complex:
* throughput ~ 200 Mbytes/s
* split cycle protocol
(message passing)
* 64/256 bit packets
* special drivers required
* impossible to connect commercial
chips or boards
- Development of full set of June87 I/O chips impossible:
* not enough time/manpower
* system not easily extensible
==> most I/O must be implemented on a commercial bus connected to the DynaBus: the IOBus. Display chip is the only exception due to bandwidth.
- IOBus also used for bootstraping the machine
Choice of the IOBus
- Possible candidates:
* Multibus 1 / 2
* VME Bus (16 or 32 bits)
* PC/AT Bus
* QBus
- PC/AT bus selected:
* simple to interface
* variety of peripherals available
* small board size
* Multibus and VME more oriented to systems integration
* also allows PC/AT emulation
PC/AT bus summary
- asynchronous
- 16-bits data, 24-bits memory addresses, 12/16 bits I/O addresses (byte addressing)
- 375 ns min. cycle time => 5 MBytes/s
- little-endian (LSB at lowest address)
- Problems:
* PC/AT processor required
* no complete specification
* byte ordering
* asynchronism
* idiosyncrasies:
- no bus error support
- DMA-refreshed memory
- high DMA latency (> 1 ms)
- small address space
(20 bits in MSDOS)
- Extensions:
* hack to extend addresses to 32 bits (disk controller)
The IOBridge chip
- handles IOBus / DynaBus interface
- supports a few system IO functions
(ticks counter, timer, interrupts)
- includes special support for bootstrap and system testing
- uses cache chip for DynaBus interface:
* reduced chip size & complexity
* does byte buffering
* correct consistency protocol
- Interfaces 3 different buses: DynaBus, IOBus, PBus (plus opt. DBus)
IOBridge block diagram
[Artwork node; type 'ArtworkInterpress on' to command tool]
IOBridge functionality
- DynaBus I/Os mapped to IOBus cycles:
* IOBus memory, I/O and INTA cycles supported
* all byte orderings supported
- IOBus memory cycles mapped to DynaBus memory transactions (byte stream order!) through 3 16-entry address maps:
* 64K from 20-bit range (0-1M)
* 14M from 24-bit range
* full 32-bit range
- capability to generate same DynaBus
transactions as Dragon by program:
* I/O transaction
* CWS transaction
- numerous internal hacks due to PC/AT bus structure
Interrupt structure
- IOBus to Dragon: 3 levels of controllers
* IOBus interrupt controller
||
V
* IOBridge interrupt controller
||
V
* Cache interrupt controller
- Dragon to IOBus:
* 1 "regular" interrupt
* 1 "failure" interrupt
Timer support
- All timers are 32-bit unsigned
- Tick timer: counts at 1 MHz for time-stamping
(overflow interrupt)
- Interval timer: 1 ms resolution
(interrupt on end of interval)
- Time-of-day clock: 1/10 s resolution
IOBus address mapping
- IOBus address are 24 bits. CPU accesses under MSDOS restricted to lower 1 Mbyte (20 bits). Addresses extended to 32 bits for disk controller.
- DynaBus addresses are 32 bits word addresses, i.e. 34 bits byte addresses.
- 3 address maps (page organized):
* 1 64K region in [0..1M) mapped with 16 4K bytes pages to DynaBus memory: PC/AT CPU access
* [1M..15M) mapped with 14 1M bytes pages to DynaBus memory: PC/AT DMA addresses (e.g. Ethernet)
* [16M..4G) mapped with 15 256M bytes pages to DynaBus memory
- Maps may be initialized from DynaBus and IOBus
June87 machine bootstrap process
- Reset PC/AT => control to PC/AT ROM
- Check hardware configuration using DBus
- Tune clocks using DBus
- Initialize chip parameters using DBus
- Start DynaBus, not processors
- Initialize & test DynaBus memory
- Load pre-boot program
- Start processors
- Pre-boot program will access disk/net for real bootstrap
Pros and cons of current solution
- Pros:
* simple hardware interface
* easy extensibility:
large variety of I/O boards available
* support of PC/AT emulation
* PC will help debugging prototypes
- Cons:
* low speed:
ESDI disk + Ethernet => saturation
(mutiple IOBuses possible)
* complexity of head and faces
- byte ordering
- interrupt structure
* effective support of PC emulation will require additional work
* IOBridge very dependant on PC/AT
Future developments
- Choice of PC/AT bus might be changed for NuBus if Mac2 proves successfull (cleaner & faster)
- Implementation of high-speed I/O directly on DynaBus:
* display bitmap generator
* 100-500 MB/s network
* vertical recording disks ?
- dedicated I/O processor(s) on DynaBus