Bringing up "Geneve 2020": Debugging Help Please!

[+FarmerPotato]

Building copy #2 of the BIOS memory card. This is why the prototype shop sends you 3 copies!

 

I test powering up frequently. So far current consumption is up from 450 mA to 590. The SMD are all powered up with a lot of floating inputs. The '645s on the data bus suck 100 mA as the CPU hopelessly tries to get instructions.  I think that will go down when ROM/RAM are connected to the data bus buffers. 

 

Other chips, not using much power.  The rest of the 40mA is from address bus and decoding: '645, 645, 645, 125, 138, 157. A few floating inputs there. 

My VirtualBench power supply goes to 5V 1A, and I'm worried it will reach the limit with more cards. At that point, I will disconnect its 5V, and plug in the wall wart again.

 

From the 1st card build, I removed a bunch of parts, so the short is isolated to the SMD chips, or the RAM sockets. Most likely, I damaged the PCB under the RAM sockets when I tried solder paste and had to unsolder that.

 

 

I tried to salvage the ZIF sockets, and for the first time I yanked out vias! These pins had stubborn cold solder joints, and I'm out of that magic stuff that alloys with old solder, so I applied force.

 

          <- Coppery vias         Owl Pellet ->     

 

The right picture is what came out of the desolder tool. I haven't cleaned it during this job. The suction started to fail after 1 ZIF. I ejected the "solder pipe", which stores the sucked-out solder. Found a large cone of solder bits, sintered together! (I crumbled it before I got a picture of Vesuvius, so I'm calling it Owl Pellet now.) The metal disc is probably salvageable (there's a disposable filter under it), but I put in a new one anyhow.  Also, the desolder tip was clogged (a cone with a hole in the tip), and I could not unclog it.

 

Lesson: just clean the tool before using it, every time. It has served well for years.  Time to reorder the filters. 

 

 

 

 

[+FarmerPotato]

Installed the two Flash ROMs. Current consumption of those is 150+100 mA. And with that, it is pushing the 1A limit. The CPU is running code, but poorly, with no RAM.  It is not going to run on this 1A power supply.

 

Time to put the PicoPSU back in. It is the 80W model, the smallest.  I estimated 25W for everything I'm going to put in.

 

With the PicoPSU, I lose the ability to measure DC current... hmm, I have a KillAWatt I could use to get the AC power.

 

[+TheBF]

1 hour ago, FarmerPotato said:

With the PicoPSU, I lose the ability to measure DC current... 

Could you get/put a low resistance shunt somewhere and compute the current?

 

[+InsaneMultitasker]

5 hours ago, FarmerPotato said:

I tried to salvage the ZIF sockets, and for the first time I yanked out vias! These pins had stubborn cold solder joints, and I'm out of that magic stuff that alloys with old solder, so I applied force

That's the stuff nightmares are made of with the "delicate" iteration of Geneve PCBs.  You can almost blow the pads and vias from those boards!  I've had some luck applying small diameter solder (the stuff that is close to threadlike) to the stuck pins before desoldering, and if I notice one or more stubborn joints on the same component I'll resolder them all first before desoldering. Your picture also reminded me of this old article that I had found interesting...

 

https://medium.com/supplyframe-hardware/confessions-of-a-pcb-designer-anatomy-of-a-via-f1d6aec236ec

 

[+FarmerPotato]

2 hours ago, InsaneMultitasker said:

That's the stuff nightmares are made of with the "delicate" iteration of Geneve PCBs.  You can almost blow the pads and vias from those boards!  I've had some luck applying small diameter solder (the stuff that is close to threadlike) to the stuck pins before desoldering, and if I notice one or more stubborn joints on the same component I'll resolder them all first before desoldering. Your picture also reminded me of this old article that I had found interesting...

 

https://medium.com/supplyframe-hardware/confessions-of-a-pcb-designer-anatomy-of-a-via-f1d6aec236ec

 

That was fascinating. And free!

 

 

 

I want to take a closer look at these PCBs, made at Aisler.net.  

 

Vias: 

 

 

Plated Thru-hole via (PTHV) (2.54mm pitch DIP)

 

 

Here's a closeup of the pulled-out via:

 

Vias look coppery. PTHV looks nickel-y, same as its pad.

 

Estimates relative to the known 2.54mm thru-hole pitch:

Via diameter 0.35 mm.    Kicad said drill 0.40 mm 

PTHV diameter 0.90 mm.   Kicad said drill 0.80 mm (pad is 2.4 x 1.6 mm oval)

Checks out.

 

Parameters at Aisler.net "Beautiful Boards Budget 8-day service" 

Surface finish: HASL, lead-free ("Hot Air Surface Leveling")

IPC Classification: 2.  (from that blog, 1=toy, 2=consumer, 3=critical. Aisler can do 3.)

Minimal Drill diameter: 0.45 mm

 

$25 for 3x 100x100mm, that is $1.50/3/sqin. My 50x100mm boards were $2/3/sqin.

For ENIG it costs 2x, or 3x for ENIG and 2-day service 

 

Compare OshPark at $5/3/sqin all sizes, looks like ENIG and their purple solder resist doesn't scratch.

 

 

[+FarmerPotato]

6 hours ago, TheBF said:

Could you get/put a low resistance shunt somewhere and compute the current?

 

Aha, there is a perfect spot for that on the motherboard: a power switch terminal I'm not using!

 

 

[+FarmerPotato]

I don't get why this board draws more power than the wire-wrap version. That version lacked the bus buffers/drivers, and the PLD. The WW version had the same two Flash ROMs and static RAMs, and consumed about 300 mA.

 

The current of this board went up 250 mA just from the two flash ROMs. 550+ mA in all. 

 

It runs, sort of, with the RAM installed. Current is maxed out at 1A, and supply voltage drops to 4.5V. The CPU seems to keep at it, but it is getting >FFFF back from reading the ROM. 

 

I have a 8-pin SOIC test clip, and that's going to have to suffice for testing. 

Still hunting for that darn 12V 5A brick for the picoPSU. Not sure what happens if I find a 12V 3A, but draw too much from the supply. They do rate this picoPSU at 85W, but ship it with a 60W adaptor.

 

Edited October 10, 2021 by FarmerPotato

[+FarmerPotato]

Have the power brick and the T56 programmer.   T56 is great, but requires an external power adaptor, even on a USB 3 high-power jack.

 

I swapped the bytes in the Flash, and now the BIOS runs properly. Will fix A0 (lsb) later, or just keep running "swpb.exe" on each binary.

 

I see it running properly at several sample points, but it always ends up looping in the INT1 handler. Weird, because interrupts are disabled with LIMI 0 and anyhow the interrupt lines have pull-ups.

 

This is the handler for INTs and XOPs

0018 0000 8000      data biows,reset
     0002 0096     
0019 0004 8020      data intws,int1
     0006 0080 

0054               * do-nothing interrupt handler
0055 0080 0380  18 int1   rtwp
0056 0082 0380  18 xop0   rtwp

 

[+FarmerPotato]

I stepped through the instructions and found that it crashes at >0100. Why? It reads the correct instruction at >00FC but not at >0100.

 

 

0231               begin2
0232 00FC 0200  20     li   r0,logon
     00FE 020A     
0233 0100 06A0  32 	bl   @xmt
     0102 0136     

Instead it reads

     0100 8000    C    R0,R0
     0102 0096    LWP  R6

     

Crudmuffins! That's the same as memory at >0000 (see last post)

I see the CPU fetch R0 twice. It should go nuts executing data before it gets to the RTWP at >0080 but oh well.

 

so really address 0004:

     0004 8020    C    R0,R2
     0006 0080    LST  R0

     0040 8040    C    R0,R4
     0042 0082    LST  R2
...
     0080 0380    RTWP

That explains it!

 

So, I'm looking for a failure to buffer the address bit.  RAM wasn't exercised above 80FE.

 

 

 

 

[+TheBF]

If it was easy everybody would be doing it.  

I admire your persistence.

[+FarmerPotato]

On 11/7/2021 at 7:53 AM, TheBF said:

If it was easy everybody would be doing it.  

I admire your persistence.

Thank you! that goes a long way.

 

Tonight I had some time to test the A7 address line. (Note: I now use A0 for the least significant address bit. Also the words are 16-bit so A14:A0 is a whole address.)

(the A7 line is 0100)

 

B_A7 is the backplane A7. It behaves correctly.

 

B_A7 is buffered by a 645. (I use '245s or '645s instead of 244's to simplify my life: 5 of the same chip in a row.)

 

Output of the 645 will be called A7. It is stuck at 0. It connects to a '138 input, and 4 memory chips' A7.

 

I found a floating input on the 645 next to A7. Soldered that to ground. Oops, always meant to plug that if I didn't find a use for one last input.

 

The A7 stays low during memory cycles. BUT during CRU cycles, it follows B_A7. I see it wiggling when the 9902 is written to at >1380 (the A7 line is 0100)

 

I found that the '138 chip is actually not soldered to the pad where A7 reaches it - its a disaster, must have lifted up during reflow. I don't see how it explains this problem though.

 

All I can think of is that the 138 toggles on or off depending on CRU access. I'll resolder a new chip on there. Its really weird behavior but its a solder whack-job as is.

[+TheBF]

I get stressed just reading about it!  

I will leave it in your culpable capable hands.  

[+FarmerPotato]

This sucker was the big SOIC package D, where the board called for smaller package N.

Pulled out the wrong bag of chips that day.

 

 

I replaced it - same behavior. A7 goes low when it should go high for memory access. But it happily goes high for CRU access (which would enable the 138). A7 is definitely connected to an input of the 138.

 

I've put in a sample program that does this:

 

>0080 JMP $+>100

>0180 JMP $+>100  * never actually read, I know it gets >0080 instead

>0280 JMP $+>100

...

and so on. No matter what happens to the high address byte, it will read always the same JMP instruction, and I should see the PC increase.

(I had to stop to think if JMP could go that far--yup, +127 words past PC+2. Nice.)

(Related: a quick processor test is to hard-wire the data bus to the NOP instruction, ie JMP $+2. I'm not doing that now, but making a dummy plug-in card for that might come in handy for future new CPU cards. I considered making a ROM full of NOP but I know the high address byte is the problem.)

 

 

First try: B_A7 is 1 on the backplane, A7 out of the buffer is 0. As before.

A8 is high on every other access. This is the pattern I would have expected from A7.

A10 is high on 2 out of 4 accesses. This is what I would have expected from A8.

 

It's driving me crazy. Could I really have all the backplane connections screwed up? No, it's clear that BA7 into the '645 is not equal to A7 out of the '645, except during a CRU cycle...

 

Next ideas:

 

1. Trace all the address bits as the PC high-byte cycles through 00 to FF.1. Underway, but tedious. (Lost my IC clip.)

 

2. Remove the '138 that I replaced and see if it somehow shorts out A7 only when the '138 is inactive (only a CRU cycle enables the '138)

 

3. Replace the '645 that buffers A7. Maybe it got damaged when A7 went to the whack-job '138 and A8 was a floating input. No idea why that would be. (Note: I am using '645s instead of '244s, and yes the enable pins are wired for '645s. Saves on inventory to use '645s or 'LVC245 3.3V everywhere.)

 

 

 

 

[+TheBF]

Ya removing the '138 chip should tell the tail if something is shorted elsewhere but man you have got some gremlins to deal with there.

I think I am way to old for surface mount.  

 

Give me a couple of 12AT7s and I am happy for hours.  

 

 

[+FarmerPotato]

4 hours ago, TheBF said:

Ya removing the '138 chip should tell the tail if something is shorted elsewhere but man you have got some gremlins to deal with there.

I think I am way to old for surface mount.  

 

Give me a couple of 12AT7s and I am happy for hours.  

 

 

What's a 12AT7?

 

A7 is definitely shorted to A8. 

 

I've been over the traces I can see. The short is still there when I remove the socketed RAM and ROM. 

 

My guess at this point, is that there is solder bridge underneath one of the 32-pin ZIF sockets.

 

I know from un-doing the 1st messed up board, that it is possible to get them off cleanly, so, I'll do that on the next free evening.

 

 

[+Ksarul]

Now the trick will be to find the spot that is actually shorted--those hunts can be a lot of high-magnification fun. I had to do that for a TI disk controller for @arcadeshopper a while back. Two little tiny whiskers of solder made life extremely difficult. . .

[+TheBF]

2 hours ago, FarmerPotato said:

What's a 12AT7?

LOL

(You can make one flip-flop with these suckers!)

[devorn]

mmm, with regard to the TMS9901NL's from Po**da, I have also received a number of the DBS 8815 marked chips (10).  I is somewhat doubtful that TI was still manufacturing the original TMS9901NL in 1988..?

 

Careful inspection shows:

 

- Clean black tops with labelling that is questonable in regard to authenticity (refer stargunner's posts)

- Injection mold marks etc. seem to be as they should be

- Underneath of chips vary, and some indicate some stress from being subjected to heat/desoldering, general usage in equipment etc. In contrast to the tops

- Legs are shiny, dipped in solder - small nicks and defects in some when examined under a magnifying glass, but covered in shiny solder;

- Pin orientation straightened to resemble manufacturers spec sheet or close;

- Like stargunner mentioned, some light printing on the underside, mostly all rubbed off. 

   - Two chips still legible with printing 'D9902S/17251 SINGAPORE'  and 'D9902S/1**47 SINGAPORE' (? 2nd one difficult to read). Does not look like it is printed to stay on long term.

 

My theory is that at least some of these may be real chips (or even some completely different chip in some cases?) that have been recovered from e-waste via various desoldering techniques. sorted and temporarily stamped on underneath with identifying chip, legs straightened, dipped in solder... Later (quite some time later) assembled into a large batch, tops cleaned and oversprayed with new identification 'DBS8815 PHILIPPINES'..  distributed for sale.

 

The 'S' in the underside suffix of 'S' may also give us some clues? ...  D9902S   American Microsystems Inc. was a alternative source supplier of TMS9902 ACC compatible chips. Theirs was called an S9902 in their Winter 1979 product catalog. https://usermanual.wiki/Document/1979AMIMOSProducts.1693266659.pdf  ( 5.44 (p326) )

 

I am yet to discover whether any or all of them work per spec (will report in a few weeks or over Xmas holidays). It is possible that some work, others may not.

 

Has anyone verified whether their batch of purported TMS9902 'DBS 8815' actually function per spec?

 

Edited November 15, 2021 by devorn
added reference to S9902

[+FarmerPotato]

@devorn. It’s great to hear from someone else with these chips. Unfortunate circumstance, but. 

Good thinking on the AMI possible source. I don’t have any knowledge of AMI’s beyond seeing the SBP9900 offered. 

1988 is a plausible year. TI was still putting 9900 into industrial and military products. On eBay I saw some VMEBUS card with a 1989 TMS9995 in it. 

I agree with your case that these are pulls, relabeled after cleaning. 
 

 

my batch of chips were erratic.  Random transmit errors. No consistency from one chip to the next. 
 

I ordered many others from US stock. The 9902A from specspecialty (eBay, Dallas based) performed consistently better.
 

However I can’t rule out my code and wiring, because I have one awful bug that is consistent across all the chips I have. 

I’d be very much interested in whatever else you find out.

 

 

 

 

[devorn]

@FarmerPotato thanks for the comments and suggestions on how to obtain more reliable TMS9902A's

Well, I took the plunge and equipped my vintage board with a NOS Winchester Electronics DB25S connector, three resistors,  a TI 75188 from a known good source, and a TMS9902NL as described in my previous post.  

 

First power up, the machine did not like it at all and continuous Beeps (BEL) were emitted as soon as I attempted to initialise the RS232 port.  Suspecting the TMS9902, I tried a second (..., after all I purchased 10 at a very reasonable price). .... it quietened down immediately and all seemed OK. Connected to a PC via the serial port (a proper RS-232 tolerant one, no USB-> serial adapters),... and was conversational using Hyperterm and Teraterm straight away.  No sync errors even after 2 hours, seems to work perfectly fine so far.  As suspected, I guess that the TMS9902NL chips were indeed genuine (albeit blacktopped and remarked) and at least some of the batch work well.  

[+TheBF]

Hey that's great news. Congratulations.

Almost time for a Forth ROM?

[devorn]

10 hours ago, TheBF said:

Hey that's great news. Congratulations.

Almost time for a Forth ROM?

Well, yes, ... there is a space for additional EPROM/ROM on the board and that is actually a longer term goal. ... But first, a memory expansion board (off-board RAM) to be homebrewed using static RAM and some address decoding logic. This board is a TM990/189 and not so fully featured out of the box.

 

According to the well documented users guide/manual (Jan 1979) from TI, off-board memory expansion is factored into the original design and should be possible via the expansion connectors provided ... I can see no evidence on the internet that anyone has actually done this yet for this particular model board ... (undoubtedly it has been done before but pre-internet age). ... It will be a learning experience and I still have plenty to learn along the way.

 

As for software, it will need to be cross assembled on another machine (x86 ?) for now, as I have no other TI machines apart from the TM990/189.

[+FarmerPotato]

On 11/14/2021 at 4:28 PM, TheBF said:

Ya removing the '138 chip should tell the tail if something is shorted elsewhere but man you have got some gremlins to deal with there.

I think I am way to old for surface mount.  

 

Give me a couple of 12AT7s and I am happy for hours.  

 

 

I found the short A7-A8 under the LS138 chip. It was impossible to see from outside, but it was the most likely place to have a short.

 

It's soldered back on now, and the TMS99105 is happily running code without crashing. Bus A7 matches the ROM's A7 input.

 

Huh.. It's running, but I forgot that I de-soldered the A7 and A8 pins onto the ROM sockets... whoa.

[+FarmerPotato]

@devornCheering on your result!

 

The TM990/189 I've only read about. It does have a great manual. Glad you got it running!

 

Try the xdt99 suite by @ralphb for assembling and making a binary image.  I use xas99, program Flash chips, and plug them in.

 

Here's the Makefile I use (under Cygwin) to assemble and get a binary.  You'll need to separate the high and low bytes into separate EPROMs. I made my life simpler by using the same EPROM in both sockets, with the low address bit hardwired to 0 or 1.

 

 

Makefile

[+TheBF]

13 hours ago, devorn said:

Well, yes, ... there is a space for additional EPROM/ROM on the board and that is actually a longer term goal. ... But first, a memory expansion board (off-board RAM) to be homebrewed using static RAM and some address decoding logic. This board is a TM990/189 and not so fully featured out of the box.

 

According to the well documented users guide/manual (Jan 1979) from TI, off-board memory expansion is factored into the original design and should be possible via the expansion connectors provided ... I can see no evidence on the internet that anyone has actually done this yet for this particular model board ... (undoubtedly it has been done before but pre-internet age). ... It will be a learning experience and I still have plenty to learn along the way.

 

As for software, it will need to be cross assembled on another machine (x86 ?) for now, as I have no other TI machines apart from the TM990/189.

I was thinking of a Forth ROM for further hardware exploration but it will need some RAM to work in so first things first.

Once you have RAM,  Forth gives you a nice debugger environment where you can test all the hardware for validity interactively or write simple test programs in Forth or Forth Assembler, to exercise the hardware.

I can cross-compile an image with 9902 communication support.  I have a version running on TI-99.

I have not finished documenting my Forth cross-compiler so I have not shared that yet. It runs in DOSBOX at the moment.