9901 timing question

[+FarmerPotato]

I'm having a lot of questions about interfacing the 4MHz TMS9901-40 to the 99105 (6 MHz).   The 1978 databook covers both the 3Mhz (as in 99/4A) and 4MHz revisions, but I have found no actual examples (the two books I have do not show a 9901 in use.) 

 

I want to know the time it takes between /CE (chip enable, low) rising, and the CRUIN output being disabled (yeah, its named after the CPU's CRUIN.)

 

The datasheet gives the time from /CE low to data valid, but not from /CE high to output disabled.

 

The TMS99105 multiplexes CRUIN on the A0 pin, so, any CRU device needs to be off the bus when the next address is output.

 

The textbook by Avtar & somebody says to use a '125 tri-state gate, enabled by the RD* cycle pin, on any CRUIN. I'm reluctant to do that because it means adding an OR gate between each CRU chip enable and the RD* signal, so that's 3 chip delays (maybe OK, if they are the 74F32 OR gate and 74F125, to keep it under 25ns.)

LS125.G1* = OR(OR(CE0*, CE1*),  OR(CE2*, RD*))

 

or 3 125 gates with outputs tied together:

G1 = OR(CE0*, RD*)

G2 = OR(CE1*, RD*)

G3 = OR(CE2*, RD*)

 

The routing for this is a mess.

 

If the 9901 and 9902 are fast enough at getting off the bus after /CE goes high, those gates are unnecessary.

 

 

[+mizapf]

Ehm ... could we pick another question first? (just doing the student way...)

 

Anything in the 99xxx specs?

[+FarmerPotato]

2 hours ago, mizapf said:

Ehm ... could we pick another question first? (just doing the student way...)

 

Anything in the 99xxx specs?

Nope, the 99105 book doesn't mention any other 9900 family.

 

This textbook builds up CRU from discrete chips - priority encoders, 8-bit addressable latch '259 and 1-of-8 selector '151. No 9901. The '151 doesn't have an output enable pin, so it says to gate its output with a '125 tristate with OR(CE*, RD*) connected to its output enable.

 

The 99000 Microprocessor - Architecture Software and Interface Technique

Found on: http://www.stuartconner.me.uk/tms99110_breadboard/tms99110_breadboard.htm#references

 

So the only questions are tough:

 

1. I have a '138 decoding CRU addresses into CE for each thing. With chip enable G1= MEM indicating a CRU cycle. I'd like to use G2*=ALATCH so that all the CE outputs go high as soon as a new memory cycle begins with ALATCH=1. 

 

2. If the PHI3 input is a 50% duty 3MHz clock, does the 9901 work at all? The datasheet indicates that the 9901 requires Phi3 to be 225ns high, 45ns low. That's what you get from Phi3 out of the 9900 - phase 3 of a 4 phase clock. However, the 9901-40 allows 160ns high, 45ns low, so it should work with a 3 or 4MHz 50% clock. So I think that's the answer to that.

 

3. The TMS99105 (6 MHz) gives an automatic wait state to CRU devices so that the cycle is 333ns. With the above clock, the falling edge of Phi3 may occur in the first or second half of this 333ns. Is there a required phase relationship between the input clock and the read/write cycle? Phi3 seems to control only the latching of interrupt bits in the CRU, and the internal timer. Will there be glitches reading interrupts that are simultaneously being latched? I hope the worst that happens is that they are read a cycle later. 

 

4. Should I just give up on the 9901 and build the equivalent out of '147, '259, and '151 chips?

 

 

[+TheBF]

Is it possible to breadboard up a clock and a 9901 and take some measurements?

[+FarmerPotato]

2 hours ago, TheBF said:

Is it possible to breadboard up a clock and a 9901 and take some measurements?

Yes.

 

I was wondering, if I put a pull-up resistor on CRUIN, how do I measure when a pin goes hi-Z if I don't know if it was outputting a 0 or a 1.

 

I think I need two transistors, one which switches on when CRUIN is high, one which switches on when CRUIN is low.

 

 

 

 

[Stuart]

2 hours ago, FarmerPotato said:

I was wondering, if I put a pull-up resistor on CRUIN, how do I measure when a pin goes hi-Z if I don't know if it was outputting a 0 or a 1.

 

If you pull one of the 9901 programmable inputs either high or low then use the TB instruction to read the state of that input, then you'll know whether CRUIN will be high or low? So if you pull CRUIN high through a resistor and use it to measure a low input, it should be fairly obvious when it goes hi-Z?

[+FarmerPotato]

Continuing with 9901 to 99105 timing relationships, I calculate that the 6 MHz 99105 has IOCLK* low time of 70ns. The fall time is 13 ns, the rise time is 15 ns. This gives a width of less than 80. According to the 9901 datasheet, the minimum CRUCLK pulse width tw(cc) is 80 ns.

 

This can be mitigated by inserting another wait state on 9901 cycles. Or live dangerously.

 

For the 9902, I calculate the setup time for address before cruclk, tsu(ad) , is 165 ns, but the typical is 220.

CE to CRUCLK will be 165ns  less ~15ns from a latch, vs typical 180 ns.

Hold time for address after CRUCLK squeaks by with 80ns, but CRUCLK pulse width is typical 100, and as above tw(cc) I have just under 80 ns.

So that's 3 strikes against the 9902 (at least from the 1977 data manual  I have. Maybe I need the 4Mhz variety!)

 

Running at 4 MHz (16 MHz crystal) seems so much safer when operating 9901 and 9902.

 

But it looks like I need to generate a wait state for all CRU cycles.

[+TheBF]

It's hard to really win with this old tech.  At least you will have a faster processor. 

A cooperative tasker could make use of those extra cycles during I/O.

 

When you are ready give me a memory map I might be able to give to a kernel to test the new iron.

(Or I can finish the cross-compiler manual and you can build it yourself)

 

[+FarmerPotato]

2 hours ago, TheBF said:

It's hard to really win with this old tech.  At least you will have a faster processor. 

A cooperative tasker could make use of those extra cycles during I/O.

 

When you are ready give me a memory map I might be able to give to a kernel to test the new iron.

(Or I can finish the cross-compiler manual and you can build it yourself)

 

Cooperative - well, I'm talking about a single instruction like TB, or the LDCR cycles. Normally a 99110 CRU cycle is 2 clocks (333 ns) and I think I need 1 more wait state, for 500ns.)  Nothing else could happen in that time, because the address/data bus AD0 and AD15 are used as CRUIN/CRUOUT.

 

I'll be happy to have CamelForth on it. For starters, the memory map is the same as Stuart's 99110 where the first 32K is ROM, second 32K is RAM. The 99110 only reserves addresses FFFC-FFFF, no onboard RAM. I planned to use Stuart's 9900 FORTH for hardware debugging at first.I'm looking forward to having the FORTH assembler there for doing the testing and debugging!   In fact, the machine will always and forever have a built-in FORTH bios.

 

There is actually 128K of ROM and 128K of RAM. 32K of each is the supervisor. The rest is 3 separate user spaces with 32K ROM, 32K RAM too. Just because the bigger chips are cheaper than smaller ones! For now, each extra user space will be like a "cartridge" you can jump into, after the supervisor gives you a FORTH prompt. Privileged instructions jump back into supervisor space. This is just a prototype though.

 

But this initial ROM/SRAM in user space will be "mapped over" when the FPGA is in certain modes (Geneve for example). It could be covered by 4K DRAM pages (up to 32MB) or memory mapped device addresses. That's the mechanism for implementing the Geneve memory map. 

 

 

 

[+FarmerPotato]

I'm struggling to design a wait-state generator that counts 3 CLKOUT cycles. Counting two is easy enough... just clock a flip flop on CLKOUT=low, with input = !output, when each cycle completes. It outputs READY during the 2nd cycle, and the CPU samples that. Unfortunately, it doesn't stop and it gets the next CLKOUT too, which would freeze the machine.

I guess I need a count-to-four that stops on 3 and resets somehow.. yuck.

 

I considered dropping the 9901 in favor of separate  TTL (re-implementing the 9901!), but the 9902s would be left cold.

 

 

[Stuart]

Have you looked at something like https://electronics.stackexchange.com/questions/286052/divide-clock-frequency-by-3-with-50-duty-cycle-by-using-a-karnaugh-map ? Pretty simple if you're not worried about the duty cycle.

Edited January 15, 2020 by Stuart

[+FarmerPotato]

On 1/15/2020 at 3:04 PM, Stuart said:

Have you looked at something like https://electronics.stackexchange.com/questions/286052/divide-clock-frequency-by-3-with-50-duty-cycle-by-using-a-karnaugh-map ? Pretty simple if you're not worried about the duty cycle.

That got me thinking. 

 

When a write starts, READY must be pulled low on the falling edge of SE*, then pulled high after a falling edge of CLKOUT and a rising edge of CLKOUT. Otherwise SE* will never be released back to high. There may be a rising edge of CLKOUT as SE* falls... they overlap.

 

I think the solution is an edge detector with a  delayed pulse.

The edge is SE* = CE*+WE* (falls when a CRU cycle begins)

 

 

So I'm still working on this. I've come with a half dozen ideas that don't work.

 

Here's the 99105 CRU cycle. The cycle on the right is what I want. 

[Jimhearne]

On 1/15/2020 at 5:00 PM, FarmerPotato said:

I'm struggling to design a wait-state generator that counts 3 CLKOUT cycles. Counting two is easy enough... just clock a flip flop on CLKOUT=low, with input = !output, when each cycle completes. It outputs READY during the 2nd cycle, and the CPU samples that. Unfortunately, it doesn't stop and it gets the next CLKOUT too, which would freeze the machine.

I guess I need a count-to-four that stops on 3 and resets somehow.. yuck.

 

I considered dropping the 9901 in favor of separate  TTL (re-implementing the 9901!), but the 9902s would be left cold.

 

 

Can't you just use a shift register and clock a 1 bit into it.  Then the outputs will give you 1 to 8 wait states (for a 8 bit shift register).

I've got a 99105 based system running with a 9901 on it, but the 9901 is on a E-Bus card not on the cpu card.

It's a few years since i worked on it, need to get back to it.

 

Jim

Edited January 22, 2020 by Jimhearne

[pnr2015]

On 1/14/2020 at 1:54 AM, FarmerPotato said:

 

So the only questions are tough:

 

1. I have a '138 decoding CRU addresses into CE for each thing. With chip enable G1= MEM indicating a CRU cycle. I'd like to use G2*=ALATCH so that all the CE outputs go high as soon as a new memory cycle begins with ALATCH=1. 

 

2. If the PHI3 input is a 50% duty 3MHz clock, does the 9901 work at all? The datasheet indicates that the 9901 requires Phi3 to be 225ns high, 45ns low. That's what you get from Phi3 out of the 9900 - phase 3 of a 4 phase clock. However, the 9901-40 allows 160ns high, 45ns low, so it should work with a 3 or 4MHz 50% clock. So I think that's the answer to that.

 

3. The TMS99105 (6 MHz) gives an automatic wait state to CRU devices so that the cycle is 333ns. With the above clock, the falling edge of Phi3 may occur in the first or second half of this 333ns. Is there a required phase relationship between the input clock and the read/write cycle? Phi3 seems to control only the latching of interrupt bits in the CRU, and the internal timer. Will there be glitches reading interrupts that are simultaneously being latched? I hope the worst that happens is that they are read a cycle later. 

 

4. Should I just give up on the 9901 and build the equivalent out of '147, '259, and '151 chips?

 

 

I think you are maybe over-analyzing it: connecting CLKOUT to /PHI3 will likely work up to 4MHz. Connecting CLKOUT divided by two to /PHI3 will work up to 6MHz. Use the falling edge of CLKOUT to clock the divider to get phases right.

 

1. I think that the address lines may not yet be stable at the start of ALATCH, but certainly will be by the end of it, i.e. you may have a CE glitch during ALATCH. Normally this should not matter, as the actual fetch or write happens later in the cycle.

 

2. I think for the 9901 the PHI3 duty cycle does not matter. PHI3 appears to have only two uses: to drive the internal counter and to synchronize the interrupt circuit. The data sheet only says that the pulse width is *minimum* 45ns, it could be wider. Looking at the 99000 and 9901 data sheets, using CLKOUT for PHI3 should work for both purposes.

 

3. The 9901 output bits are driven by the falling edge of CRUCLK, not by PHI3; the extra PHI3 cycle does not matter I think. The input bits are read on the rising edge of /RD, again PHI3 does not matter. With the automatic wait state there is plenty access time, even at 6MHz.

 

To be sure, set up a test circuit on Stuart's 99000 board. I've glued a small strip of solder less breadboard in one corner for such experiments, but I don't have a 9901 at hand to verify my above views.

[+FarmerPotato]

On 1/24/2020 at 1:44 PM, pnr2015 said:

I think you are maybe over-analyzing it: connecting CLKOUT to /PHI3 will likely work up to 4MHz. Connecting CLKOUT divided by two to /PHI3 will work up to 6MHz. Use the falling edge of CLKOUT to clock the divider to get phases right.

 

1. I think that the address lines may not yet be stable at the start of ALATCH, but certainly will be by the end of it, i.e. you may have a CE glitch during ALATCH. Normally this should not matter, as the actual fetch or write happens later in the cycle.

 

2. I think for the 9901 the PHI3 duty cycle does not matter. PHI3 appears to have only two uses: to drive the internal counter and to synchronize the interrupt circuit. The data sheet only says that the pulse width is *minimum* 45ns, it could be wider. Looking at the 99000 and 9901 data sheets, using CLKOUT for PHI3 should work for both purposes.

 

3. The 9901 output bits are driven by the falling edge of CRUCLK, not by PHI3; the extra PHI3 cycle does not matter I think. The input bits are read on the rising edge of /RD, again PHI3 does not matter. With the automatic wait state there is plenty access time, even at 6MHz.

 

To be sure, set up a test circuit on Stuart's 99000 board. I've glued a small strip of solder less breadboard in one corner for such experiments, but I don't have a 9901 at hand to verify my above views.

Belated thanks for your answers! I stopped over-analyzing it and went with your information. I re-read the 9901 datasheet. 

 

1. Worried about a CE glitch. I will make ALATCH a low-enable to any '138 address space decoder. That will make devices get off A0/D0/CRUIN when a new A0 is being output by the CPU.

 

on p.98 of the 99110 datasheet, I see ALATCH high is twH3 = 30 ns (from 166/4-10). I need to check that the '138 propogation and 9901 CE* disable times fit.

 

I don't have hardware to test on yet. But I'm building a 4-slot backplane with one breadboard, where my CRU module will be a plug-in card. INTREQ* has a pull-up at the CPU, and INTREQ* and IC0-IC3 will be reserved for the CRU card in slot 1. Each slot can have its own interrupt line. 

 

 

[Stuart]

Did you ever get anywhere with this @FarmerPotato? I've just added a TMS9901-40 to my TMS99110 board (running at 4 MHz) and it works fine, in terms of programming the 9901 clock for 250ms level-3 interrupts. Just wired it in the same way as the 9902, and fed /INTREQ and IC0 - IC3 to the CPU.

[Jimhearne]

I don't know about the TMS9901 but a lot of my TMS9902 (both -4 and not) seem to run at 6mhz clock quite happily.

That running the TMS99105 at 24mhz and the TMS9902 connected directly to CLKOUT.

[+FarmerPotato]

On 11/12/2020 at 4:20 PM, Stuart said:

Did you ever get anywhere with this @FarmerPotato? I've just added a TMS9901-40 to my TMS99110 board (running at 4 MHz) and it works fine, in terms of programming the 9901 clock for 250ms level-3 interrupts. Just wired it in the same way as the 9902, and fed /INTREQ and IC0 - IC3 to the CPU.

 

I haven't gotten there yet. You kind of lit a fire though. I just got through debugging the 99105 to memory card at 3MHz, and I want to get the I/O working next, before cranking up the speed. 

 

It's encouraging that you and Jim are testing these chips at higher speeds.

 

My prototype is shown over here: