Qemu 0.15.0 rc2

(UPDATE Qemu 0.15.0 has been released)

I couldn’t even begin to mention what is new in this version of Qemu other then it is a *LOT* harder to build as it now depends on glib2, and it’s way pickier about finding and resolving dependencies. I should also add that compiling is *FAR* more intense than it was in prior versions.  At some point GCC was eating 1.8GB of ram.  And I know it’s only constrained by me using the 32bit tool chain. I have no idea if it’ll even build with the 64bit GCC on Windows.

So with a bit of prodding, I’ve managed to build the i386 version although I didn’t do much testing.  But it does seem to work.  So here it is, my Win32 build:

qemu-0.15.0-rc2-i386-x86_64.7z

I’ve modified it so that the NE2000 is on 0x320 IRQ 10, and I’ve slipped back in my control+alt+d for a control alt delete (CAD) substitute, along with control+alt+r for a reset hotkey.

Enjoy!

BBS’ing with Windows/386 & Windows 3.0 under Qemu or how I learned to love rlfossil

A while back I had seen this fantastic site, “Hates the internet” with a great write up on setting up a BBS on Qemu. In retrospect it did inspire me a bit later to get my BBS going with Qemu, but I chose to use OS/2 once I found out about SIO’s vmodem feature.

HTI (Hates the internet) chose this program called rlfossil, which is for MS-DOS..

RLFOSSIL is an implementation of multi-line serial port driver corresponding to the Fido/Opus/Seadog level 5 specification and a simple HAYES-compatible modem emulator. It allows applications usually worked through BBS’s to run on the Internet, or in IP-based local net.er, and rlogin and telnet emulation using IP services numbers 513 & 23. RLFOSSIL allows combined work with other FOSSIL drivers (X00,BNU etc.).

So, I thought between that, and all the Windows/386 excitement I’d try for something even more insane. How about running a multiline BBS on Windows?

In the same effort, I was going to use Qemu 0.14.1, with MS-DOS 4.01 (the first version I could find that came with share.exe), and Windows/386 2.11. The installation of MS-DOS 4.01 worked fine on an 80MB disk image, thankfully it was one of the things that DOS 4 could do better than 3 is large disk images… Yes, I know 3.31 could as well, but it didn’t come with share so it was out.  One strange thing after install was this message…

It is kind of foreboding that DOS is warning me that because of my “large” disk I better run share. Since I plan on having a multi node BBS all in one computer, I need to run share anyways.

The next exciting part was installing Windows/386 2.11. The installation went pretty smooth, and with Qemu the mouse worked fine.  So far, so good.  I couldn’t use himem.sys that comes with Windows/386, nor could I use the himem.sys that comes with MS-DOS as the Windows/386 version complains that that A20 line is already active (?) and the MS-DOS one has Windows complaining that the HMA is already in use. Sadly, then my conventional memory footprint will be unsatisfactory, but I don’t see any way around it.

The next part is configuring rlfossil. rlfossil needs a driver to talk to the network card, and you can find them on crynwr, namely the ‘other‘ packet archive, which contains NE2000 drivers.  Keeping with HTI, I’m going to use the NE2000 and configure Qemu with the PCI NE2000 driver.

Packet drivers are loaded from the command line something like this:

ne2000 0x60 11 0xc100

This loads the driver on software interrupt 0x60, and by default the PCI NE2000 is configured for IRQ 11, port 0xc100.  Qemu 1.6.0 changed the PCI NE2000 to use port 0xc000 for what it is worth..

So keeping with the HTI tradition, I’m going to put my packet driver (ne2000.com) and unpack the rlfossil archive in c:\packet. The next thing to do is configure rlfossile which uses the wattcp configuration file.  Since I’m going to use the usermode NAT and a redirect, I configure my VM like this:

Wattcp.cfg

Address:10.0.2.15
Netmask:255.255.255.0
Gateway:10.0.2.2
DNS: 10.0.2.3

With that all in place now it’s time to configure the config.sys/autoexec.bat.  Some things are going to be different from a normal install because we plan to run a BBS, and multiple instances of it!

So my config.sys looks like:

FILES=96
STACKS=0,0
DEVICE=C:\DOS\ANSI.SYS
SHELL=C:\COMMAND.COM /P /E:768

And my autoexec.bat is like this:

