Qemu vs KVM with Novell Netware 3.12

So I received an interesting tip, talking about the latest Qemu version, when it was mentioned that it isn’t the hardware that is at fault with Netware not running, but rather something in the emulated CPU.

Because, get this, Novell Netware runs in KVM.

Novell Netware 3.12

Novell Netware 3.12

I was taken back, all this time I thought it was something in the -M isapc definition that broke, but it’s the CPU!  I even rebuilt Qemu with the TCG interpreter, and it too breaks.  I even went one more crazy step, and installed with the ancient isadisk controller, and NE2000 on the ISA bus, and it works!

So for now my old copy of Netware I bought a million years ago lives in the cloud!

ReactOS build 61112

So I thought I’d look for the latest release build of ReactOS, and give it a whirl.  First I download 61112, and installed it on Qemu 1.7rc2 on OS X.  First I gave the VM a 500MB disk, and 500MB of ram… which led to the thing using the whole disk for paging and was terribly unstable, and all around no good.

So next I got smart, used 64MB of ram, and a 1Gig disk, installed then turned off swap.  Now it is more usable.  I thought I’d do something crazy, and install Visual C++ 4.0.  The installer works, except there is no progress, and it can’t create program groups.  No problem I think as it does the same thing on CrossOver(wine).  I download my QWDOS project with firefox, extract, and open the makefile and… all the menus are blanked out.  And dropping down to the CLI, although the installer ‘registered environment variables’ the compiler wasn’t in the path.  Clearly registry information is dropping.

NO Build for you!

NO Build for you!

So falling back to nmake I can at least compile my release build, and amazingly -it works!

QWDOS Win32 on ReactOS

QWDOS Win32 on ReactOS

So is it perfect? No far from it, but it certainly is a lot more usable than it was a year ago.

Qemu enters the 1.7 testing phase

I built 1.7rc2 on OSX, and I’ve only tested the x86 portion… x86_64 of course still fails on vista & friends… 2003 of course hangs at “starting windows” so no progress there.  I haven’t tried any MIPS, PowerPC, or SPARC things…

Also the Adlib/SoundBlaster is still broken in this release, there is a source change in adlib.c that has to be made.  Also I just noticed that IRQ sharing works in ISA mode again, so the Ne2000 can go back to 0x300 IRQ 9.

Also speaking of emulation, I was thinking of shoving a VAX-11/780 into the world for the heck of it.  Although I don’t think anyone would care.  I’ll have to dig out the source to 4.3 and give the shell the ability to add new users.  I wrote it once, and I fear I’ve lost those changes but it was cool for something back then.

Anyways post back here if you want an account on vax.superglobalmegacorp.com !

ReactOS gets a NTVDM

Really I saw it right here!  It is only in it’s beginning stages, but it can run some very simple COM programs.

I should also say, I ran a nightly build, and it is coming along much more than the last year.. I didn’t trap or anything messing around.  What I did do was run out of disk space with a large swap file, and downloading too much crap….

Raspberry Pi Floppy emulator

A good friend passed on this link.  And what an amazing thing!

Floppy interface board

So basically a Raspberry Pi (which can be had for sub $50 USD), running a bare metal program can emulate the control signals of an Amiga floppy drive.  It reads disk files from a flash card, and serves them to the Amiga.  It can even kickstart an Amiga 1000.

I know that floppy emulators have been an on/off hot topic, but this is pretty interesting!

And of course it has a DIY angle to it as well.

Here is a video of it in action:

 

VIM the Virtual Machine debugger

I stumbled across this site a while back, but could never get it to run.  From the description VIM is:

..(vim) is a debugger, I can’t let a bad program take out the interrupt vectors, DOS, or whatever. Hence the “Virtual” in the name — VIM takes whatever memory it can get, and sets up the interpreter to use a “virtual” processor. So, when the interpreter uses Interrupts, DOS, etc, it’s using the virtual copy, so that a bad program destroying them won’t hurt VIM, the real DOS, real interrupt vectors, etc.

Which is very cool, unlike traditional debuggers which try to hide in memory, VIM executes outside of memory and is then invisible.  Unfortunately it is rather tied to ANCIENT hardware.  And executes better on an 8088/8086/80286 processor.  I thought I could run it on Qemu, but it’ll trap on the BIOS as it’ll have instructions outside of VIM’s understanding.  However using PCem’s 80286 emulation it’ll run fine.

VIM running MS-DOS

VIM running MS-DOS

Another interesting thing about VIM, is that it includes the full source code, which is built with Aztec/C, however it doesn’t build cleanly as you have to finagle some of the assembly.

Running this on PCem is quite nice, as you can set it for a FAST 80286 computer, so it won’t take 10 minutes to boot a virtual copy of MS-DOS.

Is this useful? Well maybe if you feel the need to write an MS-DOS device driver, VIM can debug it.. but otherwise, it is an interesting fossil.

Linux on the VAX

I don’t know how I missed this thing!

