Creating a Benchmark: part 5 – a road-block in testing

Some months ago I set about working on creating a bench mark program to compare the Borland Graphics Interface (BGI for short) with a hand coded in assembly VGA library. I had completed work on the library and even tested it on my Pentium 200Mhz MMX. So I decided to do the final tests to get the results when I ran into a road-block that still has me stumped.

I had three different setups to test the code on. Dosbox (at a fixed cycle count), my Pentium 200Mhz MMX machine running MS-DOS 6.22 and this machine (the last in the post), a 386sx running at 20Mhz. The BGI code runs fine on all three machines, but the hand coded library fails on the 386sx locking up during the first test – blitting sprites.

This was quite confusing as the test appears to at least partially work as a number of sprites are drawn to the screen quite quickly, but sometime during the test it always freezes. I thought about what could cause this and decided to try disabling interrupts during the drawing process. I did this as the main instruction used for copying bytes to video RAM does have an interrupt bug on older processors (286). This unfortunately had no effect. See this previous post to see code I used for copying memory.

Whilst disabling interrupts didn’t fix the problem, it did confirm which instruction was causing the problem. The rep movsw instruction was the only one I put between disabling and enabling interrupts (using cli and sti). When the machine froze with this change it no longer responded to keyboard interrupts that it did before. This indicates a crash during either an interrupt itself (unlikely) or this repeating instruction.

Given this strange problem I decided to test the machine by running memory tests and another graphical benchmark to see if there could be a hardware issue. It seems that the memory is ok, and it ran a 3d VGA benchmark with no trouble over night. I’ve also played some games such as Hocus Pocus that have parallax scrolling and would put a bit of load on the relevant parts with no problems.

So the question arises, am I putting too much data/strain into the Trident graphics chip for it to cope? I’m unsure if i can answer this. The process of copying the memory has several overheads. The processor has to read the word, write the word, increment the memory indexes and then decide whether to stop copying for each iteration of the instruction. This would at best be one word copied per 2 bus clock cycles, but is likely to be quite a bit slower, from memory I think like 6 clocks per memory copy for a 386.

I think it unlikely that I’m over taxing the graphic chip, but this problem does highlight one of the major problems people had when creating their own graphics libraries. Small shareware developers couldn’t have tested enough hardware to ensure that what they wrote would work on a large array of systems. The BGI however, having more resources behind it, has a quite good compatibility record.

Motherboard: GA-586ATE

Today we return to the series on motherboards with a Socket 7 Intel chipset board made by Gigabyte. The Socket 7 standard was popular in the mid to late 90’s, usually running Pentium and K5-K6 class chips. It would be considered unusual today as the standard supported CPUs from many different manufacturers, and was probably the last to really do so.

This board was donated to me quite some time ago, and luckily it works. Unfortunately the CMOS battery is dead and cannot be easily replaced on this particular board. At first glance this appears to be a high quality Intel chipset board with very few jumpers to configure.

This board has some older style cache chips seen here, much like those found on old 486 boards. They are basic high speed static RAM chips, with the brains of the caching mechanism being embedded within the chipset. Being made in 1994 this would use the synchronous caching scheme as pipeline burst caching had not been released yet.

Unfortunately I couldn’t find any documentation at all so the detailed specs for this board are unknown. Although it is obvious that it only takes 72pin EDO or fast page RAM. CPU support seems to be up to 166Mhz from the jumper settings chart printed on the board.

Here is the annoying CMOS and real-time clock chip that has a built in battery along with the flash ROM chip. These chips are a pain in the butt because you can’t easily change the battery. I may be able to get a replacement, or I might have to hack this chip to disconnect the internal battery and attach my own external battery. Luckily this particular chip (and the ROM) are socketed so I shouldn’t have to do any soldering on the delicate main-board.

In service this probably would have been quite a good board and would have been capable of carrying some of the more cutting edge processors for the time. There are few jumpers required for set up, basically one set for the processor multiplier and another for the bus speed. The board silkscreen has enough details for setting the jumpers and the front panel, so the manual isn’t strictly necessary to getting this board up and running.

This slideshow requires JavaScript.

