Belated Merry Christmas!

Sorry things have been busy @ Home & Work.

I had been thinking about doing something special for the holidays but looking around it’s a little too late.

So instead here is something nerdy from my youth, the Commodore Christmas demo diskette..   When I was lucky enough to get a C64 along with a 1541 in 1983, this was one of the bundled diskettes.

At the time I never realized how lucky I was to have the floppy drive, so many poor Europeans with their tape drives.

I hope it’s been a good holiday for everyone!

NetHack 1.3d on the x68000

Ok, I know… why? But it’s more of a why not!



So I figured since I’ve had major issues trying to get DOOM to run, I’d try something bigger, like NetHack.  I figured its a good fit, it’s all ASCII based anyways, so how complicated can it be?

Actually it turned out to not be that complicated.  Thankfully having both run68’s source and NetHack source I was able to adapt enough of the system stuff to get it running. I decided to use this build of NetHack 1.3d that has been updated to compile with modern compilers, since the cross tools use GCC 4.6.2.  NetHack 1.3d synchronized PC hack, and UNIX based NetHack enough that I could start to build under MS-DOS, and then re-target it, as Human68k and MS-DOS share a lot of features (although Human68k has support for tasks, and shared memory.  It’s more like OS/2 although no memory protection… ).

I’ve gotten it to the point where you can save, load and quit.  Oddly enough the ANSI support in Human68k isn’t as good as ansicon so it actually runs better on run68.

So my next step will be to figure out more of the console controls on Human68k, and remove the ANSI support.

Ideally I’d love to figure out how to talk to the sound drivers on the x68000.  Add some music. Maybe sound effects, and graphics?

So for anyone who cares, my source directory, binaries and a xm6 disk image is all here. I’ve seen in the cvs tree on sourceforge that run68 has some support for BSD.  That’d be another interesting thing to add, common exe’s between windows/linux.  But console access first!

WinUAE 3.0.0 released!

The biggest feature of course is…

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

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

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

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

Nothing worse than a firewall crash

So, for my email setup I use an OpenBSD firewall behind a hardware firewall (provided by the telecom), and from there I use OpenVPN to connect up to the VPS that in turn forwards email to my Exchange server.

It works great.

Except that the OpenBSD VM just crashed.  And to top it off I had no other way of accessing inwards except for some test machine that luckily was still on, and I had SSH enabled, along with port redirection.

So, a few seconds with putty and you can redirect a local port on your computer to connect to a port on the remote network.  Dangerous as hell but, it certainly can save the day! (Yes you can even SSH to a machine, and then OpenVPN to it….)

Checking VMware KB 1012382 details a list of what ports are needed by which versions of their products to do what.

ESXi 5.x,443,TCP,VI / vSphere Client, ESXi/ESX Host, VI / vSphere Client to ESXi/ESX Host management connection
ESXi 5.x,902,TCP,vSphere Client, ESXi 5.x vSphere, Client access to virtual machine consoles (MKS)

Putty port redirection

Putty port redirection

These are the two ports needed for basic checking in on the status of a standalone ESXi machine. So, in this case I can point the VMware fat client to attach to and add in redirects for TCP ports 443 & 902, which let me login, and start a remote console to see how the VMs are doing.

In later versions, you need to use a proper host name.  To set this up edit your %windir%\system32\drivers\etc\hosts file, and make sure you have something like this:       localhost esxiloop

And then point the client to esxiloop, and it ought to connect.

Tracking down the InfoTaskForce from 1987.

So like all zork obsessed people (I really should get help or something), I was trying to build a z-machine interpreter for the x68000, using Lydux’s cross GCC compiler.  And it was honestly looking like a LOT of work in the IO department.  Thinking that the older versions were more simpler, I went looking for the oldest open Z-machine, called the “The InfoTaskForce Infocom interpreter”, released by the InfoTaskForce.  Unfortunately I can only find version 4.01 searching for the source code.  Which still looks too complicated.  But looking the history file, the project started back in 1987.  So with that to go on a new google search got me this:

Infocom Adventure Executor Source Files (1987)(InfoTaskForce)[C].zip

