Torbjörn Granlund’s Excellent resource on running free OS’s on Qemu

Ever get tired of x86 on x86?  yeah me too.

How to solve that problem?

Simple, grab QEMU, and jump off into all those cool RISC processors of the 1990’s that were going to save us all from the WINTEL hegemony!

Lots of instructions, samples, images, and hints here:

https://gmplib.org/~tege/qemu.html

It’s really more comprehensive than I’ve sat down to do, so yeah it’s awesome!

Supported platforms include:

mips32,mips64,sparc32,sparc64,ppc32,ppc64,arm32,arm64,s390x,alpha

InfoTaskForce running on PowerPC (Dynamips)

choices..

choices..

Well considering what a hit it was, the last time I did this, I thought I’d give it another go!

And after a bit of fighting, I got it to run!

Now what were the obstacles?  Well for starters not having a full libc certainly hurts things.  Things like a malloc.  And without getting fancy with the memory map I did the lamest cheat ever, which is a 1MB static array I just handed out with a fake malloc (no free, I didn’t bother to track chunks), and you know it works enough.

Also I need to read files, and I need to look more into the hardware to see how to do that.  There seems to be plenty of hooks for NVRAM, but the ROMMON substitute doesn’t seem to support them.  Also there is no ROMMON hook for reading from the console!  The MIPS cilo is more ROMMON dependent, while the PowerPC c1700 talks to the uart directly so this is a PowerPC thing for right now.

I also learned something exciting about ld, which is how it can absorb binary images into objects, that you can link and access directly into your program!  No more having to convert it to hex, make these insane headders that CPP may or may not bomb over.  No you can make them objects right away!

ppc-elf-ld -r -b binary -o planetfa.o planetfa.dat

In this example I read the file planetfa.dat as BINARY, and encapsulate it in an object file called planetfa.o . It’ll now have a symbol name of _binary_planetfa_dat_start for where the image begins, _binary_planetfa_dat_size will tell me how big it is in memory, and _binary_planetfa_dat_end will mark the end of this ‘file’ in memory.

Now in the old days when it was a file I could access it like this:

fread ((char *)ptr,block_size,(int)num_blocks,game_file);

But that won’t work.  So now instead of calling fopen/fclose (which don’t exist in CILO), I set a counter to what my current offset is, change the ‘fseek’ to just set the global counter to where it should be, and when I fread I just memcpy:

memcpy(ptr,_binary_planetfa_dat_start+fseekp,num_blocks*block_size);
fseekp=fseekp+(num_blocks*block_size);

I suppose I could just have wrapped the f* calls into some emulation library but I don’t need to get all that crazy sophisticated.

C:\temp\dynamips>dynamips.exe -P 1700 -X -r 4 ciscoload.bin
Cisco Router Simulation Platform (version 0.2.15-experimental(merge uppc smips)Build-3-x86/MinGW stable)
Copyright (c) 2005-2011 Christophe Fillot.
Build date: Sep 19 2015 19:33:12

Local UUID: 0450c178-6480-11e5-a559-019031cf957a

Pcap version [WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008)]
Unsure if this file (c1700_i0_rommon_vars) needs to be in binary mode
Virtual RAM size set to 4 MB.
IOS image file: ciscoload.bin

ILT: loaded table “mips64j” from cache.
ILT: loaded table “mips64e” from cache.
ILT: loaded table “ppc32j” from cache.
ILT: loaded table “ppc32e” from cache.
vtty_term_init
CPU0: carved JIT exec zone of 64 Mb into 2048 pages of 32 Kb.
C1700 instance ‘default’ (id 0):
VM Status : 0
RAM size : 4 Mb
NVRAM size : 32 Kb
IOS image : ciscoload.bin

Loading BAT registers
Loading ELF file ‘ciscoload.bin’…
ELF entry point: 0x8000d9c8

C1700 ‘default’: starting simulation (CPU0 IA=0xfff00100), JIT enabled.
ROMMON emulation microcode.

Launching IOS image at 0x8000d9c8…
CILO
CiscoLoader (CILO) – Linux bootloader for Cisco Routers
Available RAM: 4096 kB
Available commands:
queen
hanoi
horse
fib
planetfall
halt

Enter filename to boot:
malloc 64512 offset is 0 offset is now 64522
malloc 38912 offset is 64522 offset is now 103444
PLANETFALL
Infocom interactive fiction – a science fiction story
Copyright (c) 1983 by Infocom, Inc. All rights reserved.
PLANETFALL is a trademark of Infocom, Inc.
Release 37 / Serial number 851003

