Oldskooler Ramblings

The question of which DOS-era floppy backup program was “best” has always bothered me over the years, so today I spent the better part of an afternoon satisfying my curiosity. (By “floppy backup program”, I mean programs that intelligently used high-speed DMA to format and write backup data while the computer was doing other things in the background, like reading from the hard disk and compressing the data.)

Results are here, for the curious:

http://www.oldskool.org/guides/dosbackupshootout

If I missed an obvious one that runs on XT-class hardware, let me know.

No, this is not an extremely well-researched elaborate April Fool’s joke; I’m actually serious this time. In this post, I’m going to illustrate ways you can beef up your AT&T PC 6300, just stopping short of throwing it in the garbage and replacing it with an XT clone.

The AT&T PC 6300 was AT&T’s attempt to get into the personal computer market in 1984. AT&T bought the rights to sell the Olivetti M24 in the USA and made it available as the “PC 6300″ in late 1984. It exceeded the IBM PC in just about every way:

• It used a 7.16MHz 8086, about 1.7x the speed of the IBM PC’s 4.77MHz 8088
• The graphics mode could go as high as 640×400 (which also resulted in sharper text in normal text modes)
• It had special expansion slots that could be used to turn it into the 6300+, which would run AT&T UNIX, or install expanded memory boards (usually required to run AT&T UNIX :-) although the memory could be used as EMS under DOS)
• It had a few aesthetic improvements: it was smaller and lighter than the IBM PC, and the floppy drives were whisper-quiet
• It contained a battery-backed internal clock chip that would remember the time and date even if powered off
• Like Sun machines, the keyboard had a special mouse port on it, so you could buy a 6300 mouse and attach it to the keyboard. Not only did this save desktop area from cable mess, but the “keyboard mouse” had a wicked cool property: If you had no mouse driver loaded, moving the mouse would automatically press up/down/left/right arrow keys for you! You could use the mouse to navigate any program, regardless of whether or not it supported a mouse.

The problem with the 6300 is that those enhancements required many proprietary changes to the unit; they also didn’t predict how long the computer would be useful into the 1990s. These two factors led to some nasty surprises the longer you owned one:

• The enhanced video required special monitors, and could not easily be replaced with an EGA or VGA card without extreme hardware preperation. Repairing the special monitors was also quite costly; I remember a $300 charge to repair a blown flyback transformer on mine. That repair took two very long months…
• To support the mouse attachment, the keyboard had a non-standard 9-pin DIN, so you could only hook up AT&T keyboards to it. (Thankfully, there is a schematic on the web you can use to build an adapter to hook up PC/XT keyboards to it.)
• The motherboard, in an attempt to save space, has slots on the top side but the components and headers on the bottom side. This was a major pain in the ass if you had to reroute cables through the machine (as I had to do when installing a Central Point Option Board).
• To properly support the 6300 100%, you were strongly encouraged to use AT&T MS-DOS. Other DOS variants, including IBM’s true blue PC-DOS, wouldn’t support the built-in clock chip and other 6300 features.
• Tweaking CGA, at Seven Spirits of Ra extremes, did not look right with the higher-resolution text mode.
• The aforementioned clock chip was worse than not being Y2K-compliant — it wasn’t even Y1992 compliant! AT&T used only 3 bits for the year, starting at 1984, which limits the machine to the years 1984-1991. Trying to set the date to anything past January 1st 1992 has the year locked at 1991.

While the above prompted most owners to punt them past 1992, the PC 6300 remains a very interesting compatible in every sense of the word. I still own mine 23 years later, and for those who would like to restore theirs to prime game-playing condition, I am happy to share my secrets on how to “mod” your AT&T PC 6300:

