Setting up a permanent swapfile under Windows 3.0

So while I was playing around with the idea of a Windows 3.0 powered (lol) BBS I ran into one weird thing with it swapping like crazy, and eventually depleting all my disk space!

Well when I actually used Windows 3.0 back in the day, I had a 286 so I never got to play with virtual memory.  By the time I got a 386, I was using Windows 3.11 & OS/2 which in Windows you configure it with the 386 icon in the control panel.  On OS/2 it’s a line in the config.sys.

But for Windows 3.0 it’s a standalone program, swapfile.exe.  And the best part is that you cannot run it in 386 Enhanced mode, nor in standard (286) mode.  You have to first start Windows in realmode.

So now I could force it to swap on a secondary drive, or more importantly contain it’s filegrowth so it doesn’t take up the entire disk.

Idling under MS-DOS 4.01 & Windows 3.0

Well I was playing some more with my MS-DOS setup, and the annoying thing is that it doesn’t idle worth anything.

And of course running old DOS doesn’t help that most everything needs MS-DOS 5.0 or higher.

But then I found WQGHLT, which is a VXD to support idling under Windows 3.1.  And happily it works on Windows 3.0 …

The only pain is that running MS-DOS applications kills the CPU (again).  Which means that the DOS programs themselves need to idle.  And yes I did check the ‘detect idle’ but it seems that it doesn’t do what I’d hope.

Maybe it’s just the software, I should try some more and see what I get.

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?

World Of Warcraft has gone “free”…

Good lord like things could possibly look any worse!

The end of humanity

I don’t know what even overcame me as I read the news on thinkq, but I’m already thinking of backing out. LOL  But it’s now “free” to people for the first 20 levels.  But who would want to quit at level 20 and not go all the way to 87?

Oh the humanity.

For anyone crazy enough you can join HERE (Europe) or HERE (United States), HERE(Korea), HERE(Chinese)

Oddly enough no links for Japan.

Anyways don’t say I didn’t warn you but…. The full install is also some 10GB!  Good luck you people in capped areas.

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 …

terraria networking

Personally, I couldn’t care less about Terraria, although it reminds me a bit of Zelda III back in the day, but it does have this multiplayer capability.  But it never mentions the TCP port.  Well the default port is:

7777

And if you have an Apple airport network, a teenager that needs to have ‘cut off times’ and sits 2 levels of NAT in, you’ll have to forward TCP 7777 all the way to their computer.  It’s not the end of the world but UPNP doesn’t work in nat-nat scenarios (thankfully) but the blasted game doesn’t mention when setting up a network game, oh by the way you’ll need to NAT TCP 7777.

Oh well that is all.

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)

Another day in the cloud.

So my BBS thing is down… hard.  After asking the provider ….

It appears that one of the air conditioning facility at the data centre has ceased operation and so servers are struggling with the heat. Emergency work is already being carried out.

Such is life in the ‘cloud’.

It’s times like this it’d be nice if doubletake were cheap enough for us low end users.

I suppose there is rsync, but that’d take a little work with Qemu, or would it?

Well I pulled the plug on the old place….

So now this is pretty much vacant…

If anything it’ll be interesting to see the ‘google’ fallout as I know I was indexed here, but pretty much everything I wrote showed up from the old site.  Oh well worst case I can always restore the backup.

But I’m also keeping ‘virtually fun’… I spent too many years on that one to just let it lapse out for someone to google poison the thing.

Anyways I also started to add some generic info pages on OS’s and emulators… At least it’ll be a somewhat better way to find the latest builds of Qemu or what is the current release of whatever OS…

I should have done that a while back, but as they say no better time then the present.

Pre-release versions of DOOM

On the heels of a jdosbox update, I figured it’d be cool to try ALL the early pre-release versions of Doom!  I’ve setup the links so you can click on any picture, and it’ll launch the appropriate jdosbox emulator, with the disk image.  Just click & go!

So here we go!

Doom 0.2

This is a pre-alpha version of DOOM from early February 1993 — only 2 months of work had been done to this point.

This is the first version that was made semi-public.  As you can see the HUD is the inside of the helmet.  The sky doesn’t work, but you can move around, and see the monsters from various angles..

Doom 0.4

Yes, it’s the DOOM ALPHA!  (Actually, we’re just try to release theseevery two weeks or so.  This WAS going to be a pre-beta, but a certainperson let us down Super-Nintendo cart-programming-wise, so it’s just analpha.  Nonetheless, here ’tis.)

It feels more doom like… But you can’t kill anything, and they can’t kill you… better textures and whatnot.

Doom 0.5

From the notes:

It’s an ALPHA version of doom (I just run it to make sure)called “Doom: Evil Unleashed”.  Start up screen says Doom Alpha byId Software.

It has the basic Doom engine, but:

  • It has the basic Doom engine, but
  • The imps and pink demons are in the game they don’t move or anything just stand there
  • No barrels (as noted above)
  • A lot of graphics from wolf is used (eg medic kit, gold treasure cup)
  • The map key is “a” not tab
  • The strafe and open door key are both alt
  • No sounds!
  • The two weapons you start with are (1) bayonet and (2) rifle
  • There is no run key (that I could find, so makes getting around really slow)
  • It is quite easy to recognise some of the structures in the game (so the whole map structure is now over two years old).  I can’t quote exactly were they are from but I do recognise them.
  • In the screen options there is high, medium, low, <another one>, and HIGH RES, so it looks like there use to be a high res mode that was taken out in the official release.

Doom Press Release Pre-Beta

This is the press release pre-beta version.  As you can tell from the screen shot it’s basically DOOM.  Some things are different though.  The readme is pretty long, and I think it’s better to just link it here.  I took the CPU cap off this one as it really seems to want to run FAST.  But I’m probably just screwing something up in the world of jdosbox.  But it does run, and quite nicely on my core i7.

So there you basically have it… Lots and lots of DOOM!