Monthly Archives: April 2010

OS/2 1.x emulation via HXRT

Posted on by
1

I finally got this working, although I’ve got to sit down and work out the old makefile format to bind in the hxrt stub instead of running it all on the CLI…

So as a poor example, I used the ancient Fortran 5.1 to build up an OS/2 1.x VIO executable of dungeon, which would run happily on NT 3.1, but of course will not run on XP as they have removed the OS/2 subsystem.

Anyways it’s impossible to run the exe on dos, but fishing around I came across my old Visual C++ 1.5 CD, and on there was the Phar lap 286 dos extender. And one of the neat things it could do, was run simple OS/2 applications under MS-DOS!

So I bound the exe and now it’d run under MS-DOS.

phar lap 286 dungeon 2.5..6

phar lap 286 dungeon 2.5..6

However, since it’s a trial version, it’s limited to 2MB of ram, and you can’t redistribute the resulting exe. Now this is where HX DOS Extender (archive.org mirror/sourceforge mirror) comes in. Over the years, the HX dos extender has provided the functionality of the old Phar lap TNT dos extender by allowing you to run Win32 exe’s under MS-DOS, and it provides a pretty impressive subset of the Win32 api on MS-DOS.

So taking this lead, HX now has a 16 bit 286 centric version that provides a basic OS/2 emulation layer.

So by simply passing the OS/2 exe as a parameter to the DPMI loader (I haven’t quite worked out the stub syntax…) you can run the OS/2 build of dungeon under MS-DOS!

HX16 dungeon 2.5.6

HX16 dungeon 2.5.6

For anyone stuck with either legacy 16bit tools, or a need to support ancient systems, it’s certainly nicer with OS/2 as you have access to a LOT more memory! According to the documentation the HX extender should work nicely with the OpenWatcom Fortran & C, although I currently haven’t tested it.

What’s kind of interesting is that HX doesn’t work under DOSBox, while the Phar Lap 286 DOS Extender will….

Both of these dos extenders build on the old idea of the “Family API” where common API’s between OS/2 and MS-DOS could be mapped between the two OS’s, and a common “bound” executable could then run in either environment. However on the MS-DOS side, it’d be subject to the memory constraints of a realmode MS-DOS executable. The DOS extenders build on this idea, but provide access to additional memory, and a more feature rich OS/2 api.

On the road to X11

Posted on by
1

This is going to be.. involved to do… But there is some hope. The source to X11 R5 is still online, even though the xfree86-1.2 stuff is long gone. I was able to find a binary 2 bit Xserver for 386BSD, so that’s promising.

So my hope would now lay in making up a configuration file that’ll satisfy the Xfree86 1.2 server, and build enough of X11R5 to where it’s able to do something….

I have no idea if it’s even that easy to do, but if anyone has any leads on a source copy of xfree86-1.2 or 1.3 that’d probably be easier to build for 386BSD as it was used in the time frame… 2.0 was for the forks of NetBSD & FreeBSD so no doubt it’d hinge on things like DLL’s…

In the meantime, you can check out Neils Horn’s blog, with an example of what Xfree86 1.x was capable of on 0.96 linux.. Back in the day.

HTTPD 1.3

Posted on by
3

Well I was looking for a way to move data out of the 386BSD vm without too much pain, and I’ve just been hitting this brick wall about trying to compile apache.

You see the thing is, 386BSD is so old, it doesn’t have dynamic libraries, and a uname command so you have to ‘fool’ the configure scripts, and even then if you do manage to get an executable it’ll just crash… For some reason gdb couldn’t help with the whole thing… very annoying. I think it may be a program size limit..? Either way, I’m sure it was ‘fixed’ in NetBSD 0.8 ..

So after googling around the ancient news groups, I came across this post..

NCSA httpd 1.1/1.2/1.3 compile straight (well almost) out of the box. I’ve not tried the CERN one yet. I’m happy with my NCSA 1.3.

Well, now that’s interesting… Remember that NCSA gave us Mosaic, but they also gave us httpd, which apache is based on. However NCSA no longer hosts the httpd source code… It’s gone with the wind…. Except for this Slackware mirror.

So after downloading it, and building, naturally…. it crashed. However this time I was able to fire up GDB, and see that it was crashing in the mime initialization… It seems it was using a null pointer… So for the heck of it, I changed the hash macro to use the 2nd definition, and it worked!!

