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.
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.
Although for me, I really bought it for the manual.
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!
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.
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
Well it’s a bunch of assembler files. Ok, so when I try to open one from System 6.0.1 I get this:
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.
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.
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.
(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 are just no serious apps available.
Calamus is a professional DTP (Desktop Publishing) software. It’s still actively developed and sold by German company Invers. If you want to play around with the latest version you can download a 30 day trial and even purchase the Lite version for 99 Euro on calamus.net. There are versions for Windows, Mac and 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 and it was much cheaper than Mac. 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 in order to expand to other hardware platforms. An interesting fact is that the port isn’t really a full source code rewrite, which would be impossible due 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.
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.
And this is how I finally found a copy Calamus NT with support for RISC CPUs. It took me quite a lot of time and resources to track down and obtain copy of surviving media from owner of a publishing studio. This is how it looks when you first install it:
Note that there were separate builds for 386/485 and Pentium CPUs. Also as you can see the disk contains a demo version which now Santa is delivering to you. This is a fully functional trial that expires after some time. If you ever lacked serious apps for your RISC NT machine, you can how play with one! The demo version is distributed with permission of Invers Software.
If you don’t have one of these machines you can still run Windows NT MIPS on Qemu:
And finally to the goods. You can download following files:
And among them was the first C compiler I’d ever owned, 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?
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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:
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:
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.
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.
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
%T A Tutorial Introduction to the Unix Editor ed
%A B. W. Kernighan
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.