Another routine day of drudgery aboard the Stellar Patrol Ship Feinstein. This
morning’s assignment for a certain lowly Ensign Seventh Class: scrubbing the
filthy metal deck at the port end of Level Nine. With your Patrol-issue
self-contained multi-purpose all-weather scrub brush you shine the floor with a
diligence born of the knowledge that at any moment dreaded Ensign First Class
Blather, the bane of your shipboard existence, could appear.

Deck Nine
This is a featureless corridor similar to every other corridor on the ship. It
curves away to starboard, and a gangway leads up. To port is the entrance to
one of the ship’s primary escape pods. The pod bulkhead is closed.

Deck Nine Score: 0/4451
PLANETFALL
Infocom interactive fiction – a science fiction story
Copyright (c) 1983 by Infocom, Inc. All rights reserved.
PLANETFALL is a trademark of Infocom, Inc.
Release 37 / Serial number 851003

Deck Nine Score: 0/4451
>

For anyone crazy enough, you can find my MinGW Dynamips on sourceforge, cross compilers for PowerPC, and the branch of the firmware source that includes InfoTaskForce, and the binary image.

While I don’t want to write an OS for this, it is almost tempting.  Or go the other route, and add in some non router based hardware… Like audio hardware, or a framebuffer.

Does anyone have a 1700 to test to see if any of this works?  Or a 7200?! 😀

Continuing with a PowerPC ELF compiler for Windows

Continuing on from yesterdays adventure I built the PowerPC compiler to support the Cisco 1700 (and maybe the 7200 NPE-G2?).

Much to my surprise, this one works too!

Loading ELF file ‘../ciscoload.bin’…
ELF entry point: 0x8000cba0

C1700 ‘default’: starting simulation (CPU0 IA=0xfff00100), JIT enabled.
ROMMON emulation microcode.

Launching IOS image at 0x8000cba0…
CIL
Error: Unable to find any valid flash! Aborting load.

Awesome!

Building this was a lot more fun.  I thought I could sidestep building a Linux to PowerPC ELF cross compiler, but as it turns out, to bootstrap libgcc, you really need a compiler that can do this.  But with the steps basically down, it was trivial to whip up.

Although I did keep on hitting this error with the Win32 tools that “-mstrict-align” is not supported, while trying to build the startup and libgcc sources using the MinGW targeted compiler through wine.  But once I had a native Linux to PowerPC toolchain in place, not only could I build the Windows based compiler, but I can also use the flag -mstrict-align on Windows without it complaining.  So lesson learned, have a cross compiler built to the final target to make life easier when building a Canadian cross.

As always, building the binutils package was a snap, just run:

./configure --host=i686-mingw32 --target=ppc-elf -prefix=/ppc

and I had my assembler/linker/librarian in no time.

Because of the aforementioned -mstrict-align issue, I got more creative with the parameters for GCC.

./configure --target=ppc-elf --prefix=/ppc --disable-nls --disable-werror --disable-libssp --without-headers --disable-threads --build=i486-linux-gnu --host=i686-mingw32

But with the Linux to PowerPC cross compiler in place, I was able to quickly generate a working toolchain.

I copied in CILO, and added in a build batch file to manually build it, and updated the test directory to run it.

So for those who are interested here is my toolchains:

And a mirror on sourceforge of my cross toolchains, PowerPC and MIPS.

As a minor addendum, The 1700 can run stuff that is far more complicated than the MIPS.  I’m not sure why I get so many TLB violations for doing something more complicated but I (poorly) ported aclock to run on the cisco 1700!

Aclock on the cisco 1700 via Dynamips

Aclock on the cisco 1700 via Dynamips

The Dynamips ROMMON emulator doesn’t provide the keyboard input function call so it can’t read from the keyboard.  Also it can’t read the clock so I have it running 250,000 dhrystones between clock ticks.  Although I think that is far too many, maybe 125,000 would be more like it but it runs on the PowerPC.  While on the MIPS I get nothing but this:

*** TLB (Load/Fetch) Exception ***
PC = 0x80008964, Cause = 0x00008008, Status Reg = 0x00408103

Oh well.  Maybe it’s a stack problem I guess I’ll have to break down and do a memory map and write a malloc if I want to go down this road.  Although back in 1999 this would be incredible but today I don’t think anyone would run anything but IOS on their cisco hardware.