So after all of that, I built some stuff for 386BSD to test the transfer of the web server, and it “seems” ok to me… Naturally I wouldn’t expect this to withstand any large amounts of traffic as it doesn’t seem to fork itself… I also suspect this version may work with the VAX 4.X BSD stuff as well…

httpd-1.3
com (CP/M emulator)
GNUMake-3.75
Frotz-2.32
screen-3.7.1
gcc-2.5.8
bash-1.14.7
bash-2.0

It is kind of scary how this old software is disappearing, and at the same time, we hear this promise of how we can keep everything forever in the “digital age”… At any rate, I guess this preserves a somewhat usable OS/Webserver configuration circa 1993…

Back to 386 BSD

Posted on by
10

Well gunkies is getting a little more life to it, and Dugo contributed this install guide for 386 BSD. Along the way I installed it again with floppy images, and I hit the same fault again:

/386bsd: wd0a: overlaps open partition (b)

However this time I noticed that if you keep on rebooting, it’ll actually stop complaining and work!

So not only was I able to recover from a crash after trying to install the source code, but I was able to complete the install, and install the patchkits! What this has resulted in, is that Qemu can now run 386BSD!!! And it’s significantly faster then Bochs. Not to mention you gain the whole SLiRP / Usermode networking.

So far I’ve tested this with Qemu-0.11.0 just fine. I’m not sure about other levels… so it’s another YMMV.

So now I’ve been able to not only rebuild the kernel & world, but the following programs:

gzip 1.2.4
unzip 5.52
irc II-4.4
lynx 2.8.2

Oh yeah, and another f2c build, and yes it’ll run Dungeon!

So for the few people interested in some BSD history, as this is the ‘first’ Net/2 derived freely available release in a qemu format right here (sorry, link removed, if you want it install this instead).

Just uncompress the qcow2 file (sorry it’ll blow out to 500MB), then run Qemu something like this:

i386-softmmu/qemu.exe -L pc-bios -hda bsd386.qcow2 -M isapc -net nic -net user -no-reboot -m 256

And with any luck, you’ll find the VM booting, and all set and ready to roll. If it comes up in single user-mode, just close Qemu & fire it up again..

I’ll probably put together a windows install package for this later, but for now I figure I’ll unleash some 386BSD onto the world.

Follow up on Visual C++ 2010

Posted on by
2

Ok, the machine I’m going to test this on, is a Vista x64 machine (I know I just couldn’t be bothered to upgrade it yet).

The CPU is an Intel Core2 Quad Q9300 running @ 2.50Ghz, with 8GB of ram.

The “Windows Experience Index” is 5.9 (It’s 5.9 across the board).

I’m using a redo of the SDL port of Quake 1 as a benchmark. You can download it here.

Unzip it somewhere, and I’ve tried to make this pretty easy to follow… There are precompiled EXE’s for various CPU’s and Visual C++ levels.

To build, setup your CLI with the VC environment variables, then simply cd into ‘ezquake\build’ and run:

nmake -f quake.mak

If you have Visual C++ 2.0 (I forget if I needed this for 4, and I just don’t feel like installing 5.0 right now) you may need a slight ‘hack’ to undefine some things that just don’t exist in the winmm.dll setup with the vc2.mak/b2.cmd .

And this should produce an EXE with the /O2 flags for a generically built maximum speed optimized EXE. If your make has issues, you can try the build.cmd file which just blindly compiles the thing one at a time…. It should work as well.

Then to test the exe, simply cd into the ‘ezquake\test’ and run:

..\build\quake -nomouse +timedemo demo1

Anyways, now for some interesting test results:

Visual C++ 2 x86 619.4 FPS
Visual C++ 4 x86 689.1 FPS
Visual C++ 6 x86 631.2 FPS
Visual C++ 2008 x64 375.7 FPS
Visual C++ 2008 x86 400.6 FPS
Visual C++ 2010 x86 772.2 FPS
Visual C++ 2010 x64 949.5 FPS

949 FPS in Quake1!

949 FPS in Quake1!

I’m blown away with just how fast this new version of Visual C++ is.

Visual Studio 2010 just shipped

Posted on by
1

So many editions!!… I’m already confused. I think this is the last version to support the Itanium, as that platform is basically cooked.

