+FarmerPotato Posted January 30, 2018 Share Posted January 30, 2018 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 http://www.unige.ch/medecine/nouspikel/ti99/rs232c.htm 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 1 Quote Link to comment Share on other sites More sharing options...
speccery Posted January 30, 2018 Share Posted January 30, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 30, 2018 Author Share Posted January 30, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
jens-eike Posted January 30, 2018 Share Posted January 30, 2018 (edited) 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 January 30, 2018 by jens-eike 1 Quote Link to comment Share on other sites More sharing options...
+helocast Posted January 30, 2018 Share Posted January 30, 2018 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 http://www.unige.ch/medecine/nouspikel/ti99/rs232c.htm 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.