Since binaries had been requested, along with the old elf cross compiler I thought I’d try that new fangled github binary releases.
This is just taken from old artifacts from the old Building OSkit & xMach adventures.
I had made a vmdk, MachUK22-lites.vmdk.7z as well, not sure if that helps anyone.
This is a bit cheating, but I broke down and did some dump/exports of a building system to get the file layout. Since the MiG phase was totally done native, I didn’t bother with that, or trying to ‘fix’ the nested Makefiles, rather I just dumped the output and worked with that. I guess I could make my own Makefile but for now it’s a stupid script. I used the a.out build tools for Linux as the objects are all the same anyways.
So yeah, download and extract Ancient Linux on Windows, grab and extract mach25-X113-noblock.zip, and then run:
cd mach25-X113\obj\STD+WS-afs-nfs
build-gcc258.cmdSince there is no Makefile it won’t run in parallel. About 20 seconds or so later you’ll get a linked ‘a.out’ but it won’t run. The script xport.cmd is rigged for me and Qemu 0.10.5 to create a tar file to extract inside of mach and perform the native link.
Obviously this means you can us modern UI’s tools and everything else as you are now on the outside! If you can force your build to use my ancient tools you can even do the build. Nice!
Doing a rebuild of the kernel in Qemu the 2.5.8 -O2 build shaved a whole second off the build, so yes it actually did something.
Things to do would be cross linking, fixing the drivers that don’t build, and probably improving stuff like bigger disks, filesystems and memory… or networking!.. .but that’s all too complicated for me!
Back when I started blogging, I started with a few quick things on the top of my head, that being Netware, SIMH, CP/M Zork, Xenix and of course Mach. Back in the shiny new world of 1999 we may have survived the Y2K apocalypses but the valley was firmly set in the mind of start-up fever that would lead to the looming .com crash but the menatlity of IPO & dump would remain to this very day.
The Utah projects around Mach were wound down with the OSKit being the next wave for pistachio, but that set the scene of more than average users now having ‘fast’ machines at their disposal and the ability to rifle though published source and roll their own. It was this environment of trying to make it in the full force of the post ‘year of the desktop’ Linux where xMach appeared, had some interest and quickly died. For the longest time I had thought all evidence of it had been eradicated as the domain had been excluded from wayback, and searching went nowhere. But one bored night I tried exploring sourceforge, a veteran of the pre .com bubble crash to see if it had anything, and yes it did!
https://sourceforge.net/projects/xmach
Oh sure in retrospect it’s pretty obvious. All the cool kids had public repositories on the internet.. And then after the .com implosion so many took their CSV’s and went home. And so many of those just died in selfhosted, self imposed silence.
From what I remember one of the first goals was to time the source to make it easier to cross compile from either NetBSD or Linux, and utilize what was the double edged sword of Lites, the ability to run either 386BSD/NetBSD binaries or Linux binaries. And the Linux side was already incorporating shared libraries something that was desperately needed in 1993 for X11. But this was 2000! And of course the downfall of running Linux under xMach/Lites is that you will of course compare the performance, and Linux won hands down. Not to mention interest in improving and adding to Linux was in full mainstream support by 2000 so it made xMach feel all the more ancient.
But we didn’t come here for practicality!
First off I’m going to use the cross tool chain for building OS Kit. i586-linux2.tar.gz (password and 404 apply) as I not only don’t feel like fighting why MIG doesn’t work in 64bit, and it’s just easier to enable 32bit usermode. Speaking of for Ubuntu 20.04.2:
dpkg --add-architecture i386 apt-get update apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386 libc6-dev:i386 libfl-dev:i386 apt-get install sharutils gcc-multilib build-essential
And for people like me running on Windows 10, You absolutely MUST enable WSL v2. Without an actual kernel the multiarch simply doesn’t work. No doubt it has something to with actually running Linux vs emulating it. Probably mucking about with the LDT/GDT which you certainly cannot do as a process on Windows.
Next just add the old GCC 2.7.2.3 chain into your path:
PATH=/usr/local/i586-linux2/bin:/usr/local/i586-linux2/lib/gcc-lib/i586-linux/2.7.2.3:$PATH
export PATH
Next up you’ll need the source, and being all new and trendy I put it over on GitHub. Clone the repo, and you are almost ready to start compiling!
As it turns out git didn’t preserve the executable scripts so you have to manually run this:
chmod +x kernel/c*
chmod +x kernel/*sh
chmod +x lites/conf*
chmod +x lites/conf/*You may have to pay attention to the build to make sure stuff doesn’t complain about ‘permission denied’
bash: ../kernel/configure: Permission denied
Basically if you see this, you didn’t do it right.
Make an object directory and run configure like this:
../kernel/configure --host=i586-linux --target=i586-linux --build=i586-linux --enable-elf --enable-libmach --enable-linuxdev --prefix=/usr/local/xmach;cp ../updated-conf/kernel/Makeconf .
For some reason configure never populates the compiler tools right, and I can either mess with autoconf (no thanks) or I can just include a known good file. It’s not hard to figure out, you can diff it if you want to, but it’s just set for a native 32bit build of MIG, and then using the cross tools to build the kernel.
type make, and wait 13 seconds, give or take…
i586-linux-ld -r -L/home/jsteve/src/xMach/kernel-build/lib -nostdlib \
-o bsdboot.o crt0.o about_to_die.o anno.o boot_info_dump.o boot_start.o cpu.o cpu_init.o cpu_tables_init.o cpu_tables_load.o crtn.o die.o do_boot.o exit.o gdt.o idt.o idt_inittab.o idt_irq_init.o main.o malloc.o panic.o phys_mem_add.o pic.o putchar.o puts.o real_tss.o real_tss_def.o rv86_real_int.o rv86_real_int_asm.o rv86_reflect_irq.o rv86_trap_handler.o serial.o trap_dump.o trap_dump_die.o trap_handler.o trap_return.o tss.o tss_dump.o -lmach_exec -lmach_c
make[1]: Leaving directory '/home/jsteve/src/xMach/kernel-build/boot/bsd'
MACHBOOTDIR=cd /home/jsteve/src/xMach/kernel-build/boot/bsd; pwd \
/home/jsteve/src/xMach/kernel-build/boot/bsd/mkbsdimage -o /home/jsteve/src/xMach/kernel-build/Mach /home/jsteve/src/xMach/kernel-build/kernel/kernel /home/jsteve/src/xMach/kernel-build/bootstrap/bootstrap
real 0m13.135s
user 0m12.060s
sys 0m1.383s
I cannot stress just how incredibly fast this is. I’m pretty sure it literally took hours for this to run, assuming nothing went wrong, which it almost always did. As part of the fun, next do a ‘make install’
This is somewhat similar to the kernel build, however it is far more touchy. You absolutely MUST copy / fix the Makeconf file otherwise the build will be corrupted and the only way to fix is to remove the build directory and try again.
../lites/configure --host=i586-linux --target=i586-linux --build=i586-linux --enable-mach4 --prefix=/usr/local/xmach --with-mach4=../kernel;cp ../updated-conf/lites/conf/Makeconf conf
And once more again make the project and just wait a few seconds. BSD without the hardware support is pretty tiny
i586-linux-ld -o emulator.Lites.1.1.u3.out ./emulator_base -L/home/jsteve/src/xMach/lites-build/liblites -L/usr/local/xmach/lib -e __start ecrt0.o e_mig_support.o emul_generic.o error_codes.o emul_init.o emul_mapped.o emul_misc_asm.o e_bsd.o e_43ux.o bsd_1_user.o emul_mach_interface_user.o e_mach_msg_server.o e_stat.o e_bnr.o emul_exec.o signal_server.o e_uname.o e_mapped_time.o e_sysvipc.o e_linux.o e_sysv.o e_exception.o e_signal.o e_machinedep.o e_linux_trampoline.o e_linux_sysent.o e_isc4_sysent.o e_cmu_43ux_sysent.o e_lite_sysent.o emul_vector.o e_trampoline.o e_linux_getcwd.o -llites -lthreads -lmach_sa /usr/local/i586-linux2/lib/gcc-lib/i586-linux/2.7.2.3/libgcc.a && \
i586-linux-size emulator.Lites.1.1.u3.out && \
mv emulator.Lites.1.1.u3.out emulator.Lites.1.1.u3
text data bss dec hex filename
130195 16904 160 147259 23f3b emulator.Lites.1.1.u3.out
make[1]: Leaving directory '/home/jsteve/src/xMach/lites-build/emulator'
make[1]: Entering directory '/home/jsteve/src/xMach/lites-build/bin'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/jsteve/src/xMach/lites-build/bin'
real 0m6.423s
user 0m6.006s
sys 0m0.551s
Yes that’s six seconds. do a ‘make install’ and now your /usr/local/xmach directory is fully populated and ready to transport somewhere to do the ‘install’ and boot.
One thing to take notice of xMach over the standard last Mach4 is that the Linux boot options have been removed. There is all kinds of changes in 16bit assembly handling that need to be rewritten or fixed. I’m sure someone at some point has, but apparently it’s easier to go with the bsdboot and use either the machboot or GRUB (v1!) to get it going. Although Linux knows how to mount loop ‘diskfiles’ I don’t remember how to deal with partitions and BSD slices. So I did my typical trick of booting up an existing image, and using telnet/uucp to transfer xMach into an existing disk.
Booting however was a bit more fun, as the kernel is now compiled as a BSD ELF image and Grub 1.x won’t boot it. I used a ‘Super Grub2 disk hybrid‘ ISO image, and was able to just hit escape and type in:
kfreebsd (hd0,msdos2,bsd1)/Mach boot
Because of the massive drift in multiboot vs ‘BSD ELF’ the drive isn’t passed correctly so I have to manually tell it ‘/dev/hd0a/mach_servers’ and it’ll pick up Lites, and boot up!
And there we go, with my old Mach4/Lites image from 2009 with a ‘fresh’ cross compiled build from Windows 10 / Ubuntu 20.04
Realistically, nowhere. Seven years ago there was OpenMach, which seems to have done a few things, but even moving to a GAS from 2015 didn’t help me at all trying to build the 16bit stuff so the answer must lie in the past. Otherwise the fundamental problem as always is at best you will have a 4.4BSD system which again in 1992 would be awesome, but 2021? yeah it’s a curiosity at best.
I saw this great board online carousell, on some local seller board. Although eBay may be the defacto site for buying old garbage, keep an eye out for local stuff too. There is craigslist in the USA & Kijiji in Canada.
Yes, it’s an Intel l440gx+, a dual processor motherboard, with an ISA slot! I’m pretty sure it’s all 5v PCI slots, but who knows. And at $250 HKD, much cheaper than the ones on eBay. Although condition is pretty much unknown.
And it has two Pentium III’s clocked in at an amazing 750Mhz. It’ll make a great MS-DOS box for sure, with plenty of punch. Along with being great for Windows NT 4.0
I think it may have 128MB of RAM as well. Not great, but it’s still pretty good.
Being this old also means it most certainly is MP 1.1 compatible, as I just found this mp_v1_1.c lurking in the OSFMK used in the ancient/abandonded mach kernel for MkLinux. Of course half the fun will come in trying to build the kernel from source (can’t find any intel binaries), and seeing if this old board works.
Of course getting the board was a mission in itself, as I had to cross through one of the big protests last night to get it. I took some video of it on my way back, and walked up to where the front line was going to be.
While the kernel may boot on SIMH there is certainly something going on with the SIMH emulation of the hardware that threw me for a few loops. I had a pre-installed version of 4.3BSD which was on a RA81 disk but shortly after loading the kernel various binaries wouldn’t load, filesystems wouldn’t mount and of course the inevitable file corruption.
This led me to the fun of loading up 4.3 onto RP06 disks as they are smaller and I was hoping less prone to errors. During this fun, I found this page on plover.net, which as a fun filled tangent shows how to use the Quasijarus console floppy image to run the standalone programs. With the latest version of SIMH, I can run format and it initializes the disks, so I almost think it may be possible to do some kind of ‘native install’ on the VAX-11/780 SIMH, although It’s not what I was in the mood for.
So finally with an install over several RP06 disks, I was lucky enough to figure out how to build the Mach’86 kernel, and get it to boot, and then the corruption happened again. Luckily for me I had snapshotted the disks before experimenting and noticed how even those had issues booting up. It’s after a bit of searching I found that other people may have issues with SIMH’s Async I/O code, and the best thing to do, is just to disable it with a “set noasync”.
Now my disks could boot under the Mach kernel, and I could self host!
Setting up the build involved copying files from the ‘cs’ directory to their respective homes, along with the ‘mach/bin/m*’ commands to the /bin directory. Configuring the kernel is very much like a standard BSD kernel config, however the directory needs to exist beforehand, and instead of the in path config command run the config command in the local directory.
While maybe not perfect, keep in mind I haven’t found any real instructions as of yet, so this is more of a ‘wow it booted’ kind of thing at the moment.
While this kernel does have mentions of multi processor support I haven’t quite figured out what models (if any) are supported On the VAX, and if SIMH emulates them. While oboguev.net has a very interesting looking multiprocessor VAX emulation, VAX_MP it’s a fictional model based on the microvax, which I’m pretty sure 4.3BSD/Mach’86 is far too old for.
And for those who want to play along, here is a zip file of the disk images, emulator and config file I’m using, Mach86.zip
Ever since I got my hands on the Mt Xinu disk images, I’ve been working to see if the old Mach kernels on the CSRG CD-ROM set are actually buildable and runnable. And the TL;DR is that yes, they are.
The CD has 3 Mach kernels, the MK35 kernel, a kernel that appears to be something called X147, and a release of Mach 3.0. While X147 has hardware support for the SUN-3 and most of the files for the VAX, only MK35 has hardware support for the i386. The MK35 kernel has incomplete Makefiles and other dependencies, while X147 lacks i386 support. The good news is that it’s possible to use portions of the missing config & Makefiles from X147 to fill in for MK35, as it’s possible to copy the platform code from MK35 along with the i386 specific config into X147, yielding 2 working kernels.
Now this leads to the next few issues. The hardware support appears to be code ‘donated’ from various OEMs from Intel, Olivetti, Toshiba, OSF, and the CSRG. Dates vary from 1987 to 1991.
I started with the MK35 kernel as it was smaller, and since it was tagged as an ‘Intel only release’ of Mach, I figured that this one had the best chance of actually working.
boot: 442336+46792+115216[+38940+39072]
And this is as far as it got on it’s first attempted boot. The Qemu VM would immediately reboot. Since I had installed Mt Xinu on VMware I went ahead and tried it there, and it said that there was a critical CPU exception and that it was shutting down. Bochs did the same thing, as did PCem. Since nothing was being printed to the screen it must be failing in the locore.s which is split into several assembly modules. I put in a hlt at various points and kept rebuilding and rebooting to see if it would halt or if it’d reboot. Thankfully VM’s are cheap and plentiful, I can’t imagine how tedious this would be on actual hardware. Eventually I found out that right after the paging bit in CR0 was flipped the VM would reboot. Now I had something.
    / turn PG on     mov   %cr0, %eax     or   $PAGEBIT, %eax     mov   %eax, %cr0     mov  %edx, %cr3
I had tried not flipping the page bit, not flipping cr3, no matter what I tried it would triple fault and reboot.
I had to break down and beg for help, and as luck would have it, someone who knows a heck of lot more about the i386 than I could ever hope to know took a glace at the above code and immediately noted:
I looked at start.s. And it immediately jumped out at me as being very fishy. What they do is enable protected mode *and* paging, but only then load CR3. That’s something which may well work on some CPUs, but it’s against the rules. You could try just swapping the instructions around, first load CR3, then CR0. The next question is then if that code executes out of an identity-mapped page; if yes then just swapping the instructions should do the trick, if not then there is a bigger issue.
 Background: Old CPUs, especially 386/486, will decode and pipeline several instructions past the protected mode switch (mov cr0, eax). The jmp instruction is there to flush that pipeline and make sure all further instructions are executed with the new addressing mode in effect. But old CPUs did not enforce that and it was possible to execute the jmp from a non-identity-mapped page, and I guess it was also possible to execute instructions between the move to cr0 and the jmp, at least most of the time. That tends to break on modern CPUs (probably P6 and later) and definitely in emulation/virtualization. The move to cr0 effectively flushes the pipeline and if the next instruction is not in the page tables, poof, there goes the OS.
Could it really be that simple?
    mov   %edx, %cr3     / turn PG on     mov   %cr0, %eax     or   $PAGEBIT, %eax    mov   %eax, %cr0     / mov  %edx, %cr3
I commented out the cr3 line and just pasted above the cr0 pagebit flip.
Amazingly the kernel booted. Behold the first boot of Mach/4.3 which very well could be the first boot independent of the CMU and I’d venture the first boot from the source on the CSRG CD-ROM set. I tried to tell Mach to use the disk as prepared by Mt Xinu, but naturally it’s incompatible.
The next thing to do was create a root diskette, which thankfully the CMU folks left the needed files in the standi386at directory. I was able to build the disk, and using VMware I could boot into single user mode. I went through the ‘unpublished’ documentation I was able to mirror, and was able to get lucky enough to have Mach prepare the hard disk, format the partitions, and I used tar to transfer the root diskette onto the hard disk. I thought it ought to be possible to boot from the boot disk, have it mount the hard disk, and re-mount the boot disk, and copy the kernel. Sounds reasonable right?
This is where the incredibly stale platform code showed it’s head once more again as the floppy driver in MK35 is amazingly useless. It seems that the emulated hardware is too fast? But all reads from the floppy using the hard disk as root failed. Instead I removed a bunch of files from the disk, and copied over gzip & a compressed copy of the kernel to disk, along with the boot.hd program, and was able to copy them to hard disk using that modified root diskette. Luckily Mach has support for a.out binaries, and this stuff being so old it’s all statically linked. My Mt Xinu build of gzip runs fine on the Mach kernel, so I could decompress the kernel and install the bootblocks.
This is where the next weird issue would happen, which is that Mach was quite insistent on mounting everything under this /RFS directory. It appears that RFS was CMU’s answer to NFS… Which needless to say didn’t ignite the world on fire. I was later able to find that I could disable the RFS code, re-configure, rebuild and re-transfer a kernel and with a bit of fighting with mount I was able to mount hd0d/hd0e. Sadly during the install process there was no visible option to specify slice sizes so I’m stuck with a 10MB root.
With this much luck in hand I thought it may be interesting to see if Mt Xinu could mount the Mach disk. Turns out that it can without any issues. So I went ahead and wiped the Mach disk, and transfered Mt Xinu over to the Mach disk, and rebooted with that. And it “works”! Although of course there is some caveats.
The first being the aforementioned floppy support is broken. The next one being that the serial support also suffers from basically losing interrupts and leaving the system waiting. The kernel debugger still works, and you can see it in the idle loop, along with the other threads waiting. This means my favorite method of using uuencode and pasting to the terminal won’t work, MK35 locks up after 35kb, and X147 made it as far as 150kb. Keep in mind that they are using the same i386/i386at platform directories.
So I’m quite sure that there is other issues hiding in the code, maybe obvious ones like the cr3/cr0 thing. On the other front I’ve been starting at looking at doing some porting of the Tahoe/Quasijarus userland with varying success. I have already started to rebuild some binaries with a substitute crt0.o as there is no source for anything included in the Mt Xinu distribution outside of the Mach 3.0 kernel.
For those who want to play along I have uploaded VMDK’s and the source tarballs.
For people using Qemu I find that a serial terminal is FAR nicer to use than the console. Also I’m unsure of how hard the 16MB ISA DMA window is being hit, but X147 seems okay with 64MB of ram, while M35 really needs to be 50MB or less..
qemu.exe -L pc-bios -hda Mach25-MK35.vmdk -serial telnet:127.0.0.1:42323,server,nowait -m 16
This puts the serial port into TCP server mode, so you can simply telnet into the serial port. As always change the memory are your own discretion.
I’ve been looking for this, since I first found out about it a few years ago. It’s a port of 4.3BSD Tahoe to the i386, utilizing the Mach kernel. This is the biggest gap of the era, which is bringing mini-computer BSD to an affordable platform, the AT386.
Sadly like many others after Mach386, it did not find widespread commercial success and MtXinu wound down operations of the product, and eventually the company itself. It’s a shame too that both Mt Xinu & BSDi eventually exited the BSD market, while the open 386 alternatives flourished and grew.
One thing is for sure, it wasn’t cheap! At least on the perpetually starving college student budget the base license was $995! And that included no source code at all. Although the Mach 3.0 Add-on does include source code, however because of the then new AT&T USL vs. BSDI/UCB lawsuit CMU got cold feet over it’s BSDSS/BNR2SS for Mach 3.0 and pulled it, leaving you with a micro kernel with no personality. Although years later the rights would flow from AT&T to Novel who then let Caldera acquire them, and then give the infamous 32v giveaway (pdf) essentially setting BSD free. Although I was one of the people who shelled out the $100 for the oldSCO SYSIII license back in the day.
Mach386 lived from around 1991 until 1993. Needless to say the Juggernaut called Linux appeared at the right time and the right place, when all of the BSD’s had faltered because of that lawsuit. Sometimes in life, timing is absolutely everything.
Sadly by the time I could afford expensive OS’s it was 1999 and I’d bought OS X Server 1.0, with all it’s 4.4BSD + Mach 2.5 fun.
Anyways fast forward a few decades and I have been looking for a mythical 4.3BSD on i386 for far too long, and I came across a post on betaarchive mentioning retrosys.net, and all of Scott’s adventures with Mach386. So I was able to contact him, and get a copy of Mach386!
Installation:
Well the disk set is from 1992, and going back to that era means you are going be locked into the old disk geometry where an IDE disk under 500MB is the best way to go. The floppy controller is programmed in a weird way that the only thing I could get it working with was VMWare. It wasn’t so bad going through the disks, and I quickly had a system up and running. Once the install is done it’ll run under QEMU for instance just fine.
Currently there is no ‘modern’ ish networking support, aka no NE2000. So I’ve been using serial terminals to use uuencode/uudecode to get files in & out of the VM.
So what’s in the box? Well I didn’t install the X11 stuff as I’m just not in the mood to fight it, but it’s a 4.3BSD system! Sadly adventure/zork is absent, however rogue and all the other BSD type fun is there. gcc version 1.37.1 & GNU assembler version 1.36 among others are also includes, although without any diff’s or source. Although the networking headers & tools are on separate disks, there is no nonsensical link kit type thing like Xenix, meaning that TCP/IP is fully integrated to the kernel. While there is SLIP support apparently I haven’t messed with it at all yet.
What is really interesting is the other disk set, MtXinu-Mach386-M3921131020-Mach_3.0+DUI.7z which is that Mach 3.0 kernel version MK78 which I believe is the first widespread & public release of Mach 3.0.
Being that this a Mach based system it builds the 3.0 kernel with ease. It even includes a 4.3BSD (sadly binary only) ported kernel to the 3.0 Mach which you can run. It’s defiantly not as fast as the default kernel, but seems to work well enough.
The kernel in question is what they term Mach 2.6 which is the 2.5 plus lots of enhancements. Among others is a different disk layout/partitioning scheme so you can dualboot. Although in the era of cheap VMs it’s kind of pointless.
So it may not look like much, but it’s a really fun thing to play around with. At the same time 386BSD had been pushed out into the world, and Linux was also a thing. It’s not surprising that Mt Xinu & BSDi would eventually fail in the marketplace, and Linux would go on to decimate the UNIX landscape. But it’s cool to run a direct VAX based OS on the PC.
It’s just been really busy with this move, unpacking and the usual losing things, finding things and breaking things.
In the middle of it all, I found something online, that I want to at least do some proper article thing about… As it’s been really exciting, and goes back to the first month I started this blog.
Outside of NeXTSTEP, the other i386 commercial version of Mach 2.5 surfaced, the Mt Xinu version!
Even better, a few years ago, I had stumbled onto the source code for 2.5 buried on the 4th disc of the CSRG set, and with a LOT of luck and persistence I can confirm that the sources are complete enough to build.
loading vmunix.sys rearranging symbols text data bss dec hex 389088 45564 101364 536016 82dd0 ln vmunix.sys vmunix; ln vmunix vmunix.I386x.STD+WS-afs-nfs
However, as luck always has it, start.s in the i386 code does something weird at the 3GB mark causing a triple fault on any kind of modern emulation/virtualization setup.
/ Fix up the 1st, 3 giga and last entries in the page directory
mov $EXT(kpde), %ebx
and $MASK, %ebx
mov $EXT(kpte), %eax
and $0xffff000, %eax
or $0x1, %eax
mov %eax, (%ebx)
mov %eax, 3072(%ebx) / 3 giga -- C0000000
mov $EXT(kpde), %edx
and $MASK, %edx
Not all that sure why, but at least on Bochs, I can see the triple fault.
00036527018d[CPU0 ] page walk for address 0x0000000000101122 00036527018d[CPU0 ] page walk for address 0x00000000e0000011 00036527018d[CPU0 ] PDE: entry not present 00036527018d[CPU0 ] page fault for address 00000000e0000011 @ 0000000000101124 00036527018d[CPU0 ] exception(0x0e): error_code=0002 00036527018d[CPU0 ] interrupt(): vector = 0e, TYPE = 3, EXT = 1 00036527018d[CPU0 ] page walk for address 0x00000000c0161370 00036527018d[CPU0 ] PDE: entry not present 00036527018d[CPU0 ] page fault for address 00000000c0161370 @ 0000000000101122 00036527018d[CPU0 ] exception(0x0e): error_code=0000 00036527018d[CPU0 ] exception(0x08): error_code=0000 00036527018d[CPU0 ] interrupt(): vector = 08, TYPE = 3, EXT = 1 00036527018d[CPU0 ] page walk for address 0x00000000c0161340 00036527018d[CPU0 ] PDE: entry not present 00036527018d[CPU0 ] page fault for address 00000000c0161340 @ 0000000000101122 00036527018d[CPU0 ] exception(0x0e): error_code=0000 00036527018i[CPU0 ] CPU is in protected mode (active) 00036527018i[CPU0 ] CS.mode = 32 bit 00036527018i[CPU0 ] SS.mode = 32 bit 00036527018i[CPU0 ] EFER = 0x00000000 00036527018i[CPU0 ] | EAX=e0000011 EBX=0015f000 ECX=00161dc1 EDX=0015f000 00036527018i[CPU0 ] | ESP=0000efbc EBP=0000efbc ESI=00193fb8 EDI=00009d84 00036527018i[CPU0 ] | IOPL=0 id vip vif ac vm RF nt of df if tf SF zf af PF cf 00036527018i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D 00036527018i[CPU0 ] | CS:0028( 0005| 0| 0) 00000000 ffffffff 1 1 00036527018i[CPU0 ] | DS:0020( 0004| 0| 0) 00000000 ffffffff 1 1 00036527018i[CPU0 ] | SS:0010( 0002| 0| 0) 00001000 0000ffff 0 1 00036527018i[CPU0 ] | ES:0020( 0004| 0| 0) 00000000 ffffffff 1 1 00036527018i[CPU0 ] | FS:0000( 0005| 0| 0) 00000000 0000ffff 0 0 00036527018i[CPU0 ] | GS:0000( 0005| 0| 0) 00000000 0000ffff 0 0 00036527018i[CPU0 ] | EIP=00101122 (00101122) 00036527018i[CPU0 ] | CR0=0xe0000011 CR2=0xc0161340 00036527018i[CPU0 ] | CR3=0x00000000 CR4=0x00000000 00036527018i[CPU0 ] 0x0000000000101122>> add byte ptr ds:[eax], al : 0000 00036527018d[SIM ] searching for component 'cpu' in list 'bochs' 00036527018d[SIM ] searching for component 'reset_on_triple_fault' in list 'cpu' 00036527018e[CPU0 ] exception(): 3rd (14) exception with no resolution, shutdown status is 00h, resetting
Mach 3.0 doesn’t do this, so I’ll have to dig far deeper into start.s which is kind of really beyond me.
Building a boot disk … is involved. 😐
rm -rf /usr/src/mach25-i386/obj mkdir /usr/src/mach25-i386/obj cd /usr/src/mach25-i386/standi386at/boot make fdboot /home/user/mkfs /dev/rfloppy 2880 18 2 4096 512 32 1 dd if=/usr/src/mach25-i386/obj/standi386at/boot/boot.fd of=/dev/rfd0d /home/user/fsck -y /dev/rfloppy cd /usr/src/mach25-i386/ make mount /dev/floppy /mnt cp /usr/src/mach25-i386/obj/STD+WS-afs-nfs/vmunix /mnt sync umount /mnt /home/user/fsck -y /dev/rfloppy
So, I’m not all that dead. For anyone super impatient, you can download my VMDK here, which runs on Qemu & VMware, it includes a serial terminal on COM1 so you can use a real terminal, and if you are like me, uuencode/uudecode files in & out of the system. As always read the 404 page for the current username/password.
The LC isn’t a strong Macintosh. It is after all, a low cost model. And what I’m doing isn’t even slightly fair to it.
Since it has a mere 68020 running at a blazing 16Mhz with no 68881 nor any MMU running something like A/UX is simply out of the question. However MMU less Mac’s can run MachTen.
Although I did make a backup of the disk to find out that this thing had been in Harvard of all places, apparently once belonging to Mark Saroyan.
Although there was nothing even slightly academic or useful on the disk. I wonder if the software was even pirated as the last owner sure enjoyed all the various SIM games (city/earth/life/ant) it seems more than anything else.
I formatted the massive 50MB SCSI disk, put on a fresh copy of MacOS 7.0.1 along with the network driver and MachTen 2.2.
And as far as LC’s go, this one isn’t too bad, it’s loaded up with the maximum 10MB of RAM, although it seems the VRAM is pretty sparse as it’ll only go to 16 colours. But since we are playing UNIX here, I didn’t see any need for that, and set it to mono.
I thought it’d be fun to install a gopherd server onto this machine, and that is where the fun started.
Granted it’s been a long time since I used a machine with no real L2 cache, let alone running at a whopping 16Mhz, and using a compiler like GCC is just incredibly slow.
So I thought I could just ‘cheat’ the system by taking the source code to GCC-1.42 and tweaking the SUN3-Mach configuration into a SUN2-Mach configuration but keeping it targeting a BSD like OS, along with setting it to compile to a 68020 without a 68881. Oddly enough getting a cross compiler wasn’t so difficult, but the assembler on the LC, a modified GAS wouldn’t assembler the files. So I went ahead and built a68 from GAS 1.38 and now I can cross assemble from Windows. However I couldn’t get the linker ld from binutils-1.9 working. I guess it was an endian issue somewhere, but my attempt at byte swapping files it was reading just led to further confusion. And I figured linking on the target host wouldn’t be the end of the world, as compiling sure feels like it is.
I can’t see like anyone would care, but here it is:
MachTen-crossgcc-1.42-nolinker.7z
So fighting the source and in a matter of a 30 minutes of on/off work I had it compiled. All I needed to do then was FTP the objects to the machine, link and run. Surprisingly this proved to be pretty simple.
I managed to get a few pages out of it, and suddenly my telnet sessions dropped. Looking over at the console and MacOS was busy being MacOS.
And that was that.
I tried another program to cross compile and upload phoon!
It took a while to set the clock to the right year, as my minimal System 7 install doesn’t have the time control panel, and advancing 1 year at a time from 1999 takes time, by advancing the date to New Years Eve every minute 19 times to get us to 2018 with the old date syntax:
date 12312359
Obviously if I want to do something like this, I’m going to need a better Macintosh. Or just not do things like this….
I’m kind of on the fence as to whither 68k Unix is really all that useful in the age of Ghz x86.
MachTen console
Not that I need another UNIX, but I came across this fine thing googling around for some Mach based OS’s running on the 68000, and well here is MachTen. Â Perhaps the most notable thing about MachTen is that it is capable of running in usermode under MacOS. Â Without a MMU.
# cc -v hi.c -o hi gcc version 1.40 /usr/local/PMtools/cpp -v -undef -D__GNUC__ -Dunix -D__MACHTEN__ -DMACHTEN -DTENON -D__unix__ -D____MACHTEN____ -D__MACHTEN__ -D__TENON__ -Dmc68000 hi.c /var/tmp/cc000093.cpp GNU CPP version 1.40 /usr/local/PMtools/cc1 /var/tmp/cc000093.cpp -fno-builtin-alloca -fno-defer-pop -quiet -dumpbase hi.c -version -o /var/tmp/cc000093.s GNU C version 1.40 (68k, MIT syntax) compiled by GNU C version 2.3.3. default target switches: as -mc68000 -o hi.o /var/tmp/cc000093.s ld -o hi -x /usr/lib/crt0.o hi.o -lc # size hi text data bss dec hex 11220 400 1672 13292 33ec # ./hi hello!
And yes, it even supports TCP/IP with it’s own TCP/IP stack. Â It can even operate as a router of all things! Â From a users point of view it is a little sparse, but it’s 4.3BSD, and thankfully includes the C compiler, so unlike of UNIX of the era on ‘small hardware’ this one isn’t crippled.
configuring TCP/IP
TCP/IP is configured through the MacOS via the control panel. Â As you can see it can use AppleTalk, Ethernet and TokenRing interfaces. Â For my simplicity, I’m just using SLiRP on the Ethernet, so it’s the old 10.0.2.15/24 setup. Â I re-compiled my BasiliskIII to redirect a port into the VM so I can telnet into it.
To install System 7.0.1 you need to set Basilisk II / Cockatrice III as a IIci. I went ahead and used this ROM. Â The ROM however does expect there to be a FPU.
rom Mac-IIci.ROM
modelid 5
cpu 2
fpu true
Running however, I’ve been able to set the CPU to 3 or 4 (68030/68040) and it’s fine, I think the major thing is the modelid. Â If I try this under System 8 which needs a 68040, then it’ll crash in spectacular ways. Â You don’t need MacTCP as again MachTen is a 4.3BSD kernel with Mach 2.5, so it has it’s own.
MachTen also includes support for NFS! Â This greatly eases getting data in & out of the system. Â To mount my Synology I just need the following command:
mount -t nfs -o timeo=1,retry=1,rsize=512,wsize=512,retrans=1 192.168.1.3:/volume1/Data /mnt/data
And I’m good to go!