Wait States on the TI

[4Andy]

Hi, I have been trying to calculate the time for certain Assembly instructions in my routines on the TI and have been using the formula in the TMS 9900 Microprocessor Data Manual on page 28 and 29.

 

I'm a little unsure what value to use for the 'W' value placeholder (number of required wait states per memory access). In the TI-99/4A Console Technical Data manual, where it lists the I/O READ Timings on page 10 and 11. In the text it says there is "one wait state inserted in each" of the two 8 bit reads from external memory. It says one, but in the diagram on the following page, there appears to be two per byte - total 4 wait states (Clock Cycles 2, 3, 4, and 5) per 16 bit data fetch.

 

Which is correct? Am I reading this correctly?

 

Also, given that the ROM port also has an 8 bit data bus too, will executing an instruction from ROM (or storing data in the MiniMemory) be subject to the same timings and wait states as the External 32K Memory expansion above, or are there differences?

 

[Asmusr]

Hi, I have been trying to calculate the time for certain Assembly instructions in my routines on the TI and have been using the formula in the TMS 9900 Microprocessor Data Manual on page 28 and 29.

 

I'm a little unsure what value to use for the 'W' value placeholder (number of required wait states per memory access). In the TI-99/4A Console Technical Data manual, where it lists the I/O READ Timings on page 10 and 11. In the text it says there is "one wait state inserted in each" of the two 8 bit reads from external memory. It says one, but in the diagram on the following page, there appears to be two per byte - total 4 wait states (Clock Cycles 2, 3, 4, and 5) per 16 bit data fetch.

 

Which is correct? Am I reading this correctly?

 

Also, given that the ROM port also has an 8 bit data bus too, will executing an instruction from ROM (or storing data in the MiniMemory) be subject to the same timings and wait states as the External 32K Memory expansion above, or are there differences?

 

 

I have never done my own calculations, but the debugger in Classic99 is showing the execution times, and I have used that a lot.

[+mizapf]

4 is correct. The databus multiplexer inserts 2 WS for each external byte access; this is also the way I implemented it in MESS. Together you get 6 cycles per memory access.

 

The internal ROM is not managed by the databus multiplexer. Cartridge ROM and everything in the PEB is affected, though.

 

Sorry that I cannot deliver more information right now, being on a vacation in the Alps for some skiing.

[4Andy]

Is that the number in parenthesis following the disassembled instructions? I don't know how accurate the emulator is with regards to buses and wait states, does PAD RAM have zero wait states?. If the emulator is accurate (allowing for PAD vs External memory differences etc.), then that would be great, but I'd still want (initially) to check it against the data in the 9900 and 4A documentation, if possible.

[+mizapf]

Except for some detail in GROM timing which will be improved in near future, MESS is precise in terms of wait states and cycle times (tested with real hardware).

[4Andy]

Ok, that answers my question, thank you mizapf. Thank you also Asmusr, that's useful information about the Emulator.

[matthew180]

For the details of the 99/4A wait states, Thierry's website is a must read:

 

http://www.unige.ch/medecine/nouspikel/ti99/titechpages.htm

http://www.unige.ch/medecine/nouspikel/ti99/wait.htm

[4Andy]

Ok, thanks.

[Tursi]