PATH C:\WIN386;C:\DOS
PROMPT $P$G
SHARE
SET TEMP=C:\TEMP
CD \PACKET
NE2000 0x60 11 0xC100
RLFOSSIL 0 4 WIN386

And of course launching Qemu I do it like this:

qemu.exe -L pc-bios -m 16 -net nic,model=ne2k_pci -net user-redir tcp:23::23 -hda telegard.qcow2

This configures the VM for 16MB of ram (which would have cost a FORTUNE back then), the PCI NE2000, and it’ll redirect telnet from my host machine into the VM.

And just like HTI, I went with telegard, because it supports fossil based ports.

Well that sure was a *LOT* of work, and surprisingly testing it with a single node, actually works.  And you can bring up a few other MS-DOS prompts and it’ll work fine. But if you launch the second node…

Disaster struck.  So needless to say, while Windows/386 was pretty slick for the day it just couldn’t measure up.  So I figured for the hell of it, I’d try Windows 3.0 Â I mean I would have imagined that Windows 3.0 most certainly could NOT handle this kind of challenge.

So with some disks shuffled, I fired it up and..

Two node telegard under Windows 3.0

It actually worked!  So with a LOT of chaos going on I managed to get Trade Wars 2002 running, although I couldn’t figure out how to automatically figure out the node.. Hell the whole door configuration thing is.. bizarre. Synchronet really kicks ass in regards to easy of configuration.

Running TW2002, two copies

And using PIF’s to configure each node for some easy of launching, and some reduced memory, I could easily run all four nodes that rlfossil can support.

Four Nodes!

I have to admit, Windows 3.0 really is impressive considering all the UAE’s and how generally crappy we thought it was at the time.  I’m sure even emulated having a multiple Ghz cpu helps quite a bit.

460KB free!

And look at all that memory.. I guess it’s pretty impressive it even works.  Since Windows anything throttles the CPU at 100% I’m not going to put this online…. Although at the same time combined with an CPU idle program (is there a Windows 3.0 idle vxd?) it sits ok, but who wants a single user system in 2011?

OS/2 2.1 and TCP/IP 2.0

So I thought I could simply take my OS/2 2.0 install on Qemu with an ISA NE2000 and simply upgrade it to OS/2 2.1 and it’d work, right?

WRONG.

Dead WRONG.

So after an hour screwing around with various drivers, I found of all things, the PCI NE2000 will work.  The driver is available os2site.com

Thankfully the NIF’s and OS2 bits work right so you can actually use LAPS to configure it, once you copy the NIF & OS2 files into the c:\ibmcom\macs directory.

LAPS to the rescue (for once)

And then with that in place configured for user mode networking (10.0.2.15/255.255.255.0/10.0.2.2 DNS 10.0.2.3)

All is working as expected.  I’m hoping that the DPMI emulation is better in 2.1 vs 2.0.  Although what is interesting is that after applying XR06200, my OS/2 2.1 is now 2.11 …

Building Qemu for a VPS

So touching on my prior long winded post, I was mentioning that running Qemu ‘headless’ on a resource constrained VPS was different then running it interactively at home.  For starters you don’t want to install X11, and all the necessary libraries just for a single program if your VPS is limited to 2GB, as it is more then likely that you will exceed your disk space just by trying to get a workable environment.

Instead, I’ve found the way to go is to take advantage of Qemu’s built in VNC server.

I build my own version of Qemu at home, then just upload the binary.  While there may be packages, because of the expectation that you’ll be running X11 for the SDL output it could easily pull in several gigabytes, that I’d rather use for disk images.  I recommend people build with the same OS as their VPS uses, to keep things ‘sane’.  Not to mention you’ll have a far higher success rate by matching OS levels.  And yes I do this in a VM, all the more reason to have VMs.

Also I should mention that in constrained space, I find that 32bit OS stuff is smaller, if you have a 64MB memory limit, then yes size does matter.

The steps are pretty simple, it’s basically download & unpack the source, then configure it something like this:

./configure --target-list=i386-softmmu --disable-sdl --enable-vnc-thread --disable-bluez --disable-curl --disable-vnc-tls --disable-vnc-sasl --disable-spice

Then run make, and after a few minutes it should complete the build.  I then manually ‘strip’ the qemu executable, tar it up and then take it for a test run.  For the most part it really is that simple.

Again I’ve found building on the same distro as your VPS is using helped an incredible amount.  Not to mention trying to keep your ‘build’ machine as bare as possible so it’s not pulling in all kinds of wild dependencies.

The next thing with Qemu uploaded is you’ll want to test it.  It works like normal Qemu with the exception of how you then specify your display to go out via VNC. For me, I run it like this:

./qemu -m 16 -hda os2.disk -hdb data500.qcow2 -vnc <Public IP>:101 -net nic,model=ne2k_isa -net user -L pc-bios -fda empty.vfd -no-reboot  -redir tcp:23::23

Then you can connect with just about any VNC client on VNC port :101 (or TCP 6001)

My OS/2 BBS on Qemu via VNC

And from there I just wrap it in a while true/do true script so that way every time I reboot the VM or if it were to crash for what ever reason it’ll keep on trying to start it over and over.

Back to memory consumption, as you can see I’ve configured my Qemu intance for a whopping 16MB of ram, and this is what it looks like according to top:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 2785 root      20   0 72868  33m 2164 S    2 57.5   1:03.69 qemu

Which is the resident size is 33MB, out of my 64MB VPS, with lhttpd running and php for the socket support I have a whopping 1MB free!

That about covers it, and for the Debian people out there here is my build of Qemu 0.14.1. I should imagine it’ll run on other i386 Linux OS’s (or x86_64’s with the 32bit compatibility installed)

Running QEMU from a VPS

I’ll expound on this as I go on.  For now this will be an overview with separate articles going into each part.  I’ll go into the process of how I created my OS/2 2.0 BBS, bbs.superglobalmegacorp.com .

VPS’s (Virtual Private Servers) are getting cheaper as the days go on, and it only makes more and more sense to take advantage of these great things!  Almost all of them are geared to running Linux, a few to Windows, and well anything outside of those two is damned near impossible to find (I’ve seen ONE NetBSD VPS service).

So if you want to say run MS-DOS, OS/2, Xenix, or any other crazed OS (why not?!) you are basically SOL as they say, except of course, if you utilize our old friend Qemu.

The first thing you’ll need is a VPS.  Now there are thousands of providers out there, I can recommend what I use (and I’ve got a few) but as always, pick a plan that you feel comfortable with.  To get started on something small a budget of under $10 USD a month is perfectly fine.  Shop around and you can certainly find cheaper in the month to month space, and if you are willing to pay up front, I’ve seen them average down to $2.50 USD a month.  Yes for less then a Big Mac, you can have your own ‘server’ in the sky (or part of the cloud nonsense if you are into that).  Hell you can even setup your own global infrastructure, with servers in Europe, Asia and North America for about $20 a month!

Anyways you can find an overload of reviews, and listings on sites like  webhostingtalk.com, and lowendbox.  Again I know it can be overwhelming but googling around you can eventually find what you are looking for.

Now what is important for running Qemu on a VPS? I’d have to say, memory is the #1 thing, bar none.  Now the joy of running older OS’s is that they didn’t need much back then so any new VPS ought to be ‘extravagant’ to them, but keep in mind Qemu needs a fair bit of memory itself!.  I generally worked it out to consume with a ‘bare’ CentOS or Debian install with an 8MB VM to consume around 60MB of memory.

Keep that in mind, that with your VM the OS will need memory, as long as disk space is also needed.  So it all depends on what OS you plan on running.  I’ve run MS-DOS, OS/2, Windows NT, and 386BSD all on the ‘cloud’.. And 8MB was fine for 386BSD but really the VM was overtaxed for anything outside of serving the VM… This for me was fine.  Again keep this in mind if you had hopes of serving web pages, hosting a blog (wordpress needs like 512MB of ram++!!!!!) or whatever.  Another thing is the x86 vs .x86_64 (32bit/64bit) question, and for VPS’s that need to keep small you will want to run 32bit code.  Esp if your VPS is configured under 2GB of ram, really there is no big ‘deal’ in loading 64bit stuff, epically since the 64bit versions consume more memory.

If in doubt setup a VM at home with the same constraints you are shopping to see if you can even do what you hope to do.  This is the big advantage of VM software as you can test all of this from home, without any major pain!

