Mini vMac II for OS X (PPC)

Emulators in Emulators..

I wanted to run some old 68000 programs on OS X, but as luck would have it, OS X 10.5 doesn’t support the classical environment, and the 10.4 discs that I have won’t boot on a G5.  So I don’t have a good way to get there from here.  However I did remember the great mini vMac is very portable, runs 68000 code great, and even can run 68020 programs with the experimental branches.. So I had to install OS 7 on a Windows machine with my last binary, configure the source there, then import it to my PowerPC, then build it on my G5.  The OS X PowerPC build is lacking sound (did the intel OS X have it?) but it runs!

For anyone that cares, my PowerPC binary is here.

I’ve just updated it to contain all the 32bit binaries…

$ file minivmac

minivmac: Mach-O universal binary with 3 architectures
minivmac (for architecture i386): Mach-O executable i386
minivmac (for architecture ppc7400): Mach-O executable ppc
minivmac (for architecture ppc): Mach-O executable ppc

It turns out this is reliant on Carbon, which doesn’t allow for 64bit binaries…

25 years of GCC!

In 1987 the first announcement went out that Stallman had introduced perhaps the most important piece of GNU software ever:  GCC.

I haven’t been able to locate the 1.0 release or even the 0.9 beta (*Edit as an update, yes I’ve found it, and installed it!), as close as I could find was 1.21 from May 1st, 1988. Even at this time, GCC supported the following CPUs:

  • m68k
  • ns23k
  • spur
  • vax
Amazingly GCC at this point is pretty snappy, and very ANSI compliant unlike PCC.  At this point it still relies on native assemblers, linkers, librarians it still was pretty versatile. Back then there was no auto configuration tools you have to link configuration scripts by hand but even on VAX BSD it builds somewhat straightforward (providing you read the documentation)..

GCC 1.21 on 4.2 BSD

I don’t know if it serves any practical value but I went ahead and built a source package for GCC 1.21, along with a 4.2 BSD binary package.. I suspect it’d only be an interest to a select few.. Although if anyone has 1.0 or 0.9 I’d be interested!

By 1991 GCC 1.40 supported not only the i386, but Linux kernel.. And as they say the rest is history.

And finally a video summation of all the changes to GCC…

 

Yet another update for QuakeWorld/Quake for MS-DOS

You can download the source/binaries here.

The big change is that you can not play larger maps, like the dreaded Warp Spasm (which of course relies on QUOTH).

Warp Spasam under OS/2

I’ve also built it for OS/2! You can download Quake, Quake World, and the source code. This all builds with EMX 0.9d and I’m using OS/2 2.0 (patched to x06100).

Also if it matters the newer your MS-DOS the better… 4.01 works, sure but its SLOW…

Compute!’s Gazette archive

Compute 33, March 1986

Back when I was a kid (was I ever a kid), anyways the first machine I was lucky enough to get was a Commodore 64! Unfortunately I was too young to understand what it was, or what I could even do with it.  Although they did have commodore computers in our grade school, the whole microcomputer revolution was so new to everyone that they pretty much just sat there until someone came by to show us how to load programs from diskette & tape.

But to be honest ‘educational games’ in 1983/4 really didn’t grab my interest and for the most part my C64 sat dormant.  However by 1986, I remember this magazine sticking out at some convenience store, and I was hooked! The whole program in a magazine seemed so awesome, and to be honest the idea of machine code, and having to type in a CRC’d editor was so far fetched to me, that I took MONTHS to get that typed in alone..But without a modem, I suddenly was connected to so many others who were now part of the microcomputer revolution.  I recently stumbled onto this great archive at commodore.ca that has the first forty five issues scanned into PDF.  Its all there, including the ads for things like ‘sublogic football‘ ..

Enjoy the history!

Dell UNIX Lives Again!

(please note that this is a guest post from Antoni Sawicki)

