Once more unto the breach: Retrochallenge 2016/01 draws near and it is time to decide what my entry project should be.
This time it is really hard to decide what on Earth to do – as outlined previously, the “Galaxy Pressed” project is just too expensive (although there has been a recent post on the sun-rescue mailing-list of a Sun 3-slot 9U VME deskside enclosure available for postage cost only, an SS600 mainboard is still out of reach due to “museum prices”). After all the severe stress and strain of my 2015/01 PSU project “Watts Up“, I am not ready to take on a similar task for my SGI Indigo R3000 just yet – I still need time to cool off (I’m still furious at that darned crimp-tool)! In principle, my last project, “Evie Beer“, equipped me with enough electronics knowledge to better tackle the previously-aborted “Fraggle Jock“, but I just get the feeling that doing another 68hc11-based hardware task straight away, would be soooo “last year” – something a little topically different is needed.
I have toyed with the idea of mucking about with a Cambridge Z88 microcomputer (micro by 1988 standards that is – “The iPad of the 80s!”), but there are way too many Sir Clive fanbois involved in retrochallenge already, and it’s best not to encourage them! So scratch the Z88. Besides, I just missed the cheap one on eBay complete with add-in 128Kb RAM cartridge and 128Kb EPROM cartridge (£10.50 all-in).
The Norse Godess of Tools:
So let’s go for something utterly different… bear with me, this might take quite some explanation… this time around, I am going to be attempting to write and compile a small C program to run on Whitesmiths’ Co-Idris operating-system – a 1978 clean-room reimplementation of 6th Edition UNIX, that runs on top of PCDOS/BIOS (see https://en.wikipedia.org/wiki/Idris_(operating_system), https://en.wikipedia.org/wiki/Talk:Idris_(operating_system) and http://www.dadhacker.com/blog/?p=1383#comment-13123).
Writing a pretty minimal C program that does a tiny bit of I/O doesn’t sound like such a big deal, does it?
Yes, But No, But Yes, But No, But…
However, the only copy of Co-Idris I have is “runtime only” – without the C compiler, libraries, Idris header-files, assembler, linker, etc, etc, etc. Way back then (1985), I just needed a small shell-script playground – small enough to fit on a single 1.44Mb diskette, so I ditched the SDK bits and all the manpages. At the time, I had access to a complete Co-Idris/x86 cross-compiler running on a 68000-based minicomputer, so I didn;t need the native C compiler then, but that was 30 years ago and the minicomputer is long gone.
Without the Idris header-files and Co-Idris link-time libraries, it would traditionally not be possible to write a program that makes any system-calls. And without a C compiler and assembler it would only be possible to write a program in raw binary, except that that wouldn’t be possible either – unless there is some way of decoding and deconstructing the required executable file-format (remember, this is waaaaaaay before ELF, and even before NMAGIC file-format!).
Making the task trickier is that being a 6th Ed. UNIX workalike, there are no “modern” tools like bash, Bourne Shell, disassembler, object-file inspector, find, vi, ex, file, more, basename, cut, paste, join, expr, make, m4, strings, touch, nm, and so on, and so on. This is about as minimal a UNIX-like system as you could find.
There isn’t even ed – rather the Idris line-editor is called e, and operates merely “similarly”. I’m sure the usage will come back to me… ah, yes: having to memorise line-numbers just to edit a text-file.
The Idris shell is a faithful workalike of the 6th Ed. UNIX shell, which is not a good thing: no if/else, no while, no shell-functions, only 26 variables (limited to single-letter names!), no environment-variables, but at least it has “goto” and logical “&&” and “||”.
Bless the Gods, Co-Idris also has “od”, so hex-dumping files is possible, and it has “dd”, so extracting/replacing hand-computed portions of binary files can be done natively, with effort.
Of course Co-Idris doesn’t have Ethernet or graphics capability. Take your multiple serial-ports and just be grateful, dammit. It is the late 70s, after all.
A Possible Way Round:
I do have a binary distribution of a Whitesmiths C compiler and assembler for PCDOS, which produces PCDOS executables, but fortunately it does so by first producing a “Whitesmiths-format” executable file, and then running it through an external utility that converts it to a .EXE file; so the intermediate file is in the right format for direct execution under Co-Idris, except that it is linked against the PCDOS runtime libraries (ie: contains stubs that use specific x86 INT instructions to call on PCDOS services where needed, instead of stubs that invoke Idris system-calls). Hand-crafting Idris stubs to link against isn’t going to be easy – I will need to determine the Idris system-call method and numbers by inspecting the existing binary Idris program files (eg: a hex-dump and manual disassembly of “cat” etc). I do have a two-page description of the Idris relocatable object file-format in dead-tree form (that relocatable object-format is also the Idris executable format, strange as that may seem), so hand disassembly is at least in principle possible, even though it will be a royal pain in the ass🙂
So after considerable effort at reverse-engineering, I might just be able to customise the (binary) PCDOS C compiler into a cross-compiler targetting Co-Idris. I’ll also have to write my own C function library if I want to do anything beyond system-calls, but for this project, system-calls alone should suffice.
Finally, I am going to have to craft up my own assembly-code (or binary) C runtime-startup object-file (Idris-specific), to pre-open the standard input/output/error file-descriptors, initialise the stack, and convert the top-of-stack parameter data into C-style arguments to main(); all based on what I can glean from the few paper manuals I have left, or perhaps by extracting the right bytes from an existing Co-Idris binary executable (“/bin/cat”, probably)! Not a trivial exercise, by any means.
So, welcome to project “Silver Doofer”; January is going to be… well, interesting? The best feature of this project is that the results will be utterly useless, its’ just a voyage of retro-masochism. For the fun! For the fun!