Another thing to keep in mind is that with your own VPS you will be the one required to keep it up to date!  Pick a distro that you are somewhat comfortable with.  Personally I went with Debian in my VPS’s as that is what I’m the most comfortable with.  Also I’d HIGHLY recommend NEVER EVER installing a compiler on the VPS.  If someone does get onto your system, handing them a compiler is like a loaded gun.  At least make it more…. involved for them.  Also setup a VM at home with the same OS, same cpu, same flavor *WITH* compiler, so that way you can check updates at home, to make sure things work, and of course compile things like Qemu for your environment without worrying about things that are either incredibly stale in packages, or just not there at all.  The same goes for things like firewalls.  Again pick something you are most comfortable with, and try to stick with that. The majority of OS’s available are Debian, various Debian forks (Unbutu?!) and CentOS, the RedHat ‘free’ clone.

With a VPS selected and created, and a VM at home loaded up with the same OS you will want to build Qemu.  Now keep in mind that since you’ll be running this on a server that will *NOT* have any local X11, and to minimize memory consumption & disk space by not loading .. X11, you will need to create a version of Qemu that is VNC display only.  It’s not that difficult.  It’s covered in the config process.

With a version of Qemu built, and uploaded to your VM (I use scp) you will then need to decide if you are going to encrypt your disk images (can you really, really trust your host?) or if you are fine with the way things are, and you are going to run in the open.  Naturally ‘fixed/flat’ disk images will be faster and not as CPU intensive, but of course they consume more disk space.  If you are going to ‘overcommit’ your VM or just don’t want to have the empty space right away, I’d highly recommend making a swap disk for the VM, that way you won’t blow out your disks with swapfile growth/shrinks and eventual fragmentation and moves.

If you did choose to encrypt your disks, you will need the program ‘screen’.  It’s been around for a long long while, and every Linux distro should have it available.  You will need to run screen, then launch Qemu from within screen, then it’ll prompt for the password for each disk drive.  Once Qemu is operational you can disconnect the screen session and it’ll remain operational.  Doing so in a script would require you to store the password locally, and defeats the whole point of encrypted storage.

Beyond storage, you’ll want to select some kind of method for external communications with the world.  For an OS/2 BBS I simply take TCP port 23 and forward it to the VM’s port 23.  SIO & vModem take care of all the logic from there.  If  you wanted to telnet into a *NIX box, again tcp port 23.  Maybe you want to run Windows NT 4.0 Terminal server, in that case the default TCP port is 3389.  While NT 4.0 is limited to Internet Explorer 6.0 and Firefox 1.5, it still can be a handy thing to have a multiuser version of NT (like a windows mainframe) out there somewhere for some things, although its usefulness is dwindling.  Maybe you want your own Exchange Server, or even SQL 7 instance, again older software performs better in tight disk/memory constraints.

Another thing to keep in mind is CPU consumption.  You will want a guest OS that can idle.  Otherwise you will consume 100% of the CPU 100% of the time, and they *WILL* notice this, and kick you out.  Be mindful of VPS services, and you have to share CPU resources.  Again watch your task manager or ‘ps’ locally and watch how things behave.  I know for the BBS stuff, you have to watch what doors you are interested in running as some of them happily gobble 100% of the CPU.  OS/2 friendly stuff is the way to go (IMHO) as CPU hogging was a big deal back then, and it’s best to ride on the back of how people solved this stuff a while ago.  Also for MS-DOS people, things like Dbase III applications it’d be a “bad idea” to put them into the cloud.  Although if you get one with a higher SLA that lets you run 100% then.. have at it!

If Qemu runs ‘normally’ you can even set it up into a batch file loop that calls Qemu over and over as needed between reboots.  You could even do some ‘house cleaning’ between reboots, say make a backup, email a notice etc… It’s all up to you, and what you are capable of batch script programming wise.

Also you will probably want your VPS to automatically launch your Qemu VM, and the best way I’ve found to do this is via the GNU screen program.  I just added the following to my /etc/rc.local file:

screen -S qemu -d -m /usr/local/os2bbs/run.sh
screen -S cpulimit -d -m /usr/local/bin/cpulimit -e qemu53 -l 8

This gives me two named instances, and will automatically limit my Qemu to only 8% of the host CPU that way I don’t get kicked for being a CPU hog.  8% of a 3Ghz CPU is more than enough for stuff that ran comfortably on a 16Mhz machine back in the day.