Dell UNIX is so ultra rare among rare Unix species that it doesn’t even have a Wikipedia entry. I have been hunting this elusive but important piece of computer history for well over 15 years now. Fortunately thanks to Charles H. Sauer and his excellent blog post I was finally able to lay my hands on disk and tape images and the restoration process begun.

The install tape

The system can be installed from either a tape or network server (presumably NFS). Unfortunately no virtualization software can emulate a tape drive. Hopes for a network install are even slimmer since the required network support floppy disk has been lost and chances of suitable Ethernet driver working in Bochs or Qemu are equal to that of finding the lost floppy disk.

I have decided to try a hard disk image from a readily pre-installed system. The original Dell 486 workstation had a 1GB SCSI hard disk. Unfortunately neither Dell UNIX supports LBA mode nor Qemu/Bochs support the Adaptec 154x controller required by the OS.

As all normal install options have been exhausted, the only option left was to use a second hard disk image as source of cpio archive files. Booting from the two install floppies and attaching two disk images was a snap. The next step was to inject the tape “file” in to a right place on the disk, so it can be read by cpio command. A hard disk in Dell UNIX is pretty much unusable without a valid SysV partition and VTOC. Fortunately dellsetup command does it all for you. Once VTOC was put in place I’ve attached the transfer disk image as a loopback device in my host OS. In couple of iterations I was able to aim the host os dd if=file1 of=/dev/loop0 bs=512 seek=offset at the right place, which you work out using prtvtoc /dev/rdsk/1s0 command. Then cpio -ict < /dev/dsk/1s1 was able to list contents of the emulated tape… with errors…

In my infinite wisdom, for some unknown reason I’ve assumed that LBA addressing is required above 540MB. So to be on a safe side I have made the hard disk images 512 MB. What a mistake it was! I have lost several hours trying to figure out cpio header errors coming from the disk… By pure coincidence, while the tape archive was installing (with errors) I was researching for this very blog article and found that LBA starts at 504 MB… Recreating the hard disk images just few MB smaller took all tape and prior boot problems away!

Once the cpio archive was extracted I have made few final touches taken from the original tape install script. After a reboot Dell UNIX booted perfectly. You can experience this by using the firstboot image file. The final part of installation was injecting the second tape file containing System V PKG file to the transfer disk image and running pkgadd -d /dev/dsk/1s1. This is what’s included on allsoft.img.

Dell Unix at First Boot

Some final notes on running the OS:

  • To enable mouse to work:
    • Qemu just add “-chardev msmouse,id=msmouse -device isa-serial,chardev=msmouse” to the launch arguments.
    • Bochs add to the config file:
      mouse: type=serial, enabled=1 
      com1: enabled=1, mode=mouse
      then you have to kill mousemgr process and prevent from starting by deleting /etc/rc2.d/S25mse
      then edit /usr/lib/X11/Xconfig:
      disable Xqueue
      enable Microsoft Mouse
  • To enable keyboard to work correctly in VirtualBOX start with Num Lock OFF.
  • You can use qemu-img utility to convert the image to VMware vmdk to use in VirtualBox.
  • To run X window type startx

X11 and all its glory

  • To attach it to internet use SLIP as there is no working Ethernet driver.  Contrary to most UNIXen of the time, the command is not slattach, but rather slipattach.  Thankfully it does work the same way.  I have found that running Dell Unix with VirtualBOX, along with Windows NT 4.0 I was able to connect into the Dell Unix VM, and get network access.  Just set the two VM’s up for a named pipe (\\.\pipe\dellunix) and make one of them a server, and start that VM 1st.  The steps to prepare Windows NT have been outlined before.

Telnet via SLIP

Legal disclaimer: Dell UNIX is a commercial software and should not be distributed without manufacturers permission. However as the operating system has been dead for 20 years and with a long tradition from Unix Heritage Society and Bitsavers I’m publishing this in good faith under abandonware category. If Dell or any other copyright holder wishes this software removed, please let me know.

Attached are:

  • firstboot image
  • all (pkg) software installed
  • setup instructions if you wish to install from scratch.

Download:

