Links 386 Pro

Out on the course

Links 386 is one of those programs that is very easy to love to hate.  It was 1992, and PC’s were mostly being used for business, and high powered 32-bit machines were still insanely expensive.  And then Links 386 happened.  Before there was DooM, Links 386 was the ‘must have’ executive ball clacking device.  And the specs that you needed to run this game were really over the top.  At it’s heart was the Phar Lap 386 Dos extender, along with the virtual memory module.. Which most people would have to rely on.  Links 386 really needs over 8MB of RAM to run.  Yes, that is correct, in 1992 you were recommended to get 8MB (which should have been about $400-800 USD) So you can golf at your desk.  But as the name implies you also needed a 386 classed computer, although ideally you would have one of those new 486’s!  Links 386 also pushed the edge by wanting a VESA capable SVGA card that could use mode 101, 103, or 105.  Although the higher resolutions modes just ended up with logos everywhere, it really didn’t take enough advantage of the higher resolution modes.

Another interesting thing is not only does Links 386 have sound drivers (which means you need a sound card!) but it’ll do voice through the AdLib card.  Also it has a driver model, the WLZ, which I don’t know if they ever published or if people wrote additional sound drivers.

Links 386 installer

The installer is kind of cute, in that it’s flat shading is so old it’s now modern.  How’s that for crazy?

Installation is a snap, at only four diskettes.  They sold additional courses, and I only have one additional course, although oddly enough finding others online is pretty trivial.  However I had far less luck finding the program.  One nice tip to Infocom is that the courses include a score card, like the ones you would get on actual courses.  It really tied the package together.

Don’t copy that floppy!

Although for me, I really bought it for the manual.

Pebble Beach

And I have to admit it, Access Software did a great job.  Even all these years later, it looks great.  But no doubt scaling and placing all the textures is SLOW.  Incredibly slow.

Back in the 90’s I had a lowly support job, and I’d get flown all over the country to help out with issues, and it’d never fail that the regional director would have ‘issues at home’ and amazingly they’d always ask about running Links 386 Pro.  No doubt a lot of people upgraded machines, and got to brag to their buddies on how fast Links would now load.  Running at actual 386 speeds will take nearly a minute to render the screen between shots.

The DOS Extender was forever very touchy.  It took a bit of work to get around it’s issues, with the continuous conflicts with TSR’s, drivers, sound cards, video cards.. It was a nightmare of compatibility issues.  Not to mention that although Phar Lap 4.1 was DPMI compatible, it really didn’t play that nice with OS/2 or Windows.  Microsoft would later come to the rescue for this costed gamer market in the form of buying Links away from Access software, and putting out Microsoft Golf.  And much like SimCity, being able to run this under Windows make it immensely popular in the workplace, as all you needed to find were Windows drivers for your hardware, which vendors did actually support, unlike games.

It’s amazing how companies like Phar Lap, or Rational never did try to make an actual gaming platform for their extenders, leaving it all up to individuals.  My older self says that Microsoft’s rise to prominence in the 90’s was mostly due to their competitors incompetence, rather than their brilliance.

Although DOS Extenders like Phar Lap have been around since the introduction of the 80386, Links 386 Pro is the oldest one I know of.  If you like programs that try their best to bend the limits of what you can or should do, certainly check out Links 386 Pro!

Source code to EXXOS / ERE Informatique Captain Blood not exactly released

It’s no secret that I always was fascinated with the 1988 game Captain Blood.  Last time I played it through was when I’d modified it to run with a virtual floppy drive on an Amiga 600.  While the game had been ported to numerous 8 bit and 16 bit platforms, it basically vanished into the haze that was French 80’s SciFi body horror.

But then I saw this tweet:

And sure enough I grabbed a copy of the IIGS emulator KEGS32, the ROM, an OS disk, and booted up System 6.0.1 after putting the OS disk into slot S7D1. I then mounted up the source code diskette found at brutaldeluxe.fr

Captain Blood source code release

Great right?

Well it’s a bunch of assembler files.  Ok, so when I try to open one from System 6.0.1 I get this:

Corruption

So not giving up just yet, I loaded up a program called CiderPress that can read the IIGS disk image files, and using that I was able to extract the source.

CiderPress extraction

And then I saw this gen scattered in the ASM files that were.. well honestly pretty bare of any comments.  Or sane labels.

TFBD generated externals

Which of course is the output from The Flaming Bird Disassembler, a product of Brutal Deluxe, aka where this ‘source’ came from.  Although apparently it can be re-assembled into a working executable, as Antoine had fixed it so the mouse used toolbox calls for the mouse for ROM 03.

I put the source code online in CVS.  Although I don’t think many people would care, as it’s reversed and VERY terse.