Then that would about wrap it up, you would now have a Linux VPS running your own OS, so you could serve up whatever application you want in the cloud.  The best part is, because Qemu is multiplatform, and will run on various OS’s and CPU combinations, you can jump ship very quickly to other platforms as you see fit, as all you need to do is rebuild your Qemu hosted binary, then copy your disk images & startup scripts and you are good to go!

Not to mention there is nothing to stop you from building the VM on Windows, to upload to Linux, then maybe move to SPARC Solaris!

Screw Java, Qemu is the ultimate VM!

 

Spot the difference….

Picture A

Picture B

I know, it’s hard they both look identical.  Well they kind of are, Picture A is the installed OS/2 2.0 image that I’ve been playing around with.  It’s a 500MB IDE disk formatted with the HPFS filesystem.  For the heck of it, I used the qemu-img tool to convert it from a qcow2 into a vhd (qemu-img convert 500M.disk -O vpc 500M.vhd) and then tried to boot it up on Virtual PC.  I know in the past it’d fail with some weird error as something on HPFS wouldn’t transfer and it’d be the end.

But it worked!

This is really a great victory for Qemu!

Qemu starts to add more Dec Alpha support.

From the mailing list:

Since virtio devices intentionally access memory directly, we
are not actually dependant on the iommu patches in order to 
make progress.  Merely fixing the PCI interrupt setup was 
enough to get the virtio-pci interface working.

We now make it quite a long way into the Debian Lenny install.

At some random point during the install, it hangs.  I assume
we're somehow losing an interrupt or something, but it's very
hard to tell.  The cpu is still running, servicing timer
interrupts, but the userland process is stuck.

I hope to get the vga console working next.  That should allow
me multiple vt's, which should allow me to poke at the install
process from within the VM.

And..

$ ./alpha-softmmu/qemu-system-alpha -nographic -kernel 
../../linux/linux-git/vmlinux -append 'console=ttyS0 rdinit=/bin/sh' -initrd 
../alpha-test/initrd.gz
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.39-rc4+ (address@hidden) (gcc version 4.7.0 
20110408 (experimental) (GCC) ) #18 SMP Thu Apr 28 10:11:46 PDT 2011
[    0.000000] Booting GENERIC on Tsunami variation Clipper using machine 
vector Clipper from MILO
[    0.000000] Major Options: SMP MAGIC_SYSRQ 
[    0.000000] Command line: console=ttyS0 rdinit=/bin/sh
[    0.000000] memcluster 0, usage 1, start        0, end        8
[    0.000000] memcluster 1, usage 0, start        8, end    16384
[    0.000000] freeing pages 8:2048
[    0.000000] freeing pages 3813:16384
[    0.000000] reserving pages 3813:3814
[    0.000000] Initial ramdisk at: 0xfffffc0007b26000 (5079886 bytes)
[    0.000000] SMP: 1 CPUs probed -- cpu_present_map = 1
[    0.000000] PERCPU: Embedded 6 pages/cpu @fffffc0000126000 s12608 r8192 
d28352 u49152
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 16272
[    0.000000] Kernel command line: console=ttyS0 rdinit=/bin/sh
[    0.000000] PID hash table entries: 512 (order: -1, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 65536 bytes)
[    0.000000] allocated 524288 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=memory' option if you don't want 
memory cgroups
[    0.000000] Memory: 110088k/131072k available (3489k kernel code, 20920k 
reserved, 8487k data, 384k init)
[    0.000000] SLUB: Genslabs=16, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, 
Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  RCU-based detection of stalled CPUs is disabled.
[    0.000000] NR_IRQS:32784
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [ttyS0] enabled
[    0.000000] Calibrating delay loop... 10138.40 BogoMIPS (lpj=158408704)
[    1.343750] pid_max: default: 32768 minimum: 301
[    1.343750] Mount-cache hash table entries: 512
[    1.343750] Initializing cgroup subsys ns
[    1.343750] ns_cgroup deprecated: consider using the 'clone_children' flag 
without the ns_cgroup.
[    1.343750] Initializing cgroup subsys cpuacct
[    1.343750] Initializing cgroup subsys memory
[    1.343750] Initializing cgroup subsys devices
[    1.343750] Initializing cgroup subsys freezer
[    1.343750] Initializing cgroup subsys blkio
[    1.343750] SMP mode deactivated.
[    1.343750] Performance events: Supported CPU type!
[    1.343750] Brought up 1 CPUs
[    1.343750] SMP: Total of 1 processors activated (10138.56 BogoMIPS).
[    1.343750] devtmpfs: initialized
[    1.343750] atomic64 test passed
[    1.343750] NET: Registered protocol family 16
[    1.375000] EISA bus registered
[    1.375000] bio: create slab <bio-0> at 0
[    1.375000] vgaarb: loaded
[    1.375000] Switching to clocksource qemu
[    1.375000] NET: Registered protocol family 2
[    1.375000] IP route cache hash table entries: 1024 (order: 0, 8192 bytes)
[    1.375000] IPv4 FIB: Using LC-trie version 0.409
[    1.375000] TCP established hash table entries: 4096 (order: 3, 65536 bytes)
[    1.375000] TCP bind hash table entries: 4096 (order: 3, 65536 bytes)
[    1.375000] TCP: Hash tables configured (established 4096 bind 4096)
[    1.375000] TCP reno registered
[    1.375000] UDP hash table entries: 256 (order: 0, 8192 bytes)
[    1.375000] UDP-Lite hash table entries: 256 (order: 0, 8192 bytes)
[    1.375000] NET: Registered protocol family 1
[    1.375000] Trying to unpack rootfs image as initramfs...
[    1.406250] Switched to NOHz mode on CPU #0
[    1.625000] Freeing initrd memory: 4960k freed
[    1.656250] srm_env_init: This Alpha system doesn't know about SRM (or 
you've booted SRM->MILO->Linux, which gets misdetected)...
[    1.687500] VFS: Disk quotas dquot_6.5.2
[    1.687500] Dquot-cache hash table entries: 1024 (order 0, 8192 bytes)
[    1.687500] ROMFS MTD (C) 2007 Red Hat, Inc.
[    1.687500] msgmni has been set to 224
[    1.687500] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 
253)
[    1.687500] io scheduler noop registered
[    1.687500] io scheduler deadline registered
[    1.687500] io scheduler cfq registered (default)
[    1.687500] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    2.093750] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    2.125000] brd: module loaded
[    2.125000] mousedev: PS/2 mouse device common for all mice
[    2.125000] TCP cubic registered
[    2.125000] NET: Registered protocol family 17
[    2.156250] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    2.156250] Freeing unused kernel memory: 384k freed

