• Please review our updated Terms and Rules here

Unidentified Turbo XT Clone has F/C stuck low

In turbo mode, does your CPU "tick" run faster? Does the ctrl-G beep get higher in tone? If so, your peripherals aren't using the 4.77MHz clock; they're using the CPU clock. That was one of the issues with the initial "cheap" turbo models. Good turbo boards use a fixed peripheral clock, so that time isn't warped.
 
In turbo mode, does your CPU "tick" run faster? Does the ctrl-G beep get higher in tone? If so, your peripherals aren't using the 4.77MHz clock; they're using the CPU clock. That was one of the issues with the initial "cheap" turbo models. Good turbo boards use a fixed peripheral clock, so that time isn't warped.
Yes, it ticks faster. Do I need to check the CLK pin in the ISA slots for that? If so, I can see that the CLK pin is at 4.77MHz when normal, and it goes up to 8MHz when in turbo mode.
 
There you go--the "turbo" in this case runs everything, including the time-of-day clock faster. Some BIOSes would introduce a scaling routine when the thing was in turbo mode to at least keep the time-of-day correct. Of course, the correct way to do things is to run the peripherals at 4.77Mhz all the time--which is why many PC ATs have a separate source for that.
 
There you go--the "turbo" in this case runs everything, including the time-of-day clock faster. Some BIOSes would introduce a scaling routine when the thing was in turbo mode to at least keep the time-of-day correct. Of course, the correct way to do things is to run the peripherals at 4.77Mhz all the time--which is why many PC ATs have a separate source for that.
I guess there is no easily implementable fix for this?

Anyway I have finally fixed the board - it was a bad 82C84, I guess it threw out a messed up turbo speed somehow.

A new 8284A fixed everything and the board is now stable - most chips don’t get hot as they did either.

So I guess my years-long quest to fix this board is now complete.

Thank you for your invaluable help and Happy New Year, everyone!
 
There you go--the "turbo" in this case runs everything, including the time-of-day clock faster. Some BIOSes would introduce a scaling routine when the thing was in turbo mode to at least keep the time-of-day correct. Of course, the correct way to do things is to run the peripherals at 4.77Mhz all the time--which is why many PC ATs have a separate source for that.
Technically it is not the 4.77 MHz clock what peripherals care about.

Here is a bit of info about the 8284 and the clock generation in IBM PC, XT, and their clones:
The 8284 supports two clock sources, a built-in oscillator, IBM PC and compatibles typically have a 14.31818 MHz quartz crystal connected to it, and an external clock connected to the EFI input. The clock source is selected using F/C pin.
In case of IBM PC/XT, the external clock is not used, and the F/C pin is hardwired to ground, causing the 8284 to use the internally generated clock.
The built-in oscillator produces 14.31818 MHz clock signal on the OSC output, this signal does not depend on the EFI input or the F/C pin value. The OSC signal is buffered and made available on the ISA bus. It is used by CGA, Adlib, SoundBlaster, and so on.
The 8284 divides the clock selected by F/C by 3 for the CPU clock - 4.77 MHz, and then that signal is divided by 2 to obtain the peripheral clock - PCLK, roughly 2.39 MHz. In IBM PC that PCLK is divided further by 2 to obtain a roughly 1.19 MHz clock for the 8253 PIT, which is used for time keeping, sound generation, and memory refresh.

Now, a straight forward, although quite a bit problematic approach to implement the "turbo" mode, is to simply wire a faster clock to EFI, say using 24 MHz crystal oscillator, and use the F/C pin to switch between the standard and the turbo frequency. This approach has several problems:
1. When switched to turbo mode, it will speed up the timer, resulting in time keeping issues, sound being high, etc.
2. The F/C clock switching is not "glitchless", that is, it can result in shorter pulses than either one of the source frequencies, causing all kind of synchronization and stability issues.
3. It will cause issues with the DMA, as the 8237 DMA chip runs on CPU frequency, but it does not work reliably above 5 MHz
4. It might cause issues with extension cards, as they are not designed to run faster... Now ISA is not a synchronous bus, so you can't really say it runs at XX MHz frequency, but rather the timing becomes too fast for certain things, particularly older controllers.