DOSBox 0.74 can run Windows 3.0/3.1 in 386 Enhanced mode!

DOSBox… in a box!

I don’t know why I never tried it before, but it actually works!  And it’ll even spawn out to a window two.  Although without share/record locking it’ll end up being a world of pain, I suspect.  Maybe vDOS/vDosPlus will work?  I know it’ll work fine if you boot MS-DOS inside of DOSBox, but for some reason I never actually tried to stress the v86 mode of DOSBox from within Windows.

Welcome to the uncanny valley

It’s that awkward time of the year when those of us that still have to work feel as if we really should be on vacation…  But here we are flipping your burgers and keeping the lights on.

Oh and I thought it’d be fun to do one last giveaway for the year.  And a good one too, DooM 3 BFG!

As always, I have 5 keys.  So to the first 5 people!

Calamus for Windows NT RISC

(This is a guest blog post by Antoni Sawicki aka Tenox)

A Christmas gift for those who run Windows NT on Alpha AXP, MIPS or PowerPC. These ports of Windows are really lacking some good applications. Yes, there are utilities and games, Alpha even has Microsoft Word, Excel and Oracle DB, but apart from that there just are no serious apps available.

Calamus is a professional DTP (Desktop Publishing) software. It was actively developed and sold by a German company Invers up until 2018. If you want to play around with the latest version you can download a 30 day trial and (at the time this article was written) even purchase the Lite version for 99 Euro on calamus.net. There are versions for Windows, Mac and Atari ST.

Atari ST ?! Well yes, the original Calamus was born some 30 years ago on Atari ST:

I had pleasure of using Calamus professionally on Atari for several years in early 90s. At the time when 486 could have max 64MB RAM and 640×480 VGA, a high-end Atari TT packed 256MB Magnum card and 1280×1024 framebuffer. The memory and high resolution displays were really needed to process large images and complex page layouts.  You can read more about my Atari TT restoration efforts.

In the mid ’90s DMC decided to port Calamus to Windows NT to take advantage of emerging high end PCs and RISC platforms. An interesting fact is that the port wasn’t really a full source code rewrite, which was impossible due a large codebase size. Even that Calamus has 100% native Windows GUI and a lot of functionality has been rewritten, inside the software lives a small embedded Atari ST emulator that does on fly translation of some of the Atari/m68k ABI. You can read a bit about it here.

Calamus on Windows NT Alpha AXP

At the time of the port, Windows NT was still being actively developed on RISC platforms, so thankfully Calamus has been compiled on all of the available NT CPUs. Alpha version was probably the most popular choice because of performance. High end Alphas were the fastest machines capable of running Windows among all hardware. When publishing firms were thinking about upgrades they naturally looked at DEC as a first choice as regular PCs weren’t powerful enough.

I finally found a copy Calamus NT with support for all the RISC CPUs. It took me quite a lot of time and resources to track down and obtain copy of a surviving media from an owner of a publishing studio. This is how it looks when you first install it:

Calamus NT Install Wizard

Interestingly there were separate builds for 386/486 and Pentium CPUs. 

If you don’t have one of these machines you can still run Windows NT MIPS on Qemu:

Calamus on Windows NT MIPS under QEMU

And finally to the goods! You can get them in my my archive. If you just want to play with small demo without installing the whole app look in the demo folder.

Commodore Programming Languages

While looking for nothing in particular, I came across Glenn Holmer’s excellent site which has an excellent collection of languages for the Commodore 8bit computers.

And among them was the first C compiler I’d ever owned, SUPER-C!

SUPER-C

Towards the end of the effective life of the Commodore 64, people started to dump expensive software on the cheap.  It was a great time to go to the World of Commodore, and see all the great vendors and wares.  And of course feel that ever pervasive shift to the Amiga.  It was where I picked up this fun little binder:

And what about programming in C?

Super-C CCP

It boots up into a CP/M like environment, complete with drive letters.  You can write programs to either be loaded up from the BASIC ROM environment, or the CCP environment.  On the one hand it’s pretty cool, it includes a simple text editor, and the compiler and linker.  But one thing is for sure, using this with a single 1541 is incredibly slow.  The touted Commodore 128 version with REU support would have made it’s insanely slow speeds a little more tolerable.  That and having multiple machines would have been a must.

As interesting as it was to look at, if you really wanted to do anything with C on the Commodore 64, seriously use cc65. There is something to be said for using a cross compiler when you are running at GHZ vs the 6502’s 1Mhz.

OS/2 2.00 CGA on PCem v13

I don’t know why I did it, as honestly I didn’t like it on CGA back when it was a thing.  Also, thankfully the hard disk speed on PCem is way faster than the real thing.  And I’m not complaining.

