Skip to Content

History of the Swift IOS Development.

The Swift IOS project began after a comment from Nigel Sargent at Alaska Airlines. He asked if it was not possible to retarget all of the old CRDS hardware onto the PC platform and thus remove a large maintenance effort. We thought this was a good idea.

After a lot of thought and many diagrams, the initial design was sketched out. This was a complete emulation of the MVME-167 card, based around the published documents from Motorola. To run on a 167 would required an upgrade of UNOS to UNOS 9.3.3+, which seemed a small price to pay for the benefits. The first initial prototype systems were built (based on the UAE CPU core from Aranym and BasiliskII).

At this point it started to become obvious that the level of emulation was simply unneccessary. So we reviewed the objectives. Based on input from the maintenance guys the main usage of the CRDS UNOS is runtime IOS, GSD Update and page build.

So we had to change direction from a full hardware emulation to what we call a contained process emulation. The theory is simple, we run on a Unix system, so we have a UNOS process container, which has the 68k emulator and translators for syscalls and device (/dev) access, network access, and other trans-environment engines for the rest. After while we had a basic container capable of running the UNOS echo command. The benefits of this approach are many, but primarily the UNOS process is running under Unix, and so we don't need UNOS, all processes can communicate via TCP/IP over the native network. The syscall overhead is small and the overall performance is better (because we are emulating much less 68k code).

From this point we began to make serious progress and a lot of code to write to complete the next stage. This took a lot longer, but finally we could run /UNOS/bin/ksh, with support for forking and run /UNOS/bin/echo from the UNOS CPE. Then concentrated on the complexities of the next stage. This was agreed to be the provision of native X11 graphics via the standard mechanisms by building libX under UNOS, thus providing. After the success with the graphics there was a lot of work ahead building the complete CPE but finally we could see an IOS page displayed on the X display. As expected the performance was far superior to the native baseline of a 68020.

Then we developed the communications layer. The serial communications layer runs as a native process, and uses a much simplified protocol, which is modelled after Reflective Memory. The IOS sends a series of packets starting with a unique ident, followed by repeating set of 40 bits indicating address and size. The response is a message containing 72 bit packets containing address and size followed by value. The comms is triggered by read access to values in a shared memory segment with represents the RMB.