Perhaps some early XT clones used this approach. I personally think only a few did, due to all these issues. But it is quite possible that some people "hacked" their systems this way...

Most turbo XT clones address the issues above as follows:
1. Instead of using PCLK/2 for the PIT, they take OSC and divide it by 12, e.g., this can be done using a 74LS92 counter.
2. Instead of using F/C clock switching method, they implement an external glitchless clock multiplexer, that gets the OSC and the external clocks as inputs, and has the output connected to the EFI input, with F/C tied "high" so that the 8284 uses the EFI input
3. They monitor the DMA requests, and switch the system clock to the "standard" 4.77 MHz clock during DMA requests.
4. They add extra wait cycles in turbo mode (or more naively, regardless of the mode)

Another approach is to use second 8284 to generate the CPU clock only. This addresses the first and somewhat addresses the third issue (DMA always runs on 4.77 MHz, but there are possible synchronization issues) from the list above. It doesn't address the second and the forth issue, unless there are additional circuits to take care of them. This approach is used by somewhat popular PC-SPRINT turbo hack: https://ctrl-alt-rees.com/2020-03-02-overclocking-the-ibm-5150-8088-cpu-with-pc-sprint.html, https://github.com/reeshub/pc-sprint)
 
Technically it is not the 4.77 MHz clock what peripherals care about.

Here is a bit of info about the 8284 and the clock generation in IBM PC, XT, and their clones:
The 8284 supports two clock sources, a built-in oscillator, IBM PC and compatibles typically have a 14.31818 MHz quartz crystal connected to it, and an external clock connected to the EFI input. The clock source is selected using F/C pin.
In case of IBM PC/XT, the external clock is not used, and the F/C pin is hardwired to ground, causing the 8284 to use the internally generated clock.
The built-in oscillator produces 14.31818 MHz clock signal on the OSC output, this signal does not depend on the EFI input or the F/C pin value. The OSC signal is buffered and made available on the ISA bus. It is used by CGA, Adlib, SoundBlaster, and so on.
The 8284 divides the clock selected by F/C by 3 for the CPU clock - 4.77 MHz, and then that signal is divided by 2 to obtain the peripheral clock - PCLK, roughly 2.39 MHz. In IBM PC that PCLK is divided further by 2 to obtain a roughly 1.19 MHz clock for the 8253 PIT, which is used for time keeping, sound generation, and memory refresh.

Now, a straight forward, although quite a bit problematic approach to implement the "turbo" mode, is to simply wire a faster clock to EFI, say using 24 MHz crystal oscillator, and use the F/C pin to switch between the standard and the turbo frequency. This approach has several problems:
1. When switched to turbo mode, it will speed up the timer, resulting in time keeping issues, sound being high, etc.
2. The F/C clock switching is not "glitchless", that is, it can result in shorter pulses than either one of the source frequencies, causing all kind of synchronization and stability issues.
3. It will cause issues with the DMA, as the 8237 DMA chip runs on CPU frequency, but it does not work reliably above 5 MHz
4. It might cause issues with extension cards, as they are not designed to run faster... Now ISA is not a synchronous bus, so you can't really say it runs at XX MHz frequency, but rather the timing becomes too fast for certain things, particularly older controllers.

Perhaps some early XT clones used this approach. I personally think only a few did, due to all these issues. But it is quite possible that some people "hacked" their systems this way...

Most turbo XT clones address the issues above as follows:
1. Instead of using PCLK/2 for the PIT, they take OSC and divide it by 12, e.g., this can be done using a 74LS92 counter.
2. Instead of using F/C clock switching method, they implement an external glitchless clock multiplexer, that gets the OSC and the external clocks as inputs, and has the output connected to the EFI input, with F/C tied "high" so that the 8284 uses the EFI input
3. They monitor the DMA requests, and switch the system clock to the "standard" 4.77 MHz clock during DMA requests.
4. They add extra wait cycles in turbo mode (or more naively, regardless of the mode)