• Replace the 8086 CPU with an NEC V30. This will boost the machine to 2.1x the speed of an IBM PC.
• Try to find the 1.43 BIOS chip upgrade if your machine doesn’t already have it (you can see what BIOS revision you have when booting the machine). The enhanced BIOS chips (there were two in the upgrade package) obviously improved program compatibility, although the major players such as Flight Simulator and Lotus 1-2-3 already ran fine. They’re also required if you want to run Microsoft Word for DOS in high-res WYSIWYG mode (see below), but be careful when you install them: They’re not notched, and putting them in backwards will release the magic smoke in about 3 seconds. Please don’t ask me how I know this.
• Run programs that support the 6300’s special 640×400 graphics mode so you can feel good about maintaining a proprietary clone and monitor. For example, lots of graphical viewers like CSHOW will display B&W gifs at that resolution (and before GIF we had MacPaint images, and the 6300 had a 640×400 MacPaint viewer). There were also some games that could use 640×400, like The Colony. Also, FRACTINT (fast fractal exploration program) will use the special graphics mode. As previously mentioned, Microsoft Word for DOS 4.0 and later will use 640×400 for on-screen WYSIWYG (ie. you italicize a word and it actually shows up italicized. Look, we had it really rough in the 1980s, ok? Please stop laughing!)
• If you don’t care about 5.25″ floppy compatibility and have a hard drive, flip the DIP switches on the motherboard to enable 96 TPI mode for the floppy drives. You won’t be able to read 5.25″ regular DSDD 40-track disks any more, but you will be able to format 5.25″ disks to 720K (the drives pack 80 tracks onto a disk in that mode). This is really for personal yucks only, as you will only be able to read such disks on a 1.2MB drive.
• The speaker in the 6300 sucks; make a cable with alligator clips you can use to clip onto the speaker leads and run it to a set of speakers or a stereo.
• Install an 8087 math coprocessor and run some of the more crazy fractals on FRACTINT (see above) without waiting overnight.
• If you’re handy with a dremel and have the hard drive model (one floppy drive and one hard drive), cut a vertical 3.5″ drive bay into the front of the case, about one inch to the left of the drives. You can then add a second drive, a 720K 3.5″.
• Install a hardcard for a 2nd hard drive (or first, if you don’t have one). I used a Plus HardCard 40 myself.
• Install a Sound Blaster for some audio fun. For maximum enjoyment, use an original Sound Blaster 1.0 at IRQ 2 or 3, so you can get early programs with buggy SB support playing digitized sound, like Rise of the Dragon, Stellar 7, or Tongue of the Fatman.  (Rise of the Dragon has particularly nice opening digitized audio.)
• If you can find one, try to obtain an AT&T PC 6300 memory board (with software .sys driver!) so you can have 2MB of EMS in the machine. It helps with Lotus 1-2-3, but it really helps as a giant disk cache.
• For that matter, try to find the 6300 mouse. Moving the cursor around with a mouse in text apps that don’t support mice is a trip.

All of the above modifications will enhance your enjoyment of the 6300 while still keeping it distinctly 6300-ish. Some are difficult (dremel’ing a drive bay), but the effort is worth it.

Or, you can buy my 6300 off of me. For one meelyion dohlaars.

I’ve finished what I consider to be a workable alpha of MONOTONE and am distributing it to a few testers. I hope they forgive me :-)

It is functional enough to compose tunes on, but the real work will be done at Block Party next week, hopefully in the demo room if we have enough space there. I’m bringing a PCjr and am hoping to add support to what will be the world’s first PCjr tracker. If you’re attending, please stop by and feel free to mock me :-) or just talk about hacking, programming, the demoscene, whatever. But no heckling me during my talk Saturday afternoon!

Video for the curious and bored:

I have one major and two minor things to add to MONOTONE and then I simply can’t work on it any more before the party (I have to work on my presentation). So what do I do? More procrastination!

Today’s experiment is in HD; while the encoding didn’t work quite the way I wanted it to, you can still make out the text on the screen.  View it full-screen for your best chance at doing so.

After having a cold for 4 days and hacking up half a lung, I feel less like coding and more like procrastination.

So today, we have an experiment for y’all.

