Oldskooler Ramblings

the unlikely child born of the home computer wars

Archive for the ‘Programming’ Category

Next Entries »

8088 Videos

Posted by Trixter on June 25, 2007

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.

Posted in Demoscene, Programming, Vintage Computing | 11 Comments »

8088 Corruption Explained

Posted by Trixter on May 13, 2007

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.

Posted in Demoscene, Programming, Technology, Vintage Computing | 6 Comments »

The crazy upside-down world of 8088 hardware programming

Posted by Trixter on March 28, 2007

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.

Posted in Programming, Vintage Computing | 4 Comments »

Oldskooler is wrong!

Posted by Trixter on March 18, 2007

In my last post, I stated that interrupts were supposed to be disabled on an 8088 for a MOV to the stack segment register (SS). Turns out that interrupts are supposed to be disabled during ALL segment register moves, not just SS! That explains why the procedure works to test if you have a buggy CPU or not:

Start DEBUG and run the following commands:

-A 100
MOV ES, AX
INC AX
NOP
-T

All registers are displayed at this point, where you want to look at the value in the AX register. If it is “0000” your 8088 CPU has the bug. AX = “0001” means your CPU passes the test & does not have the bug.

Why does this work? The T(race) command tries to single-step the MOV ES,AX instruction, but on a working cpu, the trace will include the INC AX as well, before the cpu stops so that you can check the result (value in AX). You can just as easily check the IP value, i.e. the position of the next opcode to be executed: If this is INC AX then you have a buggy cpu.

Many thanks to the venerable Terje Mathisen and DJ Delorie for cluing me in.

Posted in Programming | 1 Comment »

Post something, dammit!

Posted by Trixter on March 17, 2007

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.

Posted in Programming, Technology, Vintage Computing | 2 Comments »

Government workers are so very helpful

Posted by Trixter on October 25, 2006

In all my days of computing, the software that has impressed me the most has been software that pushes a machine seemingly beyond its limits, making it do things that it was never meant to do. One such piece of software was ICON: The Quest For The Ring. It tweaked CGA to within an inch of its life, displaying 16-color graphics on a video card only meant for four ugly colors in graphics mode.

I’m a software collector. I collect vintage retail packages of software as a hobby. (I’m comfortable enough with my nerditude to admit this, so go ahead and mock me — I don’t mind.) So imagine the nerdly dance of joy I did when I found that ICON was up for auction, bid on it, and won! The package I’d been searching for for over two decades, the game that had inspired me to learn assembler and graphics tweaking, the game that shaped my hobbyist world, would finally be mine!

That’s where the governmental workers come into the story. It seems that they were in need of a football to relieve the overwhelming tension and stress of delivering packages, so what I actually received was this:

If you’re not familiar with the hobby of software collecting, I can sum it up in five words: The Value Is The Box. 90% of a software collectable’s value is in how good a condition the box is, then the printed materials inside it, then the diskette labels, then finally the actual software code itself. (Why? Because most software has been pirated already… and most people throw away the box and lose the manuals.)

My twenty-year dream quite literally crushed, I decided to visit my local US Postal Services office to file the claim for the $50 I had paid for it. And this is where we again meet our lovable and cute governmental workers, for here is what I learned today about insuring packages:

  1. You have to provide proof of the item’s value. So if the USPS determines that your item is worth less than what you insured it for, and you cannot provide any “documented proof” (the validity of which is at the government worker’s discretion, of course) that it is worth more, you get what they are willing to give you, not what it is actually worth. This is how they justify giving you less money than the value you wrote down on the form when requesting insurance, they always offer a very cheap car insurance but then you end up with such bad service or no service at all.
  2. You cannot insure something for more than what you paid for it. See #1 for rationale. So if you completely luck out and find an Akalabeth with a Buy It Now of $4, the most you can insure it for is $4 even though its value is anywhere from 10 to 150 times that value.
  3. If your item is only slightly damaged, and you want to keep it, you can’t. You must completely give over every single thing you are filing a claim for, never to be seen again. This means that there is no protection against *partial* damage — if it’s partially damaged, bend over, since you can’t get partial money for it.

