dalegass@dalcsug.UUCP (Dale Gass) (07/06/87)
My XT-clone is basically a no-name taiwanese machine (the ROM says IBS Ultra Board). It has served me well, and I have only had one minor (though annoying) compatibility problem: The machine has two clock speeds: the standard 4.77Mhz, as well as a handy 6.67Mhz mode. However, it seems that when one switches to the 6.67Mhz mode, the real time clock interrupt also speeds up from 18.2 ticks/second to 25.4 ticks/second. In other words, the designers of the board used the faster clock signal one too many times; i.e. to drive interrupt 0, whereas they should have used the 4.77mhz signal at all times for this clock interrupt, since it is a standard time reference interrupt, upon which many programs rely. The first obvious solution I came up with was to reprogram the clock divisor latch on the 8253 chip, so as to slow down the interrupts (i.e. require more ticks on the CLK0 of the 8253 before producing the IRQ0 signal. However, this value was already set to it's maximum (I think) at 65536 (actually a value of 0). I then fudged around this by setting the value of this divisor to a *smaller* value so than the interrupt occurred twice as frequently as it should. (B475 hex was the appropriate value, which produces 36.4 ticks/second). In my interrupt 0 handler, I only bump the clock every *two* interrupts.i This fixed the real time clock problem... However... Several programs intercept the timer interrupt, and use it for their own purposes before passing control onto the old servicing interrupt. With my patch, they effectively have a distorted (and rather hurried) perception of real time. Programs such as MIRROR have their real time clocks and timers run twice as fast as they should, and some programs such as FASTBACK which rely heavily upon 18.2 ticks/second fail altogether with this patch. I have thought of halving the occurence frequencly of this interrupt in other ways, such as having my ISR set and reset the ISR vector to a dummy routine (which later restores the original value). This would only work if the intercepting program happens to intercept the vector when it is pointing to the first (and main) ISR service routine, and would bomb out when the value was pointing to the secondard ISR (which does nothing but restore the first ISR's vector). Any suggestions? I'm now looking for a hardware solution. Hopefully it will be as simple as cutting one trace from the 6.66mhz signal and putting a jumper in from the 4.77mhz signal. Does anyone have any experience with such a situation? I'm not sure if the 4.77mhz signal is still valid once you switch speeds... (There are two separate crystals). My idea is to change the PCLK value going into the 8253 chip to a constant 4.77 mhz. This will also affect the speaker frequency (which uses the same 8253), but this should be no problem, and would actually make the speaker frequencies more compatible with the standard. Also: Can the stanard 4.77 mhz signal be pulled off the external bus? I could be wrong, but I thought that it was there for use by some video cards without their own crystals... I am not an expert when it comes to computer hardware, so I would appreciate any advice, guidance, suggestions anyone might have to offer. Thank you, dalegass@dalcsug.uucad