You may also be interested in my post about a sister System V operating system – Interactive UNIX:

Update: Dell Unix now runs on 86Box with higher resolution and proper networking.

Dungeon for the SHARP x68000 (on NetBSD)

Dungeon on the x68000

Its been a while since I’ve added a new port of Dungeon (zork!) so here we go!

Building f2c was a snap on the x68000, it just took a while..

Getting data into the VM was easy, just make an ISO image, and mount it.. Getting data out was.. a challenge, as the floppy doesn’t work under NetBSD, and it didn’t seem to want to see my other hard disks, just my root.  Well thankfully it’s virtual so I just did a:

tar -cvf /dev/sd0c dungeon.tar.gz

NEVER do that on a real machine kids!!!

Anyways here you go, for anyone who loves zork & the m68k!

XM6i

While checking out the NetBSD emulation page, I came across this interesting emulator, XM6i, which can run the x68000 NetBSD port.

Wasting no time, I downloaded it, and quickly found out it is all in Japanese… But hell that is what Google translate is for!  Just be forwarned that it’ll translate things like:

# memswitch -w boot.device=ROM; memswitch -w boot.romaddr=0xeac000

into

# Boot.Device Memswitch-w = ROM; Memswitch-w = 0Xeac000 Boot.Romaddr

I was able to get all the system bits, and get it to boot up the ROM!

Sharp boot logo

As you can see, I’m emulating a 68030 with MMU, running at a blazing 25Mhz with 12MB of ram! No doubt this is top of the line!  So I generated the boot floppies as described on the XM6i page, and booted NetBSD.  The boot loader on the x68000 looks kinda cool:

Boot with the daemon!

And after waiting for an eternity, like a real machine I booted up, swapped disks, read some more and then watched the kernel initalize:

NetBSD 5.1 68000

Installation is pretty straight forward, it is like any other NetBSD platform.  Although it is *SLOW*, even after I discovered the ‘turbo mode’ … As shown below:

Turbo mode!

Even in this mode, I’m running 220% faster than the real machine… I’m sure there are more tweaks to do, but my not being able to read Japanese isn’t helping any.

I figured for future’s sake, I’d just 7zip up what I have so far, maybe it’ll save some time for me later if I try this again.. Getting & generating the ROMS was kind of involved.

After an hour I had a base machine installed!

Of course it runs NetBSD!

All my work is here, and my NetBSD 5.1 install (to save yourself an hour+) is here.  Both files will blow out a 2GB disk image… FWIW.

Also if you’ve never used a Japanese keyboard before, they aren’t quite QWERTY with symbol layouts… This cheat sheet will help!

If you don't know where the colon is, vi can be impossible to use.

Newer ‘fixed’ Qemu 1.0.1 binaries

Well I booted my PC back up, and did a test with Darwin… I’d kind of given up on the newer Qemu because anything beyond MS-DOS & OS/2 would crash as soon as the disk was to be accessed from protected mode… Like this:

So as I had found out before from this post, I rebuilt coroutine-win32.c without any optimizations (-O0) and….

It works!

It booted up like it was expected!

I’ve relinked everything, and just uploaded it to the old package name, so anyone new that comes along that doesn’t hit this page first won’t get binaries that won’t work.  Naturally these have the NE2000 on Interrupt 10, port 0x320, the AdLib included and my shortcuts for control alt delete & reset (control+alt+d/control+alt+r) ..

Download it here.

Enjoy!

Slow VM disk access on Qemu/SIMH or other emulators running on Windows?

Turns out from an interesting thread on the SIMH mailing list, is that the Windows volume shadow copy service, and other ‘system’ protecting services may tag files like .dsk to be monitored, and to save a difference of every write to the file.

Yes that is right, on top of NTFS’s transaction log and rolls, you have the OS doing the same thing which in turn makes your disk access slower than hell.

The fix?

Quite simple, dont use TLA (three letter acronym) file extensions, or no extensions at all and suddenly you’ll find that your disk based emulation is significantly faster.