See, all this time I was under the silly impression that, if you insured something for a certain dollar value, that was the value they were going to give you when you showed them it was damaged. Or that maybe, just maybe, you were insuring it against partial damage — like depreciation or something. How wrong I was: Insurance is only protection against complete and total destruction of property and/or complete and total loss of delivery. If it *arrives*, and is only *somewhat* damaged, you’re shit out of luck! How glad I am to be educated! (although I could have done without the “bending over the table” portion of my education)

So what did I do? I made the obvious determination that something I had been searching two decades to locate — in *any* condition — was worth more than the $15 or so they were going to give me for it. So I tore up the claim form, took back the item, and left. Since then, I have been researching cardbox box reconstruction techniques, for I am not only a nerd, but a stubborn nerd.

About the only satisfaction I got from today’s visit was the audible popping noise the government worker’s synapses made snapping apart into individual neurons as I tried to explain that, yes Daisy Mae, the value really was the BOX itself and not the contents inside it. The complete and total lack of understanding confused her to such a degree that she was unable to blink her eyes in unison for at least 10 minutes after I stopped talking. I could have done without the drool, though.

Posted in Gaming, Programming, Software Piracy, Vintage Computing | 5 Comments »

The Zen of Programming

Posted by Trixter on April 24, 2006

I ran across this quote from Peter Jennings (the programmer, not the newscaster) and thought it was worth republishing. It almost completely expresses my love for coding:

I love programming. It is almost impossible to explain the joy of writing software to someone who has not experienced it.

First and foremost, it is an act of creation. From a simple thought, and the arrangement of a few words and symbols, a reality is created that did not exist before.

No other activity can keep you in the moment the way that writing software can. At each step, one hundred percent of your concentration is applied to the solving of the current problem. Time disappears.

A well written program is a work of art. From conception to final presentation, the activity is that of an artist – the embodiment of a dream world expressed as an interactive experience for the user.

Peter was the author of the first commercial computer game, MicroChess, for the KIM-1 (yes, I'd never heard of it either until today). It's a chess program that runs in 1K of ram (variables and code).

Posted in Programming | 3 Comments »

I’ve been Dugg!

Posted by Trixter on January 24, 2006

One of my hacker-ish projects was featured on digg.com. It completely ripped my home network infrastructure asunder.

I will be moving my home network infrastructure to something a little more robust in the coming weeks. :-)

Posted in Demoscene, Programming, Vintage Computing | 3 Comments »

8088 Corruption

Posted by Trixter on January 13, 2006

I just put up a web page on 8088 Corruption, my program that plays video synced with audio on an original IBM PC.  What’s significant about the page is that I include a video file you can play if you don’t have an original IBM to run it on.

Posted in Demoscene, Programming | 28 Comments »

Programmers: Deeper understanding of video games?

Posted by Trixter on January 11, 2006

Being a programmer for two decades has given me a special insight into video games; because I know how the majority of them are programmed, hardly any of them feel foreign to me. I may not be a master at any one particular game, but I can definitely pick them up quickly.

This has led to some chuckles along the way. Two games popular around the house lately have been Need For Speed Underground 2 and Ratchet: Deadlocked. In NFSU2, you can use a simulated GPS to continuously point an arrow to your destination so you can find it easier. When you first select the destination, it pauses for a few seconds with the text “Searching Connection: Unable to contact Satellite”. Sounds like a cute simulation, yes? Because I’m a programmer, I know what’s actually happening: The pathfinding algorithm is slow and taking a few seconds to plot the quickest path to the destination. The programmers of NFSU2 masked that pause with the “Searching Connection” message so the user wouldn’t see it as a flaw.

As for Ratchet: Deadlocked, there is a 2-player cooperative mode where you can play through the game with a friend. If the two of you get too far away from each other while playing, the game threatens to blow the both of you up if you don’t get closer to each other again. While this looks intentional, I have a very strong suspicion that it is there to mask a limitation of the game engine — such as, if both players are too far away from each other, that’s too much geometry for the engine to cache and fling around.

I’d be curious if anyone else notices things like this…

Posted in Gaming, Programming | 5 Comments »

Next Entries »