Poor performance in a Turbo XT motherboard

[nestor]

Hi,
I acquired this motherboard from eBay, a Turbo XT with a 8088-2 processor and 512 kb ram:


Click to enlarge

It runs at 4.77 MHz by default, but switches supposedly to 8 Mhz Turbo mode with a "Ctrl Alt -" key combination (there is a 24 MHz TTL oscillator in the board).
The design seems similar to other Taiwanese XT clone boards, but this has 3 PAL ICs: one is at bottom center near the RAM sockets and the other two are located in the left, between the two Crystal oscillators. From one of these two PALs there are two wires soldered in the bottom side that also enable Turbo mode when shorted.

The problem is that benchmark results report slower clock rates or less performance than expected (Checkit for example says that the 8088 is running at 6 MHz). Without turbo engaged the performance is the expected at 4.77 MHz.

I have tried different bioses with the same result.
Any idea or advice to discover how is wrong?

 

[per]

Perhaps the system clock is changed too when you trigger turbo mode? I would believe that the system and CPU have separate crystalls, but if it's a really cheap board, it may not be the case.

 

[mikey99]

That looks very similar to the XT clone board I have. Mine has an IBM Basic burned
into those ROM chips.

I haven't tried running a benchmark on this but I'll try sometime over the next few days
as I do currently have this board installed in a case . EDIT: I dont think mine is a Turbo board
though, because it has a V20 installed :

 

[Chuck(G)]

Perhaps the system clock is changed too when you trigger turbo mode? I would believe that the system and CPU have separate crystalls, but if it's a really cheap board, it may not be the case.

They do have different crystals--the 8254 continues to use 1.19 MHz as its clock regardless of turbo setting.

This board was an ERSO-standard design with lots of little tweaks. I have yet another version that looks more like Mikey's board, but there are 3 DIP packages just above the switches.

Again, the trick here is to figure out what the frequency coming into the CPU clock is. If it's 6MHz, you look upstream and see how an 18MHz signal could be derived from a 24MHz source. If it's 8MHz, then you look to see who's adding the wait states.

Just for yucks, have you tried a different CPU in the socket?

 

[nestor]

Yes, I tried with a 8088 in plastic package (the original 8088-2 has ceramic package) and the result is the same. How can I see what is adding wait states?

 

[deathshadow]

Most likely suspect is RAM timings. The ram is probably down at the system bus speed and the 8088 with it's 8 bit bus is then spending a lot of time waiting.

It boils down to how assembly is executed on the 8088. Thanks to the 8 bit bus that let it be built with cheaper componants it takes a minimum of 2 clocks to read a word-sized parcel of data, and the pre-fetch will always grab a word... Real world this works out to about 4.13 clocks to read the average x86 instruction from memory thanks to the DRAM refresh interval.

Now, if the instructions being executed take more than that 4 clocks to execute, the next word can be grabbed while it's being processed -- the problem is that if the opcodes take less than four clocks -- inc, dec or bitwise operators for example -- multiples of those in a row end up 'rounded up' waiting for the data to be retrieved from RAM. Micheal Abrash called these types of effects the "cycle eaters".

http://www.phatcode.net/res/224/files/html/ch04/04-01.html

Which is why a benchmark might only report a 30-40% speed increase despite the CPU's clock speed being doubled. The tandy 1000's 7.14 mhz clock speed sees similar issues waiting on memory which is why really long instructions (like jmp, mul, etc) see the speed boost but short instructions (shl ax,1; inc ax) actually end up some 80-90% of the time the same speed as they do at 4.77mhz, as the CPU is sitting there with it's thumb up it's backside waiting on RAM for the next instruction.

Which is why the 8088 is often a very poor candidate for higher clock speeds unless the RAM can keep up. At really high clock speeds (12mhz+) you often end up with little if any speed bonus over 10mhz as the code is executing inside the CPU so fast, it's outpacing the prefetch queue unless you are on a design that uses more modern ram with a more robust caching controller. (see why many of the rare 20mhz XT class boards used 70ns 30 pin SIPPs or SIMMs)

 

[nestor]

Thank you for the link, I found it very interesting.

Here are some benchmarks:

LandMark6:
at 4.77 MHz: CPU Clock: 4.77 MHz, performs like a 2.49 MHz AT
at 8.00 MHz: CPU Clock: 7.997 MHz, performs like a 3.78 MHz AT


Norton Utilities 4.5 System Information:
at 4.77 MHz: CPU 1.0
at 8.00 MHz: CPU 1.4


Checkit 3.0

at 4.77 MHz: CPU Clock: 4.77 MHz, 344 Dhrystones / 6.6K Whetstones
at 8.00 MHz: CPU Clock: 6.14 MHz, 558 Dhrystones / 10.6K Whetstones

Do you find this results normal?

 

[Chuck(G)]

A quick check with Norton 4.5 on my own "Turbo XT" (this one) gives an SI of 1.7 at 8MHz (that's with an 8088 installed).

So it looks as if yours probably has some memory speed issues. Not all "Turbo XTs" were created equal.

But given the similarity of mine to yours and the look that yours is somewhat more modern, I've got to wonder about those wire jumpers on yours.

 

[nestor]

So the board is performing worse than expected at 8 MHz... now that it is confirme, I will trace the 24 MHz oscillator path to the 8284. I suspect the two PALs will be in the middle of this path, at least physically they are placed in the board between oscillator and the 8284.

The two wires have one side soldered to one of the PALs, in the back side of the PCB. The other side is soldered to a 2 pin header. Shorting this header makes the board switch to Turbo mode, the same as pressing "Ctrl Alt -" key combination.

 

[per]

If we think perofrmance-wise, each clock cycle usually takes 4 clocks. When 4 clocks is expected at 8MHz and one extra waitstate is added, the performance will resemble 6.4MHz.

On the other hand, 24MHz/4 = 6MHz too.

 

[nestor]

As I suspected, the 24 MHz clock is connected to one PAL and not directly to the 8284 clock generator, so who knows what black magic happens inside...

I will build a frequency counter with a PIC16F877 and then read what gets inside the 8284.

 

[sergey]

8088 requires a 33% duty cycle clock... so I assume that it divides 24MHz OSC by 3 (it's very difficult to get 33% duty cycle from a 50% signal even using a PAL). So I guess that the slowness is related to additional wait cycles. Not sure what PAL is doing there, perhaps they just use it as a buffer, or to generate additional clocks (e.g. DMA clock).