My laptop sucks. It's an Averatec. Don't buy from them. It overheats badly, and when it overheats, it turns off its CPU fan, which is not exactly the ideal situation, then it turns off. Usually just after the wave of heat hits your lap and you begin trying to use the laptop two inches above your legs (not feasible).
It came to my attention that the problem with this laptop is actually an ACPI bug. ACPI features a scripting language called ASL/AML (AML is the compiled form) which is actually quite neat, it gives a simple byte code for accessing most of the system management features, allowing you to write processor-independent drivers to present standard interfaces to devices such as IRQ controllers, battery chargers, and thermal management. It is, however, code, and as such, it can be written by morons.
ACPI code comes with the BIOS, so before trying to rewrite it myself, I decided to see if perhaps Averatec had a new BIOS. Indeed -- released just a few days earlier. So I downloaded it and it contained WinSFI.EXE and flash.exe and AMIBOOT.ROM. AMIBOOT.ROM is an exactly 512kB file. The other two are shitty Windows-only programs that are supposed to copy AMIBOOT.ROM into my BIOS.
AMIBOOT.ROM can be loaded automatically if you put it on a floppy disk, but my laptop doesn't have a floppy drive (and good riddance). It appears to try to load AMIBOOT.ROM off of the CD-ROM, actually, but I couldn't convince it to actually work, it just kept ejecting the CD tray. So I eventually found AMIFLASH.EXE, which is the standard program to flash AMIBOOT.ROM under DOS. At about the same time I discovered that the FreeDOS bootdisk I had been using featured UNIFLASH.EXE, which is supposed to be a universal flasher.
Some futzing around with DOS boot arrangements later, UNIFLASH was executing. Everything went perfectly. I rebooted. It did nothing. I turned it off, and turned it back on. It did nothing. I had bricked my laptop. *whine*
Visions of gutting my shitty laptop in my head, I started to take it apart:
Hey is that a removable BIOS chip?!!
Hot diggity. A 32-pin PLCC 5V 512kx8 flash chip. Very simple to program, not quite common enough to consider it disposable, but certainly something I can work with. I tried to build a PLCC socket for my programmer. That turned out so embarrassingly that I will not even post pictures. It kind of looked like a heap of wires on a 2x4. Bad.
I ordered a PLCC socket. It arrived and I built a little flash programmer:
The idea is to use 4 8-bit latches to multiplex the 8 data pins on a parallel port between 19 address pins, 8 data pins, and 2 control signals (write enable and output enable) on the flash chip. An additional 8-bit buffer is used to read from the flash chip, it drives the parallel port's status pins (paper out, printer on fire, etc.).
It was a grand idea, and the design was easy enough. I forgot a problem with parallel ports...they're TTL and so they expect a load. I use 74HC-series logic chips (in general) because they do not have a load but will drive a huge load, it's a good compromise. But the downside is that the clock strobe pins on the 74HC574 latches are extremely sensitive to what TTL world considers acceptable levels of crosstalk.
So I debugged it with my 'scope and added another chip to trigger the latches independently based off of just a single strobe from the parallel port:
That headless laptop in the picture is courtesy of a friend. It belongs on the workbench. I just wanted something with a parallel port that wouldn't require me to build too long of a cable.
To deal with the noise on the remaining strobe line, I added the smallest capacitor in my collection to essentially make a low-pass filter. It cut everything over about 2kHz off. At about an ideal 5 operations to read a byte, it was a pretty shitty setup, but an hour later, I had completed reading the chip (to see what had gone wrong in the original flash).
When the reading was about 60% done I compared it to the ideal...I'd assumed that UNIFLASH.EXE was simply incompatible with my flash chip, so I was blown away to find that the files compared exactly. The flash had proceeded perfectly! So I called up Averatec customer care and chewed them out. The guy on the phone was too polite. It was totally unsatisfying, I was defused in about two sentences.
So the read finally completed, all 0x80000 bytes. And there it was, in the very last sector, byte 0x7FFD1 was a 0xF8 and was supposed to have been a 0xFA. Weird, thought I. A little hacking around and I had reflashed the last sector. Some prying (PLCC sucks) and pushing and it was in my laptop. Bling!
Lessons learned... Well, it may be my fault, maybe UNIFLASH.EXE had a separate "verify" step that I was supposed to do manually. But my best recollection is that it printed "VERIFYING" right after "WRITING" and it indicated success. So I'm inclined to say that the lesson here is that UNIFLASH is a useless fucking piece of shit. Next time, I'll just cut the wires to the fan and power it straight off the +5V from the USB, then it won't ever shut off.
The other lesson here is that PC parallel ports fucking suck. I'm thinking about putting a PIC board together just to provide a healthy variety of proper tristate CMOS-drive pins for breadboarded computer interfaces. But the next project I'd need that for is -- you guessed it -- a PIC programmer. The irony.
In case you hadn't already guessed: The new BIOS did not fix the underlying ACPI bugs.