Oldskooler Ramblings

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.

Several times in my life, I’ve asked a question that nobody could answer. Sometimes I wait patiently and the answer comes one decade later (such as a walkthrough to Tass Times in Tonetown) or even two decades later (the solution to Hack). Other times, my need for information is too great and I research it myself (8088 Corruption) or architect a solution that can provide me the answer (MobyGames). The latter is a lot of work — I greatly prefer the former, as does everyone. But it doesn’t happen often, and sometimes I write off the entire cause and forget about it.

Today, however, I had one of those moments. I’m a compression geek, with a focus on high-performance decompression. I’ve always wondered how well real-time disk compression products like Stacker, Drivespace, Doublespace, SuperStor, EZDrive, etc. performed. How fast were they at compression? Decompression? How much compression did each achieve on a set of test data? Well, today I stumbled across this:

Real-time Data Compression Algorithms’ Benchmarks

After everyone is in bed tonight, I am setting aside an entire hour with a comfy chair to sit in and a pop to just… soak it all in.

Just a quick note that I’ve rewritten the 8088 Corruption page substantially, posted a new video player, and posted all of the sample videos in my talk along with a few extra ones.

I appreciate all of the nice comments I’ve gotten regarding my lack of motivation (ie. possible depression); again, thanks.  I’m battling it now with a mixture of work, playing Worms with the kids, trying to speed up 8088flex even more, and a mystery fourth ingredient.  What could it be?  Why, it’s mysterious!  When I finish ingesting the fourth ingredient, I’ll post about it here.  It’s… immersing.

I had hoped to completely update the 8088 Corruption webpages before posting this, but it’s going to be at least another week and people have been asking me for it, so: An edited video of my NOTACON/Block Party 8088 Corruption Explained talk is available at archive.org. All of the embarrassing and missing parts have been fixed, added, edited, massaged, spindled, and mutilated, and it should be completely watchable. I replaced most of the bad video-camera-aimed-at-the-monitor footage with the actual conversion footage, filled in the hey-where’d-my-electricity-go? missing section with a voiceover, replaced all filmed slides with the actual slides, and took out two embarrassing swears (embarrassing not because they were swear words, but because I was nervous and stumbled over them).

While it is tempting to watch the flash version in a browser, I went through a great deal of trouble to make the MPEG-2 version perfect, including true 60Hz video in places. If you can spare the time, grab the MPEG-2 version and watch it on a real set-top dvd player for full effect. (Or a software player that isn’t broken; for example, use my favorite MPEG-2 player, VLC, with Deinterlace set to Linear.)

Work and home have been particularly busy this week and will be next week, so I apologize in advance for not having the extra movies, updated 8088 player, full source code, etc. available on the website yet. When I do, I’ll make a note of it in this blog.

I’m rewriting the 8088 Corruption player for the talk I’m giving at Block Party. No doubt this is a form of procrastination (I haven’t even done any PowerPoint slides yet) but I also have a fear of the player crashing when I’m showing it off, which would be a serious blow to my fragile ego. For one particular demonstration, I was going to wow the audience with a double-rate version of Corruption. Yes, 60 frames per second on an XT. The memory speed is there, but there’s so little CPU time left over that the poor disk can’t keep memory filled, and it rebuffers constantly — every four seconds, which is hardly fun to watch.

(This is going somewhere; trust me.)

Although it would be “cheating”, I have a hardware LIM EMS 4.0 board in my 8088 with 2MB of RAM in it. Last night I started to write a version of the player that buffered to EMS, then to system RAM where it could be transferred to CGA RAM. I figured, hey, maybe I can delay the rebuffering for a few more seconds for the presentation so I don’t look like an idiot.

I found that doing so was slower than simply reading the data from disk right into regular memory. You read that correctly: RAM buffering was slower than hard disk buffering. WTF?

I thought about why this might be, and when I figured it out, I started laughing. It’s a perfect example of just how wrong it is what I’m doing. Here’s the explanation:

• Old IBM PCs have a DMA controller in them to move memory around instead of forcing the CPU to do it. On a PC/XT, it’s primarily used when reading from disk, because the slower the disk, the slower the transfer and the longer the CPU would be hung up. The DMA controller can move a byte of memory in one cycle, giving it a maximum memory move speed of about 960KB/s.
• My hard disk, however, is not what the DMA chip was designed to help with — it’s a 340MB IDE drive connected to an 8-bit IDE controller. It’s about 5-10x faster than what was available in 1983. It maxes out around 300KB/s.
• Moving memory around maxes out at a top speed of 240KB/s.