These final two images are of the processor that is installed and the two main chips of the chipset. The processor is a pretty bog standard 100Mhz Pentium that performs surprisingly quite well. I had a quick look at benchmarks from the time and found it does nearly as well as some 120Mhz parts. This is likely due to limited memory bandwidth and perhaps the way the old cache on these boards worked. There is a socket near the main chipset that I haven’t seen before.

With no information available online there isn’t much more to be said about this particular board. It does still work, and if I can replace or hack that RTC chip it could be returned to service. The board feels and looks well made so I’d have to guess it was a higher end board, definitely capable of carrying a faster processor, and certainly quite reliable. It has managed to continue functioning even though it is a little over 20 years old. I guess technology of its era is more robust than much of what has come later.

Space Intruders for DOS

Today I played a clone of Space Invaders simply called Space Intruders. It was made by Softlair Computer F/X back in 1993. We got this particular game from a shareware magazine cover disc back in the day, it would have to be the only Space Invaders clone or otherwise that I really played at the time.

The game supports VGA graphics as you’d expect from a game of this vintage, and I think they are good, but not spectacular. The sprites are colourful and have some basic animation, but being a simple clone of space invaders there isn’t much more to be impressed by. Sound support comes in the form of PC speaker and Sound Blaster support, both of which sound quite good, albeit a bit loud. The PC speaker sound in particular is impressive as it sounds like it is producing digitised sound, but in higher quality than I’ve usually heard.

Game-play wise it’s pretty much just bog standard Space Invaders, although there is one minor change that makes a surprisingly large difference. With Intruder you can have quite a large number of shots in flight at a time, and the aliens also tend to drop many more bombs. This means you can put up almost a wall of fire and destroy almost an entire column of aliens at a time. Combined with a little dodging and you can quickly kill off an entire wave. This isn’t however the best strategy to use for getting a high score, for that you need to shoot the saucers that traverse the top of the screen for 1000-5000 points a hit.

As a clone of Space Invaders it’s not super faithful because of how much that one difference changes, but as a basic arcade shooter it’s pretty fun.

This slideshow requires JavaScript.

DGTech PVR Tear down

Having done some cleaning up recently I have finally started to make my workspace usable again. So today I decided to take a look at some hardware I’ve been meaning to tear apart for salvage. My old DGTech DG-HDPVR5009 set top box that doesn’t tune into signals properly anymore.

I got this unit about 7 years ago and it had served me well for quite some time. It had a 500Gb hard disk in it so I could store quite a large collection of recordings and two tuners so I could record and watch TV at the same time. Unfortunately it started having trouble receiving recently. Lets look inside.

There’s not much to the insides of a modern device like this. From the look of the available space they could have made this much smaller. A Seagate hard disk dominates the space obscuring the view of the mainboard and to the left is the power supply.

Upon removing the hard disk I found this IDE (also known as PATA or ATA) to SATA converter. This one allows a SATA device to be used with a more traditional IDE interface card. Most converters I saw in the day were the other way around, and in a device like this I would have expected a direct SATA connection instead.

  Here is the converter chip that does the work on the adapter. It is a JM20330 JMicron part. I couldn’t determine much from the data sheet except that it supports CD/DVD drives as well as the usual hard drives. It appears that this chip was made on the 29th week of 2008.

The main board on the right here is fairly minimalistic. What looks like two RAM chips are over to the left of the main SoC which has a heatsink attached. It must do most of the work as there are few support chips any where else on the board. you can see a couple of the buffer chips at the bottom right which are used to provide the IDE interface.

Not much to look at here, and not much to salvage apart from the expected hard drive so far.

Until I took the front panel apart and found this VFD just begging to be hacked. This board has all the front buttons, the display and the IR receiver all in this one handy package. The two plugs just below the display are the interface, the 3 pin one connects to the power supply and the other to the main board. I suspect this will be a simple serial interface of some kind that we could perhaps hack for our own purposes.

On the flip side of the board there is what appears to be a micro-controller. It is however a VFD driver and controller chip. With its data sheet and a bit of work I might very well be able to get the display to work. Although what exactly I’ll do with such a display I haven’t worked out yet.

In the end I’ve at least salvaged a useful hard drive, SATA adapter, some wiring and perhaps a usable VFD. The other components are less useful as I don’t have the skills to hack SMT or the chips on the mainboard. I may be able to use the chassis to mount the front panel and any project inside, but it does take up a bit too much space. I’ll have to sit and think about what the ultimate fate of this device will be.