Ghosts in the mainframe!

There is a LOT going on in this image, and I’ll try to explain it, but yeah “it’s complicated”.

SNA networking & Hercules has always been a goal for a lot of people, including me as we always wanted to setup some SNA server of some kind. Especially on RISC platforms, as there is only so much fun on SQL server.

Okay I know the practical among you will say, doesn’t it support telnet 3270? Isn’t that good enough? Yes for day to day mundane stuff, absolutely. But I’m not all that interested in that, I wan’t to have the whole ancient network, and I wan’t it self contained and on my desk! Or on a laptop, as I see fit.

What started this whole adventure was a simple image from 9track.net, showing that being able to connect physical devices to Hercules was indeed possible!

Image from https://www.9track.net/hercules/dlsw/

This is a physical IBM 3178 & 3179 terminals talking to TK4- , a MVS3.8j pre-configured system!

The magic that makes this all possible, is a cisco router, running enterprise IOS, with dlsw support.

My setup is going to be inspired by this setup, but not exactly 100% But this is what I’m going to use on Windows 10

  • Dynamips for the cisco router, running JS-M 12.2(25)S8
  • Qemu 0.90 with PCAP running Windows NT 3.51 Server along with SNA Server 2.1
  • Qemu 0.90 running Windows 3.1 and XVision
  • VMware Player
  • WireShark
  • Microsoft Loopback adapter
  • WSLv1

I had originally wanted to run the NT server on VMware but for some reason it just hangs trying to initialise the NT kernel. I didn’t bother trying to troubleshoot it, I just jumped to Qemu. Even service pack 5 didn’t help. VMware left me with the virtual network that will NAT if needed, and of course let me telnet to the Dynamips program. The SNA traffic is isolated to the MS Loopback adapter, which will let pcap programs talk to each other.

The first thing I did was run ‘hdwwiz’ on Windows 10, and added in the KM-TEST loopback adapter

We know what we want, so go to the manuall selection

Network adapters

And select the KM-TEST Loopback Adapter

Next I changed the protocols available on the loopback, as I don’t want my Windows 10 host interfering with the SNA network at all.

So the next thing to do is to get your network GUID’s. ethlist.exe from the Dynamips download will get you that:

C:\dynamips>ethlist.exe
Network devices:
  Number       NAME                                     (Description)
  0  \Device\NPF_{3DF0EC5D-7FBE-46DF-ACF8-EF5D8679A473} (loopback)
  1  \Device\NPF_{D9FBD118-B9DF-4C3C-BD9E-07A0E34D8F75} (Local Area Connection* 8)
  2  \Device\NPF_{F5057901-6A30-413A-80E4-4765DA794B7C} (Local Area Connection* 7)
  3  \Device\NPF_{E3D3EC8D-29C3-4B70-B01C-600D3F9ED1D6} (Local Area Connection* 6)
  4  \Device\NPF_{82EEDBC1-899D-416F-BD51-3DBE2287257F} (VMware Network Adapter VMnet8)
  5  \Device\NPF_{3BC364F4-5A15-405D-926C-C594383F0323} (VMware Network Adapter VMnet1)
  6  \Device\NPF_{DDF1FA94-7488-414F-A41A-EC88C1FB0DE4} (Ethernet)
  7  \Device\NPF_{E7CA8F40-4639-410D-B5CA-F402FE69AF5D} (Ethernet 2)

I want the cisco router to have two interfaces, one with TCP/IP for me to be able to telnet into it (maybe other management as well?!) and the other one for the SNA traffic.

Setting up Dynamips

As mentioned above I’m going to use the VMnet1 for TCP/IP to the router, and the loopback adapter for SNA traffic. To try to make things a little easier to read I setup a small batch file that let’s me plug in variables to Dynamips:

set loopback=\Device\NPF_{3DF0EC5D-7FBE-46DF-ACF8-EF5D8679A473}
set vmnet1=\Device\NPF_{3BC364F4-5A15-405D-926C-C594383F0323}
set IOS=c7200-js-mz.122-25.S8.bin
set NPE=npe-200
..\dynamips.exe -P 7200 %IOS%  ^
-t %NPE%  ^
-p 0:C7200-IO-FE ^
-s0:0:gen_eth:%vmnet1% ^
-p 1:PA-4E  ^
-s1:0:gen_eth:%loopback% ^
-p2:PA-4T+

The caret symbol will break up lines on NT, much like the ampersand will on Unix. And this let’s me use clear variables for the networks, IOS & NPE type so it’s nowhere near as complicated to edit.

This will create a cisco 7200 with an NPE-200, with the following cards:

The next thing is what ip address is bound to VMnet1? This is mine:

Ethernet adapter VMware Network Adapter VMnet1:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::c3d2:c891:b7e0:6797%5
   IPv4 Address. . . . . . . . . . . : 192.168.199.1
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

So all my TCP/IP in this example will be using 192.168.199.0/24

As mentioned on the 9track page, all the magic happens on the cisco router. I’ve made a few changes as I may want to try the SDLC in the future to perhaps some other experiment if I can find an emulator that’ll drive it over serial, but for now let’s just get to the config:

!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname dlsw
!
boot-start-marker
boot-end-marker
!
enable password cisco
!
ip subnet-zero
!
!
no ip domain-lookup
!
ip cef
no mpls traffic-eng auto-bw timers frequency 0
call rsvp-sync
!
!
!
!
!
!
!
source-bridge ring-group 1
dlsw local-peer peer-id 192.168.199.10
dlsw remote-peer 0 tcp 192.168.199.1
dlsw mac-addr 4000.1020.0100 remote-peer ip-address 192.168.199.1
dlsw udp-disable
dlsw transparent switch-support
!
interface FastEthernet0/0
 ip address 192.168.199.10 255.255.255.0
 duplex half
 no clns route-cache
!
interface Ethernet1/0
 no ip address
 duplex half
 no clns route-cache
 dlsw transparent redundancy-enable 5555.5555.5000
 dlsw transparent map local-mac 4000.1020.0100  remote-mac 4000.0999.0100
!
interface Ethernet1/1
 no ip address
 shutdown
 duplex half
 no clns route-cache
!
interface Ethernet1/2
 no ip address
 shutdown
 duplex half
 no clns route-cache
!
interface Ethernet1/3
 no ip address
 shutdown
 duplex half
 no clns route-cache
!
interface Serial2/0
 no ip address
 encapsulation sdlc
 no keepalive
 serial restart-delay 0
 clockrate 64000
 no clns route-cache
 sdlc role primary
 sdlc vmac 4000.0999.0100
 sdlc address C1
 sdlc xid C1 01700019
 sdlc partner 4000.1020.1000 C1
 sdlc dlsw C1