Another approach is to use second 8284 to generate the CPU clock only. This addresses the first and somewhat addresses the third issue (DMA always runs on 4.77 MHz, but there are possible synchronization issues) from the list above. It doesn't address the second and the forth issue, unless there are additional circuits to take care of them. This approach is used by somewhat popular PC-SPRINT turbo hack: https://ctrl-alt-rees.com/2020-03-02-overclocking-the-ibm-5150-8088-cpu-with-pc-sprint.html, https://github.com/reeshub/pc-sprint)
Hooked up the LA (haven't got an oscilloscope - yet) and checked for the four cases.

1. It doesn't do 1 since PC Speaker sound in games is noticeably accelerated.
2. Definitely doesn't do this since the entire board is controlled by F/C (goes high and low) instead of being tied high.
3. This doesn't happen as even during floppy reads the CLK stays either 4.77MHz or 8MHz.
4. This is BIOS dependant right?

I honestly don't want to build a PC Sprint circuit, it would be redundant and would pretty much nullify all my efforts in repairing this board since I could just use my other (working) 4.77MHz one. Considering how half-assed the turbo function on this one is, I might still do it in the future.

Anyway, I am almost done with this board but I am having the following issue:

I usually switch back and forth between Anonymous’ XT Turbo Bios (the one on phatcode.net) and GLaBIOS (pretty nice!) and I found out that the floppy drive didn’t read anything at all under the Anonymous XT Turbo BIOS, while it worked fine under GLaBIOS but only in 4.77MHz mode, while in turbo it gave the same issue as the other BIOS.

But I *could* remember it working, and why would it work under a BIOS and not on the other one? So I started looking on Vcfed and found a post by Ruud that advised checking the 8237. After swapping it, Anonymous’ XT Turbo BIOS started trying to boot the drive (but failed in turbo mode, while it kinda worked in 4.77MHz) and the drive also started working fine in turbo mode under GLaBIOS, which was something it didn’t before.

I guess that GLaBIOS addes wait cycles, that's why the floppy is always working using that one? But why such an erratic behaviour on Anonymous’ XT Turbo Bios? It should work fine in 4.77MHz mode...

Thanks for the help!

Haven't I said this in several posts over the years (other than for the PC Sprint)? I guess forgetfulness is part of the forum.
Sorry, I had never stumbled upon this while reading the forum - if I knew about it I would've saved myself purchasing yet another clone board :)
 
Sorry, I had never stumbled upon this while reading the forum - if I knew about it I would've saved myself purchasing yet another clone board
It's okay--it seems that the Internet way of doing things engenders amnesia. Very early on, when the "isn't this wonderful?" web people were saying that books were obsolete and that everything worth knowing would be online, I opined that "we're writing our history in sand". Will AI solve that or merely concoct lies? I don't know.

I recently tried out Google Bard to find the earliest mention of that physics demo "Fletcher's Trolley". Bard confidently informed me that the earliest mention was 1925. I found mentions online in 1911 and 1916--and I suspect that if I'd gone deeper, I'd have found 19th century sources.

Bottom line is that we don't know what we once knew. (Sorry for the OT).
 
1. It doesn't do 1 since PC Speaker sound in games is noticeably accelerated.
2. Definitely doesn't do this since the entire board is controlled by F/C (goes high and low) instead of being tied high.
3. This doesn't happen as even during floppy reads the CLK stays either 4.77MHz or 8MHz.
4. This is BIOS dependant right?
So it appears that you have confirmed that your board uses the naive turbo switching method using F/C signal, so it suffers from all the issues I've described above.
Regarding (4) wait states - it is hardware feature, but if the wait state generator is programmable, it would depend on the BIOS too.
In older/simpler/non-chipset Turbo XT board, it tends to be a non-programmable wait state generator, that in the best case will have some jumpers to configure the number of wait states.
In your case, I don't think that the manufacturer bothered to implement anything beyond what is present on IBM XT board (one wait state for I/O and BIOS ROM accesses), although it can be measured. I wrote this utility, which you can try: https://github.com/skiselev/testwait. Run once in the normal mode and in the turbo mode, and check the output.

I usually switch back and forth between Anonymous’ XT Turbo Bios (the one on phatcode.net) and GLaBIOS (pretty nice!) and I found out that the floppy drive didn’t read anything at all under the Anonymous XT Turbo BIOS, while it worked fine under GLaBIOS but only in 4.77MHz mode, while in turbo it gave the same issue as the other BIOS.
Use GLaBIOS then... I have a very low option about Anonymous' XT Turbo BIOS... I think it is ERSO BIOS, with some modifications, it used to have silly bugs.
The floppy particularly, is the only common I/O device that uses DMA, unless you have an MFM HDD. Memory refresh also uses DMA, but that gets programmed only once at the boot time, and it doesn't care about data being transferred, and works as long as the DMA outputs some addresses on the address lines.

But I *could* remember it working, and why would it work under a BIOS and not on the other one? So I started looking on Vcfed and found a post by Ruud that advised checking the 8237. After swapping it, Anonymous’ XT Turbo BIOS started trying to boot the drive (but failed in turbo mode, while it kinda worked in 4.77MHz) and the drive also started working fine in turbo mode under GLaBIOS, which was something it didn’t before.
It is possible that some 8237 might be "faster" than others. Particularly CMOS versions - 82C37 should be faster. Harris/Intersil used to make these up to 12 MHz, but in PLCC-44 packages only. As it typically happens, I don't think they used different masks/manufacturing for 5 MHz vs 12 MHz chips. 12 MHz chips were simply tested to work on faster clock, and perhaps 5 MHz were supporting that clock too, it just no one cared about 12 MHz 82C37 in a DIP-40 package
I guess that GLaBIOS addes wait cycles, that's why the floppy is always working using that one? But why such an erratic behaviour on Anonymous’ XT Turbo Bios? It should work fine in 4.77MHz mode...
It's not, but it might add some I/O delays when talking to the DMA...
 
So it appears that you have confirmed that your board uses the naive turbo switching method using F/C signal, so it suffers from all the issues I've described above.
Regarding (4) wait states - it is hardware feature, but if the wait state generator is programmable, it would depend on the BIOS too.
In older/simpler/non-chipset Turbo XT board, it tends to be a non-programmable wait state generator, that in the best case will have some jumpers to configure the number of wait states.
In your case, I don't think that the manufacturer bothered to implement anything beyond what is present on IBM XT board (one wait state for I/O and BIOS ROM accesses), although it can be measured. I wrote this utility, which you can try: https://github.com/skiselev/testwait. Run once in the normal mode and in the turbo mode, and check the output.
I can’t see any jumpers on the board, sadly. There’s a reset header next to the 8284 and a jumper that toggles between 256kb/640kb on the bottom of the board. It is pretty much a straight 5160 clone.

Thank you for this utility! It seems the BIOS ROM has 0WS while I/O has 2WS. It doesn’t change between normal and turbo mode. Weird?

Use GLaBIOS then... I have a very low option about Anonymous' XT Turbo BIOS... I think it is ERSO BIOS, with some modifications, it used to have silly bugs.
The floppy particularly, is the only common I/O device that uses DMA, unless you have an MFM HDD. Memory refresh also uses DMA, but that gets programmed only once at the boot time, and it doesn't care about data being transferred, and works as long as the DMA outputs some addresses on the address lines.
I trust your judgement as I am a long time fan of your works.

Not using MFM but SCSI with a Seagate ST02. I *guess* that it does DMA as well? SCSI without DMA would be pretty stupid (but it has been done a lot of times in Amiga-land, so it is definitely possible…).

Yeah I am sticking with GLaBIOS - GLaTICK is awesome as well. I just wished that the SCSI Boot ROM appeared before the boot screen instead of in the middle. I will see if I can submit a bug report…

Just noticed that your BIOS should also run on XT-compatibles! Looks like I have another ROM to burn and play with 😁

It is possible that some 8237 might be "faster" than others. Particularly CMOS versions - 82C37 should be faster. Harris/Intersil used to make these up to 12 MHz, but in PLCC-44 packages only. As it typically happens, I don't think they used different masks/manufacturing for 5 MHz vs 12 MHz chips. 12 MHz chips were simply tested to work on faster clock, and perhaps 5 MHz were supporting that clock too, it just no one cared about 12 MHz 82C37 in a DIP-40 package
I see - my 8237s are indeed marked as 5MHz. As you say, some might actually tolerate better higher frequencies, but it’s another chip lottery I don’t want to get into 🙃 As long as the floppy works with at least one BIOS, I can call it a victory.

It's not, but it might add some I/O delays when talking to the DMA...
That might be it, yeah. Will report back after testing your BIOS :)
 
Back
Top