WinDooM on SoftPC, on SheepShaver

So I was hammering out something with SheepShaver (more on that later!) and I thought a quick test of just how fast SheepShaver is vs a real PowerMAC would be interesting.  So I was playing with my old copy of SoftPC, which is 68000 based, but There were PowerPC versions, years ago when I bought a G4 to run OS X to only find out that it wasn’t supported (the dark days of OS X Server 1.0, before the 10.0 public beta) I used to run Windows NT 4.0 on SoftPC on MacOS 8.6.  Ugh, dark times indeed!

So with some luck, I got SoftPC 3.0 up and running on MacOS 7.5.3 using SheepShaver for Windows. Then I noticed that unlike SoftPC for the 68000, SoftPC for the PowerPC emulates a 486!  So how does DooM run?  A little slow, it’s kind of dream like.

But since there is Windows and a 32bit processor, I thought this would be a great time to load up Win32s, Video for Windows, WinG, and WinDooM!

WinDoom on SoftPC

WinDoom on SoftPC

And much to my amazement it runs!  And I was further impressed that there is a shim sound driver, and it works!

So I made a quick video to compare DooM for Windows vs DooM for MS-DOS on this setup.

Yes it’s pointless, but I kinda think it’s really cool.

As a bonus, here is E1M1 under MacOS 8.0.  The MIDI support in 8.0 is MUCH more stronger than 7.5.3!  And I should add, it actually feels faster on 8.0 than 7.5.3

GSOC bringing MacOS 9 to Qemu

It's some progress!

It’s some progress!

I know it may not look like much right now, but Cormac O’Brien is working on bringing MacOS 9 support to Qemu!  This is really great news as Sheepshaver has painted itself in a corner with it’s CPU code that requires memory access to 0x00000000 which more and more operating systems deny.

So you can download the snap and follow the instructions here. And you too can watch it fail.

Screen Shot 2015-07-20 at 9.57.16 AM

Starting to boot

During the boot you’ll see a message from MacOS on the CLI that it is unable to find a NVRAM partition.  During this time you will either see a bunch of CUDA and IRQ messages, and there is a good chance from here it’ll progress to loading the New World ROM.  If it gets stuck you’ll see tonnes of the following messages:

CUDA: read: reg=0xd val=00
CUDA: read: reg=0x0 val=30
CUDA: read: reg=0xd val=00
CUDA: read: reg=0x0 val=30

From here the screen should turn grey, and again it may or may not go to a happy mac, or again get stuck on the CUDA read 30/00 thing above.

New World ROM loaded

New World ROM loaded

Once it goes New World happy mac, it’ll load MacOS then bomb over one of the extensions.

I tried some OpenBSD for the heck of it, the good news is the kernel loads and starts the boot, but it has some issues with either memory or mapping the PCI bus.

Screen Shot 2015-07-19 at 6.03.43 PM

OpenBSD 5.7

Screen Shot 2015-07-19 at 6.08.31 PM

OpenBSD 3.3

Screen Shot 2015-07-19 at 6.16.02 PM

OpenBSD 4.0

And for the heck of it, Debian 5.0.0

Debian 5.0.0 installer

Debian 5.0.0 installer

I didn’t bother installing but nice to see the installer CD runs fine.

WinUAE 3.0.0 released!

The biggest feature of course is…

  • PPC CPU emulation. CyberStorm PPC and Blizzard PPC boards emulated using QEMU PPC core, on-board SCSI supported.

I’ve never used the PowerPC stuff before, I had a 68030 accelerator in my Amiga 2000 going back some 15 years ago, and I never could justify the cost for the board vs a new PC as the Amiga was so super fringe back then.

But for those who want to give it a shot, the installer is here, along with the PowerPC pluggin

All of the additional features are with the announcement here..

SheepShaver with pcap support

It "works", just incredibly slowly

It “works”, just incredibly slowly

so I got it to “work” on OS X….. well 10.6 in VMWare. I have no idea if this means it will work on your setup.

  • If AppleTalk packets get passed early in the boot stage, it will crash.
  • If JIT is enabled, it will crash
  • Performance is horrible, I’m getting 150k/sec on my LAN, Basilisk II with no JIT blows this thing away.