Installing

Text mode is all the same setup wise, but on reboot the installer goes forward in glorious CGA ‘high res’ mode.  Which is pretty terrible.

Welcome to OS/2!

Yuck.  I guess at the time I just felt lucky that I could at least run it.  Although once I got lucky enough to score an EGA card + monitor.  Anyways let’s continue the horror!

Command prompt

Yep, there is the desktop! .. barely.  The desktop constantly want’s to jump around which is annoying, just as command prompt’s cant decide if they should be black or white.  And the font’s get truncated.  It’s almost as if nobody cared about actually supporting CGA.  Which honestly I’m more surprised that it even made the cut.

Word and the fox

Sure, I could have changed the default font, but why should I?  I know Word 1.1 is very primitive but wow.

To be fair, Windows in CGA is pretty terrible as well.

Could they make the title bar any larger?

Not to mention solitaire on both is nearly impossible between the lack of colour, and the lack of any high resolution.  I suppose the Wyse 700 display ought to be much nicer, if only they had gone through the hell of making OS/2 device drivers.

One neat ‘feature’ of PCem is that it’s CGA emulates the single ported memory, so that the card & host cannot properly share the video memory so for programs not watching the retrace line you get the snow effect. (here is a demo, GP-01 by Genesis Project with snow, and here without snow).

but of course in this day & age all of this really is moot.

learn: Ancient troff sources vs. modern-day groff

(This is a guest post by xorhash.)

Introduction

I’ve been on a trip on the memory lane lately, digging around old manuals of UNIX® operating system before BSD.† In doing so, I’ve come across the sources for the 7th Edition manuals. I wanted to show one part of volume 2A to other people, but didn’t want to make them download the entire 336 pages of volume 2A for the part in question. The part I wanted to extract was “LEARN — Computer-Aided Instruction on UNIX”, starting at p. 107 in the volume 2A PDF file).

A normal person would, I presume, try to split the PDF file. That is straightforward and produces the expected results. I believe I needn’t state that you wouldn’t be reading this if I solved this problem like any sane person would. Instead, I opted to rebuild the PDF from the troff sources provided at the link above.

I am not a very clever man, and thus I completely disregarded the generation procedure that was already spelled out. However, it wasn’t exactly specific anyway, so I didn’t miss out on much.

Getting the sources

So I knew what I needed to do: Get the troff sources. I asked that the Heavens have mercy on my poor soul if this requires a lot of adjustment for 2017 text processing tools. However, a man must do what a man must do. The file in question was called “vol2/learn.bun”. I had no idea what a bun file is, hoped it wasn’t related to steamed buns and clicked it. As it turns out, it’s just what we would call a self-extracting archive today. The shell commands are not very weird, so the extraction process actually worked out just fine. Now I had files “p0” through “p7”. Except what happened to “p1”, the world will never know.

First Steps

I’ve dabbled in man pages before, but that was mostly mandoc, not actual troff.
Accordingly, the first attempt at getting something going was as naive as it could get:
$ groff -Tpdf p* | zathura -
It led to, shall we say, varying results.

really butchered rendering attempt

Clearly, I was doing something very fundamentally wrong. Conveniently, volume 2A also had a lot of troff documentation. Apparently I was supposed to pass -ms and first run tbl(1) over the troff source before actually giving it to groff. That sounded like a good idea, but the results were still somewhat off:

not very butchered rendering attempt

Allow me to express my doubts that this text was written in 2017. If you compare the output with the known-good PDF, you’ll also notice that, somehow, “Bell Laboratories, Murray Hill, New Jersey 07974” turned into “CAI”. Unfortunate.

Back to Square One and Pick Up the Breadcrumbs

Continuing to read the page I got the learn.bun from, I also spied a section called “Macros and References”. That sounds relevant to my interests. tmac.s, which after studying groff(1) seems to be what would get used with -ms references some files in /usr/lib/tmac. I was not in the mood to let this flood over into my system, so I had to make minor adjustments and turn it into relative paths. I also renamed tmac.s to tmac.os to avoid colliding with the one provided by groff, making the new invocation:

$ tbl p* | groff -M./macros -mos -Tpdf | zathura -

Now we’re getting somewhere:

almost not butchered rendering attempt

It’s better than the previous attempts. But there are also some warnings and problems that need cleaning up:

  1. There’s a note that Bell Laboratories holds the UNIX®
    trademark, which is no longer true.†
  2. Now, this most certainly was not written in December 21,
    19117, either.
  3. tmac.os:806: warning: numeric expression expected (got `\')
  4. Every time the .UX macro was requested, I got:
    warning: macro `ev1' not defined (possibly missing space after `ev')
    environment stack underflow