BusyBox v1.10.2 (Debian 1:1.10.2-2) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/bin/sh: can't access tty; job control turned off
~ # mount -t proc none /proc
~ # cat /proc/cpuinfo
cpu                     : Alpha
cpu model               : EV67
cpu variation           : 0
cpu revision            : 0
cpu serial number       : 
system type             : Tsunami
system variation        : Clipper
system revision         : 0
system serial number    : MILO QEMU
cycle frequency [Hz]    : 250000000 
timer frequency [Hz]    : 1024.00
page size [bytes]       : 8192
phys. address bits      : 40
max. addr. space #      : 255
BogoMIPS                : 10138.40
kernel unaligned acc    : 0 (pc=0,va=0)
user unaligned acc      : 0 (pc=0,va=0)
platform string         : N/A
cpus detected           : 0
cpus active             : 1
cpu active mask         : 0000000000000001
L1 Icache               : 64K, 2-way, 64b line
L1 Dcache               : 64K, 2-way, 64b line
L2 cache                : n/a
L3 cache                : n/a
~ # QEMU: Terminated

It’s incredible isn’t it?  I know the VMS crowd will be thrilled, even the legacy Digital UNIX folk.. Heck maybe one day it’ll even run Windows NT!

OS/2 and virtual COM ports.

With TCP/IP working under OS/2 I went looking for the next thing that I’ve always wanted, and that is a good modem emulator.  Funny enough SIO the COM driver replacement for OS/2 actually includes this functionality.

And has for years… I just never knew it.

I know in the NT centric would we live in today, it’s all moot, but I thought it was really interesting for those of us that still hinge on modems… And freaky hardware, since OS/2 can let some things talk directly to the hardware without OS/2 drivers (IOPL=YES).

So for the sake of it, I downloaded version 1.60 of SIO, went through the install, then added a virtual modem as described to my config.sys .. And I placed a test ‘call’ with OS/2’s terminal program, and I was talking to my MUD!

So I thought I’d try something crazier, like load up a BBS, then configure it for four modems!

 

