The laptop I’m using at the moment is old, Alienware 14 P39G that is 5 years old. The power is convinced that it can’t run over 700Mhz unless it’s on battery for some reason, then it’ll jump to 2.3Ghz just fine. Oh well It’s otherwise not bad, just getting old.
Also it’s only using the Intel GPU. I think I need to do a fresh install of the 2018 version of Windows 10 on this thing.
Anyways so CXBX Reloaded can run many xbe’s directly so you don’t need a ROM or dashboard, but it’ll run the dashboard if you have it. It’s really cool though as JSRF did come to Android but it won’t run on any modern versions of Android. As far as I know it never came to PC, but being able to run the X Box version is certainly cool.
Sourcecode & nightly binary builds are currently on github:
As you can read right now It’s running a simple OpenWatcom 16bit hello world based program. The 16bit OS/2 and 32bit OS/2 API’s ended up having different calling sizes, among other issues which had complicated the bridge program. However Ryan’s newer use of scripts to generate the required glue for the API’s at least mean that adding the 16bit/32bit calling conventions & required bridges/glue is at least now automated.
This is super cool, as this will eventually open the door to Watcom C/Fortran, Zortec C, Microsoft Basic/C/Cobol/Fortran and of course many other languages that burst out into the initial OS/2 scene before the eventual weight of the SDK & associated costs doomed OS/2 to failure.
Seriously, for those among us who love OS/2 and have like $5 to spare, send some encouragement to Ryan… 🙂
So this is really super cool! Ryan C. Gordon has written a Wine like program to run OS/2 programs!
Using 32bit Linux, and some native libraries, 2ine can load up an LX (32bit) executable and try to run it under Linux, much in the same way that Wine can run Windows programs. And yes it’ll run EMX built stuff. Although keep in mind the original Microsoft based languages, programs and tools is all 16bit. After the whole Windows 3.0 thing and the split of Microsoft from the OS/2 project all their tools are either 16 bit, or 32bit LE format, which IBM had dumped for the LX format once OS/2 2.0 had shipped.
You can read about his incredible progress, and all the trials and tribulations of running OS/2 programs, along with the craziness that is thunking back and forth to the 16bit space for the old VIO calls that had never were updated to 32bit in that transition phase where a good chunk of OS/2 never was updated from 16bit, over on his patreon page here.
Attempting to run anything 16bit or LE will give you:
At End Of Road Score: 36/0
Welcome to Adventure! Do you need instructions? (y/n) >n
A Modern Classic
Based on Adventure by Willie Crowther and Don Woods (1977)
And prior adaptations by David M. Baggett (1993), Graham Nelson (1994), and
Adapted once more by Jesse McGrew (2015)
Release 1 / Serial number 151001 / ZILF 0.7 lib J3
At End Of Road
You are standing at the end of a road before a small brick building. Around you
is a forest. A small stream flows out of the building and down a gully.
At End Of Road Score: 36/0
Again it’s works so well it’s amazing!
You can find the 2ine source over on icculus.org here. I had to tweek the heck out of the CmakeList.txt to get it to build, and since I was interested in the command line, I ended up disabling all the SDL / PM stuff, and make sure I had the ‘wide/unicode’ version of ncurses installed.
I don’t think there really was any killer 32 bit OS/2 applications, but with clean room versions of:
Not to mention being able to call into Linux DLL’s and using ‘clean’ OS/2 DLL’s would let you embrace and extend OS/2.. Or maybe even let you build the proverbial fantasy of both RISC & 64 bit OS/2. …..
So what this means is that now you can make fully standalone Win32/Win64 executables out of CLI based MS-DOS applications.
D:\tcc>msdos\binary\i486_x64\msdos.exe tcc -Iinclude -Llib hi.c
Turbo C++ Version 3.00 Copyright (c) 1992 Borland International
Turbo Link Version 5.0 Copyright (c) 1992 Borland International
Available memory 4215648
D:\tcc>c:msdos\binary\i486_x64\msdos.exe -c hi.exe
‘new_exec_file.exe’ is successfully created
Isn’t that great?
I’ve had one issue with Turbo C++ 3.00 and that is the embedded executable will run out of memory while linking, but invoking it by calling msdos.exe let’s it run fine. If you compile and link separately it’ll run just fine.
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.
I read somewhere that kids these days are interested in games where you can modify how the game operates with sub programs written in their own languages etc.
So while this does sound interesting, it does remind me of that good old fashioned syscall emulation, where you emulate the CPU, load an executable, but any system calls that are made, are handled by the simulator, little if any hardware is actually emulated. Yes Basilisk II is an example of this, but so is Wine, WOW, NTVDM, i386 code on x64 platforms, and various others. The major advantage is that they typically can access your native file system so you don’t have to mess with virtual disks. Of course it all depends on the implementation.
I did remember this old simulator, Apout, which could run UNIX v6, 7 along with BSD 2.9 stuff on modern Unix. The emulation layer here being LIBC, and how pretty much the basics of how UNIX operates hasn’t changed since those ancient days in the 1970’s.
So I thought I’d try to see how much of this works on Win32 using Microsoft Visual C++ 5. And surprisingly I didn’t have to glue in that much, the biggest thing I had to do was trying to detect if a file about to be opened was ASCII or BINARY as the UNIX platform doesn’t distinguish these two but Win32 with it’s MS-DOS legacy does. As you can see I did get the banner program running, some of the games work ok, although I had to comment out the sgtty functions as there is no immediate equivalent on Windows, and I didn’t think there would be that much of a demand for such a thing anyways. I can even run the login program. Which brings me to the issue which is that it’ll spawn new programs fine, but when an exit is called Apout just exits. Even on Linux it’ll just do this. I tried doing something with setjmp/longjmp but it crashes shortly afterwards… No doubt some stack unwinding fun. As such trying to compile things just bomb out. I went ahead and took the source code to cc and made a native Win32 version that then calls apout for the various parts and that almost worked except I then found out that the assembler on the PDP-11 is a 2 pass assembler, written in assembly. And yes, when as calls as2, and unwinds all hell breaks loose. Which is another problem that UNIX likes to share file descriptors among itself and children, but children like to close things when they die. I guess the solution is to give each child it’s own descriptor table as everyone likes to close stdin/stdout/stderr and even #4, which the simulator uses for logging. it’s very annoying so I just prevented it from closing handles under 4.
But running each of the phases manually does get me an executable but it doesn’t seem to do anything, the only syscalls are closing all the file handles and exiting.
I don’t think anyone will care, but here is my source/binary along with Unix v7. It’s hard coded to dump stuff into c:\temp for temporary files, the Unix v7 must be in c:\v7 … ugh.
But yeah, you can play that thrilling game from 1979, hunt the wumpus!
Wow this was without a doubt one of the more confusing things I’ve ever done.
So here is the problem. I want to delete some files from an IMD disk image, and then copy some new ones in. Easy right? .. maybe.
Ok first up the easiest tool I’ve found to manipulate CP/M disk images is cpmtools. Even better their pre-compiled binary is for Win32, so I’ll run it with Wine on OS X. which works fine. Although there is one slight problem, cpmtools doesn’t read the IMD disk format. So you will have to download imd118.zip from a backup of the late author’s computer.
Now using IMD you need to convert the OS disk into a ‘raw’ or ‘binary’ file. Naturally IMD is a MS-DOS program so firing up DOSBox, I ran:
IMDU CPM68K12.IMD CPM.RAW /B
And a few seconds later I had my raw file. Now the next thing was to manipulate the image in cpmtools. cpmtools has a database of disk drive types, and naturally there is no definition for the SAGE2. However thanks to a friend of mine (hi Lorenzo!) I took at look at 22disk, and found their demo version did in-fact have a definition for the SAGE:
BEGIN SAG2 Sage IV – DSDD 96 tpi 5.25″
SIDE1 0 1,2,3,4,5,6,7,8
SIDE2 1 1,2,3,4,5,6,7,8
BSH 4 BLM 15 EXM 0 DSM 315 DRM 63 AL0 080H AL1 0 OFS 2
Which is great, however it took a bit of experimenting to work out how to format this information for cpmtools. I compared a bunch of known formats, and then managed to work this out:
So I tidy up the image, and copy it back to the IMD program for compressing. And this was, without a doubt the most difficult to figure out, until after a bunch of searching, and Lorenzo once more again pointed me in the direction of bin2imd
BIN2IMD X.RAW X.IMD DM=2 N=80 SS=512 SM=1-8 /2
And the best part is that it worked! So now I was able to transfer over a binary version of com.68k, com2.68k, along with Zork, and fire it up!
Unfortunately the interpreter doesn’t work right. It could be the disk transfers fault, maybe the SIMH SAGE emulator, or even the 8080 emulator. But it worked this far.
Which.. isn’t right enough. I’m not sure what is up with dir.php ..
Oh well, I was able to build a simple hello world type program, but anything that hopes to pull data off the drive won’t work. If anyone thinks they can do better my archive of all the bits is here (48MB), and the ‘runnable’ version is here .. hi is about as much fun as it’ll get.
I know that there is some people out there that seem to be all into Xenix, and old binaries… So I thought I’d share this little gem I found before I head out for the day… I came across this post, talking about how ibcs2 has fallen apart in the latest version of NetBSD. But the gem in there is that version 4.0.1 works perfectly fine!
So I copied in the old gcc, filled in some bits and….
Robots is so perfect you’d never know!
And it runs Xenix Dungeon/Zork without missing a beat!
So this may be yet another avenue for some people… I’d suspect that you could even build the 32v userland under the Xenix tools…? Since all the default stuff is keyed to licensing, but you could roll your own Unix v7 32bit userland which basically is Xenix and go from there…. Maybe even some of the OpenSolaris SYSVR4 stuff as well but that sounds too ambitious!