One of the side effects of designing a tracker completely from scratch, using the best software design I can muster, is that everything is virtualized. A song is an object; the player engine is an object; the output device is an object. I’m probably going to make the editor an object itself, if just to keep the source consistent.  The nice thing about objects is that they can be abstracted and used as “parents” for descendant objects. So I have done just that for the internal speaker output. So that leads to some good news and bad news:

The good news is that the tracker will probably come with basic support for the Tandy/PCjr sound chip, and Adlib, and heck probably the CMS as well, out of the box, all in addition to the internal speaker.  This is because once the parent object is done, it’s easy to create a descendant for each output device.  And it will make it easier to add more complex internal speaker support in the future, such as mixing 3 or 4 voices realtime for “true” multichannel output from the speaker.  Just don’t expect the Adlib to sound better than the rest — I have a common denominator to target, and it ain’t 9-channel FM instruments.

The bad news about all this is that the tracker is still mostly in my head and not on paper. Which means I may only have a tracker to enter into the wild compo at Block Party instead of a demo. Or neither, considering that the presentation I’m giving takes precedence over compos :)

If I were never releasing the code, I could’ve hacked something together by this time already.  But I am, and I want people to be impressed by the code as much as music (democoder background, remember?  Both form and function are equally important :-)

All (and I really do mean all) of the hardware info for low-level PC programming available on the internet today is for ATs and later. Which didn’t help me debug my keyboard handler, as I’m on an XT and the behavior is different.

So I got fed up with looking and decided to just locate the BIOS’ own keyboard handler and see what it’s doing:

c:\>debug
-u f000:0d78
F000:0D78 50            PUSH    AX
F000:0D79 53            PUSH    BX
F000:0D7A 51            PUSH    CX
F000:0D7B 52            PUSH    DX
F000:0D7C 56            PUSH    SI
F000:0D7D 57            PUSH    DI
F000:0D7E 1E            PUSH    DS
F000:0D7F 06            PUSH    ES
F000:0D80 FC            CLD
F000:0D81 E88EEC        CALL    FA12
F000:0D84 E460          IN      AL,60
F000:0D86 93            XCHG    BX,AX
F000:0D87 E461          IN      AL,61
F000:0D89 8AE0          MOV     AH,AL
F000:0D8B 0C80          OR      AL,80 <--Hey, that's
F000:0D8D E661          OUT     61,AL <--new!!
F000:0D8F 86E0          XCHG    AH,AL
F000:0D91 E661          OUT     61,AL
F000:0D93 FB            STI
F000:0D94 93            XCHG    BX,AX
F000:0D95 B44F          MOV     AH,4F
F000:0D97 F9            STC

So, after reading the scan code from port 60h like on ATs and later, the PC/XT is also finding it necessary to acknowledge the scancode by setting bit 7 on port 61. Thanks for nothing, intarweb!

This is an example of why I tell my co-workers at my Unix sysadmin job that my old DOS knowledge from 1983 helps me in all of my computer work: Because basic troubleshooting skills are basic troubleshooting skills. Computers are pretty much the same; if you train yourself to think a certain way, it will lend itself to other computer problems.

If this post seems incoherent and not an example of my best writing, that’s because I just got finished playing my first game of Team Fortress 2 and my vision is still blurred. The last online FPS I played, Counter-Strike, was in 2004… I’m way out of practice and still quite disoriented.

