Jump to content
FarmerPotato

CRU read cycle and enabling signal to CRUIN

Recommended Posts

I'm trying to understand the CRU read behavior, to determine what goes in a PEB card logic to gate a signal to CRUIN.


Memory cycles have MEMEN*, DBIN, WE* signals to gate them, but from what I can tell from the PEB Technical Data, a CRU cycle is defined by the absence of MEMEN*. CRU writes are signaled by CRUCLK* but CRU reads just... fill all the rest of time?


I looked at Thierry's RS232 page



but it lacks the black-box logic for CRU_I*, which enables the gate that drives CRUIN.


It seems like there is the potential for multiple drivers on CRUIN while A2-A14 are changing. Since address is stable on the falling edge of PHI3*:


CRU_I* = NAND(MEMEN*, 10011 == A3-A7), perhaps a latch gated on the rising edge of PHI3. (10011 is >13 for first RS232 card.)


Does anyone know what's in the actual CRU_I* or how CRUIN is enabled on a real PEB card?


This is for my re-invented FORTI card project. (Yeah I know the original has no CRU.)


-Erik


  • Like 1

Share this post


Link to post
Share on other sites

 

Does anyone know what's in the actual CRU_I* or how CRUIN is enabled on a real PEB card?
This is for my re-invented FORTI card project. (Yeah I know the original has no CRU.)
-Erik

 

It seems we share the same name - good stuff :)

I am curious - what is your FORTI card project?

 

As I am working on the ET-PEB project this topic is actually very current for me. I do not have a PEB, I am just connecting directly to the edge connector, but I think the logic is the same, as described below.

 

- For reads, this is very simple: you need a three state buffer driving CRUIN. The buffer is off, except when you have an address match with MEMEN# high. Since CRU reads are not really qualified, it is not really possible to trigger activities based on CRU read. If and when you have multiple bits to read, you need to multiplex the correct bit (using low bits of address bus) to the input of your 3-state buffer.

- For writes, you gate with address match and MEMEN# high, with rising edge of CRUCLK. At least on the edge connector the CRUCLK signal is actually inverted, so it would be falling edge of CRUCLK when data is valid.

  • Like 1

Share this post


Link to post
Share on other sites

Yes, that is consistent with what is documented in the PEB technical Data (old blue manual).

 

RS232 PIO uses an LS251 one-of-eight multiplexer with 3 address bit inputs and the signal CRU_I* enabling the output (tri-state) to drive CRUIN. There is probably a PAL on the card that outputs CRU_I* which isn't documented.

 

I'm concerned about multiple drivers on the bus. MAybe not a big deal as long as the signals settle down on schedule.

 

One strategy might be to capture what the actual RS232 puts out on CRUIN.

  • Like 1

Share this post


Link to post
Share on other sites

I'm concerned about multiple drivers on the bus. MAybe not a big deal as long as the signals settle down on schedule.

 

 

 

With proper address decoding, only one CRU device is active at any time - so this shouldn't be an issue. The 9901 in the console isn't fully decoded, so keep out of it's address range!

 

http://www.mainbyte.com/ti99/schematic/schematics.html has several schematics, the FDC card has the '251 connected directly to CRUIN.

Edited by jens-eike
  • Like 1

Share this post


Link to post
Share on other sites

 

I'm trying to understand the CRU read behavior, to determine what goes in a PEB card logic to gate a signal to CRUIN.
Memory cycles have MEMEN*, DBIN, WE* signals to gate them, but from what I can tell from the PEB Technical Data, a CRU cycle is defined by the absence of MEMEN*. CRU writes are signaled by CRUCLK* but CRU reads just... fill all the rest of time?
I looked at Thierry's RS232 page
but it lacks the black-box logic for CRU_I*, which enables the gate that drives CRUIN.
It seems like there is the potential for multiple drivers on CRUIN while A2-A14 are changing. Since address is stable on the falling edge of PHI3*:
CRU_I* = NAND(MEMEN*, 10011 == A3-A7), perhaps a latch gated on the rising edge of PHI3. (10011 is >13 for first RS232 card.)
Does anyone know what's in the actual CRU_I* or how CRUIN is enabled on a real PEB card?
This is for my re-invented FORTI card project. (Yeah I know the original has no CRU.)
-Erik

 

Not sure if I'm helping or hindering, but here goes:

CRUIN (not inverted) back-originates at TMS9900, pin 31 as an input-only pin. It then travels to TMS9901, pin 4 as an input-only pin then continues on to the GROM port, pin 6 available for input from a command module (very few commercial ones communicated via this and therefore NC in a QI motherboard).

Regardless of MB, it then has an in-line 100 ohm resistor that continues to I/O side port, pin 33. From there it passes STRAIGHT through the console end of the PEB fire hose until it reaches the PEB interface card as pin 1, then routed down to the back plane of the PEB, pin 55 (now available to any card plugged into the PEB back plane. No pull ups or downs that I see in that unbroken signal chain.

I think what you may also be asking is what/how is that line manipulated? Please see the pin extract from the TMS9900 Microprocessor Data Manual, Dec. 1976, Table 2 attached below.

Hope that helps.

post-48993-0-56997300-1517350664_thumb.jpg

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...