Yet another Peripheral Expansion Box troubleshooting thread

[+chue]

I did something that I said I would never do, which is purchase a Peripheral Expansion Box.  It came with 4 TI branded cards: 32K RAM, RS232, Disk Controller, and Flex Cable card.

 

Initially the TI would not boot with all 4 cards in the PEB.  So I took out the RS232 card and then the TI would boot.  I was able to see the 32K RAM in XB; however, when I ran @jedimatt42's 32K RAM tester half the RAM appeared bad.

 

 

Here's what I've done since:

 

- Removed all the cards and cleaned all the contacts on the cards themselves, the PEB, the flex cable, and the TI.

- Measured the voltages in the PEB using the Molex cable.  I get these voltages, which seem ok: +5.00, +11.71

- Inserted just the 32K and flex cable card; I reran the RAM diagnostic above and get the same result.

- The flex cable has several small rips (tears) in it and so I took it apart to test for continuity.  All lines in the cable show continuity, except one - the yellow arrows below indicate the potentially faulty line:

 

 

So my question at the moment is, should this line in the cable show continuity?

[JasonACT]

The schematics show there are 44 wires from the TI-99/4A plug part going to the PEB card - and I see 44 pins on each of your photos - so I'd say yes.  EDIT: might be address line A2 given where the failure is in the RAM check, where the last bank being checked might be incorrectly mapped into 0xCXXX which passed, so 0xEXXX would pass too.  EDIT2: That looks like pin 1 (based on the ground pins I can see) which is CRU IN - and explains why the RS232 card isn't working, it uses CRU IN extensively.  Maybe you have a bad line driver in the 32KB card?  EDIT3: Or in the flex card, which wouldn't affect most cards except the 32KB one.  You can use the Mini Memory Easy Bug to check if 0xCXXX is the same as 0xEXXX to see if A2 is dead.

Edited December 13, 2023 by JasonACT

[+chue]

