With a 16Mhz 80386 it took 70 minutes. I just formatted a blank image on the gotek, copied IO.SYS, MSDOS.SYS and COMMAND.COM, then rebooted. went back to the compiled DOS 4, and re-formatted the floppy as a system disk so the attributes are set. (DOS 5 lets you change system files), and yeah. It can be done!
Let me spell out the steps, in this case I’m going to use Windows 10. I use the git from the WSL (Windows subsystem for Linux) I have DOSBox mount c:\dos as my c: drive . ZIP/UNZIP are Info-ZIP versions, you MUST have the Win32 native version!
- md \dos
- md \dos\temp
- wsl git clone https://github.com/microsoft/MS-DOS
- cd MS-DOS\v4.0
- zip -r \dos\temp\src.zip src\*.*
- cd \dos
- unzip -a -LL temp\src.zip
- start dosbox
- cd \src
- edit setenv.bat to reflect the paths:
set BAKROOT=c:
set LIB=%BAKROOT%\src\tools\bld\lib
set INCLUDE=%BAKROOT%\src\tools\bld\inc
set PATH=%PATH%;%BAKROOT%\src\tools
- setenv
- nmake
it will then fail in mapper on getmsg.asm change the 3 chars to a '-'
- nmake
- cd ..
- nmake
continuing from dosbox, you need a 1.44mb fat formatted disk image somedos144.img . I used a dos 6.22 diskette, it needs the bootsector already in place to load io.sys/msdos.sys
- cd \src
- md bin
- cpy bin
- imgmount a somedos144.img -t floppy
- a:
- del *.*
- copy c:\src\bin\io.sys
- copy c:\src\bin\msdos.sys
- copy c:\src\bin\http://command.com
- boot -l a:
And now I’ve booted MS-DOS 4.00 from within DOBOX!
Also as interest to most people there is a bug in msload.asm, where DOS 4.0 won’t boot on a lot of machines, from VMware, Qemu and even my PS/2. It’s a small fix to the IO.SYS initial stack being too small. Props to Michal Necasek for the fix!
For further guidance here is a video spelling it all out:
Don’t get me wrong, it’s a very 1980’s awesome machine. Aesthetically. But practically? No way, it’s a legit white elephant. And it killed OS/2 before it even became a thing. I know what about the JDA, and IBM interference? What about the poor choice of the 80286 processor? What about DOS Extenders? YES it’s all there, Half an Operating System, for Half a computer, the real reason OS/2 failed, and it’s wrapped up in a 20 x 8 x 18 inches package weighing in at 40 pounds.
Behold the IBM PS/2 model 60.
The PS/2 model 60 from the OS/2 1.0 brochure
The base model PS/2 60 with the 44Mb hard disk was priced at an eye watering $5,925 in 1987. And to be clear that is with only has ONE megabyte of RAM which is nowhere near enough to even boot OS/2. Realistically, you would need the additional memory card, and another 4MB of RAM, raising the price far higher, as stated in the requirements for the sales demonstration of OS/2.
The realistic OS/2 requirements, 5MB of RAM!
The 77Mb disk system would set you back $6,295, again not counting the needed memory upgrades.
It’s BIG, loud, expensive, and more importantly obsolete on day one.
Going back, to the original success of the IBM PC and it’s open architecture lead to the one big issue, which is that it was trivial for people to clone, as they published everything you’d want to know in their technical reference manuals. The one thing that was copywrite was the BIOS. However as I’m sure everyone heard the story of how Columbia Data Products released the MPC 1600, which set the gold standard on reverse engineering, but opened the floodgates to bigger players like Compaq, and ushered in the clone revolution.
IBM was obviously not happy with this. IBM always looked to hardware for money, and IBM build quality, and of course that lead us to the PS/2. There is no way they could have developed this in the space of a year, which again if it took 2-3 years to bring them to market, it would explain so many of the missteps of the Model 30 which both had an ISA bus, and had either an 8086 or 80286 processor. This may have been okay for 1985, but they were far too old & slow for 1987. Many people have cited that part of the PS/2 revolution was the new bus on the model 60/80 Microchannel which unlike ISA had to be licensed from IBM, but of course it didn’t catch on, instead it gave confidence to the industry to not only set out on their own 386 machines, but then their own 32bit bus EISA. Yet another reason the 8086/80286 machines should never had existed.
$5,795 MSRP for the IBM AT – InfoWorld 3 Dec 1984
Looking back to December of 1984 we can see the MSRP for the 6Mhz IBM AT was $5,795, the AT model 099 included a whopping 20MB hard disk, a single high density 1.2MB 5 1/4″ floppy drive, and 512kb of RAM. Now jump forward a few years, and every clone manufacturer has benefited from economies of scale as the commodity parts increase of demand and sourcing has only led to lower prices. Except for IBM. While the Model 60 does have twice the RAM going up to a base configuration of 1 megabyte, and a 44MB hard disk, the price is $6,995 or a 20% price increase!
What lead to this massive stagnation from 1985 to 1987? I’m sure it has almost everything to do with Don Estridge’s untimely death in 1985. I can’t imagine IBM releasing an XT years later with the same design language as the new ‘powerful’ machines, no doubt just fooling consumers into thinking they are ready for the 1990’s when instead, it’s a product more akin to 1982.
IBM PS/2 models at a glance – InfoWorld 6 Apr 1987
From Infoworld 1988:
On the one hand, IBM has shipped nearly 2 million PS/2s in the year since the machines were introduced. The Model 50 is currently the best-selling microcomputer in the industry a position it has held since November 1987, according to market research firm Store-board Inc. What makes these figures even more significant, say analysts, is that many of the alleged benefits of the PS/2 have yet to be fully exploited.
Although there was certainly an initial corporate interest in the PS/2’s IBM did not keep up with faster Intel CPUs quick enough and failed to keep up interest in the base models, leading to significant price cuts in the spring of 1988.
Drastic price cuts – InfoWorld 18 Apr 1988
Time and time again you’ll hear how there was no software poised to take charge of these 286/386 models, and there was no compelling reason to do so. And it’s why it was such a big mistake to not have allowed Microsoft to being GDI to OS/2 along with it’s working drivers & applications to have shortened development time to get them to market. By shipping these expensive premium machines without OS/2 (normal users don’t change operating systems), and the double slap insult being that none of these machines are capable out of the box of running *any* version of OS/2 it’s not hard to see why it failed.
Okay so the PS/2 was too expensive!
Actually, it was too cheap! They should have not bothered with the new look XTs it only created branding confusion, and really all 286/386 equipped models should have been able to run OS/2, with no upgrades needed. I can’t imagine anyone would be happy after spending six plus thousand on a new machine to only find out that to run the OS of the future, you need to spend a few more thousand.
Windows was irrelevant in 1987!
There is no doubt that being able to run Windows applications natively on OS/2 would have only helped it tremendously, as OS/2 would be the ‘professional’ version of Windows. Although OS/2 did achieve this through paravirtualization, having GDI/USER native to OS/2 would have consumed far less ram as you wouldn’t need to load two windowing environments at once!
While Balance of Power may not have been the #1 chart topper, it was one of the first commercial games for Windows (Maybe it was the first?), showing that instead of developing UI code & drivers, that even a run-time platform was a viable choice.
v86 mode was too difficult and it delayed OS/2 2.0 for years!
What if I told you that there is FOOTBALL & PIGSKIN? Granted they are text mode, but they absolutely incorporate v86 mode into what is basically OS/2 1.0. In 1987. Why was there no OS2/386? Yeah. IBM.
Instead, all the 1.x versions of OS/2 had a SINGLE MS-DOS box, or penalty box, even the 386 has the single DOS session limitation. So if your work flow was stuck to a single DOS session what compelling reason would there be to upgrade to OS/2? NONE. Speaking of 1987 however there was Windows/386 towards the end of the year.
Windows/386, is the friendliest glance into today’s future (Think of it as a graphical hypervisor, like VMware/KVM). Windows was the one environment where Microsoft didn’t need IBM’s permission to do anything, or adhere to any other standards, Microsoft added v86 support into Windows, and it brought mainframe power to the average user, by allowing them to create virtual machines running their own isolated MS-DOS applications, and even allowing copy/paste of data from between them, and into new Windows applications. While Windows 2 was a shadow of what would become the Windows 3.0 juggernaut of 1990, it was quickly headed in the right direction.
What is it with the 386 anyways?
And why were they so adverse to the 386? the 1st gen Model 80 motherboard feels more like a begrudging reaction to Compaq rather than what it should have been by the time they released the 3rd – 25Mhz version, with onboard cache controller & ram. Beyond v86 mode, there was the large memory space, and 32bit registers making it possible to port minicomputer (and even mainframe) programs to the PC. Was this desktop future too scary for IBM? Did they really thing that by refusing to adopt the 386 that they could somehow influence the rest of the market to not being 32bit computing to the masses? Even in the early 80’s there was the Definicon, a NS32016 cpu board you could plug into your IBM PC and unleash a programmable 32bit processor with upwards of 2MB of RAM. If IBM was not going to make a 32bit computer, others would find a way, utilizing the ever-increasing supply of open PC hardware.
As far as I can tell IBM didn’t even permit Windows/386 or any version of Windows to be bundled or shipped with the PS/2’s further alienating them from the growing market of software. And of course, by not increasing the RAM the pre-loaded operating system was still PC-DOS, not OS/2. It really shakes confidence when IBM won’t even preload their jointly developed Operating System of the future.
Then along came Windows.
While Windows 3.0 was fine enough running in 16bit protected mode on both the 286 & 386, having the ability to launch v86 machines, and take advantage of hardware paging of the 386 on Windows 3.0. At least you were 2/3rds of the chip’s capabilities, unlike OS/2 1.x where you used none.
There is money in those developer hills!
Time and time again, this has been one of the industry’s biggest failings. Just as IBM charged a fortune for SDK’s and DDKs all it did was raise the bar so high very few people paid for them, strangling the supply of apps & drivers.
InfoWorld 6 Apr 1987
While the PS/2’s were very expandable, it seems outside of collectors, very few are. Which again speaks to why it was so important to get that initial pre-loaded configuration right. And you control that with the pre-load, just as Apple forced the wedge by first loading OS X onto machines, then making it the default. At best with Warp IBM pre-loaded it on many devices, but users were oblivious that it was even there. It was more than once I’d seen someone buy a retail copy of Warp, to run this OS/2 thing to only find out their ThinkPad already had a copy.
$3,000 a bargain!
The prices to get started with technical information, the toolkit and a compiler may seem expensive, but compared to the infamous $3,000 SDK & seminars.
Instead, developers should have been given copies for free, or even back then, on the MSPL. While the Microsoft Programmer’s Library is an invaluable resource, the lack of tools is just odd. Why even have slack space on those early CD-ROMs?
No doubt all the painful lessons were learned from OS/2 for Windows. Just as Windows NT ended up being everything NTOS/2 3.0 was going to be.
So yeah, really it was the PS/2 Model 60?
Bringing out a super expensive 16bit machine in 1987, holding Microsoft back in every technical way possible, along with all the poor choices revolving around IBM’s fear of the 386, and the 32bit future doomed OS/2 before it even began.
At best the 8086/80286 machines should have been cheap machines for MS-DOS present, but again the outlier is the PS/2 Model 60. Far too expensive with no real compelling reason to buy one – Don’t get me wrong I love mine! But it’s incredibly impractical.
If anything, once more again, OS/2 1.x should never been a thing, it performs terribly on 286’sand the single 3xdos session is just painful. With its heavy requirements, it always should have been targeting the 386, and the brave future of 1987 onwards, not 1984, and certainly not the PS/2 model 60, which never should have existed.
Hamstringing OS/2 to the $6,995 PS/2 model 60 in 1987 doomed it all from the start. It never stood a chance.
Originally with all the buildup of compilers & GCC ports to OS/2, I had a small goal of getting Sarien running on OS/2. I did have it running on both a 286 & 386 DOS Extender, so the code should work fine, right?
To recap, years ago I had done a QuakeWorld port to OS/2 using the full screen VIO mode, a legacy hangover from 16bit OS/2. It works GREAT on the released 2.00 GA version. I went through the motion of getting the thunking from 32bit mode to 16bit mode, to find out that it doesn’t exist in the betas!
No VIO access from 32bit
So that meant I was going to have to break down and do something with Presentation Manager.
So the first thing I needed was a program I could basically uplift into what I needed, and I found it through FastGPI.
Donald Graft’s FastGPI
While it was originally built with GCC, I had rebuilt it using Visual C++ 2003 for the math, and the Windows NT 1991 compiler for the front-end. As you can see it works just fine. While I’m not a graphical programmer by any stretch, the source did have some promise in that it creates a bitmap in memory, alters it a runtime, and blits (fast binary copy) it to the Display window. Just what I need!
for (y = 0; y < NUM_MASSES_Y; y++)
{
for (x = 0; x < NUM_MASSES_X; x++)
{
disp_val = ((int) current[x][y] + 16);
if (disp_val > 32) disp_val = 32;
else if (disp_val < 0) disp_val = 0;
Bitmap[y*NUM_MASSES_X+x] = RGBmap[disp_val];
}
}
It goes through the X/Y coordinate plane of the calculated values, and stores them as an RGB mapping into the bitmap. Seems simple enough right?
DosRequestMutexSem(hmtxLock, SEM_INDEFINITE_WAIT);
/* This is the key to the speed. Instead of doing a GPI call to set the
color and a GPI call to set the pixel for EACH pixel, we get by
with only two GPI calls. */
GpiSetBitmapBits(hpsMemory, 0L, (LONG) (NUM_MASSES_Y-2), &Bitmap[0], pbmi);
GpiBitBlt(hps, hpsMemory, 3L, aptl, ROP_SRCCOPY, BBO_AND);
DosReleaseMutexSem(hmtxLock);
It then locks the screen memory, and then sets up the copy & uses the magical GpiBitBlt to copy it to the video memory, then releases the lock. This all looks like something I can totally use!
I then have it call the old ‘main’ procedure form Sarien as a thread, and have it source the image from the Sarien temporary screen buffer
And WOW it did something! I of course, have no keyboard, so can’t hit enter, and I screwed up the coordinates. I turned off the keyboard read, flipped the X/Y and was greeted with this!
Welcome to OS/2 where the memory is the total opposite of what you expect.
And it’s backwards. And upside down. But it clearly is rendering into FastGPI’s gray palette! I have to admit I was really shocked it was running! At this point there is no timer, so it runs at full speed (I’m using Qemu 0.80 which is very fast) and even if there was keyboard input it’d be totally unplayable in this reversed/reversed state.
The first thing to do is to flip the display. I tried messing with how the bitmap was stored, but it had no effect. Instead, I had to think about how to draw it backwards in RAM.
{
for (x = 0; x < NUM_MASSES_X; x++)
{
disp_val = ((int) screen_buffer[y*NUM_MASSES_X+x] ); //+ 16);
if (disp_val > 32) disp_val = 32;
else if (disp_val < 0) disp_val = 0;
Bitmap[((NUM_MASSES_Y-y)*(NUM_MASSES_X))-(NUM_MASSES_X-x)] = RGBmap[disp_val];
}
}
Running in the correct orientation
Now comes the next fun part, colour.
I had made the decision that since I want to target as many of the OS/2 2.0 betas as possible they will be running at best in 16 colour mode, so I’ll stick to the CGA 4 colour modes. So the first thing I need is to find out what the RGB values CGA can display.
So now it’s looking right but there is no timer so on modern machines via emulation it runs at warp speed. And that’s where OS/2 shows its origins is that it’s timer ticks about every 32ms, so having a high resolution timer is basically out of the question. There may have been options later one, but those most definitively will not be an option for early betas. I thought I could do a simple thread that counts and sleeps, as hooking events and alarms again suffer from the 32ms tick resolution problem so maybe a sleeping thread is good enough.
And it crashed. Turns out that I wasn’t doing the threads correctly and was blowing their stack. And somehow the linker definition file from FastGPI kept sneaking back in, lowering the stack as well.
The next big challenge came of course from the keyboard. And I really struggled here as finding solid documentation on how to do this is not easy to come by. Both Bing/google want to suggest articles about OS/2 and why it failed (hint it’s the PS/2 model 60), but nothing much on actually being useful about it.
Eventually through a lot of trial and error, well a lot of errors I had worked uppon this:
case WM_CHAR:
if (SHORT1FROMMP(parm1) & KC_KEYUP)
break;
pm_keypress=1;
switch (SHORT1FROMMP(parm1))
{
case VK_LEFT:
key_from=KEY_LEFT;
break;
case VK_RIGHT:
key_from=KEY_RIGHT;
break;
case VK_UP:
key_from=KEY_UP;
break;
case VK_DOWN:
key_from=KEY_DOWN;
break;
case KC_VIRTUALKEY:
default:
key_from=SHORT1FROMMP(parm2);
break;
}
I had cheated and just introduced 2 new variables, key_from, pm_keypress to signal a key had been pressed and which key it was. I had issues mapping certain keys so it was easier to just manually map the VK_ mapping from OS/2 into the KEY_ for Sarien. So it triggers only on single key down events, and handles only one at a time. So for fast typers this sucks, but I didn’t want to introduce more mutexes, more locking and queues or DIY circular buffers. I’m at the KISS stage still.
I’m not sure why it was dropping letters, I would hit ‘d’ all I wanted and it never showed up. I then recompiled the entire thing and with the arrow keys now mapped I could actually move!
Roger walks for the first time!
And just like that, Roger Wilco now walks.
From there I added the savegame fixes I did for the 286/386 versions, along with trying to not paint every frame with a simple frame skip and…
Sarien for OS/2 running at 16Mhz
And it’s basically unplayable on my PS/2 model 80. Even with the 32bit XGA-2 video card.
I had to give it a shot under 86Box, to try the CGA/EGA versions:
CGA
It’s weird how the image distorts! Although the black and white mapping seems to work fine.
Sarien on EGA
I should also point out that the CGA/EGA versions are running on OS/2 2.0 Beta 6.123, which currently is the oldest beta I can get a-hold of. So at the least I did reach my goal of having a 32bit version for early OS/2.
I would imagine it running okay on any type of Pentium system, however. So, what would the advantage of this, vs just running the original game in a dos box? Well, it is a native 32bit app. This is the future that was being sold to us back in 1990. I’m sure the native assembly that Sierra used was far more efficient and would have made more sense to just be a full screened 16bit VIO application.
So how long did it take to get from there to here? Shockingly not that much time, โ 02/20/2024 6:02 PM for running FastGPI, to โ 02/20/2024 10:56 PM For the first image being displayed in Presentation Manager, and finally โ 02/21/2024 10:39 PM to when I was first able to walk. As you can see, that is NOT a lot of time. Granted I have a substantially faster machine today than what I’d have in 1990 (I didn’t get a 286 until late 91? early 92?), compiling Sarien on the PS/2 takes 30-40 minutes and that’s with the ultra-fast BlueSCSI, compared to even using MS-DOS Player I can get a build in about a minute without even compiling in parallel.
I think the best way to distribute this is in object form, so I’ve created both a zip & disk image containing the source & objects, so you can link natively on your machine, just copy the contents of the floppy somewhere and just run ‘build.cmd’ which will invoke the system linker, LINK386 to do it’s job. I have put both the libc & os2386 libraries on the disk so it should just work about everywhere. Or it did for me!
So that’s my quick story over the last few days working on & off on this simple port of Sarien to OS/2 Presentation Manager. As always, I want to give thanks to my Patrons!
So, with a renewed interest in OS/2 betas, I’d been getting stuff into the direction of doing some full screen video. I’d copied and pasted stuff before and gotten QuakeWorld running, and I was looking forward to this challenge. The whole thing hinges on the VIO calls in OS/2 like VioScrLock, VioGetPhysBuf, VioScrUnLock etc etc. I found a nifty sample program Q59837 which shows how to map into the MDA card’s text RAM and clear it.
It’s a 16bit program, but first I got it to run on EMX with just a few minor changes, like removing far pointers. Great. But I wanted to build it with my cl386 experiments and that went off the edge. First there are some very slick macros, and Microsoft C just can’t deal with them. Fine I’ll use GCC. Then I had to get emximpl working so I could build an import library for VIO calls. I exported the assembly from GCC, and mangled it enough to where I could link it with the old Microsoft linker, and things were looking good! I could clear the video buffer on OS/2 2.00 GA.
Now why was it working? What is a THUNK? Well it turns out in the early OS/2 2.0 development, they were going to cut loose all the funky text mode video, keyboard & mouse support and go all in on the graphical Presentation Manager.
Presentation Manager from OS/2 6.605
Instead, they were going to leave that old stuff in the past, and 16bit only for keeping some backwards compatibility. And the only way a 32bit program can use those old 16bit API’s for video/keyboard/mouse (etc) is to call from 32bit mode into 16bit mode, then copy that data out of 16bit mode into 32bit mode. This round trip is called thunking, and well this sets up where it all goes wrong.
Then I tried one of the earlier PM looking betas 6.605, and quickly it crashed!
SYS2070:
Well this was weird. Obviously, I wanted to display help
Explanation:
This ended up being a long winded way of saying that there is missing calls from DOSCALL1.DLL. Looking through all the EMX thunking code, I came to the low level assembly, that actually implemented the thunking.
EXTRN DosFlatToSel:PROC
EXTRN DosSelToFlat:PROC
After looking at the doscalls import library, sure enough they just don’t exist. I did the most unspeakable thing and looked at the online help for guidance:
No VIO
So it turns out that in the early beta phase, there was no support for any of the 16bit IO from 32bit mode. There was no thunking at all. You were actually expected to use Presentation Manager.
YUCK
For anyone crazy enough to care, I uploaded this onto github Q59837-mono
It did work on the GA however so I guess I’m still on track there.
From cracyc and roytam’s fork, I have incorporated a correction. These include file access using FCB and fixing exceptions around the FPU of the MAME version of the i386 core. In addition, the DAA/DAS/AAA/AAS/AAM/AAD instructions of the MAME version of the i386 core have been modified based on the DOSBox implementation. With the Pentium 4 version, the testi386.exe is the same as the real thing.
The I386 core of NP21/W has been updated to equivalent to ver0.86 rev92 beta2. Also, fixed the build time warning so that it does not appear.
Improved checking when accessing environment variables, referencing incorrect environment tables. Recent builds have resolved an issue that prevented testi386.exe from working. Improved the efficiency of memory access handling. Basic memory, extended memory, and reserved areas (such as VRAM) can be accessed in that order with a small number of conditional branches. The processing speed may be slightly increased.
I don’t want to complain or anything, I’m very thankful for the tool. It’s just so amazing.
but on my Windows 10 install I have so many issues relating to the font/screen changes, that I just made an incredibly lame fork, and commented out those changes, msdos-player_. I stumbled onto the issue by accident by redirecting stdout/stderr, and compiling stuff ran fine, but as soon as it started to mess with the console it’d just crash.
No console changes, no crashes.
OK so you can run some basic stuff like compilers, but what about ORACLE?!
Oracle 5!
I did have to subst a drive, as I didn’t feel like dealing with paths and stuff, I had extracted it from oracle-51c-qemu, and modified the autoexec & config.ora and yeah, using the 386 or better emulation it just worked! Sadly there is no network part of the install, although there is a SDK so I guess there ought to be a way to proxy queries.
OK, but how about something even more complicated?! NETWARE!
Netware 3.12 on MS-DOS Player
Obviously there is no ISA MFM/IDE disks in MS-DOS Player, but the server loaded!
Needless to say this update is just GREAT!
I’d say try the one hosted on Takeda’s site! It’ll almost certainly work fine for you. Otherwise I guess try mine. Or not.
Because I hate myself, I tried to get the Microsoft OS/2 Beta 2 SDK’s C compiler building simple stuff for text mode NT. Because, why not?!
Since the object files won’t link, we have to go in with assembly. And that of course doesn’t directly assemble, but it just needs a little hand holding:
Microsoft (R) Program Maintenance Utility Version 1.40
Copyright (c) Microsoft Corp 1988-93. All rights reserved.
cl386 /Ih /Ox /Zi /c /Fadhyrst.a dhyrst.c
Microsoft (R) Microsoft 386 C Compiler. Version 1.00.075
Copyright (c) Microsoft Corp 1984-1989. All rights reserved.
dhyrst.c
wsl sed -e 's/FLAT://g' dhyrst.a > dhyrst.a1
wsl sed -e "s/DQ\t[0-9a-f]*r/&XMMMMMMX/g" dhyrst.a1 | wsl sed -e "s/rXMMMMMMX/H/g" > dhyrst.asm
ml /c dhyrst.asm
Microsoft (R) Macro Assembler Version 6.11
Copyright (C) Microsoft Corp 1981-1993. All rights reserved.
Assembling: dhyrst.asm
del dhyrst.a dhyrst.a1 dhyrst.asm
link -debug:full -out:dhyrst.exe dhyrst.obj libc.lib
Microsoft (R) 32-Bit Executable Linker Version 1.00
Copyright (C) Microsoft Corp 1992-93. All rights reserved.
I use sed to remove the FLAT: directives which makes everything upset. Also there is some weird confusion on how to pad float constants and encode them.
MASM 6.11 is very update with this. I just padded it with more zeros, but it just hung. I suspect DQ isn’t the right size? I’m not 386 MASM junkie. I’m at least getting the assembler to shut-up but it doesn’t work right. I’ll have to look more into it.
Xenix 386 also includes an earlier version of Microsoft C / 386, and it formats the float like this:
So I had thought maybe if I replace the ‘r’ with a ‘H’ that might be enough? The only annoying thing about the Xenix compiler is that it was K&R so I spent a few minutes porting phoon to K&R, dumped the assembly and came up with this sed string to find the pattern, mark it, and replace it (Im not that good at this stuff)
wsl sed -e "s/DQ\t[0-9a-f]r/&XMMMMMMX/g" $.a1 \
| wsl sed -e "s/rXMMMMMMX/H/g" > $*.asm
While it compiles with no issues, and runs, it just hangs. I tried the transplanted Xenix assembly and it just hangs as well. Clearly there is something to do with how to use floats.
I then looked at whetstone, and after building it noticed this is the output compiling with Visual C++ 8.0
Great they look nothing alike. So something it totally broken. I guess the real question is, does it even work on OS/2?
Since I should post the NMAKE Makefile so I can remember how it can do custom steps so I can edit the intermediary files. Isn’t C fun?!
INC = /Ih
OPT = /Ox
DEBUG = /Zi
CC = cl386
OBJ = dhyrst.obj
.c.obj:
$(CC) $(INC) $(OPT) $(DEBUG) /c /Fa$*.a $*.c
wsl sed -e 's/FLAT://g' $*.a > $*.a1
wsl sed -e "s/DQ\t[0-9a-f]*r/&XMMMMMMX/g" $*.a1 \
| wsl sed -e "s/rXMMMMMMX/H/g" > $*.asm
ml /c $*.asm
del $*.a $*.a1 $*.asm
dhyrst.exe: $(OBJ)
link -debug:full -out:dhyrst.exe $(OBJ) libc.lib
clean:
del $(OBJ)
del dhyrst.exe
del *.asm *.a *.a1
As you can see, I’m using /Ox or maximum speed! So how does it compare?
Dhrystone(1.1) time for 180000000 passes = 20
This machine benchmarks at 9000000 dhrystones/second
And for the heck of it, how does Visual C++ 1.0’s performance compare?
Dhrystone(1.1) time for 180000000 passes = 7 This machine benchmarks at 25714285 dhrystones/second
That’s right the 1989 compiler is 35% the speed of the 1993 compiler. wow. Also it turns out that MASM 6.11 actually can (mostly) assemble the output of this ancient compiler. It’s nice when something kind of work. I can also add that the Infocom ’87 interpreter works as well.
I had a small twitter account, and I tried not to get dragged into anything that would just be basically wasting my time. Just stay focused and on topic. FINE. I just wanted to see if anyone ever saw it, if it was even worth the effort of doing WIP’s as I didn’t want to make it super annoying.
I logged on to post a fun update that I’d finally gotten a Phar Lap 386 version 4.1 app to do something halfway useful, the sairen AGI interpreter up and running in the most basic sense.
Talking about DOS Extenders is spammy and manipulation!
I don’t get what triggered it, but oh well there was a ‘have a review’ and yeah that was fine. Great. So I’m unlocked so I go ahead and post with the forbidden topic, as I’m clearly dumb, and forgetting that Twitter is for hate mobs & posting pictures of food, and cat pictures.
The Sairen AGI interpreter built with Watcom 386/7.0 & Phar Lap 386 4.1
So yes, that was a line too far, and now that’s it.
Now some of you may think, if you buy ‘the plan’ you’ll no doubt be exempt from the heavy hands of Twitter
3 squids a month
But I already was and had been for a while.
Your account is suspended
So that’s the end of that. I guess it’s all too confusing for a boomer like me.
Cancel me, cancel you
So needless to say I cancelled Twitter as well. Kind of sneaky they didn’t auto-cancel taking money.
So yeah, with that out of the way, let’s continue into DOS Extender land. I added just enough 386 magic, onto github: neozeed/sarien286. Yes I see now it really was a poorly named repo. Such is life.
There is 3 main things for porting old programs where they take care of all the logic, it’s going to be File I/O, Screen I/O, and timers. Luckily this time it was easier than I recalled.
Over on usenet (google groups link) Chris Giese shared this great summary on direct memory access from various methods:
/* 32-bit Watcom C with CauseWay DOS extender */
int main(void) {
char *screen = (char *)0xA0000;
initMode13();
*screen = 1;
return 0;
}
/* 32-bit Watcom C with DOS/4GW extender
(*** This code is untested ***) */
int main(void) {
char *screen = (char *)0xA0000;
initMode13();
*screen = 1;
return 0;
}
/* 32-bit Watcom C with PharLap DOS extender
(*** This code is untested ***) */
#include <dos.h> /* MK_FP() */
#define PHARLAP_CONVMEM_SEL 0x34
int main(void) {
char far *screen = (char far *)MK_FP(PHARLAP_CONVMEM_SEL, 0xA0000);
initMode13();
*screen = 1;
return 0;
}
/* 16-bit Watcom C (real mode) */
#include <dos.h> /* MK_FP() */
int main(void) {
char far *screen = (char far *)MK_FP(0xA000, 0);
initMode13();
*screen = 1;
return 0;
}
It is missing the Phar Lap 286 method:
/* Get PM pointer to text screen */
DosMapRealSeg(0xb800,4000,&rseg);
textptr=MAKEP(rseg,0);
But it’s very useful to have around as documentation is scarce.
Which brings me to this (again?)
Phar Lap 386|Dos-Extender 4.1
Years ago, I had managed to score a documentation set, and a CD-ROM with a burnt installed copy of the extender. I didn’t know if it was complete, but of course these things are so incredibly rare I jumped on the chance to get it!
2011!
Unfortunately, I didn’t feel right breaking the books apart, and scanning them, then add in some bad life choices on my part, and I ended up losing the books. Fast forward *years* later and Foone uploaded a document set on archive.org. GREAT! As far as I can tell the only difference in what I had is that I’ve got a different serial number. Thankfully I was smart enough to at lest email myself a copy of the CD-ROM contents! And this whole thing did inspire me to gut and upload the Phar Lap TNT 6.0 that I had also managed to acquire.
Although unlocking the video RAM wasn’t too bad, once I knew what to do, the other thing is to hook the clock for a timer. ISR’s are always hell, but at least this is a very simple one:
The methodology is almost always the same, as always, it’s the particular incantation.
So yeah, it’s super simple, but the 8086/80286 calling down to DOS/BIOS from protected mode via the int86 just had to be changed to int386, and some of the register structs being redefined. I’m not sure why but the video/isr code compiled with version 7 of Watcom, but crashes. I think its more drift in the headers, as the findfirst/findnext/assert calls are lacking from Watcom 7, so I just cheated and linked with Watcom 10. This led to another strange thing where the stdio _iob structure was undefined. In Watcom 10 it became __iob, so I just updated the 7 headers, and that actually worked. I had to include some of the findfirst/next structures into the fileglob.c file but it now builds and links fine.
Another thing to do differently when using Watcom 7, is that it doesn’t include a linker, rather you need to use 386LINK. Generating the response file, as there is so many objects didn’t turn out too hard once I realized that by default everything is treated as an object.
Another fun thing is that you can tell the linker to use the program ‘stub386.exe’ so that it will run ‘run386’ on it’s own, making your program feel more standalone. From the documentation:
386 | LINK has the ability to bind the stub loader program, STUB386.EXE, to
the front of an application .EXP file. The resulting .EXE file can be run by
typing the file name, just like a real mode DOS program. The stub loader
program searches the execution PATH for RUN386.EXE (the
386 | DOS-Extender executable) and loads it; 386 | DOS-Extender then loads
the application .EXP file following the stub loader in the bound .EXE file.
To autobind STUB386.EXE to an application .EXP file and create a bound
executable, specify STUB386.EXE as one of the input object files on the
command line.
So that means I can just use the following as my linker response file.
One interesting observation is that the 386 extender is actually smaller than the 286 one. And being able to compile with full optimisations it is significantly faster.
16bit on the left, 32bit on the right.
I ran both the prior 16bit protected mode version (on the left), and 32bit version (on the right), on the same IBM PS/2 80386DX 16Mhz machine. You can see how the 32bit version is significantly faster!.
I really should profile the code, and have it load all the resources into RAM, it does seem to be loading and unloading stuff, which considering were in protected mode, we should use all ram, or push the VMM386 subsystem to page, and not do direct file swapping, like it’s the 1970s.
Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.
-Ian Malcolm
Ever since I got my first 286 board way back in the early 90’s (1990? 1991?) I have been intrigued by the whole protected mode of operation. Unfortunately, in the era the required tools were way out of my reach, and of course were not available at retail. But now I live in the future where I have all the parts! Let’s look at the needed parts
I have to once more again thank my patrons, and people tolerating the google ads as it made all the difference in being able to buy all this stuff. And now is as good a time as any other to put it all together.
I stumbled upon this repo on sourceforge, Sarien. It included a Turbo C++ port, which is pretty exciting! So, this became my goal, get Sarien running on Phar Lap 286.
Installing Microsoft C 6.0a
Installing Microsoft C requires you to pick and choose both hosting, targeting environments, along with what the preferred libraries are. In the business we call this foreshadowing as this can be such a giant PITA. At least virtual machines are fast, plentiful, and cheap. In addition I had been using MS-DOS player to host the tools on Windows 11. This of course proved weird later.
The first step was getting it running on MS-DOS using Microsoft C 6.0a. This was actually pretty easy, the hard part was working out the makefile, as some files don’t compile with optimisations. And overall, the project doesn’t seem to work with /Ox at all. I haven’t spent enough time mixing and matching settings to find what actually doesn’t work, but I’m in a hurry, and /Os seems to work just fine.
In no time I had both the CGA & VGA drivers up and running and verified working on my PS/2. Great!
Now comes the fun, getting it ready to run on Pharlap.
The magic!
Phar Lap’s 286|DOS-Extender is pure magic. A DOS extender is a special program that can load a protected mode program into memory on a 286 or better computer and run it. At it’s heart, it can proxy MS-DOS functionality from protected mode to real mode, allowing you to use a lot of methodology and code from traditional real mode code. Phar Lap, goes beyond that by providing a pseudo OS/2 1.2 environment on MS-DOS, including advanced features like DLL’s, and being able to use ALL the RAM in your computer. Of course on the 286 there is a massive caveat:
The 286 has no built-in function for switching from protected mode to real mode. This makes programs that rely a LOT on MS-DOS potentially very slow. You can absolutely feel the difference between the real mode and the protected mode version of Sarien.
Phar Lap does include a test program, swtest which can benchmark the switching methods, so let’s run it and get some scores.
Switch code version = 1.14
BIOS signature: BA66CC86
BIOS date: 02/13/87
Machine ID = 0, A20 method = PS2, Reset method = Standard
Starting test for Switch Mode 3 (SLOW) ... Test complete.
Avg switch time (usecs): To prot = 34, To real = 101, Total = 135
Min switch time (usecs): To prot = 32, To real = 98, Total = 130
Max switch time (usecs): To prot = 35, To real = 103, Total = 138
Machine ID = 0, A20 method = PS2, Reset method = Standard
Starting test for Switch Mode 2 (AT) ... Test complete.
Avg switch time (usecs): To prot = 34, To real = 86, Total = 120
Min switch time (usecs): To prot = 33, To real = 83, Total = 116
Max switch time (usecs): To prot = 36, To real = 88, Total = 124
Machine ID = 0, A20 method = PS2, Reset method = Standard
Starting test for Switch Mode 1 (SURE) ... Test complete.
Avg switch time (usecs): To prot = 34, To real = 70, Total = 104
Min switch time (usecs): To prot = 32, To real = 68, Total = 100
Max switch time (usecs): To prot = 35, To real = 72, Total = 107
For those of you wondering what the timing is like on a 386, here is my 16Mhz PS/2 Model 80 board (now with fully 32bit memory)
Switch code version = 1.14
BIOS signature: 039D2DB4
BIOS date: 03/30/87
Machine ID = 0, A20 method = PS2, Reset method = Standard
Starting test for Switch Mode 5 (386) ... Test complete.
Avg switch time (usecs): To prot = 31, To real = 22, Total = 53
Min switch time (usecs): To prot = 30, To real = 20, Total = 50
Max switch time (usecs): To prot = 32, To real = 23, Total = 55
I’m honestly surprised the 286 switches from protected back to real so quickly! Although as you can see from the 386 timings it’s significantly faster than the 286.
Here is a quick video, real mode on the left, protected mode on the right. Yes I need to get a VGA capture card. Sorry.
Real mode on the left, Protected on the right. Running on the 386
Being a DOS extender it does have built in functions for things like hooking interrupts like this:
Using pointers into things like video ram do require ‘asking for permission’ but it’s not too involved:
int rseg;
/* Get PM pointer to text screen */
DosMapRealSeg(0xb800,4000,&rseg);
textptr=MAKEP(rseg,0);
with the segment mapped, and a pointer to the segment, and now I can read/write directly into video RAM!
/* save text screen */
memcpy(textbuf,textptr,4000);
Just like that!
I’m not sure what I screwed up on the VGA graphics, as it doesn’t work correctly, but oddly enough CGA does work.
And now this is where everything goes off the rails.
Sairen running on Qemu & DOSbox
It ran fine on emulation. So all excited I fired up the PS/2 and….
General protection fault
This lead me to more fun in how on earth to debug this. Of course Phar Lap 286 version 2.5 requires me to have Microsoft C/C++ 7.0. I shamelessly downloaded a disk set from pcjs.org. You actually need to install it, to copy out the files required:
28/05/1991 05:37 pm 47,216 CFIG286.EXE
26/11/1991 11:19 am 13,531 GORUN286.EXE
19/03/1992 04:00 am 42,720 shw0.dll
19/03/1992 04:00 am 105,039 eew0cxx.dll
19/03/1992 04:00 am 410,112 cvw4.exe
19/03/1992 04:00 am 91,118 eew0can.dll
19/03/1992 04:00 am 74,400 emw0w0.dll
03/08/1992 09:34 pm 2,649 INT33.DLL
03/08/1992 09:40 pm 2,718 MSG.DLL
03/08/1992 09:40 pm 1,702 NAMPIPES.DLL
03/08/1992 09:42 pm 2,073 NLS.DLL
03/08/1992 09:43 pm 5,184 PTRACE.DLL
03/08/1992 09:45 pm 2,320 SESMGR.DLL
03/08/1992 09:50 pm 1,508 WIN87EM.DLL
05/08/1992 12:04 am 3,100 KEYBOARD.DLL
05/08/1992 06:33 pm 270 TOOLHELP.DLL
14/08/1992 07:38 pm 7,891 KERNEL.DLL
14/08/1992 09:40 pm 14,545 USER.DLL
09/09/1992 10:59 pm 209,922 RUN286.EXE
09/09/1992 10:59 pm 229,046 RUN286D.EXE
14/09/1992 11:01 pm 14,024 TLW0LOC.DLL
17/09/1992 07:26 pm 34,152 CVP7.EXE
While CVP7 does come with Phar Lap, you have to run it via run286. As you may have noticed there is a mixture of OS/2 and Windows DLL’s in here, as at this point CodeView was a Windows protected mode debugger. The divorce was in full swing, and Microsoft C/C++ 7.0 had amputated the majority of OS/2 support. I’m sure all this is in the manuals, however all I have is disk images. There was no C 6.0a supported hosted debugger. Maybe it’s in the v1/v2 of Phar Lap 286, but I only have 2.5. There is version 3 files on the internet but I wanted to stick to 2.5.
Exception #13
And this is all I got. Yes, I did recompile with ‘/Od /Zi’ along with using cvpack on the executable. Yes, after copying the source to the PS/2 I was able to see the source line mapping, but it immediately jumps to assembly and GP Faults. All this is fine, but IT RUNS UNDER EMULATION.
What is going on?!
I asked around on discord, and found someone willing to test on their 286. It also crashed. I tried VMware and .. it crashed too! So did 86box! Ok now we’re going somewhere!
Since I had been using MS-DOS player to run the tools, I had an issue with the linker in C 6.0a crashing, so I tried the one from C/C++ 7. It also didn’t work. I tried the one from Visual C++ 1.5. It also failed. Almost giving up on the entire thing, since I had copied the source code to the PS/2, I tried something really silly, I compiled it using the /qc or QuickC flag. I wasn’t too worried about sizes as again I’m going to run in protected mode. It took some 20-30 minutes to compile, as 10Mhz machines are not the best for building software in this modern age. Much to my surprise it actually ran.
First run!
This was kind of shocking as I’m not sure what I screwed up to not get this to work, but it worked! I went ahead and changed the build to not use QuickC, but rebuild with /Os (Optimize for space). It took about an hour. And it too worked.
Phar Lap 286 running on OS/2 2.00 on VMware
Shockingly it runs! I’m not sure what on earth is up with the linking. I did find it easier to just rebuild on Qemu since it can easily map into my source directory and copy everything over and re-build very quickly.
Later I did try copying over compiled objects built using the MS-DOS Player, and linked them natively, and they ran fine.
What is it with the LINK?!
It all fits! Stacker rules!
One weird thing on 86box is my pre-built machine I was using has a 5 1/4″ 1.2Mb floppy for the A: drive. It’s too small to fit MS-DOS, the game data and Phar Lap 286 all on there. Although Stacker to the rescue and it fits!
It can save and even load those saves!
I removed a lot of Unix quality of life, to make it more MS-DOS dumping everything in the same directory so you can save & load games.
It’s not mine, rather it’s Asianometry‘s. It’s a nice overview of the rise of Unix. I’d recommend checking it out, it’s pretty good. And of course, as I’m referenced!
Years ago I had tried to make these old OS’s accessible to the masses with a simple windows installer where you could click & run these ancient artifacts. Say 4.2BSD.
Installing should be pretty straight forward, I just put the license as a click through and accept defaults.
Starting BSD via ‘RUN BSD42’ and the emulator will fire up, and being up a console program (Tera Term) giving you the console access. Windows will probably warn you that it requested network access. This will allow you to access the VAX over the network, including being able to telnet into the VAX via ‘Attach a PTY’ which will spawn another Tera Term, prompting you to login.
telnettting into the VAX
You can login as root, there is no password, and now you are up and running your virtual VAX with 4.2BSD!
All the items
I converted many of the old documents into PDF’s so you may want to start with the Beginners guide to Unix. I thought this was a great way to bring a complex system to the masses, but I’m not sure if I succeded.
776 downloads
As it sits now, since 2007 it’s had 776 downloads. I’d never really gotten any feedback so I’d hoped it got at least a few people launched into the bewildering world of ancient Unix. Of course I tried to make many more packages but I’d been unsure if any of them went anywhere. It’s why I found these videos so interesting as at least the image artifacts got used for something!
But in the off hand, maybe this can encourage some Unix curious into a larger world.
On the heels of discovering BOW, I thought I’d try to make a cross compiler. Attempts at running binaries on *BSD systems had mixed results, although I thought it was interesting that my old Linux a.out cross compiler can generate object files BOW can happily link, although anything more complicated resulted in disaster. As part of that project I had build a 386BSD 0.1 cross so I figured that’d be worth a shot.
And it worked!
Sor for the two or three people who care here we go!
I’ve broken this up into each of GCC’s phases (programs) so that I can inspect the output of each as I go. This also lets me control exactly what gets passed where. And in this case forces the use of the 80387 where/when needed. It’s also nice to see where and what gets pulled in by the C pre-processor what magical numbers are set, and of course to see how the calling conventions work in the resulting assembler file. While I had built this around the idea of cross compiling the 386BSD 0.1 kernel, it’s still fascinating to me that it can be hammered into making BOW compatible executables. Although I didn’t update the CPP flags, no doubt I probably should as the headers probably expect something more FreeBSD.
Running make yields:
C:\bow\src\hello>make
cpp -I../../include -v -undef -D__GNUC__ -Dunix -Di386 -D__unix__ -D__i386__ -D__386BSD__ hi.c hi.i
GNU CPP version 1.39
cc1 hi.i -quiet -O -m80387 -version -o hi.S
GNU C version 1.39 (80386, BSD syntax) compiled by GNU C version 7.1.0.
default target switches: -m80387
a386 hi.S -o hi.obj
ld -o hi ../../lib/crt0.o hi.obj -L..\..\lib -lc -lgnulib -lm
C:\bow\src\hello>size hi
text data bss dec hex
24576 4096 0 28672 7000
C:\bow\src\hello>wsl file hi
hi: a.out little-endian 32-bit demand paged pure executable not stripped
C:\bow\src\hello>
It should also probably be worth mentioning that the linage of BOW has to be in the dark days of the AT&T v CSRG/BSDi lawsuit as this toolchain does produce binaries that run, unlike the 1.0 phase of both NetBSD/FreeBSD where they dumped all the prior code and forked harder from the common 386BSD 0.1 that we all loved.
fib
Simple Fibonacci sequence
Inform ’87 interpreter
My favorite ZIP interpreter
NS32016 emulator
Now this one is interesting it’s a NS32016 emulator! I left the ns32016 cross in the data directory if you want to generate the data file. I was surprised it worked, but wow!
phoon
Phases of the moon may not seem all that exciting at first, but the big thing is the handling of the math coprocessor, and of course to be sure to link against the BOW libm. Otherwise it just hangs the system.
trek
And of course the old TREK game from Unix lore.
I would imagine that a newer version of GCC or at least CC1 should be easy enough to build, and of course cross compiling gives you an out of the 16MB RAM limit that WINMEM32 imposes.
The biggest WTF I had was for Hack 1.03. I’m not sure why it didn’t want to link, but rest assured, the cross compiled objects just linked fine. I don’t know.
In other BOW news I have been in contact with the author, I don’t want to bother him too much but I’ll try to glean a lot more info from him.