Point 1 was easy to address, it’s a simple text change. Point 2 was caused by spurious dots in front of a call to .ND. However, the actual volume 2A PDF said a different date than in the file, so I adjusted that to match (June 18, 1976 to January 30, 1979).

And Down the Slippery Slope

As for points 3 and 4… Let’s just say groff/troff macros are definitely not meant to be written or read by humans and it’s a feat comparable to magic that someone wrote this set of troff macros. Line 806 is .ch FO \\n(YYu. Supposedly, that changes the location of a page trap when the given macro is invoked. The second argument is meant to be a distance, which explains why groff is complaining. I tried to checked what groff does and left none the wiser. FO seems related to the page footer, I seemed to get away with just deleting that line, though.

Finally, point 4. Apparently, .ev1 was used multiple times in the tmac.os. This looked like it should’ve been .ev 1 instead. Changing those, lo and behold, .UX stopped behaving funky for the most part. Yet for some reason, I’d still get multiple footnotes about the trademark ownership of the UNIX® trademark.† tmac.os sets a troff register (GA) when the .UX macro is first encountered so that the footnote is only made once. The footnote is being made twice. Something does not add up here..AI (author’s institution) resets GA, but the first .UX comes after .AI, so that’s not the problem. Removing the .AB/.AE macros from page 1 caused only one footnote to be made. Thus, I infer it’s actually intended behavior that the footnote is made once for the abstract and once for the main body. Checking with the volume 2A PDF again, I realized that point 4 was, in fact, fixed just by the ev1 changes and I was just chasing a bug that does not exist. I really should’ve checked the PDF twice.

The abstract finally looks okay.

good rendering attempt

Done! Wait, No, Almost

Okay, we’re done, we can go home, right? Almost, one last thing to do: On the last page, there’s something really important missing: the bibliography. Instead, there’s just “$LIST$” there. We can’t just turn Brian W. Kernighan and Michael E. Lesk into plagiarists!

Back to the troff documentation in volume 2A, there’s a match for “$LIST$” on p. 183. Apparently I need a reference file and preprocess the file with refer(1). That sounds simple enough. Fortunately, I got the reference file along with the macros above, so I didn’t have to look for that separately.

$ refer -pRv7man -e p* | tbl | groff -M./macros -mos -Tpdf | zathura -

half of the references are blank

Of course. Why would it work? That’d have been too much to ask for.
At least I get some nice hints:

refer:p2:148: no matches for `skinner teaching 1961'
refer:p3:114: no matches for `kernighan editor tutorial 1974'

The troff documentation conveniently explains the format for the reference file, so I could just add these two entries to Rv7man and be done with it. Thankfully, the pre-compiled PDF of the volume 2A manual had the information necessary to compile the bibliography entries with.

%T Why We Need Teaching Machines
%A B. F. Skinner
%J Harvard Educational Review
%V 31
%P 377-398
%D 1961

%T A Tutorial Introduction to the Unix Editor ed
%A B. W. Kernighan
%D 1974

now that’s what I call a bibliography

And of course, here is the product of this whole ordeal.

Closing Remarks

The Heavens were feeling somewhat merciful, but only just enough that I could waste no more than a day on this project. They really wanted me to spend that day on it, though.

On a side note, “the missing learn references” aren’t available from the link that was
provided. http://cm.bell-labs.com/cm/cs/who/bwk/learn.tar.gz is now down, though the web archive still has it. Needless to say, I didn’t read that.

I will never, ever touch troff/groff again. mandoc is good at what it does and I’ll stick to mandoc for writing man pages. But if I ever need to get something typeset nicely from plain text?

LaTeX is the answer.
Not troff.
Never troff.
Not even once.

†UNIX® is a registered trademark of The Open Group.

OS X Server 1.0 on Qemu (almost)

booting

I was pretty amazed to see it even get this far.  Credit to Steve Troughton Smith for his patched BootX, which gets the boot process this far.  It’ll actually start the NeXTSTEP style install, but the keyboard won’t work either USB or ADB.  Oh well.

..\qemu-system-ppc.exe -L .. -m 256 -drive file=MacOSXServer10.iso,index=0,format=raw,media=cdrom -drive file=BootX_custom.dmg,index=2,format=raw,media=disk -drive file=bla.disk,index=1,format=qcow2,media=disk -prom-env “boot-device=ide2:2,\BootX” -prom-env “boot-args=-v rd=sd0 debug=0xffe kdp=2” -prom-env “boot-file=ide0:11,\mach_kernel” -g 800x600x8 -device adb-keyboard -device adb-mouse -cpu G3 -M g3beige