"MTX Plus⁺" ROM - Timing

MTX CTC Pin-out	MTXPlus+ CTC Pin-out

Background

Both the original MTX and MTXPlus⁺ computers include a Z80 Counter/Timer Circuit (CTC), the CTC has four independently programmable counter/timer channels that can be used to perform functions such as interrupt timing and clock rate generation. Each channel has an external Clock/Timer Trigger input (T/T0 to C/T3) and can drive one or two outputs. Channels 0 to 2 each have an individual Zero Count/Timeout output (ZC0 to ZC2) and all channels can drive the Interrupt Request (INT) pin.

The diagrams above show the connections to the Z80 CTC for the original MTX and MTXPlus⁺, the only differences being the connections to pins 20 and 7. Allocation of the CTC channels for the MTX and MTXPlus⁺ are shown in the table below :

As the device name suggests, each channel can be configured as either a counter or a timer. Each channel is programmed with two or three (if interrupts are enabled) 8 bit words - a control word and a time-constant word.

Time related functions in the MTX, such as the system clock and keyboard repeat rate, are controlled by periodic interrupts with a frequency of 125Hz which are generated by the CTC.

Channel 0 of the CTC is connected to the VDP interrupt output pin (VDPINT), the VDP generates an interrupt signal at the end of each active display scan, which, in the case of the TMS9929A, is about every 1/50 second. The MTX ROM has an interrupt routine called VDPINT that handles the internal clock, key auto repeat, cursor flash and some sound functions.

Using this method means that the interrupt period would be the same for the NTSC (TMS9918, 60Hz) and PAL (TMS9929, 50Hz) versions, allowing the ROM code to be common.¹

MTXPlus⁺ Timing

If a copy of the MTX ROM, with interrupts generated from the CPU clock, was used in MTXPlus⁺ without modification, then the time related functions would only be correct when the system was operated at 4MHz, as the system speed increased, so would the rate of the timing dependent functions.

Although it is possible to cascade more than one counter to get values greater than 256, the problem would still be that the interrupt frequency would only be correct for a single clock speed. To keep the timing correct at all clock speeds without having to change constants in the software for each, some method of automatically controlling the interrupt frequency was required.

Tony Brewer suggested a mechanism for doing this that didn't need additional resources (on my board anyway), using the redundant CTC channels C/T3 and ZC0, as well as spare I/O in the CPU control buffer GAL², enabling the GAL to count ZC0 pulses and generate 125Hz interrupts for any of the three defined clock speeds.

Design Development

Having the GAL22V10 divide ZC0 by 1, 2, 3 or 4 for 4, 8, 12 or 16 MHz CPU clocks was an ideal solution when the system clock speeds were multiples of 4MHz, but becomes less useful now that the system has the capability of running at clock rates that are not multiples of 4MHz.

The GAL22V10 has now ben removed and the CTC ZC0 output fed back directly to the CTC C/T3 input.

ZC0 pulses high whenever CTC channel 0 down-counter reaches zero. This will happen in two different cases, when :

(a) CPU clock is divided to generate 125 Hz interrupt or

(b) /VDPINT input used to generate interrupt, as discussed separately below.  

For a normal MTX at 4 MHz, the CPU clock is divided by a pre-scaler of 256 and a time constant of 125 to generate the 125 Hz interrupt (see Equation 1 above). The time constant value is pure coincidence as 4000000 / (256*125) = 125. A time constant of 250 for an 8 MHz clock and maximum of 256 (0 value is programmed) for 8.192 MHz clock is possible.

Anything higher ('fast') requires two cascaded CTC channels, 0 and 3, the latter, otherwise unused cassette interface, is not supported.

If 'fast' = 10 MHz, have channel 0 pre-scaler of 16 (cannot be 256), time constant of 125 and channel 3 time constant of 40.

If 'fast' = 12 MHz, have channel 0 pre-scaler of 16 (or 256), time constant of 125 and channel 3 time constant of 48 (or 3).