Thanks.  I confirmed it is pin 1.  In the schematic, pins 42 and 44 are 8V and are tied together, at least on the PEB side.  I checked for continuity on both sides of the cable to see if I could locate pins 42 and 44.  Indeed I see continuity on the left side (where I've marked pins 42 and 44 below):

 

 

So my next step will be to see if I can fix the wire that goes between the two pin 1's.

[JasonACT]

Well, when you get up to it, if Easy Bug shows 0xCXXX different to 0xEXXX, then it won't be address line A2 - and means it'll most likely be one of the 8 DRAM chips in Bank 0 (there are 2 banks of 8 x 4116 chips, one for 0x2 & 0xA - and another for 0xC and 0xE).

[+chue]

I have done a little surgery on the flex cable.  I actually found 2 cut lines, one on each edge of the flex cable.  These were lines for pins 1 (CRU) and 44 (8V).  The 8V line was showing continuity previously, because it is also tied to another 8V line (pin 42). 

 

So the good news is that the TI boots now with the RS232 card installed.  I will probably test that later on. 

 

The bad news is that this didn't change the RAM issue; this makes sense since the broken lines had nothing to do with any address/ data lines.  More on the RAM issue in the following post.

 

[+chue]

On 12/13/2023 at 12:40 AM, JasonACT said:

if Easy Bug shows 0xCXXX different to 0xEXXX

I did do some debugging with EasyBug - I confirmed that Cxxx and Exxx show different data.  When I write to one range, it does not show up in the other range.

 

Additionally, I wrote 00 and FF values to two consecutive bytes in each of these ranges: 2000, C000, A000, and E000:

 

 

The FFs were written and read ok, but when writing 00s, there looks like a single bit is stuck on 1 in the 2000 and A000 ranges.

 

At this point this looks like one bad RAM chip, does that make sense?

[RickyDean]

Wasn't there a program, back in the day that could test the TI 32k each IC and tell which chip was bad?

[+chue]

I actually found one on AA. It was in BASIC and I manually typed it in. When I ran it it showed 8 bad chips. It’s possible I mistyped something.

 

 

Edit: I used this one: 

 

[RickyDean]

If you have an extra 32k card, it would do well to try that and see if the same errors exist. Then I'd start by checking the lines in the cable that run through the flex card buffers to those IC's. Then test the buffer chips in the flex card, there are 4 in the flex card and I think a couple in the foot of the flex cable to see if there are any bad ones. At this time since you've already had an issue with the cable, it seems like something may have shorted or there are breaks in the ribbon cable lines that are not allowing the card to work right. At least that's where I would look first if another card showed the same failure.

[JasonACT]

It's interesting that only the even bytes have a stuck bit, but not so much that it's stuck on the same bit at both >2000 and >A000.  It's not what I would describe as an open-and-shut case.  That basic program is difficult to follow too, given it says it wrote 0 but got 36 (>24 hex) only 2 chips should show as faulty, one of which matches your EasyBug experiment.

 

I'd write another very simple basic program which sets 64 bytes starting at >2000 to 0 (and another loop for >A000) and report back what they read as.

 

Looks weird to me.

[+chue]

12 hours ago, RickyDean said:

If you have an extra 32k card... Then test the buffer chips 

Unfortunately I do not have an extra card. However, I do have a nanopeb which I should try running these tests on.  It would rule out errors in the TI and in the testing software.  I think eventually I will have to test the buffer chips in the cable and in the RAM card.  I do think the flex cable is ok.  Continuity seems ok on all pins, so I don't think there are breaks in the cable.

 

11 hours ago, JasonACT said:

only 2 chips should show as faulty

I agree it does seem to show two bits stuck, and only on the even byte. Here's the other half of the test which writes 1s to each bit position:

 

 

The other interesting thing is that when I tested with EasyBug, the one stuck bit did not show itself when I wrote to the even byte.  It only manifested when I wrote to the odd byte.  For example, I would write "00" to A000, and then read back the value - it was zero.  Then I wrote "00" to A001.  Reading back A001 showed 00, but reading back A000 showed "04".  I assume this has something to do with the fact that the processor does not write bytes - it can only write words, so when writing a byte it does a word read, update, and word write.

 

11 hours ago, JasonACT said:

I'd write another very simple basic program which sets 64 bytes starting at >2000 to 0 (and another loop for >A000) and report back what they read as.

My next step will be to try this and report back, I just have to get some time to do it.

[Fritz442]

If you have a Minimem or Finalgrom modules, try this: Run from Minimem module

 

Press keys '0' thru 'F' to get results on the banks, whatever key you press you should

see the same under the bank area. '0' you should see '00', '7' you should see '77', etc...

Then press 'P' and look for the odd marked chip under the failed bank.

 

 

MEMWRITE_v2.1.zip

Edited December 17, 2023 by Fritz442

[+chue]

I wrote a Mini Memory BASIC program that writes 00 and FF to each of the ranges (2000, A000).  It then immediately reads back the value - if the written and read values are different, it prints them to the screen.  It does this for 64 bytes at the beginning of each range.

 

10 DIM NVAL(2)
20 DIM MSTART(2)
30 NVAL(1)=0
40 NVAL(2)=255
50 MSTART(1)=8192
60 MSTART(2)=-24576
70 FOR K=1 TO 2
80 PRINT "TESTING";MSTART(K)
90 FOR I=MSTART(K)TO MSTART(K)+64
100 FOR J=1 TO 2
110 CALL LOAD(I,NVAL(J))
120 CALL PEEK(I,P)
130 IF P=NVAL(J)THEN 150
140 PRINT I;":";NVAL(J);"<> ";P
150 NEXT J
160 NEXT I
170 NEXT K
180 PRINT "DONE"

 

I ran it several times and got errors when writing "00" to differing addresses, so the errors don't happen consistently.  No errors occurred when writing "FF".

 

 

At this point I might just start desoldering RAM chips, but will need to order some replacements.  I will start by replacing the 3rd chip from the right in the bottom row of chips in the 32k expansion card, hopefully this is bit 3.  If that doesn't work I'll replace the 3rd from the left.  It's 50-50 at the moment.  Finally I'll look at replacing any related buffer chips.

[+chue]

2 hours ago, Fritz442 said:

If you have a Minimem or Finalgrom modules, try this: Run from Minimem module

Hello @Fritz442, thank you.  I have both modules, but no disk storage.  I think I will not be able to run your application.  There may be a way to get the application onto my nanoPEB, and then onto the Minimem.  It's been a while since I've used the nano, so I'm unsure if that is possible.

[Fritz442]

29 minutes ago, chue said:

There may be a way to get the application onto my nanoPEB, and then onto the Minimem. 

Yeah, that should work. Here's a .dsk of it to install on Nano.

MEMWRITE.dsk

Edited December 18, 2023 by Fritz442

[+chue]

On 12/17/2023 at 7:23 PM, Fritz442 said:

Here's a .dsk of it to install on Nano.

I was able to get the disk image on the Nano, and then from there save it to the minimem.  When run from the minimem, it seems to confirm the 2 stuck bits.  However, I am unsure how to interpret the "Chip Test" results:

 

 

[Fritz442]

OK it looks like you have two chips stuck on, the chip tester page only works good with one bad chip.

Looks like U22 and U25 are stuck on for Bank 1. That's why you see '24' under the Bank. U22 is the LH-2 and U25 is the RH-4.

Edited December 19, 2023 by Fritz442

[+chue]

In preparation for the RAM chips arriving in the mail, I desoldered RAM chips U22 and U25.  I put some sockets in and then put back the old chips.  I ran @Fritz442's chip tester and got an unexpected result.  Instead of getting stuck bits "42" or "24" I got "06" instead.  It turns out I desoldered the wrong chip (U26).  So I went back and socketed U25. 

 

It wasn't easy desoldering the RAM in my unheated garage where the temps were below freezing.  In the process I ended up damaging some caps near the sockets, but was able to replace them. 

 

Here's the final result with 3 new caps (a half-sized yellow one, and two brown) and the 3 socketed chips (U22, U25, U26):

 

 

According to the schematics, all the small yellow caps near the RAM are 10nF.  The Larger blue ones are 10uF, 25V.

 

Also, as replacements for the two 4116s I used two 4164s.  The 4164s require the mod in the following thread:

 

 

And here are the RAM test results:

 

 

[Geoff Oltmans]

Good job!