And it worked!

Sure there are some slightly easier to configure ways to achieve this (DOSBox includes modem support), and I suppose the better thing to do would be to give virtual modems to Qemu.  Then OS’s with no TCP/IP can benefit from this.

Qemu OS/2 TCP/IP networking

Well this should have been ‘easy’ but let me assure you it was not.  However this may save someone LOTS of effort if they ever want to get TCP/IP running in a fossil like OS/2 2.0.

First of all OS/2 2.0 will not install in new versions of Qemu.  I had to go all the way back to Qemu 0.9.0!  Although there is a tonne of floppy images to shuffle, OS/2 2.0 will install somewhat straightforwardly.  Once OS/2 is installed, You will almost surely want the xr06100 service pack.  I found I was unable to run MS-DOS or WinOS/2 sessions at all without either crashing the system, or trapping the entire OS.  But after loading the service pack it works as expected.

Now Qemu supports all kinds of network cards, from the NE2000 ISA, a PCI version of the NE2000, the rtl8139, an AMD PcNET adapter, and a bunch of Intel adapters.  And the annoying thing is that the OS/2 driver I have for the AMD PcNET adapter does not work at all.  It can’t find the card no matter how much I tried.  Which is funny when Netware 3.12 of all things can see it…

I tried all kinds of NE2000 drivers set for 0x300 irq 3 or irq 9 (I changed hw/pc.c to reflect what it was set to) to either not loading, or it’d load and transmit packets, but NEVER receive any packets.

The rtl8039 (ne2k_pci) and rtl8139 would also either not find the card, crash on binding, or send packets and again receive nothing.  To say it was very annoying was an understatement.

So I almost gave up, I found some update for the TCP/IP, u64092 went through the needed fun with loaddskf, and finally got working diskettes, and … It still didn’t work.

So in a fit of rage, I removed the 0x300/9 ne2000 in the config, so the next one, the 0x320, IRQ 10 one is in order, and….. It worked!  It even works with the Microsoft NE2000 driver!

So I go ahead and modify Qemu 0.14.1 to force the ne2000 to 0x320/IRQ 10, and it works great on the latest version!  It’s a shame it doesn’t install… But hopefully you only need to do that once!

So there we go, saved by the NE2000 again.

For anyone crazy enough to reproduce this, here is my config.sys & protocol.ini … I’ve also installed EMX, but I don’t think that really matters…

 

Qemu 0.14.1 released!

I just found out that a new version of Qemu has hit the street!  From the changelog:

  • Version 0.14.1 (commit)
  • virtio-blk: fail unaligned requests (commit)
  • qed: Fix consistency check on 32-bit hosts (commit)
  • exit if -drive specified is invalid instead of ignoring the “wrong” -drive (commit)
  • vhost: fix dirty page handling (commit)
  • Do not delete BlockDriverState when deleting the drive (commit)
  • vnc: tight: Fix crash after 2GB of output (commit)
  • lan9118: Ignore write to MAC_VLAN1 register (commit)
  • Don’t allow multiwrites against a block device without underlying medium (commit)
  • lsi53c895a: add support for ABORT messages (commit)
  • virtio-pci: fix bus master work around on load (commit)
  • fix applesmc REV key (commit)
  • rbd: don’t link with -lcrypto (commit)
  • net: Add the missing option declaration of “vhostforce” (commit)
  • lsi53c895a: Update dnad when skipping MSGOUT bytes (commit)
  • Revert “prep: Disable second IDE channel, as long as ISA IDE emulation doesn’t support same irq for both channels” (commit)
  • isa-bus: Remove bogus IRQ sharing check (commit)
  • virtio-net: Fix lduw_p() pointer argument of wrong size (commit)
  • hw/sd.c: Add missing state change for SD_STATUS, SEND_NUM_WR_BLOCKS (commit)
  • vnc: Fix fatal crash with vnc reverse mode (commit)
  • qemu-char: Check for missing backend name (commit)

I’ve also included my patches to enable ctrl+alt+d for a quick control alt delete, ctrl+alt+r for reset, and the ISA Cirrus adapter.

As always, I’ll have win32 builds up in the usual spot.  i386/x86_64 and everything else.  I’ve tested these on Windows 7 x86_64, and they should work on XP & Vista i386 as well.

Also I’ve switched this to 7zip to save space.