Do you see where this is going? I’ve put a hard disk in my machine whose transfer speed, thanks to copying help from the DMA controller, exceeds the CPU’s ability to move memory around. Let’s word that another way in case it’s not obvious: The hard drive is faster than the RAM.

That’s just wrong.

It is probably the only configuration in the entire IBM PC/compatible family where this is the case (where the hard drive is faster than RAM). Any 286 or higher, with its 16-bit memory accesses, would be faster at moving memory around. Crazy upside-down world of 8088 hardware!!

So I’ll use this newfound realization to write a DMA version of the player to keep memory filled while playing, right? Nope. The only way to do that is to switch to reading absolute disk sectors, and that means the player would work on my machine only. Not an option.

This weekend was spent obsessing over the fastest text editor I could find for a 4.77MHz 8088 that had a functional undo. The results were a bit too lengthy for a blog post, so you can view the article I posted regarding the subject.

Nerd Alert:  If you’ll never type on an XT for more than 10 minutes at a time for the rest of your life, don’t bother reading the article.  There are much better things to do with your time :-)

That was the IM I got from a “friend” who shall remain “nameless” who was “unhappy” with the state of my “blog”. Fine, so I’ll post something, but for the record I have had excuses for not posting the last four weeks:

• Not losing weight, so that alone is depressing
• Went to GDC and was very sick the entire damn time (although I did have some good experiences; more on that later)
• Still sick 2.5 weeks later (yes, I’m seeing a doctor)
• Weathered a layoff storm at work, sometimes violent, sometimes petty
• Child problems at school

etc. etc. My life is actually quite privileged, and it sounds utterly ridiculous to complain, but I am human, which means I’m damaged, and this stuff affects me. I know it’s irrational. I’m sorry.

So, until I can lose some weight or report on some other stuff that is actually interesting to someone, I’m going to Post Something Dammit. Today’s PSD is on the topic of: 8088 CPU bugs. It’s time for some st00pid k0mp00ter history! Yes, the 8088 had bugs in the first iterations. Forget the Pentium FDIV bug; they’ve all had issues from day one :-) Two of the bugs were caught by Intel in 1982-ish, but not until 200,000 IBM PCs were sold. The third was fixed in the 80186.

The first two bugs involved interrupts and the stack. The first bug was that a MOV to SS (the stack segment) did not disable interrupts for the next instruction, meaning that you could get an interrupt in the middle. This is bad, because the interrupt will try to set up it’s own stack (something you were trying to do with the MOV SS!) and the stack is unlikely to recover, taking the machine with it. The workaround was this:


CLI
MOV SS,DX
MOV SP,AX
STI


ie. disable interrupts before you do the switch, then re-enable them when done. Which sucks, but is a good practice that I would imagine most people were doing anyway because they didn’t know that MOV SS,reg was a special case that was supposed to disable interrupts. Hell, I didn’t even know that until I started researching the bug.

But not all was good in Intel land: If you didn’t know the state of the interrupt going in, then you were supposed to preserve it, like this:


PUSHF
POP BX
CLI
MOV SP,word ptr [my_stack]
MOV SS,word ptr [my_stack+2]
PUSH BX
POPF


…except there was a second bug in the original 8088 in the POPF opcode which meant that, even if the state was still CLI after the POPF, interrupts would still be enabled for a single cycle! Try tracking THAT bug down in your program! So the workaround, which is just st00pid, is to fake POPF using IRET. (BTW, the odds of this particular bug cropping up is somewhere in the neighborhood of 1 in 5 million, and only when you switch stacks, so it is such a longshot that I never bother in my own code.)

But wait, there’s more! There’s a third bug where, if you try to use a segment override on MOVS or LODS (ie. so you can attempt to use something other than DS as the source) and an interrupt fires off during, say, a REP MOVSW, it stores the wrong return address. This was fixed in the 80186… I think. Not sure. I’m not sure that behavior is even officially documented so I’ve never had the urge to try it.

So now that I have this giant extra drive on my XT, what should I do with it? Other than the obvious frivolity (such as an entire movie 8088_corr style), backups is the obvious choice since I still actively develop software on it. The best way to do this would normally be rsync, but since I haven’t come across a 16-bit DOS port of rsync that functions properly, the obvious alternative is XXCOPY. Why XXCOPY and not DOS’ XCOPY? Because XXCOPY has rsync-like functionality, where you can have it copy only changed files and also delete non-existant files/dirs in the destination. In other words:

rsync -va --delete <source> <destination>

…is handled by XXCOPY thusly:

xxcopy <source> <destination> /clone /yy

And best of all, the author of XXCOPY is the guy who coded Mad Planets, which was an 8086, so compatibility with my XT is all but assured! (rubs hands in glee)