This very bulky piece of hardware is meant to support upto eight peripheral cards that will enhance the capabilities of the TI-99/4A console. It has its own power supply, which provides each card with the necessary power for a +5V, a +12V and a -12V (possibly -5V, with a large heat sink...) voltage regulator.
It is connected to the console side port via a 38-connection cable that ends up in a peripheral card. And here goes one of the eight available slot. For some reason, the cable does not carry all lines available on the console side port (even though some of them are present in the PE-box bus).
The PE-box is a ventilated unit, and is designed to cool the peripheral cards when the lid is close. The manual specifies that proper ventilation cannot be insured if the lid is left open.
The front pannel has little glass window in front of each card slot. A card can thus use an onboard LED to signal the user that it is in use. It may be usefull for troubleshooting purposes, but I suspect it was mainly meant to look cool... Here is a picture (not mine).
The PE-box also has room for a disk drive unit and provides it with power. This drive of course requires a controller card. The original card by TI could also control two more disk drives, to be intalled externally (with their own power supply). Later on, some third parties offered slim units that would allow to fit two disk drives in the space originally meant for one.
The connection card
Fixing the firehose cable
A typical peripheral card
The PE-box provides unregulated power, meant to be used by voltage regulators intalled on each card. Typically, these would be a 78x05 (+5V) , a 78x12 (+12V) or a 79x12 (-12V). According to the specs, these regulators need an input voltage at least 3V in excess of the required output voltage. Therefore, the PE-box supplies them with +16V, -16V and +8V. Note that if you need -5V, you could use a 79x05 and feed it with the -16V supply. This would just mean that you need a really big heat sink, since this regulator is going to dissipate a lot of power...
The PE-box connect each card to a xxx-lines internal bus. Some of the lines on the bus are meant for production purposes and are held high in the PE-box. Supposedly, the card manufacturing machines used them to burn EPROMs or test the card. Here is a picture of the inside (not mine).
59 Left 1
Front ===================== Rear
60 Right 2
# Name I/O Use
-- ----- --- --------------------------------------------
1 Power supply for a +5V 3-T voltage regulator (about +8V)
4 READYA < System ready (goes to READY, 10K pull-up to +5V) A low level puts the cpu on hold.
6 RESET* > System reset (active low)
8 SCLK nc System clock (not connected in interface card)
9 LCP* nc CPU indicator 1=TI99 0=2nd generation (not connected in interface card)
10 AUDIO < Input audio (to AUDIOIN in console)
11 RDBENA* < Active low: enable flex cable data bus drivers (1K pull-up)
12 PCBEN H PCB enable for burn-in (always High)
13 HOLD* H Active low CPU hold request (always High)
14 IAQHA nc IAQ [or] HOLDA (logical or)
15 SENILA* H Interrupt level A sense enable (always High)
16 SENILB* H Interrupt level B sense enable (always High)
17 INTA* < Interrupt level A (active low, goes to EXTINT*)
18 LOAD* nc Unmaskable interrupt (not carried by interface cable/card)
19 D7 <> Data bus, bit 7 (least significant)
21 D5 <>
22 D6 <>
23 D3 <>
24 D4 <>
25 D1 <>
26 D2 <>
28 D0 <> Data bus, bit 0 (most significant)
29 A14 >
30 A15 > Address bus, lsb. Also CRU output bit.
31 A12 >
32 A13 >
33 A10 >
34 A11 >
35 A8 >
36 A9 >
37 A6 >
38 A7 >
39 A4 >
40 A5 >
41 A2 >
42 A3 >
43 A0 > Address but, bit 0 (most significant)
44 A1 >
45 AMB H Extra address bit (always High)
46 AMA H Extra address bit (always High)
48 AMC H Extra address bit (always High)
50 CLKOUT* > Inverted PHI3 clock, from TIM9904 clock generator
51 CRUCLK* > Inverted CRU clock, from TMS9900 CRUCLK pin
52 DBIN > Active high = read memory. Drives the data bus buffers.
54 WE* > Write Enable pulse (derived from TMS9900 WE* pin)
55 CRUIN < CRU input bit to TMS9900
56 MEMEN* > Memory access enable (active low)
57 Power supply for a -12 Volts 3-T voltage regulator (about -16V)
59 Power suppy for a +12 Volts 3-T voltage regulator (about +16V)
Here is the same info, arranged as on the connector:
+8V 1||2 +8V
GND 3||4 READY
GND 5||6 RESET*
GND 7||8 (nc)
(nc) 9||10 AUDIO
RDBENA* 11||12 (high)
(high) 13||14 (nc)
(high) 15||16 (high)
INTA* 17||18 (nc)
D7 19||20 GND
D5 21||22 D6
D3 23||24 D4
D1 25||26 D2
GND 27||28 D0
A14 29||30 A15/CRUOUT
A12 31||32 A13
A10 33||34 A11
A8 35||36 A9
A6 37||38 A7
A4 39||40 A5
A2 41||42 A3
A0 43||44 A1
(high) 45||46 (high)
GND 47||48 (high)
GND 49||50 CLKOUT*
CRUCLK* 51||52 DBIN
GND 53||54 WE*
CRUIN 55||56 MEMEN*
-16V 57||58 -16V
+16V 59||60 +16V
The main purpose of the connection card is to buffer signals to or from the console, before to send them out on the PE-box bus. The buffers are 74LS244 TTLs, except for the data bus that requires a bidirectional transceiver 74LS245. The console end of the cable also contains a 74LS245 chip to buffer the data bus once more. Nevertheless, the TI specs insist that each card must rebuffer all signal from or to the PE-box bus.
The LED in the front of the connection card is turned on by DBIN (high = on). Thus, it will shine for reading operations, and shut off for writing operations. The end result is that it twinkles when the bus is active.
Here is a picture of the card, and one of the connector on the console side of the cable.
Most of the lines are buffered (or generated) by TTLs inside the TI-99/4A console. In addition, the data bus D0-D7 is buffered in the connector itself. The connector "black box" contains a 74LS245 buffer and a 78M05 voltage regulator powered by the PE-box. It also contains 47 Ohm serial resistors placed within many lines (D0-D7, A0-A14, Reset, DBIN and Memen*).
Most signals are buffered again in the connection card: the 16 address lines A0-A15, DBIN, Memen*, WE*, CLRCLK*, RESET*, CLKOUT*. As mentionned above, D0-D7 are buffered again by a second 74LS245 onboard the card, after another set of 47 Ohm serial resistors. The direction of both 74LS245 buffers is set automatically by the DBIN line. However, the peripheral card is responsible for activating these buffers when it needs them. This is done by lowering the dedicated RDBENA* line which is connected to the OE* pin of each 74LS245 (but not to the console side port).
You will have noted that all input signals are left unbuffered: CRUIN, INTA*, AUDIOIN, READY. Maybe so that the peripheral card has the option to leave them in high-impedence state? Of these, only READY has a 10 K pull-up resistor in the connection card.
The "for production line only" pins AMA, AMB, AMC, SENILA*, SENILB*, PCBEN, HOLD* are pulled up to +5 Volts by 47 Ohms resistors. These would be really hard to pull down! Anyway, most third party cards ignore them. The TI disk controller card on the other hand makes use of several, posssibly for test procedures on the production line.
The PE-Box lines SClk, SCP*, IAQHA, and LOAD* are not even connected to the connection card.
Similarly, some lines present on the console side port are not part
of the cable. These "lost" lines are:
SBE* Output line which is low to signal an access to the speech synthesizer (address >9000-97FF). We can dispense with that one.
MBE* Output line which is low to signal an access to the card ROMs (address in >4000-5FFF). This one would spare us the need for a 74LS138 decoder!
IAQ Interrupt acknowledged by the CPU. Not very usefull anyhow except possibly for a debugger card.
LOAD* Input line used to send an unmaskable interrupt to the CPU. This could have been really usefull, too bad!
You probably have realised that the PE-box is byte-oriented: it has 16 address lines and 8 data lines (as opposed to 15 address pins and 16 data pins on the TMS9900 CPU). I always wondered why TI decided to cripple their system in such a way. Probably because most peripherals in the early eighties were byte-oriented. Or maybe it was just to save a few lines in the connection cable? Or else, just to copy IBM and make the same mistake they did with the PC XT??
Anyhow, what it means is that the data bus has to be multiplexed. This is achieved by a small logic circuit inside the TI console: any memory access to the range >2000-7FFF and >A000-FFFF is multiplexed. The least significant byte (odd address, D8-D15) is passed first, and this is signaled by a high level on the additional address line A15. For input operations, this byte is latched into the console by a 74LS373 D-type latch. Then the multiplexer puts the CPU on hold (with the READY line) and places the most significant byte on the data bus (even address, D0-D7), which is signaled by a low level on A15. The operation will only be completed after 4 clock cycles on Phi3*, by releasing the block on the TMS9900.
Concretely, this means several drawbacks:
If you wanted to use a peripheral with a 16-bit data bus, you could use the circuit below to de-multiplex the PE-box data bus. It is similar to the multiplexing circuit in the console, with a few modifications (tested by yours truly: works fine).
CardSel* is an active low selection signal generated by your
card (see below).
The '245 is activated by CardSel*, only when A15 is low, i.e. for the even (most significant) byte. Its direction is set by DBIN.
The '244 is active when both A15 and DBIN are high, i.e. when reading an odd (least significant) byte.
The '373 is only addressed by writing operations. It latches the odd byte when A15 is high and WE* low, and outputs it to the 16-bit bus when A15 and DBIN are low , thereby reconstituting the 16-bit bus as the TI-99/4A sends the even byte.
NB The 8-bit bus is numbered the way TI does, i.e. D0 is the most significant bit. The 16-bit bus is numbered like everyone else does, i.e. D15 is the most significant bit.
The most delicate part of the PE-box is probably the connection cable (aka "firehose"): it's easy to bend and/or bang it, and it may eventually become defective. Not to worry though: it can easily be replaced.
Depending on which line was broken, the symptoms may vay quite a bit. For instance, I had one case when the console would boot by itself, but crash when the connection cable was plugged in (even with the PB-Box off, even with the card out of the PE-Box).
If it boots, you can check the data and address busses with the Easy-Bug function of the Mini-memory, or CALL LOAD and CALL PEEK in Extended Basic: write >FF (i.e. 255) and >00 at addresses >3333 (13107) and >CCCC (-13108). Then check if the data is ok, and if it was written at the right place.
If the memory expansion works but you cannot select any other peripheral card, then it's probably the CRUCLK line that broke.
A key symptom may be that the problem comes and goes as you fumble with the cable, bend it, stretch it, etc. This points toward a broken wire inside the cable.
First, make sure the problem is not bad connnections in the side port. Get a contact cleaner spray and clean the console side port and the firehose connector. While you are at it, remove the connection card from the PE-box and clean its contacts, as well as its slot in the PE-box (heck, clean ALL slots in the PE-box)..
If this does not solve the problem, a wire may be broken, or a chip may be defective. Let's first check the cable.
Refer to these pictures to identify the components on the card, and on the connection board. Now you are ready to test the cable (we couldn't do it without dismantelling the cable, because of the resistors and buffer chips). Flip both boards upside down, so you can access the pins from under. Using a continuity tester, make sure current goes from each pin on the console end of the cable, to its corresponding pin on the card side. If you already know which line is bad, refer to the above schematic to locate its wire and test it directly. Remember that the problem may come and go as you move the cable.
If everything looks ok, then is may be that a given buffer chip is dead. These are very common and cheap TTLs, so you should not have any problem buying a spare. Then just unsolder the original (using a soldering pump), and solder back the new chip.
Replacing the cable is not much harder:
Repeat your point-to-point tests, to make sure that the new cable makes proper contacts everywhere. If so, you can put everything back together:
In case you want to design your own peripheral cards, there are a few common features that should be present on each and every card. The schematic below represents a typical card, but you don't have to adopt all my design choices (especially since I did not test all of them yet!). If you need help about a chip, have a look at my TTL chips page.
Typically, you would use a 78L05 connected to the +8V power line.If you need more current than the 100 mAmps delivered by the "L" version, you could use a 7805 (1 Amp), a 78T05 (3 Amp) or a 78H05 (5 Amp). By all means, use a heat sink.
If you need +12V, you may similarly use a 78L12, a 7812, a 78T12 or a 78H12.
Negative voltages can be derived from the -16V supply, via 79x12 or 79x05 regulators.
The address lines require two 74LS244 buffers. The extra CPU output lines require a third one.
The data bus is buffered by a 74LS245, with the DIR pin driven by DBIN (high = read cycle) and the EN* pin driven by RDBENA*.
The extra TMS9900 input lines (if you are using them) can be buffered by 74LS125. This way, you can keep them in high impedance state when your card is not accessed.
As described in the page on CRU, you'll need a 74LS259 for CRU ouput from the TMS9900, and a 74LS251 for CRU input operations. It is generally good practice to echo each bit from the '259 to the '251, unless you have a need for specialised input bits. In addition, some selection logic is needed: a 74LS85 does a pretty neat job, as it allows the user to select the CRU address of the card with a DIP switch (tested: works fine). In this schematic, I also included a master switch (accessible from the back of the PE-pox) so that the user can shut off the card if necessary.
ROM selection logic
A 74LS138 decoder can be used to detect memory accesses in the range of the card ROM, >4000-5FFF. The G2A* active low selection input is driven by MEMEN*, so that the card only reacts to memory operations. I also included a master switch (which may or may not be the same as the one for the CRU) connected to G2B*: when the switch is open the card is never selected. Finally, the G1 enabling input of the decoder is controlled by CRU bit 0, so that the card will only answer when it is enabled via the CRU. You may want to use that bit to enable/disable other important functions on your card: in this exemple all it does is to enable the data bus.
Of course, nowadays many people would use a GAL (programmable logic) to implement the selection logic, both for ROM and CRU...
The LED is generally driven by CRU bit 0, but that's up to you.
When it comes to choosing a memory chip to install the card DSRs in, you have several choices:
Price is of course a consideration, but nowadays memory becomes cheaper and cheaper, at least at the scale of the TI-99/4A. Therefore, our choice is basically down to EEPROMs or SRAM, possibly FLASH. These can easily be mail-ordered from several places on the Web (Digikey, Jameco, Mouser, etc). For your information, here is a comparative table I came up with, after only an hour surfing the net. You could fill in the blanks, with a little more hunting...
STM (+battery) $7.30
Atmel $225.20 !
Atmel $978.60 !
Rather than using an expensive EEPROM programmer, it would be nice to install an EEPROM (or a FLASH) so that it can be programmed while inside the PE-box. Traditionnally, writing and erasing is done by applying a programming voltage (+12V, +13V, +25V, etc) on a given pin. This could be implemented on a peripheral card with a +12V voltage regulator, whose output is applied to the programming pin of the EEPROM via a PNP transistor, controlled by a CRU bit for instance.
But there is a better solution: you can now find FLASH and EEPROM memories that have a built-in voltage converter. That is, they only need the regular +5V applied to Vcc. FLASH generally have a protection against spurious writings: to program or to erase them, you must first send an "unlocking sequence" (kind of a password). This is a slight annoyance for us, since the TI-99/4A won't write a single byte in 8-bit memory. We saw above that it will perform 4 access operations: first reading a pair of addresses, then writing to them. This will mess up the unlocking sequence and prevent us from writing to the chip. Unless we add extra hardware to accept only the relevant write cycle and filter the other three: such a circuit could be enabled by a CRU bit, so as not to disturb regular ROM reading operations (see below).
Unlike FLASH, then +5V EEPROM generally don't require an unlocking sequence, but writing a byte will stall the chip for a moment, while the internal logic is writting it. So again we will need some kind of circuitery to access odd and even bytes independently.
A simple solution would be to have two memory chips: one for odd bytes and one for even bytes. The chips can be piggy-backed, with all their corresponding pins connected together except for the CE* pins. These are driven by the CardSel line combined by OR gates with either A15 (even bytes) or the inverse of A15 (odd bytes).
In this circuit I also filtered the WE* line by combining it with the inverse of CRU bit 1. This provides a write-protection mechanism: you can only write to the memory if CRU bit 1 is set to 1. Note that all CRU bits are 0 at power-up time, so the memory will be write-protected by default. For the opposite behaviour, remove the 74LS04 inverter.
CRU bit 1 also serves to prevent read operations, when set to 1. This is only required for chips that have an unlocking sequence: it prevents the read operation that comes along with each write in the TI-99/4A system, from messing up the unlocking sequence. If you are using EEPROMs that have no unlocking sequence, CardSel* can be directly combined with A15 and not-A15.
Finally, additional CRU bits could be used to page the memory, so as to implement more than 8 Kbytes.
The controlling software could be something like this:
* Routine to send an unlocking sequence to two FLASHs and program a word
SELPAG LI R12,>1x00 CRU address of our card
This example assumes that the unlocking sequence is the following:
Remember that there are two chips, (one for odd bytes, one for even bytes) so the addresses need to be multiplied by two and become >0AAA and >1554 respectively. To which we add >4000, which is the address of the card.
If you don't like the idea of having two FLASH chips to implement only 8K of memory, here is an alternative: a circuit that lets you access only even bytes (or only odd bytes) at will.
The FLASH programming routine should be modified accordingly:
* Crude FLASH-writing routine
FLASHW LI R12,>1x00 CRU address of your card
What if you need more than 8K of ROM in your card? Well, nothing prevents you from installing a larger EEPROM/FLASH: these are quite cheap nowadays. But you'll just need some sort of switching mechanism to page the memory into the >4000-5FFF bank. One way to do it is to drive the extra address lines with CRU bitsas demonstrated in he circuit above.
Another way is to use a 74LS273 latch to store a page number. This chip can latch 8 bits, so you'll have a maximum of 256 pages. This comes to 256 * 8K = 2 Megs of ROM. This should be enough...
74'273 EEPROM/SRAM (2 megs)
To avoid the problems due to data bus multiplexing, this design uses of a commonly used TI trick: latching a value in the 74LS273 is done by writing to an address in the range >4000-5FFF. Bits A7-A14 of the address bus are latched by the pulse on the WE* line, and make up the new A12-A19 for the memory chip (we cannot latch A15 since it is automatically toggled by the multiplexer). Of course, we don't have to use all eight bits: even if we latch eight, only those that we need will be connected to the memory chip.
CRU bit 3 is used to enable latching at will. This is only necessary if you plan to write to this memory , e.g to program a FLASH/EEPROM, or if you are using static RAM. If you are using a pure ROM, you can assume that it will never be written to and dispense with CRU bit 3: every write operation is considered as a page selection.
The RESET* line insures that page 0 will always be selected at power-up time. That's required if you want to place a standard header in your card ROM.
The control software would look like this:
* Routine to latch an address and select a page in the memory chip
SELPAG LI R12,>1x00 CRU address of our card
Back to the TI-99/4A Tech Pages