Considering how lackluster and scarce they were at the launch I guess it’s not surprising.

Anyways It’ll be nice to fire up the x64 CLI tools, and not be told that the ‘release’ is infarct a beta…

Anyways, there is some details over at the MSDN site.. And a demo/eval download.

On the ‘cheap’ front, the express editions are also updated to the 2010 level. I’d recommend getting the ‘offline’ ISO image… That way you’ve got all the bits in one shot.

On the UNIX front, I found that on OpenSolaris, that the SunStudio is a free download. This includes SUN’s C/C++/Fortran (77/90/95) compilers.

I took a quick look at the SUN F77 compiler, and it’s certainly the UNIX one from the days of v7 as it behaves the same way… I guess that’s not too surprising.

Other then that, not a heck of a lot going on.

More CDROM madness.

Posted on by
8

Well I found that one of the things that was preventing me from booting up this “Solaris 1.1.2” AKA SunOS 4.1.4 CD is that Qemu on Win32 using raw devices has issues with all these slices and whatnot.

Slices you say?

Yeah, back in the ISO9660 Rock Ridge days, CD-ROMS were basically given a common format for the “LCD” of the day. In that case MS-DOS. Naturally people like Unix vendors were not to keen on that, as they wanted file attributes, long file names, symbolic links etc… So a *LOT* of people started to split up their CD’s into partitions like hard disks, and slap down actual filesystems on the disks. NeXT just used one giant partition on the CD-ROM, but their exe format let them ‘bind’ all the CISC machines onto one CD, and all the RISC machines on another. Meanwhile SUN decided to make all these ‘boot’ partitions for various machines, a miniroot, then an I9660 partition for basic tar files of the OS…

Like this:

2,998,272 DEBUGGING
4,161,536 DEMO
3,219,456 GAMES
1,826,816 GRAPHICS
999,424 INSTALL
1,073,152 NETWORKING
7,815,168 OPENWINDOWS_DEMO
9,748,480 OPENWINDOWS_FONTS
23,756,800 OPENWINDOWS_PROGRAMMERS
34,316,288 OPENWINDOWS_USERS
925,696 RFS
327,680 SECURITY
1,409,024 SHLIB_CUSTOM
524,288 SUNVIEW_DEMO
1,884,160 SUNVIEW_PROGRAMMERS
2,727,936 SUNVIEW_USERS
4,104,192 SYSTEM_V
729,088 TEXT
49,152 TLI
7,872,512 USER_DIAG
29,638,656 USR
622,592 UUCP
6,103,040 VERSATEC

Which is kind of funny seeing how some BSD derived OS’s still keep some of these package names alive.

Anyways, the problem is that I tried to use \\.\d: for the cdrom, and booting didn’t work at all. I even tried reading an ISO from the CD, but all it ended up doing was skipping to the ISO9660 part, and dumping that, ignoring the slices, giving me this:

243,599,360 sol14.iso

So after googling around, trying to at least find a way to back up this CD (it was a souvenir from Japan!) I found someone mentioning to backup their Solaris CD, they had to use the “readcd” program.

Well, I’d never explored that much with the cdrtools, but behold there is a readcd program that’ll dump an entire CD out!

So running it with –scan-bus to find your CD drive…

readcd -scanbus
scsibus0:
0,0,0 0) *
0,1,0 1) ‘HL-DT-ST’ ‘BDDVDRW GBC-H20L’ ‘1.B8’ Removable CD-ROM
0,2,0 2) *

We can go on to dump a full image of the CD.

readcd -dev=0,1,0 f=sunos.iso

Which now gives us a much larger ISO image…

329,605,120 sunos.iso

Sadly it crashes on bootup… But on Win32 it’s a lot better then not reading *ANYTHING* at all!

ok boot disk1:d -vs
Boot device: /iommu/sbus/espdma@5,8400000/esp@5,8800000/sd@1,0:d File and args: -vs
Boot Release 4.1.4 (sun4m) #2: Fri Oct 14 11:07:52 PDT 1994
Copyright (c) 1983-1990, Sun Microsystems, Inc.
Boot: Romvec version 3.
root on /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@1,0:d fstype 4.2
Boot: vmunix
.Size: 868352…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………+2319136+75288 bytes
Statistics:

–edit

