In the USA, Kingston supports cross-shipment. So I already have my replacement RAM. Two days later.
With a lifetime warranty and such speedy RMA/warranty service, I think they’ve earned my money for life.
Archive for March, 2007
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 »
Losing my memory
Posted by Trixter on March 28, 2007
In 25 years of personal computing, I have never once had RAM go bad on me. So when my Athlon box started to reboot randomly, I was initially at a loss to troubleshoot it. It was only after a few sobering minutes in memtest86 and switching sticks from slot to slot that I learned both of my KVR400X64C25/512 sticks were bad. No idea how they got that way; one was REALLY bad (half of it is trashed), and the other I probably could live with (only a few single-bit errors) but I filled out an RMA for both of them anyway. I don’t need my main desktop randomly flipping bits on me.
I learned two things from this experience:
- Lifetime warranties are good.
- With my Athlon out of commission for a week, it’s so… quiet in here.
Maybe I’ll finally get some console game-playing in.
Posted in Technology | Leave a Comment »
8088 Textitude
Posted by Trixter on March 26, 2007
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 :-)
Posted in Technology, Vintage Computing | Leave a Comment »
GDC Highlights from a Sick, Sick Man
Posted by Trixter on March 18, 2007
(This post is a week late, but posts are usually better late than never.) I went to GDC the first week of March, and although I was incredibly sick the entire time and missed 90% of the conference, I did manage the following highlights which made it all worthwhile:
- Finally met Mike Melanson, reverse-engineer virtuoso of video and audio codecs, because he lives in the area. Went to dinner with him and the local MobyGames crew (Flipkin, Ron, Tom Servo) and had great food in a great bar called The Chieftain. (Despite the name, it was an Irish/California-themed bar.) I quickly lost my voice, but it was worth it.
- GDC awards ceremony. Graeme Devine presented a community award to The Fat Man; Lord British awarded lifetime achievement to Miyamoto, who accepted in person; some Sam & Max jokes; great fun. Presented by Tim Schaefer who cracked jokes. Excellent vibe. That was the only time I saw Simon Carless (on stage) as he was too busy to meet with anyone during the event. Our MobyGames intern rushed Miyamoto and shook his hand as he got off stage. Whore :-)
- Later that night, we went to a bar looking for food and I quite literally bumped into The Fat Man by accident and we talked for 10 minutes. He loves Moby; I love his music; it was something I always wish I could have done and now I have. That guy deserves more work.
- Thursday I met Chris Hargrove (Kiwidog / Hornet) and some other sceners. Chris was this chance thing — I literally screamed to him from the booth when I recognized him. Hadn’t seen him since he crashed at my place a decade ago. We talked about why Duke Nukem Forever has been delayed for so long; caught up on other stuff; he gave me the skinny on what finally happened to Tran. Nice catch-up.
- Thursday went to the programmer’s challenge and got a few right (to myself — the gameshow was for the super-talented panel) . Some questions/answers were played for laughs. Some scary smart people on that panel…
- Friday participated in a game preservation roundtable sponsored by IGDA and am now a member of the group (!).
- Met Jeff Roberts of Rad Game Tools and expressed my appreciation of his Smacker video codec, a low-resource codec used in hundreds if not thousands of DOS games. Always wanted to do that.
Sick, sick, and more sick, had three fevers, just now this week getting over it. Because of fever I was in the hotel room half the time, only saw Miyamoto at the awards and missed his keynote. I also had to leave Friday afternoon and missed the demoscene party that Pyro throws every year after the event… Still, I’ll never forget it and am glad I went.
Posted in Demoscene, Gaming | 5 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 »
Oldskooler Ramblings 