It obviously has to be some highly localized failure because there is no way the machine would be able to even load an OS otherwise.
I'm not entirely convinced that it's RAM because how could RAM show errors at so many addresses within the VGA text buffer and zero or almost zero errors elsewhere? What would be the mechanism behind RAM duplicating bytes? That being said, if you have a possibility to boot from pendrives/CD, download and try to run memtest86+.
If you can, try to boot Linux in VGA text mode. If this loads and works fine (except for garbled text), then
Wild guess: dried up capacitor in the northbridge Vgpu buck converter.
BTW, how old is "old" and does it have the DRAM controller in the CPU or in the NB?
The Acer F2 is a bit over 12 years old. Good that at one time I used my laptop to locate a drivers for the F2's chipset, so I had a copy of the F2's driver manager screen print saved on the laptop. The device manager has the graphic chipset as Intel 82865G/PE/P/82848P.
Since I don't have Linux (I have a Linux install disk on ISO on that F2), so,
I tried some other disks I do have that is display-heavy...
This trying Linux a good idea, I found some interesting clues I didn't see before.
DOS running gdisk (from Norton's ghost), as expected it read the HDD just fine. I've encountered HDD power issues and except for boot-disk, it rarely drops to blue-screening out. Running DOS, it occasional missing a letter or two on the display. I didn't want to run Ghost, that one is easier to make a mistaken and write something to the disk when ran in my machine's "semi-blind" mode.
A home made PXE (I use Bart PE's instruction to create it, and same GUI tools as Bart PE, but I use Server 2003 as the base OS), it fails similar to my normal WinXP boot. This was tried before, so I have to find another display-heavy thing to try...
Seagate HDD Utility Disk - this one gave me some insights. I use V1.1 (no GUI, but VGA), it use > CGA resolution to display 43 lines by 80. This utility doesn't let you do a thing until you accept the user agreement, so it is safe even in "semi-blind" mode.
The user-agreement is long with multiple pages of disclaimer text that is scroll-able by page. When I press random keys, it does a full screen erase and rewrite the exact same text; and if the key is held down, the full-screen erase and text rewrite repeats -- rapidly. So, any change to the display stands out right the way!
Holding the key down, I notice some positions were failing to erase frequently, while some other position also fails but at a much lower frequency. Some position doesn't seem to fail at all. It is not what is displayed but the physical row/column position of letter. The positions stay consistent after a reboot, and after power-cycle. That to me points to specific bytes of memory somewhere, be it RAM or buffers on the GPU.
If it is a dry-out capacitor causing power issues, the failure location-consistency kind of say no to that, I think (or does it really?). If it is a buffer inside the GPU, not much I can do there. If it is a RAM failure, it has to be the page(s) where it was memory-mapped to the GPU or the display.
What do you guys think?Thanks