I should also add that Qemu’s CDROM (like 99% in the world) are fixed block, while SUN (and other vendors) had these CD ROM’s that could change block size… So in Qemu you have to use the DISK driver vs the CDROM driver….

ie use -hdb sunos.iso instead of -cdrom sunos.iso

Qemu Sparc snapshot getting better!

Posted on by
19

Thanks to Artyom Tarasenko‘s tireless work on the Sparc MMU, DMA, SCSI It’s not possible to install some versions of Solaris, and boot others to single user mode!
Heck, even the NeXTSTEP 3.3 boot program goes ahead and loads up..

However this is all done without a graphical console, as the sparc rom’s dont understand the framebuffer that Qemu emulates…

qemu-system-sparc.exe -nographic -monitor null -serial mon:telnet:127.0.0.1:23,server -bios ..\ss5-170.bin -M SS-5 -m 256 -hda ..\solaris.disk -startdate “2009-12-13” -cdrom \temp\cd46.iso

Running it is something like this. The key here is the lines:

-nographic -monitor null -serial mon:telnet:127.0.0.1:23,server

Which setup a serial port console you can just telnet into (for us Windows users).

This gets around all the errors like this:

chardev: backend “stdio” not found
qemu: could not open serial device ‘mon:stdio’: Result too large

Sadly my SunOS cd doesn’t seem to want to boot, and I somehow saved a copy of Solaris 8, but not 6..? Sigh.

ok
ok boot cdrom -vb
Boot device: /iommu/sbus/espdma@5,8400000/esp@5,8800000/sd@6,0:d File and args:
-vb
Size: 259712+54162+47510 Bytes
SunOS Release 5.8 Version Generic_108528-13 32-bit
Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved.
Ethernet address = 52:54:0:12:34:56
Using default device instance data
vac: enabled in write through mode
mem = 262144K (0x10000000)
avail mem = 258322432
root nexus = SUNW,SPARCstation-5
iommu0 at root: obio 0x10000000
sbus0 at iommu0: obio 0x10001000
dma0 at sbus0: SBus slot 5 0x8400000
dma0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000
/iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 (esp0):
esp-options=0x46
esp0 at dma0: SBus slot 5 0x8800000 sparc ipl 4
esp0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000
sd6 at esp0: target 6 lun 0
sd6 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@6,0
root on /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@6,0:
b fstype ufs
obio0 at root
obio0 at obio0: obio 0x100000, sparc ipl 12
zs0 is /obio/zs@0,100000
obio1 at obio0: obio 0x0, sparc ipl 12
zs1 is /obio/zs@0,0
cpu0: FMI,MB86907 (mid 0 impl 0x0 ver 0x4 clock 1070 MHz)
# uname -a

SunOS 5.8 Generic_108528-13 sun4m sparc SUNW,SPARCstation-5
#

Which is all cool. And check the CPU, 1070Mhz! Don’t we all wish we had SPARC’s that fast!

I’ve even managed to install OpenBSD/Sparc! … But it crashed on booting.

Anyways it’s late, and thats it for now.

The real programmer’s Snoopy Calendar.

Posted on by
2

I was googling around last night waiting for this huge dataset to copy (lol more on that disaster later) when I came across this cute posting about real programmers.

And of course in there, every ‘real programmer’ has a Snoopy Calendar dated from 1969.

With a bit of googling, I come across this site that has the needed snpcal.for, snppic.for and snpcal.dat. Now granted this is from 1987, but hey, it’s as distant as even the original program from the 1960’s.

Now there is a lot of folklore about this program from the 1960’s along with an older version which can be found here, but sadly it wasn’t enough to keep the wikipedia page alive as they had no real sources backing it up prior to the 1980’s.

Anyways with a few minor tweaks, the code from the 1980’s will compiler on MS Powerstation Fortran, and that code will in turn compile via f2c!

So, for the few people that care about this kind of thing, or stumbled upon it, here it is:

Just take note that it’s made for a 132-column printer, which was a popular thing back in the day. Although I’m sure laser & various ‘jet’ printers can print this thing in portrait mode.

I’ve included the source that I changed, along with a win32 exe and the output (in MS-DOS text format) here.

If you want a more ‘modern’ version of the calendar, just edit the data file, you can easily find the star/stop portion in there (search for 1969!).

Next time I’m near a printer and nobody’s looking I’ll have to print one!