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?
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.
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.
[table “” not found /]
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 127.0.0.1, 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:
127.0.0.1 localhost esxiloop
And then point the client to esxiloop, and it ought to connect.
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’scross 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:
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
* 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
Macintosh Aztec C Version 1.06F 18/05/87
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
Living Room Score: 10/19
A nasty knife
A brass lantern (providing light)
A brown sack
A glass bottle
The glass bottle contains:
A quantity of water
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.
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.
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.
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.
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 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:
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!
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 ptouchman.weebly.com