** NOTE ***
I know the code linked here has been broken for some time. Apparently the FAME emu, or (more likely) my abstraction on top of it, does not boot OS-9 properly on x86_64 Windows. I do intend to look into the issue (really!) but have been swamped by 'real life' the last while. I appreciate your patience; please check back periodically to see if I've finally fixed this to work on modern x86_64 Windoze installations and hopefully Linux, where I'm spending more time nowadays. -rlm
The Motorola 68000, sadly, is mostly a relic nowadays. It had a beautiful instruction set and a clean architecture, from software all the way down to the bus protocols. Alas, all good things must pass...
I know the code linked here has been broken for some time. Apparently the FAME emu, or (more likely) my abstraction on top of it, does not boot OS-9 properly on x86_64 Windows. I do intend to look into the issue (really!) but have been swamped by 'real life' the last while. I appreciate your patience; please check back periodically to see if I've finally fixed this to work on modern x86_64 Windoze installations and hopefully Linux, where I'm spending more time nowadays. -rlm
The Motorola 68000, sadly, is mostly a relic nowadays. It had a beautiful instruction set and a clean architecture, from software all the way down to the bus protocols. Alas, all good things must pass...
However, there was a damn good operating system written for this CPU which I just can't stand to see die slowly, rotting on lost floppy discs and SCSI drives. The OS of which I speak is the OS-9 RTOS by Microware: a microkernel which was originally written for the Motorola 6809 CPU as a contract from Motorola to showcase their new CPU (most famously used on the Tandy Color Computer, various GIMIX systems, the Sharp X68000 series in Japan, and the Fairlight/CMI synthesizers of the early 80s), then ported to the Motorola 68k series of processors, the x86, ARM and Hitachi SH series, amongst others.
This operating system has been really short-changed by history. Ask most programmers which consumer (non-mainframe/UNIX/'big-iron') system was able to do multitasking and/or timesharing; you'll usually get answers of the Commodore Amiga, or the PC, or the Mac. They're all wrong. OS-9 was doing this in 1979, before the Commodore 64 even existed, with a full-fledged UNIX-style shell environment and all of the flexibility that philosophy brought with it, in less than 64 kilobytes!
The folks at Microware really should be legends in the industry for their forward-thinking software. Applications, device drivers, the kernel, and even instances of devices were all modules using an object-based structure that could be configured at boot time, then subsequently reconfigured at run-time, as modules were added or removed, with no reboots. Hmm, it only took, what, twenty-plus years, for other mainstream desktop operating systems to achieve this (and imperfectly)?
With that in mind, I now place here a small lifeline for this amazing operating system in the hopes it will be preserved (and perhaps improved...)
OS-9/68k 'RUSSBOX' Emulator Proof of Concept
This uses the FAME/68K emulation library under Cygwin to boot an OS-9 68000 'idealized' abstract system of my own design (by 'abstract', I mean a system which doesn't correspond to any 'real' historical system and is as simple as possible for the purpose of booting OS-9).
--
BUILDING AND RUNNING THE RUSSBOX OS-9/68K (TEST EMULATION):
Requirements
--
Windows XP or Win7_x86 (32-bit)
cygwin (32-bit)
From the cygwin prompt in your home directory:
$ git clone git://tripe.blitter.com/os9_68k_sdk_v12.git MWOS
$ cd MWOS
[This gives the pristine MWOS OS-9/68k port dev tree, sans Hawk UI cruft, etc.]
$ git checkout origin/rlm-sys-1
[This switches to a branch which adds the virtual 'RUSSBOX' support files:
MWOS/OS9/68000/PORTS/RUSSBOX - plus some .d/.a files to support the virtual
hardware in higher directories within MWOS/...]
$ git submodule add git://tripe.blitter.com/rlm-sys-1.git \
MWOS/OS9/68000/PORTS/RUSSBOX/rlm-sys-1
[This is the emulator itself, using FAME 68k library]
$ cd OS9/68000/PORTS/RUSSBOX
$ . ./mwos_env.sh
[open a second cygwin terminal]
$ cd MWOS/OS9/68000/PORTS/RUSSBOX/rlm-sys-1/
$ stty -echo -icanon -icrnl -inlcr min 1 && nc -u 127.0.0.1 8800
[return to first cygwin terminal]
./run.sh
[switch to second cygwin terminal]
[press ENTER]
[You should see a RomBug: prompt.]
[Type [.],[ENTER] to see 68k registers]
[Type [g],[ENTER] to start boot]
[After a few seconds you should see the OS-9 '$' prompt.]
[Type some common OS-9 commands, eg 'devs', 'free', 'mdir', 'dir']
NOTES
The backspace/del key doesn't work.. the terminal via UDP is primitive and the exact setup for 'stty' above can probably be improved to at least let through delete properly.
Typing CTRL-C on the OS-9 terminal also terminates the stty connection, rather than transmitting CTRL-C through to the OS-9 target.
** NOTE after typing CTRL-C to interrupt the UDP terminal, one must type blindly:
stty echo
.. to turn on echo for the cygwin shell again.
Eventually I would like to write a dedicated UDP terminal + emulator 'front panel' that can pass all ascii codes through properly, and integrate in other ways with the virtual target (such as some way to show the virtual framebuffer, I/O, etc.)
While rudimentary this serves as a demonstration that the FAME/68k emulation library is sufficiently accurate to fully bootstrap and run the OS-9 68000 kernel and as such we can preserve the OS-9/68k operating system in an environment which will never be subject to the ravages of time, dying hardware etc. :)
rlm-2013-08-22
UPDATE
For posterity and my own records, I am adding below the notes I made years ago on how to backup an RBF (disk) device from an OS-9/68000 machine to a Windows box over serial line via Kermit or ZModem. This was the best solution in my experience for imaging OS-9 disks, with the minor drawback that it requires a working OS-9/68000 box. Linux (and AFAIK Windows/DOS) really don't like 256-byte sector formats, so it's difficult to do from 'the other side'.
---
HOWTO: Transfer OS-9/68k disk images to a remote system
This HOWTO describes the procedure for transferring raw disk images from an
OS-9/68k system to another computer over serial port.
Hardware Required:
1. OS-9/68k target with one functioning serial port
2. Remote system with a terminal program and zmodem capability (I used
Windows XP and ‘teraterm pro’)
Gathering information
First you must know the format of your OS-9 target’s disks.
[TODO: Quote microware /u0, /d0, /pc0 formats common to many systems]
A utility not included with OS-9 distributions officially, but essential
for managing different disk formats, is ‘dmode’. It can be found on
os9archive.rtsi.com
[http://os9archive.rtsi.com/index.php/os-9-archive-new/file/3913-os-9-archive]
Example for the WCP306:
wcp:dir /hs0
Directory of /hs0 00:13:10
CMDS MODS OS9Boot SYS USR
WCP306.readme init.ramdisk startup
wcp:dmode /hs0
name=hs0
drv=0 stp=3 typ=$27 dns=$03 cyl=80 sid=2 vfy=0 (on) sct=32 t0s=32
sas=8 ilv=2 tfm=0 toffs=0 soffs=0 ssize=256 cntl=$0000 trys=0 lun=0
wpc=0 rwr=0 park=0 lsnoffs=0 totcyls=80 ctrlrid=0 rates=$30
scsiopt=$0000 maxcount=65535
wcp:
Transferring the raw disk image
On the OS-9/68k side, the ‘sz’ utility is used to send the output of the
disk’s raw data (using the OS-9 ‘@’ suffix on a device name to indicate raw
mode) via ZMODEM protocol.
Eg., from the OS-9 shell:
$ sz /hs0@
[OS-9 size will wait for connection from remote side]
Then in TeraTerm Pro, choose File->Transfer->ZMODEM->Receive.
The resulting file will be called ‘hs0@’ on the receiving side. That isn’t
ideal, so one can also use OS-9 pipes effectively to give the data stream
a more meaningful name:
$ list /hs0@ >/pipe/wcp306_os9v3.0_disk1of5_hs0.dsk &
$ sz /pipe/wcp306_os9v3.0_disk1of5_hs0.dsk
Or, using kermit in server mode on the OS-9 side and TeraTerm to get files
(bear in mind KERMIT is much slower than ZMODEM):
$ kermit -x -i
Then in TeraTerm, choose File->Transfer->KERMIT->Get...
and enter the raw filename of the disk (eg., /hs0@)
Here again, one would have to rename the downloaded file to something
meaningful before transferring another disk so as not to overwrite the last
transferred image.
One could also use the stock OS-9 ‘copy’ command with named pipes and tar to
send over serial, then use untar on the other end, or similar methods, to
transfer raw disk images. But ZMODEM has error correction, which is desirable
since serial comms can have errors that would otherwise go undetected.
To do a file-level (rather than sector level) copy of a disk device, one
could use tar on both ends to transfer the disk’s contents:
[From OS-9 side]
$ gtar cf /pipe/hs0.tar /hs0 #128k &
$ sz /pipe/hs0.tar
[On PC side, using TeraTerm Pro]
File->Transfer->ZMODEM->Receive---