!
interface Serial2/1
 no ip address
 shutdown
 serial restart-delay 0
 no clns route-cache
!
interface Serial2/2
 no ip address
 shutdown
 serial restart-delay 0
 no clns route-cache
!
interface Serial2/3
 no ip address
 shutdown
 serial restart-delay 0
 no clns route-cache
!
ip classless
!
no ip http server
!
!
!
!
!
!
control-plane
!
!
dial-peer cor custom
!
!
!
!
gatekeeper
 shutdown
!
!
line con 0
 session-timeout 35791
 stopbits 1
line aux 0
 stopbits 1
line vty 0 4
 password cisco
 login
!
!
end

This sets up the router so I can telnet to it from my desktop at 192.168.199.10, and allows it to talk to the base Windows machine on 192.168.199.1

All the magical MAC addresses come from 9track.net, as he wrote the dlsw hooks, so I just copied that. There is probably a great deal that could be cleaned up, but once I saw the two talking I kind of froze what I was doing.

With that much in place I then jumped to WSL,and built the emulator from github. I cloned it, and renamed that to herc-dlsw. At least for me this was pretty straightforward. The Hercules fork will build with Visual Studio as well, but I knew I was going to need some kind of tn3270 emulator, and I wanted to use x3270, and I had just recently bought this discounted copy of XVision, so of course I wanted to use that.

Despite this catastrophic defect that wasn’t disclosed in the auction.

I downloaded and extracted the TK4- latest distro on WSL. I just created a ‘herc’ directory in my home to house the tk4- release. The next thing to do is overlay your dlsw enabled exe’s and libraries.

cd ~/herc-dlsw/.libs
mkdir x
cp * x
cd x
rm *.o *.lai
cp *.so $HOME/herc/hercules/linux/64/lib/hercules
cp *.la $HOME/herc/hercules/linux/64/lib/hercules
rm *.so *.la
cp * $HOME/herc/hercules/linux/64

Now with the binaries in place, I do need to setup the Xvision VM so I can receive the X11. Of course there is so many other ways to do this, but this is mine:

qemu.exe -L pc-bios -m 64 -hda xvision.vmdk -net nic,model=ne2k_isa -net user -redir tcp:6000::6000

The important thing is that tcp port 6000 is redirected inwards, and that I’m using the NE2000 card, which on my weird fork will print out the hardware config, so I know how to find the nic.

added SLIRP
adding a [GenuineIntelC♣] family 5 model 4 stepping 3 CPU
added 64 megabytes of RAM
trying to load video rom pc-bios/vgabios-cirrus.bin
added parallel port 0x378 7
added NE2000(isa) 0x320 10
pci_piix3_ide_init PIIX3 IDE
ide_init2 [0] s->cylinders 203 s->heads 16 s->sectors 63
ide_init2 [1] s->cylinders 0 s->heads 0 s->sectors 0
ide_init2 [0] s->cylinders 2 s->heads 16 s->sectors 63
ide_init2 [1] s->cylinders 0 s->heads 0 s->sectors 0
added PS/2 keyboard
ps2.c added PS/2 mouse handler
added Floppy Controller 0x3f0 irq 6 dma 2
installing PS/2 mouse in CMOS
  Bus  0, device   0, function 0:
    Host bridge: PCI device 8086:1237
  Bus  0, device   1, function 0:
    ISA bridge: PCI device 8086:7000
  Bus  0, device   1, function 1:
    IDE controller: PCI device 8086:7010
      BAR4: I/O at 0xffffffff [0x000e].
  Bus  0, device   1, function 3:
    Class 0680: PCI device 8086:7113
      IRQ 0.
  Bus  0, device   2, function 0:
    VGA controller: PCI device 1013:00b8
      BAR0: 32 bit memory at 0xffffffff [0x01fffffe].
      BAR1: 32 bit memory at 0xffffffff [0x00000ffe].

And in this case it’s 0x320 IRQ 10. XVision being it’s own level of disappointment, I’ll have to cover it further, and later but suffice to say it at least catches the x3270 so I can get onto the console.

Setting up Hercules

Editing conf/tk4-_default.cnf is pretty easy as it’s on Linux and you can use VI.

# NCP VTAM
#
0660 3705 lport=${N660PORT:=37051} locncpnm=N07 rmtncpnm=N08 …
          unitsz=252 ackspeed=1000
0661 3705 lport=${N661PORT:=37052} locncpnm=N10 rmtncpnm=N11 …
          idblk=017 idnum=00018 locsuba=10 rmtsuba=11 unitsz=252 …
          ackspeed=1000
0662 3705 lport=${N662PORT:=37053} debug=yes dlsw=yes locncpnm=N12 …
          rmtncpnm=N13 idblk=017 idnum=00019 locsuba=12 rmtsuba=13 …
          unitsz=252 ackspeed=1000
0663 3705 lport=${N663PORT:=37054} locncpnm=N14 rmtncpnm=N15 idblk=017 …
          idnum=0001a locsuba=14 rmtsuba=15 unitsz=252 ackspeed=1000

And it’s simple, just assign the dlsw to the 0662 3705 controller.

The real fun is in the VTAM configuration. Which had been stumping me for well over a year. But then I found this Bradrico Rigg article aptly titled : Run your own mainframe using Hercules mainframe emulator and MVS 3.8j tk4, and it gave me the confidence to get this DONE. Thanks Bradrico!

First get MVS up and running. You have to run the ‘console_mode’ script to see what is going on.

cd herc/unattended
./set_console_mode
cd ..
./mvs

It’s not all that difficult XVision is using SLiRP, so it’s listening on all my IP addresses so I just do a simple

export DISPLAY=192.168.1.72:0
nohup x3270 &

And the emulator will pop up in Qemu. Just connect to localhost:3270 and you’ll be greeted by the login pannel:

Credentials are HERC01 / CUL8TR

I would HIGHLY recommend following the tutorial to get used to submitting a simple COBOL program. It walks through the key concepts of locating a file, and viewing it on MVS. Something that up until yesterday was out of my league.

We need to edit the file S3705 on SYS1.VTAMLST

Basically it’s 1,3,4 from the main pannel:

or RFE, Utilities, DSLIST

Type in the Volume name, then tab over to the left of the volume and put in V to view