I couldn’t save my old XT keyboard (enter key died, and that’s pretty much the #1 most important key on the damn thing) so it has been tossed into the spare parts bin. My remaining keyboard, however, survived my pokings and I have a functional XT keyboard again. My last, but beggars can’t be choosers.

Thanks to a functional keyboard, I started working on MONOTONE again, starting with the interface (the design docs are done — yes, design docs — hey, stop laughing!) except that I was immediately sidelined by my custom keyboard handler.

A keyboard handler, for the uninitiated, is a little routine that “replaces” the “hold-key-down-and-watch-it-repeat-after-a-short-delay” behavior with “hold-key-down-and-it-stays-down-without-beeping-incessantly” behavior. This is good behavior, if you want to make your keyboard act like a piano. But my trusted old handler code locked up the machine after the first keypress.

Here is the code in question, which I had been using since 1994:

Procedure New9handler; Interrupt;
Var
  b: Byte;
Begin
  port [$20] := $20; {send end-of-interrupt to PIC}
  b := port [$60];   {read scancode from keyboard}
  If b < 128
    Then kbd [b] := True
    Else kbd [b And 127] := False;
End;

On keyboard interrupt, grab a friggin’ character and stuff it in a bitmask array. Easy as pie. Yet the XT locked up, so I am clearly doing something that the XT is allergic to (or, more likely, forgetting to do something). So now I get to research early XT keyboards/signals and try to figure out what I’m doing wrong. Luckily, I have a lot of programming books to consult; here are the ones I’m going to take to bed:

• Compute’s Mapping the IBM PC and PCjr by Russ Davies
• The Undocumented PC by Frank Van Gilluwe (founder of V Communications — thanks for Sourcer, Frank!)
• Sam’s IBM PCjr Assembler Language by David C. Willen (why a PCjr-only book? Because eventually monotone will support PCjr — ssh, keep it a secret!)
• Compute’s Beginner’s Guide to Machine Language on the IBM PC and PCjr by Christopher D. Metcalf and Marc. B. Sugiyama
• Assembly Language Primer for the IBM PC & XT by Robert Lafore

Overkill, but I want to check them all so that I can get all the info on handling a keyboard interrupt and then pick out what I need.

I know all this seems stupid and unnecessary, and makes me seem like a freak, but honestly it is the reason over the years I have gravitated towards older and slower platforms to code for fun on. It’s the same reason people still code demos on the Commodore 64 and other legacy platforms: They are fixed in nature, which means you can truly discover the absolute fastest way to accomplish a particular task on them. It’s impossible to do this on a modern winbox, because winboxen are moving targets. It also explains perfectly why modern demos have evolved in the last decade the way they have, but that’s a topic for another day.

PS: The last book by Robert Lafore is the best book you can read to learn assembler on an IBM PC. It teaches you the basics by making you assemble, by hand, in DEBUG. It sounds incredibly scary and hardcore, but it’s actually very fun!

A lot of old gamers continue to beat the dead horse of “The games were better when I was a kid!”  While there are a ton of reasons why this is just nostalgia rearing its ugly head, there is one very strong reason this is true in some cases:  Since the graphics and sound of early home computers were so terrible compared to arcades of the day, game designers had to focus on actual game design and not just excuses to blow shit up.

I bring this up because my eight-year-old son Max and I just finished playing Archon for the last 90 minutes.  We didn’t even play it on one of the “cool” platforms, like NES or Amiga, but rather on one of the ugliest ports: The IBM PC.  Terrible sound, horrible graphics, and yet none of that mattered.  In 3 minutes I was able to explain the basics, and then 90 minutes later we were still laughing at each other for some crazy battle.  The entire time, I couldn’t get over how basic game design still reigns supreme, 25 years later.

The 5160 (PC/XT) has gotten significant use this weekend; not only was I finishing up the design docs for BeeperTracker (which Jason Scott is heavily lobbying to rename MONOTONE, which will ultimately prove successful), but Max was bored and we spent time playing old games on it.  Unfortunately for me, the use was significant enough that the keyboard’s spacebar stopped working.  Normally I’d whip out another one and keep going, but this was, in fact, my last 83-key keyboard that had a functioning spacebar.  I pried all of the keys off and cleaned out all of the gunk… only to find that the spacebar doesn’t go back on the way it came off, as there are two metal prongs that need to fit into holes.

I’m terrified of taking the plate off of the back (buckling springs everywhere!) so I’ve asked the Classic Computer Mailing List for a more official way to repair it.  Until then, I’ll be playing Half-Life: Episode 2.