$ cat lvax
load -r ka655.bin
set rq0 ra92
att rq0 /tmp/vmlinux.dsk
att xq dummy0
boot cpu
$ ./vax lvax

MicroVAX 3900 simulator V4.0-0 Beta git commit id: 55c5d205

KA655-B V5.3, VMB 2.7
Performing normal system tests.
40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25..
24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09..
08..07..06..05..04..03..
Tests completed.
>>>show dev
UQSSP Disk Controller 0 (772150)
-DUA0 (RA92)
-DUA1 (RD54)
-DUA2 (RD54)
-DUA3 (RX50)

UQSSP Tape Controller 0 (774500)
-MUA0 (TK50)
-MUA1 (TK50)
-MUA2 (TK50)
-MUA3 (TK50)

RLV12 Controller 0 (774400)
-DLA0 (RL01)
-DLA1 (RL01)
-DLA2 (RL01)
-DLA3 (RL01)

Ethernet Adapter 0 (774440)
-XQA0 (08-00-2B-AA-BB-CC)
>>>boot dua0:
(BOOT/R5:0 DUA0

2..
-DUA0
1..0..

CPU type:
80004A04KA650
Boot Head.S loaded at address 00004A00
rpb/bootr5/ap/sp 00000000 00000000 00000344 00004800
relocated at phys address 00100307
CPU type: 0A000006 sidex: 01530302

Starting VM
Linux/VAX ([email protected])
KA650 sidex = 01530302
RPB info: l_pfncnt: 00007f98, .l_vmb_version: 0a000207 .l_badpgs: 00000000
Physical memory: 00007f98 HW pagelets, 00000ff3 pages (16332KB)
CPU type: KA650, SID: 00000000
VM: mapped physical from 80000000 to 80ff3000, iomap from 80ff3000
VM: vmalloc from 810f3000 to 814f3000
VM: ptemap from 814f4000 to 837f4000 for 64 processes
calling start_kernel…

Linux version 2.4.16 ([email protected]) (gcc version 2.95.2-linuxvax-dynamic-dev (CVS)) #28 Wed Feb 12 09:55:28 GMT 2003
kernel_cmd_line 80004a04
root=/dev/nfs ip=192.168.5.240:192.168.5.67:::vaxemu:eth0:none nfsroot=/mnt/redhat/vax_emu/vaxroot rw debug init=/bin/sh
VAXMM: Initialising mm layer for 64 tasks of size 64MB
VAXMM: system page table base 8020b800, length (bytes) 6fe80 length (ptes) 1bfa0
bootmap size = 00000200
calling free_bootmem(start=00001000, len=000ff000)
calling free_bootmem(start=0027c000, len=00d77000)
On node 0 totalpages: 4083
zone(0): 4083 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nfs ip=192.168.5.240:192.168.5.67:::vaxemu:eth0:none nfsroot=/mnt/redhat/vax_emu/vaxroot rw debug init=/bin/sh
Calibrating delay loop… 23.29 BogoMIPS
Memory: 14556k/16332k available
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with no serial options enabled
block: 64 slots per queue, batch=16
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
IO mapped phys addr 0x20088000, 0x0008 pages at virt 0x80ff3000 (IOMAP PTE index 0x0000)
ttyS0: Internal processor register console
IO mapped phys addr 0x20001000, 0x0001 pages at virt 0x80ffb000 (IOMAP PTE index 0x0008)
delqa qbus vector: 4 (0004, 0x0004)
Ethernet address in ROM: 08:00:2b:aa:bb:cc
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 512 bind 512)
eth0: resetting DELQA… done
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
device=eth0, addr=192.168.5.240, mask=255.255.255.0, gw=255.255.255.255,
host=vaxemu, domain=, nis-domain=(none),
bootserver=192.168.5.67, rootserver=192.168.5.67, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.5.67

I’m amazed that it runs this far under SIMH.  Sadly though disks are not supported on any of the SIMH models, as Linux relies on certain CPU models:

  • VAXstation 3100m76 (KA43 CPU)
  • VAXstation 3100m38 (KA42 CPU)

The project has moved from sourceforge, to a dedicated server.  Sadly it seems that it has been a few years between updates, but I guess someone could carry the torch….

QuakeWorld Clients

I thought Id’ take a few hours to update some builds based on the latest QWDOS source.

So I spent a few hours updating some QuakeWorld clients.. for reproducibility sakes, I built out the MS-DOS one and that worked fine.  The OS/2 one ‘works’ but the keyboard isn’t working.  Not so sure why not.  The Win32 version works fine, although I’m building with Visual C++ 4.0, and no assembly or DirectX.  Just straight GDI.

Next will be Linux with svgalib.

So my work is here.  I could go more into how to build, but I don’t know if anyone cares.

Emulating a Cray X-MP Supercomputer

I just saw this, and it looks incredibly awesome.  I didn’t know that early Cray’s were more in line with mainframes.  And the X-MP could reach speeds of 105Mhz with 16MB of ram back in 1982.

Talk about awesome!  Andras did an awesome job of recovering this lost gem of early supercomputing.