From an TRS-80 dump of all things.  I don’t know what version this is other than the brief copyright mention:

/* (C)opyright 1987 InfoTaskforce. */

All of the files are dated 4/12/2001 so they obviously aren’t original. And the version string is:

echo ( “Interpreter: C Version 1.0\n” ) ;

So assuming this is correct, from the 4.01 history file:

REV_E – June 25, 1987.

REV_E is the first major overhaul to the interpreter.

* The source is now significantly lint free.

* TERMCAP support has now been added [#define TERMCAP option].

* Screen paging and word wrap has been added, along with a new
command line option which disables screen paging (-p).

* Random number generator seeding using time () added [#define
TIMESEED option].

* Attributes in the object list are listed as bits.

* A debuging version can now be produced as an inbuilt options
[#define DEBUG option].

* The coded requirement that 25k is always free in the system can
now be removed [#define ALLOCALL option].

* A new command line option was added to print the object/room list
as a tree (-r).

* interp.c has been re-written to improve efficiency [large
switches have been replaced with arrays of pointers to funcions].

There are now 14 machines on the porting list:

Machine C Compiler Operational Porting details

128K Apple
Macintosh Aztec C Version 1.06F 18/05/87

128K Apple
Macintosh Lightspeed C 2.01 29/05/87 Use “rb” & “wb” in all fopen()s

IBM PC/AT Microsoft C 4 30/05/87 Link with binmode.obj

DEC VAX 11/780 UNIX V7 cc 01/06/87

HP-9000 HP-UX cc 02/06/87

gould cc 03/06/87

Amiga Aztec C 04/06/87

Pyramid 9810 cc 04/06/87

Pyramid 90x cc 04/06/87

Osiris cc 05/06/87

DEC PDP-11/? UNIX V? cc 07/06/87 EXTENSIVE
mods to fix problems with signed chars.

VAX VMS cc 16/06/87 Add #define
times ttmes to fix multiply defined symbol problem. [infocom.h]

Version 1.00 – August 17, 1987.

The REV_C interpreter of June 2, 1987 was officially archived as
Version 1.00 on August 17, 1987.

So this means it’s very 16bit & 32bit friendly, especially on BIG endian machines like the 68000 processor.

Luckily this older version is pretty trivial to compile, and get running.  But I was over thinking the build process and decided to strip the executable as GCC would kick out a 500kb file, which objcopy would extract a 81kb executable.  Stripping it brought the size down to a 50kb executable but it wouldn’t run in either xm6 or run68.  I ended up going in circles for a while trying to find fault in what is broken where until I manually compiled the interpreter, and omitted the strip step and suddenly had a working interpreter.

Now there is one issue, saving doesn’t work.  Something in the libc is having issues using fopen with a file to write.  Reading works perfectly fine though.  So to fix it, I went ahead and redid the save feature to use the HumanOS native _open/_write/_close functions and I’m able to now save & restore a game.

D:\proj\run68\test>run68.exe infocom.X minizork.z3
MINI-ZORK I: The Great Underground Empire
Copyright (c) 1988 Infocom, Inc. All rights reserved.
ZORK is a registered trademark of Infocom, Inc.
Release 34 / Serial number 871124

West of House
You are standing in an open field west of a white house, with a boarded front
door. You could circle the house to the north or south.
There is a small mailbox here.

West of House Score: 0/0
Filename: mz1.sav

Living Room Score: 10/19
You have:
A nasty knife
A rope
A sword
A brass lantern (providing light)
A brown sack
A glass bottle
The glass bottle contains:
A quantity of water
A leaflet

Living Room Score: 10/20

In this process I’ve also managed to build run68, and verified that it’s operating correctly, as both run68 and XM6 both failed to write to a file with fopen, and both work using the native calls.

Planetfall on a x68000

Planetfall on a x68000

I’m sure most people won’t care but I think it’s great having the ability to run a GCC generated C program in a relatively small interpreter.

If anyone cares, here is my updated cross compiler + run68 source along with tweaked Info Task Force 1.0 source.  Or a disk image that XM6 can boot up, and run some demo programs from Infocom of ages ago.

Cross compiling to i386 Linux ELF from OS X

This isn’t terribly useful for 99.9% of the people out there but I needed to do something creative on an F5.  Luckily they run a somewhat sane version of Linux.

Unfortunately I am stuck on Windows 10 right now, so installing a matching Linux distro is out of the question.  So on my OS X box, I thought I’d just build a cross compiler.  Going back to my DJGPP cross compiler, I thought I’d stick with binutils 2.9.1 and gcc 2.95.3, since they worked so well before.

Plus to flesh it out, you’ll want libc, libg++, and the appropriate Linux includes.  I took all of these from Slackware 3.3 since it’s from around that era.

So on the plus side this cross compiler + library set , will crank out static ELF executables, which makes running things on alien platforms all the better.

On the realistic side, I doubt anyone will need it, but here it is.

Clang didn’t want to build anything this old, but luckily that backported GCC-4.2 has no issues.

As part of DOOM’s 21st birthday, John Romero releases some unused ART

It’s on his twitter account.

Some of my favorites:

This pic was taken for an interview in 1994 while making DOOM II. Jay, Adrian, Bobby, Kevin, John, me in front.

This pic was taken for an interview in 1994 while making DOOM II. Jay, Adrian, Bobby, Kevin, John, me in front.

This original DOOM II box cover was painted by Julie Bell. The Cyberdemon didn't look right so we switched to BROM

This original DOOM II box cover was painted by Julie Bell. The Cyberdemon didn’t look right so we switched to BROM

Here are Adrian's scans from his sketchbook for various screens, pre-pixel edit

Here are Adrian’s scans from his sketchbook for various screens, pre-pixel edit

I would normally link to the jdsobox stuff so you can check out Doom in a browser, but Oracle has successfully screwed up Java so badly that it’s a nightmare to get any 3rd party applets to run.

I suppose as a consolation there is a javascript version of DOSBox, jsdosbox.

Jsdosbox with DOOM

Jsdosbox with DOOM

And it has DOOM!

Virtual Printers

So I got this SPAM today.. Ebay now tracks if you’ve clicked on anything (even when not signed in) and will alert you (and the seller no doubt) that something is price reduced.

Ebay at it's worst.

Ebay at it’s worst.

I was looking at some old setup, and I remembered back in the 80s I had an Okimate 10 printer.  It was without a doubt the worst printer I’ve ever used.  Not only was it god awfully slow, it required special ink cartridges that were almost impossible to find (and if you did they were very expensive) but to print properly it required special glossy paper.

The 10's test page

The 10’s test page

And if you hit the wrong button on the printer, you’d get this fabulous test page. Over and over. Ugh.  It banded a full Yellow/Magenta/Cyan stripe on every pass.  If you got 10 pages out of a ribbon it was amazing.  But on my nostalgic trip to remember how badly this printer sucked, I found a Virtual OkiMate 20!  It’s a javascript program of all things, that’ll interpret the graphics output of an OkiMate 20 dump file.

Test file from an Amiga

Test file from an Amiga

The test image is a picture from an Amiga Workbench.  It’s immediately recognizable.  But what is really cool, if you scroll down you’ll see something like this:

How the Oki works

How the Oki works

And here you can see how the OkiMate 20 was busy devouring a colour band from it’s virtual cartridge.

Peter has quite a few virtual printers on his blog, The one that caught my eye was the Epson JX-80.  Windows NT supports that printer (probably many other OS’s but I was going to stick with something quick and easy).  I took my 10 crash screen, and printed it out!

Printing from Windows NT 4.0 at 120x144

Printing from Windows NT 4.0 at 120×144

Pretty cool!

For some reason the printer emulator only is printing in monochrome, it’ll interpret the colour bands, but it doesn’t switch ink colours.  I guess it automagically is doing that.  Also I had to change the default Windows resolution of 144×240 to 144×120, to get it to print.

Of course if you wanted to the best thing to do is install an Apple Laser Write II printer, and have it output to a file, as they are PostScript printers.  Then you can use ghostscript to convert your postscript file to a PDF, and print that email it, or remember what a pain write only devices are.

As an update you can download all of the printer emulators from the authors blog