Channel 0 is in timer mode and channel 3 in counter mode with no pre-scaler available and external trigger ZC0. Therefore simply connect ZC0 output to C/T3 input and remove C/T3 from all other devices.  

Time constant of 1 ensures that /INT goes low every time /VDPINT goes low so that CPU is interrupted 50 times per second at the end of active display. As ZC0 will go high whenever /VDPINT and hence /INT go low, we have a choice of which of /INT or ZC0 to connect to CPLD for Speculator logic (which must know when /INT goes low) but we don't need both.

N.B. ZC0 and C/T3 changes mean must have different interrupt code for 4MHz and 'fast'. If latter is only 8 MHz now as temporary measure, only one byte would differ (time constant 125 or 250) as one CTC channel sufficient for 125 Hz (but not true for 10+ MHz).

Explanation of currently implemented ROM code (from Martin)

The current setup for the CTC is : 

Channel 0 is set up as follows: 

 The original MTX code would have had the interrupt bit set, as this was the only counter in use   The modified hardware has the output to this pin connected to the input of channel 3   The timer constant that follows is 31 (decimal) instead of 125.   At 4mhz counting to 125, with a pre-scale of 256 results in an interrupt every 32000 cycles, giving the system its 125hz interrupt.

The MTXPlus⁺ however, with it’s count of 31 and a pre-scale of 31, results in the input of channel 3 being pulsed every 7936 cycles.

Channel 3 is set up as a counter and not a timer

The time constant that follows is the CPU speed in MHZ that’s detected on start up.  

So, channel 0 triggers channel 3 every 7936 cycles, If the MTXplus⁺ CPU is running at 4mhz, that results in the channel 3 interrupt being triggered every 31744 cycles, Which is a fraction faster than the original MTX, there are now an average 126.008 interrupts per second. So by changing the count for the software clock from 125 to 126, TIME$ is now sufficiently accurate for normal use.

 Using the CPU speed as the constant for the 2nd stage count means that whatever speed the CPU is clocked at, as long as its an exact number of MHz, the result is a 126hz tick   i.e. 10MHz CPU, the interrupt triggers every 79360 cycles, 10,000,000 / 79360 = 126.008 as above, the system clock runs as before.

At 10.5mhz, the interrupt would still trigger every 79360 cycles, however 10,500,00 / 79360 = 132.3 so the system clock will run 5% fast  

"Final" Implementation

Using CPLD or GAL logic developed by Tony, MTXPlus⁺ now has the ability to operate at any one of 16 clock frequencies from 4MHz to 16MHz. To support this, 16 different CTC time constants are required :

For clock frequencies of  4, 6.40, 8.0, 12.80 and 16.0MHz, the clocks can generate a 125 Hz interrupt precisely, the rest have small errors as listed in the table of CTC time constants, the worst case error is at 5.82MHz, where the error is 1s in 3201, i.e., 1s in 53 minutes, or approximately 26 seconds per day.

 Identifying the CPU speed, in software 

The MTXPlus⁺ is designed to have an adjustable CPU clock. 4MHz for Compatibility with the MTX, mostly for games, and a range of faster speeds to take advantage of the enhanced hardware.

The support ROM, therefore uses the on-board RTC chip to calculate the CPU speed.   To do this it counts how many processor cycles it completes in one second of real time as determined by the DS12887. The ROM counts how many times it executes a 9874 cycle sub routine, It’s a slightly odd figure as the count routine averages 126 cycles per loop which has to be taken into account. From there it knows to within 0.01 of a MHz how fast the system clock is. Tested with an 11.0592mhz oscillator  it reported 11.06, close enough!  

The CTC only counts in integers, which for the majority of available oscillators isn’t a problem, Having the 4MHz compatibility mode really means the master clock is going to be some multiple of that anyway.

Credits :

1  Information about the CTC configuration in the original MTX ROM courtesy of Tony Brewer, January 2015

Notes :

2 Utilising the GAL22V10 used on Dave's CPU board to buffer the Z80 control signals