Honestly I feel kind of hesitant releasing this, but I know it was desired, and I guess it’ll help someone somewhere being able to have an easier conversation… So I’m going to upload my source tree, including binaries built with GCC 4.0 & 4.2 with either O2 or Os flags. I’m not sure which is more stable/faster…So here is my source tree. Sorry you still have to deal with the changing password thing, but cancel it, and it’ll tell you the password.Other lessons learned… SheepShaver’s segfault model only works when the CPU thread is the main thread. Even though you “can” stuff the CPU into a subordinate thread, it doesn’t play nice once it segfaults, it’ll just spin waiting for something that clearly isn’t going to happen.In config.h I added in USEGLOBALvideo as a way for main to call the screen update to end the vast majority of pool leakage. I also added SHEEPSHAVER_CURSOR to enable the hardware cursor. I was having some issues installing OS 8.x when the ‘hand’ was drumming the fingers waiting for the OS to install it crashed many times, while disabling the hardware cursor made it play nicer. Maybe it’s my setup, I’m not sure.

Also in this version I don’t read .sheepshaver_prefs but rather sheepshaver_prefs in the current working directory. I didn’t want to trash any other prefs. I have to test again but I think this should work on 10.10 … As I found out the hard way x86_64 binaries can no longer mess with the zero page, so this is a 32bit only build, but I was running it with my SLiRP fixes ok on my macbook air.

This hasn’t been extensively tested. I hate to even call it tested, I just copied a few MB of stuff over an NT server running AppleTalk,a nd viewed some flash video with Internet Explorer 5.1 …. I’m sure there are PLENTY of things broken. JIT should work with these binaries (Quake 1 is quite playable), but DOOM crashes hard (isn’t it a 68k binary?). DOOM runs ok on Basilisk II so does it matter?

If you want speed, JIT + SLiRP is the way to go. Since this is basically the same as the version I was using with BasiliskII I think it’s more stable than the generic version as I could at least run all kinds of programs with some of my fixes vs the ‘stock’ github version.

I should add that I’ve been primarily testing with that PowerMac 9500 v1 ROM, along with MacOS 8.6. I found 8.0 and 8.1 too unstable, 7.x & 9.0.4 uninteresting.

To get around the early crashing while booting 8.6, I rigged it to drop the first 30 packets. I’ve successfully booted 10/10 times, so I’m almost OK with that. I’d rather know when the OS is ok, and go with that, but I’m not sure. I thought about a timer, and say ignore the network for the first 30 seconds, and maybe that is the better way to go. When you launch this you’ll see some message updating about packets and “wait for 30->” and a number… once it reads “wait for 30->30” , the message will no longer update, and it’ll start to forward packets into the machine. You probably will have to disable and re-enable AppleTalk from the chooser to see the network (or I had to). You may have to get creative to generate the needed packets on your network to get it over 30, as those are packets received. Broadcast packets work too, so maybe you can work with that… As long as Sheep Shaver isn’t alone something should be looking for other devices.

Phase one on a SheepShaver rebuild complete

SheepShaver on Linux

SheepShaver on Linux

Only because people were asking for it.  The first thing I did for Basilisk II was to get it building on Linux, so here we are.  I only tweaked the config process to let me build it with GCC 4.7.2 .

So this will be in the same effort of removing features, and trying to place in my SDL drivers, network and SCSI stuff.

Im starting with SheepShaver v2.2, which is pretty old.  But 700kb compressed is a good starting point.  As you can see it boots MacOS 8.0 which is also good enough for me.

The other questions will be, can this build under Windows with MinGW configured like this, and can it build with OS X.  It looks like all the stuff is there so this may be kind of easy. I hope.

Also SheepShaver does something funky with it’s memory space, it does some direct mapping to the user area.  I’ll have to see if I can disable that, performance be damned (well I turned off JIT as it won’t compile with 4.7 either) so this won’t be fast, but I’m just patching stuff up, not re-implementing the wheel here.

Qemu 1.7.0 released!

The main qemu page hasn’t been updated yet, but the download page has the source to the new version of Qemu.

I’ve gone ahead and built binaries for OS X, both a full version, and  a i386 minimal version.

As always testing is very minimal, all I’ve done is installed MS-DOS 6.22 & Doom 1.1, and tested the SoundBlaster 16 emulation.  And as with the pre-release versions, the adlib code is still broken.  And Ive done the ‘better’ fix in this code regarding that.

I haven’t run anything else, including fun things like the PowerPC & OS X emulation, MIPS with Windows NT, or even trying anything x64 based as I’m sure it is still broken from back in the Qemu 0.90 days.