Now we will get a list of all the files. We want to edit S3705, so you can tab/arrow down, but sure to put an `E’ next to it, then hit enter so we can edit the file

F7/F8 will page down/page up as needed. As mentioned we are interested in Subarea 13, PU type 2.

The line we are changing is the MAXDATA or MTU size for this unit. Since we are doing dlsw, or an emulated serial link, we need to knock it down to 256. Notice all the plus signs on the right hand? THOSE ARE IMPORTANT! Not only do they need to exist, but they also have to be on the far right.

For those wondering the MTU sizes on the client side by media type are as follows: And notice that the host size is different, as this takes in account of packet headers.

Making sure to overtype the 3780, to a 256, and ensuring the + sign hasn’t moved you can hit enter, cursor to the top and type in SAVE.

We can then edit the N13 file, changing line 35 to have MAXLU=3

Hopefully this clears up editing VTAM files.

As mentioned the easiest way to regen the system is to delete the old object files. So hit f3 a few times and get back to the dataset list

This time we want the VTAMOBJ set. Go and ‘V’iew it like last time and we will get the list of files:

Now we are going to put a ‘d’ next to N13 and S3705. This will flag them for deletion. Hit enter!

The files are now gone! On the next boot they will be rebuilt.

I just hit F3 a bunch of times and it’ll drop to some TSO shell

From here you can shutdown the system. It’ll take a few minutes, but you can start it up again just the same way you brought it up. Remember to attach your console.

Setting up SNA Server

Just like Dynamips, I setup a batch file, as the default one is just far too long to read:

@echo you need to figure out your nic name..
@echo something like
@echo \Device\NPF_{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
set loopback=\Device\NPF_{3DF0EC5D-7FBE-46DF-ACF8-EF5D8679A473}
set vmnet1=\Device\NPF_{3BC364F4-5A15-405D-926C-C594383F0323}
qemu -m 64 -L pc-bios ^
-hda SBS15.vmdk ^
-soundhw sb16,adlib ^
-net nic,model=pcnet,macaddr=52:24:00:22:00:01 ^
-net pcap,devicename=%loopback% ^
%1 %2 %3 %4 %5 %6

This will setup a small machine with 64MB of ram, a single AMD PCNet adapter on the loopback interface. I installed Windows NT 3.51 from the Small Business Server 1.5 setup. I don’t know why VMware + NT 3.51 didn’t get along, maybe it’s my Erying, Or maybe it just plain doesn’t work, I’m not sure, and far too impatient to troubleshoot it.

It’s very important that you do add the DLC Protocol during setup. It’s in the ‘Add Software’ part. I kept my NT very simple with only NetBEUI and DLC protocols. At the moment I’m not that interested in actually networking the NT, and if I was, I would add a second NIC, just like what I did for Dynamips.

Setting up NT isn’t that interesting, but SNA server is. I did use the 2.11 on the Back Office CD, but for completeness sake of testing I tried the oldest one I could find, and 2.1 beta from June, Build 2.1.0.216.

I left the network name & control point name blank as I just want terminal, I’m not even going to think that LU6.2 applications on such an ancient version of MVS was even possible.

This is pretty much default, the Link service basically sets itself up as we only have the one NIC.

Take note of the remote network address. 400010200100 which came from above the address we directly point to the dlsw. Also it’s form the 9track blog.

Insert a 3270 LU for us to try to talk to Hercules.

I’m pretty sure it was hard coded to be a model 2.

I turned off the ability for the model to be overwitten.

Create a pool, I called it swimming, because of ‘reasons’. I made it a type 2 pool and added the terminal to it.

Next I added the EVERYONE user, and gave them access to the SWIMMING pool

Finally we are ready to save the config, and do the hand holding and start up. If the stars aligned you will see them go ACTIVE/ACTIVE and the terminal will go Available.

Sadly the terminal won’t go live, it’s stuck in SSCP.

And this is as far as I can go. I have to think that with either something far older protocol wise for the PC, such as IBM Personal Communications/3270 for Windows V2.0 (v4 didnt work either), or a far newer Mainframe software version would support whatever it is SNA server wants to give us the crazy dream of running SNA self contained.

Running Wireshark on the loopback network I see this message:

UNSUPPORTED FUNCTION

Sadly this is as far as I can take you. I do want to give a special thanks to Vinatron & blackbit for trying to troubleshoot this with me. Best we can figure is that TK4- is just too old.

Troubleshooting

From the cisco router try dlsw commands like this:

dlsw>sho dlsw circuits
Index           local addr(lsap)    remote addr(dsap)  state          uptime
2281701660      4a24.0044.0080(04)  0200.9099.8000(04) CONNECTED      00:02:23
Total number of circuits connected: 1

This does show the connection. Notice that ‘show bridge’ will show nothing in this config.

Be sure to check peers as well:

dlsw>show dlsw peers
Peers:                state     pkts_rx   pkts_tx  type  drops ckts TCP   uptime
 TCP 192.168.199.1   CONNECT         10        13  conf      0    1   0 00:05:07
Total number of connected peers: 1
Total number of connections:     1

Make sure your interfaces are ‘up/up’ and passing traffic

FastEthernet0/0 is up, line protocol is up
  Hardware is DEC21140, address is ca00.48f4.0000 (bia ca00.48f4.0000)
  Internet address is 192.168.199.10/24
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Half-duplex, 100Mb/s, 100BaseTX/FX
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 1000 bits/sec, 2 packets/sec
  5 minute output rate 2000 bits/sec, 2 packets/sec
     12768 packets input, 1439279 bytes
     Received 3609 broadcasts (0 IP multicast)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog
     0 input packets with dribble condition detected
     9999 packets output, 1037736 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out
dlsw>show int eth1/0
Ethernet1/0 is up, line protocol is up
  Hardware is AmdP2, address is ca00.48f4.001c (bia ca00.48f4.001c)
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:02, output 00:00:02, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     52426 packets input, 5148287 bytes, 0 no buffer
     Received 12336 broadcasts (0 IP multicast)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     36383 packets output, 2465490 bytes, 0 underruns
     0 output errors, 0 collisions, 3 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out
dlsw>

And of course check WireShark to see if there is any handshake:

And of course check the Hercules logs to make sure your VTAM rebuilt, look for ERROR or anything related to S3705 or N13.

Word & Excel for MIPS

Years ago when I’d bought Office 4.2 for Windows NT, it only included i386 & Alpha builds of Word and Excel in the box, and a coupon for MIPS and PowerPC.

About the only thing interesting is that it actually ran under Win32s.

But today looking at term24‘s uploads on archive.org, I saw two CD-ROM images:

I quickly fired up Qemu MIPS NT, and confirmed that both do in fact contain a MIPS version! Excel does have the PowerPC version as well.

As far as I know the only RISC platform to get apps from Office 97 was the Dec Alpha, but at least MIPS users can rejoice now, knowing that they too have been blessed with 32bit Office 4.2 apps!

One of the amazing things about NT & portable apps is that visually, they look identical. So other than me telling you that these are the MIPS native versions, there really is no way to tell.

Well, other than there is no ntvdm running. There is no WOW needed here!

100% native.

I guess the only other question is that since the Word is 1994, and Excel is from 1995, did they have earlier versions for Windows NT? It seems like everything was finally coming together for RISC NT, except the users. Would a release of 64bit Windows 2000 on Dec Alpha save the platform by bringing a strong 64bit platform with integrated JIT i386 WoW built in? (AXP64 Windows 2000 didn’t use !FX32). I guess we’ll never know.

Adding multiple PCnet NIC’s to a Windows NT 4.0 Terminal server under Qemu

So this is probably nothing that exciting for most people, but for me, I wanted to have a Terminal Server onto a DECnet network. Sure I could have probably just done one nice with tun/tap, dumped all the protocols on there, and called it even. But for some reason I wanted 2 NICs to keep the IP on one side, and DECnet on the other.

One thing I wanted was an internal bridge for DECnet only traffic, and since I just need MSRDP access, SLiRP can handle a single TCP port redirect.

The flags are as always pretty simple once you work them out:

qemu -vga std -cpu pentium -m 384 -vnc :0 -net none \
-hda nt4tse.vmdk \
-device pcnet,netdev=slback \
-device pcnet,netdev=decback \
-netdev tap,ifname=tap1,id=decback,script=/root/nt4tse-up,downscript=/root/nt4tse-down \
-netdev user,id=slback,hostfwd=tcp::3389-10.0.2.15:3389 \
-cdrom Windows\ NT\ 4\ All-In-One\ (Workstation\,\ Server\,\ Terminal\,\ Enterprise).iso

And the two network scripts starting with nt4tse-up:

#!/bin/bash
echo starting $1
ip tuntap add mode tap tap1
ifconfig tap1 up
ifconfig tap1
brctl addif decnet0 tap1
brctl show decnet0
echo done with tuntap

And the nt4tse-down:

#!/bin/bash
echo shutting down $1
ifconfig tap1 down
brctl delif decnet0 tap1
brctl show decnet0
ip tuntap del mode tap tap1
echo done shutting down $1

for completeness here is the bridge config in /etc/netplan/50-cloud-init.yaml

network:
    ethernets:
        ens3:
            addresses:
            - SOMETHING/24
            gateway4: SOMETHING
            match:
                macaddress: 00:f4:c1:56:40:7e
            nameservers:
                addresses:
                - 1.1.1.1
                - 8.8.8.8
    bridges:
      br0:
        dhcp4: no
        addresses: [192.168.23.1/24]
      decnet0:
        dhcp4: no
    version: 2

This way I have an IP bound bridge for things that talk IP, and a raw bridge, decnet0 that has my non IP decnet stuff on there. Naturally it’ll have my SIMH VAX on there:

# brctl show decnet0
bridge name     bridge id               STP enabled     interfaces
decnet0         8000.aede9f227e7b       no              tap0
                                                        tap1

Also the ability to mount directories as fake fat drives had it’s syntax change as well

 -drive file=fat:rw:win95cd

into something like this:

-drive file=fat:rw:dos,id=fat32,format=raw,if=none -device ide-hd,drive=fat32

Not as fun as Win64 Itanium, the earliest AMD64 Windows I can find

It does feel a lot like Windows XP for the Itanium, that strange half world of existence. It’s also from September 2003, the release image being named: 5.2.3790.1069.srv03_spbeta.030905-1850_amd64fre_client-professional_retail_en-us-AB1PXFRE_EN.iso

I’m sure if you google around you can easily find it.

To install you apparently need an early AMD 64 processor, otherwise it’ll trap on the installer. Back in 2004, I got a newly refurbished AMD Athlon 64 3200+ processor, from Tiger Direct. The machine was only a few months old, and I was able to get an early XP build for it. Oddly enough it’s simple enough to install on Qemu. I was able to use 0.90 & 7.20, jumping at extremes, although the PCI NIC IRQ’s do jump around on 0.90 preventing the networking from working.

I had a LOT of trouble getting a bootable hard disk image out of this for some reason. So I’ve found keeping C around 2,000 Megabytes, and installing MS-DOS 5/6 got me a bootable system. Also preserving the FAT disk. Not sure why but doing formats of FAT or NTFS always seemed to result in a non bootable disk

qemu-system-x86_64w.exe -cpu Opteron_G1-v1 -hda 2g.vmdk -m 512 -M pc-i440fx-2.0 -net nic,model=rtl8139,netdev=f00 -netdev user,id=f00,hostfwd=tcp::5555-:3389 -usb -usbdevice tablet  -accel tcg,thread=multi

Special thanks to RoyTam for the suggestion of the USB tablet & turning TCG multithreaded for v7+ of Qemu

Setting up is pretty normal.

You do get 360 days to use the beta. More than enough for simple testing. I’ve seen that the timebomb doesn’t work correctly so it may work forever. But it’s so rough around the edges, I can’t see anyone trying to run this native in 2023.

Notice it’s all AMD branding. Intel officially didn’t have their EMT64 Pentium 4’s, although IBM was pushing Intel hard to get them out the door. And I think they held off on a larger x86_64 launch as Intel had not publicly caved.

And in no time you are up and running. I find the mouse really weird on Qemu, so I always enable the remote desktop function and find it much easier to deal with.

One of the advantages of RDP is that audio redirection does work, so you can play pinball!

One annoying thing (to me) is that the SysFader process will hang all the time locking explorer.exe . Along with that it’ll leave phantom UI elements haning around like the Run… above. Yes, its annoying!

The solution is of course System Properties, and Performance, and either disable the Fade elements, or just turn off all the ‘eye candy’ which basically doesn’t really exist for this release anyways.

While there is some DirectX support, it is most likely just simple GDI passthrough, and of course no acceleration as the OpenGL screensavers run incredibly slow.

And thanks to betawiki.net for some hints & tips. I haven’t tried the VMware path, since AFAIK there is no other NIC drivers for this release.

As mentioned, hardware support is VERY limited. The single audio driver is a MPU401 port. This obviously was meant for an exceptionally limited audience.

The one thing I cannot find, is any version of a Platform SDK that targets AMD64 so early. The earliest I can find is version 14 from 2005.

The 2005 compiler does have this note:

The Microsoft® C/C++ AMD64 Processor Family-targeting compiler is a cross-compiler targeting the AMD64 processor family. The compiler runs on an x86 or AMD64 computer running Microsoft Windows® XP or Microsoft Windows® Server 2003. It is the compiler used for Microsoft® internal development and is used for building Microsoft Windows NT®, Microsoft SQL Server®, and other major applications. For debugging we suggest the use of WinDbg for AMD64. Visual Studio Whidbey will support the use of the Visual Studio debugger for debugging AMD64 applications.

2005-06 – 2944.0 – Platform SDK for Windows Server 2003 SP1 (April 2005 Edition)

With the compiler being:

Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.41 for AMD64
Copyright (C) Microsoft Corporation. All rights reserved.

If anyone knows of anything earlier, I’d love to know! If only for the sake of messing around with it.

Networking on AIX 4.3

Well oslevel says 4.3.3.0, but you get the idea.

You’ll need to have the ethernet driver handy, or better loaded. Since I had disabled the NIC on install it’s not loaded. And since I’m still using a cellphone for internet I extracted the file somewhere else and copied in some patches. I’ve managed to reproduce this twice now, so I guess it’s good to go. Apparently, this just works in later versions, but this is very touchy.

To start how I’m running qemu:

./qemu-build/ppc-softmmu/qemu-system-ppc -M 40p -bios q40pofw-serial.rom -serial telnet::4441,server -hda disk0.vmdk-post-install -vga none -nographic -net none -device pcnet,netdev=ne -netdev user,id=ne,hostfwd=tcp::42323-:23 -cdrom /mnt/c/temp/pcnet-aix.iso

With aix booted, extract the tar file from the cdrom:

mount /cdrom
mkdir /pcnet
cd pcnet
tar -xvf /cdrom/pci.tar

Fix your terminal up… if needed (it probably is)

export TERM=vt100
stty erase ^?
export LIBPATH=$LIBPATH:/usr/lib
export PATH=/usr/local/bin:$PATH

Now run smitty -> devices -> after ipl

Change the directory to /pcnet , and let it run It will give errors but thats okay. All being well it won’t crash AIX, otherwise you’ll want to restore your hardisk. You did make a backup beforehand right?!

I don’t think it matters but I run this afterwards:

odmchange -o CuAt -q "name=ent0 and attribute=busio" /cdrom/lance_ch.asc
odmget -q "name=ent0 and attribute=busio" CuAt
shutdown -h now
halting does take forever

As tempting as it is to kill the emulator, wait for it to complete. Otherwise you may have to do the whole thing agian.

For me the value attribute was never preserved, so we get to do it again on reboot/restart:

odmget -q "name=ent0 and attribute=busio" CuAt
mount /cdrom
odmchange -o CuAt -q "name=ent0 and attribute=busio" /cdrom/lance_ch.asc
rmdev -l ent0
mkdev -l ent0
ifconfig en0 10.0.2.15
ping -c 1 10.0.2.2

If everything went well this time you should get a ping reply! Great! Now to configure the system for real.

smitty -> communication -> tcpip -> minimum -> en0

simple slirp

As always I configure my system for slirp. We’re almost there! Now to pad the DNS records for slirp:

cat >> /etc/hosts
10.0.2.2 slirp
10.0.2.3 slirpdns
^D

And now you can reboot!

If everything goes well, you will have a patched up pcnet driver that works (well mine does)

It works!

The big test is to of course reboot. Then you’ll know for sure.

I have tried this a few times, and yeah it can crash when adding the drivers, so I had to restore a few times. I would say 1/3 times worked flawlessly. So be patient. And backup!

Revisiting AIX 4.3 on Qemu

I had gone over the install a while ago, but I wanted to re-install on a newer machine. And going from GCC 7 to 11, well a number of things changed. And I found with experience that letting Qemu select as much as it wants leads to numerous dependencies that end up being problematic.

jsteve@piorun:~/atar-boot/qemu/ppc-softmmu$ objdump -p qemu-system-ppc | grep NEEDED
NEEDED libvdeplug.so.2
NEEDED libncursesw.so.6
NEEDED libtinfo.so.6
NEEDED libz.so.1
NEEDED libxml2.so.2
NEEDED libpixman-1.so.0
NEEDED libutil.so.1
NEEDED libnuma.so.1
NEEDED libnettle.so.6
NEEDED libgnutls.so.30
NEEDED libfdt.so.1
NEEDED libgthread-2.0.so.0
NEEDED libglib-2.0.so.0
NEEDED librt.so.1
NEEDED libstdc++.so.6
NEEDED libm.so.6
NEEDED libgcc_s.so.1
NEEDED libpthread.so.0
NEEDED libc.so.6

So using the same atar qemu git dump, I found the newer config string a bit more refined:

./configure --target-list=ppc-softmmu --disable-sdl --disable-vnc --disable-gtk --disable-gnutls --disable-nettle --disable-gcrypt --disable-spice --disable-numa --disable-libxml2 --disable-vde --disable-werror --disable-seccomp --disable-capstone --disable-vhost-net --disable-vhost-crypto --disable-vhost-scsi --disable-vhost-vsock --disable-vhost-user --disable-tpm --disable-live-block-migration

Another fun think is that there is submodules from other servers, and it seems their certs have expired.. Which also means it’s inevitable at some point this will become impossible to build. Be sure to set this environment variable in order to build:

export GIT_SSL_NO_VERIFY=true

As always Qemu will try to sneak a few things in there that we don’t need like audio support. As an example here is what I trimmed from config-host.mak:

$ diff -ruN config-host.mak config-host.mak-cutdown
--- config-host.mak 2022-11-08 09:37:41.104441392 +0000
+++ config-host.mak-cutdown 2022-11-08 09:37:25.084441253 +0000
@@ -27,8 +27,8 @@
CONFIG_SLIRP=y
CONFIG_SMBD_COMMAND="/usr/sbin/smbd"
CONFIG_L2TPV3=y
-CONFIG_AUDIO_DRIVERS=oss
-CONFIG_AUDIO_OSS=m
+CONFIG_AUDIO_DRIVERS=
+CONFIG_AUDIO_OSS=n
ALSA_LIBS=
PULSE_LIBS=
COREAUDIO_LIBS=
@@ -72,7 +72,6 @@
HAVE_STRCHRNUL=y
CONFIG_BYTESWAP_H=y
CONFIG_TLS_PRIORITY="NORMAL"
-CONFIG_TASN1=y
HAVE_IFADDRS_H=y
HAVE_FSXATTR=y
HAVE_COPY_FILE_RANGE=y
@@ -164,7 +163,7 @@
DSOSUF=.so
LDFLAGS_SHARED=-shared
LIBS_QGA+=-lm -lgthread-2.0 -pthread -lglib-2.0
-TASN1_LIBS=-ltasn1
+TASN1_LIBS=
TASN1_CFLAGS=
POD2MAN=pod2man --utf8
TRANSLATE_OPT_CFLAGS=

And this cuts down the needed dll’s to:

jsteve@piorun:~/atar-boot/qemu/ppc-softmmu$ objdump -p qemu-system-ppc | grep NEED
NEEDED libncursesw.so.6
NEEDED libtinfo.so.6
NEEDED libz.so.1
NEEDED libpixman-1.so.0
NEEDED libfdt.so.1
NEEDED libglib-2.0.so.0
NEEDED libm.so.6
NEEDED libgcc_s.so.1
NEEDED libc.so.6

which is a bit better. I’m still annoyed at it’s reliance on pixman despite not having any framebuffer support, I’m guessing I could amputate it if I looked further.

AIX 4.3 booted!

Since nothing has fundamentally changed, I can still use my original bootflags:

./qemu-system-ppc -M 40p -bios q40pofw-serial.rom -serial telnet::4441,server -hda disk0.vmdk-post-install -vga none -nographic -net none -cdrom /mnt/c/temp/xlc13-gzip.iso

And for the heck of it, this is the steps I used to get xlC 1.3 up and running:

restore -f /tmp/xlc/xlccmp2
restore -f /tmp/xlc/xlccmpmE2
chmod +x /usr/bin/xlc
chmod +x /usr/lpp/xlc/bin/xlcentry
chmod +x /usr/lpp/xlc/bin/dis
cp /usr/lpp/xlccmp/inst_root/etc/xlc.cfg /etc
cp /tmp/xlc/cpp /usr/lib/cpp
chmod +x /usr/lib/cpp

and with that all in place we can compile a simple hello world!


# cat mt.c
#include <stdio.h>
void main(){
printf("hi from C\n");
}
# xlc -v mt.c -o mt
exec: /usr/lpp/xlc/bin/xlcentry(xlcentry,mt.c,mt.o,mt.lst,-D_ANSI_C_SOURCE,-D_IBMR2,-D_AIX,-D_AIX32,-qansialias,NULL)
exec: /bin/ld(ld,-H512,-T512,-bhalt:4,-o,mt,/lib/crt0.o,mt.o,-lc,NULL)
unlink: mt.o
# ./mt
hi from C
#

xlC is also capable of building a running GNU Chess. And I updated the git so that book building works. Not that I expect anyone to care.

Chess
book
Compiling book, please wait…
186 games added, 3384 positions added, 3383 total positions in book

It has the same desire to move pieces back and forth for thousands of moves, but it’s doing a heck of a lot more than any modern C compiler.

Since we don’t have any networking, Everything is on the console. I’ve found making CD-ROM images being a much easier way to get data in, and I’m still using uuencode to get data out from the console. I guess I should setup Z-modem at some point but that’s very futuristic. Or just break down and learn how to use C-kermit.

My go to quality of life startup is:

export TERM=vt100
stty erase ^?
export LIBPATH=$LIBPATH:/usr/lib
export PATH=/usr/local/bin:$PATH

Sure not perfect but it makes it slightly more usable. As a follow on, I got networking working here: Networking on AIXI 4.3

Re-visiting an install of 386BSD 0.0

    I shall be telling this with a sigh
    Somewhere ages and ages hence:
    Two roads diverged in a wood,
            and I ---
    I took the one less traveled by,
    And that has made all the difference.
       "The Road Not Taken" [1916] -- Robert Frost

I didn’t want to make my last post exclusively focusing on 386BSD 0.0, but I thought the least I could do to honor Bill’s passing was to re-install 0.0 in 2022. As I mentioned his liberating Net/2 and giving it away for free for lowly 386/486 based users ushered in a massive shift in computer software where so called minicomputer software was now available for micro computer users. Granted 32bit micro computers, even in 1992 were very expensive, but they were not out of the reach of mere mortals. No longer did you have to share a VAX, you could run Emacs all by yourself! As with every great leap, the 0.0 is a bit rough around the edges, but with a bit of work it can be brought up to a running state, even in 2022.

But talking with my muse about legacies, and the impact of this release I thought I should at least go thru the motions, and re-do an installation, a documented one at that!

Stealing fire from the gods:

Although I had done this years ago, I was insanely light on details. From what I remember I did this on VMware, and I think it was fusion on OS X, then switching over to Bochs. To be fair it was over 11 years ago.

Anyways I’m going to use the VMware player (because I’m cheap), and just create a simple VM for MS-DOS that has 16MB of RAM, and a 100MB disk. Also because of weird issues I added 2 floppy drives, and a serial & parallel port opened up to named pipe servers so I can move data in & out during the install. This was really needed as the installation guide is ON the floppy, and not provided externally.

VMware disk geometry

One of the things about 386BSD 0.0 is that it’s more VAX than PC OS, so it doesn’t use partition tables. This also means geometry matters. So hitting F2 when the VM tries to boot, I found that VMware has given me the interesting geometry of 207 cylinders, 16 heads, and a density of 63 sectors/track. If you multiply 207*16*63 you get 208656 usable sectors, which will be important. Multiply that by 512 for bytes per sector you get a capacity of 106,831,872. Isn’t formatting disks like it’s the 1970s fun? Obviously if you attempt to follow along, obviously yours could be different.

Booting off install diskette

Throwing the install disk in the VM will boot it up to the prompt very quickly. So that’s nice. The bootloader is either not interactive at all, or modern machines are so fast, any timeout mechanism just doesn’t work.

As we are unceremonially dumped to a root prompt, it’s time to start the install! From the guide we first remount the floppy drive as read-write with the following:

mount -u /dev/fd0a /

Now for the fun part, we need to create an entry in the /etc/disktab to describe our disk, so we can label it. You can either type all this in, use the serial port, or just edit the Conner 3100 disk and turn it into this:

vmware100|VMWare Virtual 100MB IDE:\
:dt=ST506:ty=winchester:se#512:nt#16:ns#63:nc#207:sf: \
:pa#12144:oa#0:ta=4.2BSD:ba#4096:fa#512: \
:pb#12144:ob#12144:tb=swap: \
:pc#208656:oc#0: \
:ph#184368:oh#24288:th=4.2BSD:bh#4096:fh#512:

As you can see the big changes are the ‘dt’ or disk type line nt,ns and nc, which describe heads, density and cylinders. And how 16,63,207 came from the disk geometry from above. The ‘pa’,’pb’… entries describe partitions, and since they are at the start of the disk, nothing changes there since partitions are described in sectors. Partition C refrences the entire disk, so it’s set to the calculated 208656 sectors. Partition A+B is 24288, so 208,656-24,288 is 184,368 which then gives us the size of partition H. I can’t imagine what a stumbling block this would have been in 1992, as you really have to know your disks geometry. And of course you cannot share your disk with anything else, just like the VAX BSD installs.

With the disklabel defined, it’s now time to write it to the disk:

disklabel -r -w wd0 vmware100

And as suggested you should read it back to make sure it’s correct:

disklabel -r wd0
wd0 labeled as a custom VMware 100

Now we can format the partitions, and get ready to transfer the floppy disk to the hard disk. Basically it boils down to this:

newfs wd0a
newfs wd0h
bad144 wd0 -f
mount /dev/wd0a /mnt
mkdir /mnt/usr
mount /dev/wd0h /mnt/usr
(cd /;tar -cf - .)|(cd /mnt;tar -xvf -)
umount /mnt/usr
umount /mnt
fsck -y /dev/rwd0a
fsck -y /dev/rwd0h

Oddly enough the restore set also has files for the root, *however* it’s not complete, so you need to make sure to get files from the floppy, and again from the restore set.

One of the annoying things about this install is that VMware crashes trying to boot from the hard disk, so this is why we added 2 floppy drives to the install so we can transfer the install to the disk. Also it appears that there is some bug, or some other weird thing as the restore program wants to put everything into the ‘bin’ directory just adding all kinds of confusion, along with it not picking up end of volume correctly. So we have to do some creative work arounds.

So we mount the ‘h’ partition next as it’s the largest one and will have enough scratch space for our use:

mkdir /mnt/bin
mount /dev/wd0a /mnt/bin
mount /dev/wd0h /mnt/bin/usr
cd /mnt/bin/usr

Now is when we insert the 1st binary disk into the second floppy drive, and we are going to dump into a file called binset:

cat /dev/fd1 > binset

Once it’s done, you can insert the second disk, and now we are going to append the second disk to binset:

cat /dev/fd1 >> binset

You need to do this with disks 2-6.

I ran the ‘sync’ command a few times to make sure that binset is fully written out to the hard disk. Now we are going to use the temperamental ‘mr’ program to extract the binary install:

cd /mnt
mr 1440 /mnt/bin/usr/binset | tar -zxvf -

This will only take a few seconds, but I’d imagine even on a 486 with an IDE disk back then, this would take forever.

The system is now extracted! I just ran the following ‘house cleaning’ to make sure everything is fine:

cd /
umount /mnt/bin/usr
umount /mnt/bin
fsck -y /dev/rwd0a
fsck -y /dev/rwd0h

And there we go!

Now for actually booting up and using this, as I mentioned above, VMware will crash attempting to boot 386BSD. Maybe it’s the bootloader? Maybe it’s BIOS? I don’t know. However old versions of Qemu (I tested 0.9 & 0.10.5) will work.

With the system booted you should run the following to mount up all the disks:

fsck -p
mount -a
update
/etc/netstart

I just put this in a file called /start so I don’t have to type all that much over and over and over:

Booting from Hard Disk, under Qemu

On first boot there seems to be a lot of missing and broken stuff. The ‘which’ command doesn’t work, and I noticed all the accounting stuff is missing as well:

mkdir /var/run
mkdir /var/log
touch /var/run/utmp
touch /var/log/wtmp

Will at least get that back in action.

The source code is extracted in a similar fashion, it expects everything to be under a ‘src’ directory, so pretty much the same thing as the binary extract, just change ‘bin’ to ‘src’, and it’s pretty much done.

End thoughts

I think this wraps up the goal of getting this installed and booting. I didn’t want to update or change as little as possible to have that authentic 1992 experience, limitations and all. It’s not a perfect BSD distribution, but this had the impact of being not only free, but being available to the common person, no SPARC/MIPS workstations, or other obscure or specialized 68000 based machine, just the massively copied and commodity AT386. For a while when Linux was considered immature, BSD’s led the networking charge, and I don’t doubt that many got to that position because of that initial push made by Bill & Lynne with 386BSD.

Compressed with 7zip, along with my altered boot floppy with my VMware disk entry it’s 8.5MB compressed. Talk about tiny! For anyone interested here is my boot floppy and vmdk, which I run on early Qemu.

And there we go!

Revisiting Windows NT 4.0 MIPS on QEMU

(This is a guest post by Antoni Sawicki aka Tenox)

This was previously well covered by Gunkies and Neozeed, however as almost a decade passed, some improvements could be made and annoyances fixed.

Firstly NT MIPS now works in 1280×1024 resolution under QEMU. It previously had issues with mouse tracking, but this is now fixed. So the new image has a higher resolution.

Secondly the old images were made with FAT filesystem which I didn’t like too much. The reason for that is the infamous RISC NT osloader needs to be placed on a FAT partition. Then, if NT is installed on a second NTFS partition the default drive will be D:\, C:\ being the just the osloader drive. This was super annoying in practice. So a common procedure was to just have one FAT partition for both osloader and winnt. I have fixed it by supplying a pre-partitioned disk and specified the second partition for osloader and the first for NT.

Also I only had just a bare/vanilla image with no additional software installed. The new image includes most of the available apps, including IE3, some editors, Reskit and Visual Studio.

Lastly I wanted to figure out all the right settings and flags for qemu as they were discrepancies between different sources and nothing seem to work smoothly. The correct flags seem to be:

qemu-system-mips64el -hda nt4.qcow2 -M magnum -global ds1225y.filename=nvram -L . -rtc "base=1995-07-08T11:12:13,clock=vm" -nic user,model=dp83932

The -rtc flag is not really needed if you are ok with having the current date in the guest.

Thanks to Neozeed for figuring out the network settings! Unfortunately the old/legacy -net nic -net user is no longer working while the new -device doesn’t like dp83932. The documentation was quite helpful.

Thanks to reader Mark for pointing out the correct NVRAM settings! See comments below.

The new image with all the apps preinstalled is here and a plain “vanilla” here.

Curiously this now works right out of the box on QEMU 6.1 and is pretty smooth and stable compared to what it was before. Good job QEMU team and thank you! Just in case I still keep the old binaries for Windows made by Neozeed here.

Update: I built Yori for NT MIPS! You can download here!

Re-visiting Gopher on A/UX

Rather unintentionally some 7 years ago (to the day!) I was playing with an early gopher server on Linux, musing that one day it’d be cool to run it fully on A/UX (what is it anyways?!). And thanks to Qemu’s 68040 support the time is at hand.

First off I need to run this on Linux so I’ll need to build the appropriate branch myself. Thankfully Cat_7 has boiled it down to a really simple formula:

git clone -b q800.upstream https://www.gitlab.com/mcayland/qemu q800-upstream
cd q800-upstream
./configure --target-list=m68k-softmmu --enable-gtk --enable-sdl
make

In my case I remove the gtk and sdl as I’m running this headless.

Now onto the OS itself. While I had numerous images built over the years for Shoebill there was one major issue when compared to Qemu, and that is Shoebill loads the kernel directly while Qemu emulates the hardware so it will boot MacOS 7 directly. While on the surface this is mundane that does mean however that none of my images will actually work on Qemu as they don’t include a blessed copy of System 7. Not that I care that much I could always do a simple dump/restore [ dump.bsd 0f – /dev/rdsk/c0d0s0 | (cd /mnt; restore xf -) ] of my A/UX stuff that I care about anyways. Luckily since I had added that SCSI file support to Cockatrice I could still partition out some disks and install from there.

Now for the further bit of bad news for me is that I found that the 68020 based Shoebill ran 3.0.0 far more stable than 3.0.1 or 3.1. So I’d built everything around 3.0.0. And of course trying to boot 3.0.0 on a Quadra 800 just gives you a hard lock up. I don’t have the setup disk for 3.0.0 but mounting the CD-ROM gives you access to the disk tool (the 3.0.0 version doesn’t check for the Apple string on SCSI ROMS so you can partition with that as well). Anyways too much time thinking I’d done something wrong until this had to be pointed out to me:

Compatibility matrix from penelope

That’s right, 3.0.0 doesn’t run on the Quadra 800. Much longer ago I had a Quadra 950, fantastic beast of a machine, and yes it ran 3.0.0 just great. So shockingly running the right versions got me up to a working system just fine.

Now of course back in the Shoebill days I got ‘3.0.1’ kind of working by cheating. The /mac programs didn’t work on Shoebill however I could copy them over from 3.0.0 to get a working system. Could I substitute a 3.0.1 kernel & /mac directory onto a 3.0.0 system?

So first up the System 7 install from A/UX 3.0.0 is too old for a Quadra 800. Obviously just use the one from 3.0.1. Great.

This lead to a problem where the root filesystem always needs to be checked in single user mode. Something that is shockingly hard to do when your Quadra runs so fast as you have less than a second to hit the ‘top’ button to halt the autoload.

Naturally the standalone runs fine, with no errors.

Thinking that it’s the start-up scripts I remove all the fsck’s and then get this message:

Great a kernel panic. ialloc: dup alloc. Thinking that maybe it’s confusing the UFS, I go ahead and format the disk in SYSV and restore the image onto that.

This gets me another kernel panic, this time no root filesystem. Surprise the SYSV filesystem was made optional in a default install. I run ‘newconfig sysv’ from 3.0.1 and copy that kernel back, and for good measure the shared libraries from 3.0.1. Now I get a different error:

Interesting, I try to hit restart, and instead I get dumped into text mode!

Victory!

So here we are a 3.0.1 kernel with a 3.0.0 userland! I’m going to use this as a server anyways so I don’t really care about the Mac UI. Naturally so many twists and turns I’ll just skip to the end. Networking didn’t work correctly. Maybe I should have copied all the network stuff from 3.0.1 over but at this point it’s basically a 3.0.1 system so why even bother?

So the next thing of course is just to setup Qemu to listen on a loopback and add some disks. A lot of disks.

./qemu-system-m68k \
-L pc-bios \
-m 256 \
-M q800 \
-vnc 10.11.0.1:35 \
-serial stdio \
-bios Quadra800.rom \
-net nic,model=dp83932,netdev=ne -netdev user,id=ne,hostfwd=tcp:10.11.0.1:42323-:23,hostfwd=tcp:10.11.0.1:40070-:70,hostfwd=tcp:10.11.0.1:40080-:80 \
-drive file=pram-aux.img,format=raw,if=mtd \
-device scsi-hd,scsi-id=0,drive=hd0,vendor="SEAGATE",product="ST225N",ver="1.0" \
-drive file=scsi0.vmdk,media=disk,format=vmdk,if=none,id=hd0 \
-device scsi-hd,scsi-id=1,drive=hd1,vendor="SEAGATE",product="ST225N",ver="1.1" \
-drive file=scsi1.vmdk,media=disk,format=vmdk,if=none,id=hd1 \
-device scsi-hd,scsi-id=2,drive=hd2,vendor="SEAGATE",product="ST225N",ver="1.2" \
-drive file=scsi2.vmdk,media=disk,format=vmdk,if=none,id=hd2 \
-device scsi-hd,scsi-id=3,drive=hd3,vendor="SEAGATE",product="ST225N",ver="1.3" \
-drive file=scsi3.vmdk,media=disk,format=vmdk,if=none,id=hd3 \
-device scsi-hd,scsi-id=4,drive=hd4,vendor="SEAGATE",product="ST225N",ver="1.4" \
-drive file=scsi4.vmdk,media=disk,format=vmdk,if=none,id=hd4 \
-device scsi-hd,scsi-id=5,drive=hd5,vendor="SEAGATE",product="ST225N",ver="1.5" \
-drive file=scsi5.vmdk,media=disk,format=vmdk,if=none,id=hd5 \
-device scsi-hd,scsi-id=6,drive=hd6,vendor="SEAGATE",product="ST225N",ver="1.6" \
-drive file=scsi6.vmdk,media=disk,format=vmdk,if=none,id=hd6
Yeah well… great!?

One nice thing is that since we are on Qemu I don’t have to use raw disk images, I can zero stuff out and use VMDK’s. Nice. I guess I could bridge the VM later, but for now NAT is fine enough as all I need is telnet & gopher. So I grab gopher2_3.1.tar.gz, rebuild and move over my gopher site from Linux into A/UX and I’m up and running in no time. It was shockingly easy. I update a few things to reflect it running on A/UX now.

Currently 2 days of uptime!

And just like that I took my semi popular gopher site, and moved it to A/UX seven years after thinking that this would be a ‘good idea(tm)’. I’m sure it won’t backfire spectacularly.

I don’t know if any of this is useful or interesting but it was to me. It’s been nice that Qemu has been able to keep uptime in several days, I had 3 days of uptime before I took it down to max out the storage so I could possibly do more with it.

Naturally it’s still available as gopher://gopher.superglobalmegacorp.com