Classic99's CPU timing is believed correct and tested frequently against real hardware. The last places that I was unsure about were corrected about a year ago. GROM timing is probably not exactly correct for me either, but I haven't had time to re-measure the timing. (Reads are probably close, but address writes I don't believe emulate the additional delay).

[4Andy]

Thanks I'll write some test progs on Classic99 and that should help me check whether my calculations are correct. :-)

[apersson850]

Slow memory penalizes a design like the TMS 9900 (and the TTL implementation of the 990/9, which it was designed to mimic) since they waste one memory cycle on each MOV operation as well. This is due to the read-before-write concept.

[4Andy]

Is that memory cycle for the read-before-write included in the execution times in the TMS9900 Microprocessor Data Manual, or do I have to add those on too? What actually is the read-before-write for? Is it because the registers are off-chip?

[+mizapf]

Yes, RBW is included in the execution times; this is the reason for the pretty long times - compare them with the TMS9995 that runs in the Geneve and which does not have a RBW.

 

The reason for RBW is that the TMS9900 is a true 16 bit processor but which has byte-oriented commands like MOVB. Suppose you have the following situation. The memory contains

 

address A000: 01

address A001: 02

 

Now you let the CPU perform a MOVB to address A000 (e.g. a value of FF).

 

The TMS9900 can only access 16 bits at once because of its 16 bit data bus. So how can you change the value at A000 but not at A001?

 

Texas Instruments' solution to this was the read-before-write:

 

1. Read the word at A000 -> 0102 gets into the CPU

2. Replace the first byte by FF

3. Write the complete word back into memory -> FF02 is written at A000 and A001.

 

Although the TMS9995 only has 8 data bus lines, it is better off here, because it can write to A000 without affecting A001.

 

Other architectures like x86 solved it differently: They have bus control lines to turn off one half of the data bus.

Edited March 25, 2016 by mizapf

[4Andy]

Understood. Does that also happen with word oriented instructions, like MOV ?

[+mizapf]

Unfortunately, yes. Have a look at the micro-operations.

 

Example for a MOV operation (page 4-92 from "9900 Family Systems Design"):

 

Cycle Type Description

 

1 Memory Read Address Bus = PC

Data bus = instruction

2 ALU AB = no change

DB = source data register (internal)

Ns DDS

 

3+Ns ALU AB = NC

DB = SD

Nd DDS

 

4+Ns+Nd ALU AB = NC

DB = SD

5+Ns+Nd Memory write AB = destination address

DB = result

 

 

The DDS operations are "Data Derivation Sequences". They depend on whether you do register operations, indirect operations, symbolic addressing, indexed addressing, or indirect/auto-increment addressing, and accordingly you get a different number of cycles.

 

The cheapest one is "Workspace register" which contributes 1 cycle for reading. That is, the fastest MOV operation has 7 machine cycles, which translate to 14 clock cycles since the 9900 needs two clock cycles per machine cycle.

 

Thus, the DDS of the 9900 always imply one read and possibly one write for incremental operations. Even for CLR this is true, and the specification says explicitly "Note: The operand is fetched for CLR and SETO although not used."

 

There are only few operations that do not use a DDS, like Load Immediate (LI).

[4Andy]

Ok. Is there a PDF of the "9900 Family Systems Design" manual somewhere, I can't seem to find it? Although I think I have the actual book somewhere.

 

Also, are the CPU clock frequencies of the American and European consoles different? When calculating delays for things like the Speech Synthesizer and GROM/GRAM access etc, do the delays need to be different depending on which console it is?

 

[+Lee Stewart]

Ok. Is there a PDF of the "9900 Family Systems Design" manual somewhere, I can't seem to find it? Although I think I have the actual book somewhere. Also, are the CPU clock frequencies of the American and European consoles different? When calculating delays for things like the Speech Synthesizer and GROM/GRAM access etc, do the delays need to be different depending on which console it is?

 

In the root directory of WHTech, sitelist.txt is your friend. Don updated it a week or two ago. The directory you want is “9900-FamilySystemsDesign-1stEdition”. The WHTech server seems to be offline at the moment, however.

 

...lee

[4Andy]

Ahhh, Thanks Lee. I did try looking there just before I posted, but the site was asking for log-in credentials, before it went down.

 

I'll wait for it to come back up.

[apersson850]

No, the clock frequencies for US and European consoles don't differ. But the screen refresh rate does, to match the line frequencies of 50 vs. 60 Hz. So the vertical blanking interrupt occurs more frequently on US consoles.

[+Lee Stewart]

Ahhh, Thanks Lee. I did try looking there just before I posted, but the site was asking for log-in credentials, before it went down.

 

I'll wait for it to come back up.

 

WHTech is back on line!

 

...lee

[4Andy]

Thanks again!

[4Andy]

No, the clock frequencies for US and European consoles don't differ. But the screen refresh rate does, to match the line frequencies of 50 vs. 60 Hz. So the vertical blanking interrupt occurs more frequently on US consoles.

 

So, based on that, it should be possible to determine which console a program is running on?

 

What is the actual frequency? Internet (and 4A ROM) suggest it might be 3.0Mhz, EA/TI Tech manual (rather unclearly) suggests it might be 3.579545 MHz / 3.58.

[Tursi]

It's 3.0MHz, I've measured it.

 

3.58Mhz was a common speed for computers of the day since it's the colorburst frequency, but that's faster than the CPU was rated for. You might be reading the part about calculating sound frequencies - the sound chip gets its clock from the VDP which in turn has a distinct and separate clock from the CPU.

[4Andy]

It's 3.0MHz, I've measured it.

 

3.58Mhz was a common speed for computers of the day since it's the colorburst frequency, but that's faster than the CPU was rated for. You might be reading the part about calculating sound frequencies - the sound chip gets its clock from the VDP which in turn has a distinct and separate clock from the CPU.

 

Great, thanks for clearing that up.

[+mizapf]

It's 3.0MHz, I've measured it.

 

3.58Mhz was a common speed for computers of the day since it's the colorburst frequency, but that's faster than the CPU was rated for. You might be reading the part about calculating sound frequencies - the sound chip gets its clock from the VDP which in turn has a distinct and separate clock from the CPU.

 

Yes, right. The burst frequency can be found elsewhere: The VDP is clocked at 10.738 MHz, which is 3 times the burst frequency. From here, the GROM clock is derived as 10.738 MHz / 24 = 447.4 kHz.

 

BTW, the TI-99/8 is clocked at 10.738 MHz because its VDP (9118) has no GROMCLK, so it is derived from that clock, which in turn means that the CLKOUT of the 99/8 is at 10.738 MHz / 4 = 2.68 Mhz, slower than the TI-99/4A. The Geneve, on the other hand, does not have any GROMs, so they let it run at 12 MHz.

Edited March 30, 2016 by mizapf