What if? Designing "Geneve 2020". Cool 3D views!

[Jimhearne]

Sending the interrupt over the E-bus was the last thing i was working on on these boards a few years ago before a house move and then since i've been distracted playing with the 990 stuff.

As far as i can remember i had an i/o card sending the E-Bus INTEN signal, that being acknowledged  , the interrupt code being sent across the E-bus and being latched into the CPLD, the processor was able to read the interrupt code but then i was having issues at that point. 

Can't remember for sure, unfortunately if i don't work on something for a while i forget a lot of stuff and i'm not very good at keeping notes so i have to sit down and go through it again.

 

Edited November 17 by Jimhearne

[+FarmerPotato]

Continuing to measure current.  Bent out the VCC pin for ammeter.

 

99105       65 - 75 mA  @ 5V     Datasheet:  120 mA @ 5.25V  .. I applied 5.25V, not significant.

 

Hypothesis: address pins are sinking current which travels though CPU to its ground. 

 

With the CPU removed ... uhm.  Breaking the thin part of VCC pin in the process:

 

Board         230 mA

 

There are floating OE* pins on the external bus drivers.  I bet that's the issue.  Dealing with it.

[+FarmerPotato]

Power off, the resistance from VCC to GND is 95.3 ohm. I have no previous measurement.  I was afraid I had shorted something but I guess not.

 

 

With those OE tied high:

board+cpu, no osc          340 mA

Board+cpu, osc 12 MHz   372 mA

 

 

Clock running steady.

 

Lesson: don't rush to reflow all the ICs if some inputs will not be driven yet.

 

Lesson: PULLUPS ON ALL OE not just some of them.

 

[+FarmerPotato]

On 11/17/2023 at 9:42 AM, Jimhearne said:

My TL866-II died a few months ago as well, or rather it partly died , it started failing some logic chips (74244, 245 etc) on a specific pin but it will still read and program EPROMs  

I spent a few hours trying to fix it but couldn't find any difference in signals between the pins that were passing and the one that failed so maybe internal to the processor.

So i bought a T56

 

Do you recall if it was an input or output pin? (for the 244 at least) Curious. 

 

 

My TL0-866-II reported a fault on one or two pins with a 27C010.  Always the same pins. I tinkered with the ZIF and it got better... then it started failing tests on the 22V10C.  No problem in WINCUPL simulation!  Well simulation is not reality.  It was my programming error.  But I bought the T56. 

 

 

 

[+FarmerPotato]

Some data on current consumption:

 

board no cpu             230 mA         ROM, RAM, 8 drivers, jelly beans
board+cpu, no osc        340 mA         data sheet says 120 mA
Board+cpu, osc 12 MHz    372 mA         data sheet says  10 mA.  CPU+OSC +142 mA?
Insert PLD               482 mA         CPU now accesses ROM.
Insert 9901              550 mA         70 mA, data sheet says typ 150 mA. 3 MHz clk
Steadily running         540 mA         after about 10 minutes
30 minutes later         620 mA         after RESET/NMI/RESET, lots of probing
Cool down, probes on     560 mA         Stable like this from then on

Hours later              520 mA
 

 

I removed the resistor that was attenuating OSC down from 7 Vpp.  With all the headers for the logic analyser, CPU had zero activity.  Was afraid I shorted something.  OSC was 2-3 Vpp!  With no resistor, 5.5 Vpp, and the CPU is stable.  

 

 

 

[+FarmerPotato]

 

Now the exciting part of board bring-up!  ROM is loaded with MEMTEST.

 

Boot

 

The bus status codes are recognizable (ALU cycles omitted.)

 

RESET released:

BST	Addr	Data	Cycle
A	    	    	RESET
D	0000	1506	ST
5	0000	1502	INTA	R/W=1 data should be 8000 for WS in RAM at boot
9	0000	1502	AUMS	
5	0002	1502	INTA	R/W=1 data should be 0054
C	1502	1502	WP
6	151C	1502	WS	R13	R/W=0	WR=0
6	151E	1600	WS	R14
6	1520	0000	WS	R15
3	1502	1502	IAQ	

Address output look good. Data input bad.

BST are proper
RD is correct
R/W is all 0 but 1 during full read cycle? backwards. wrong pin?
WE is 0 - disconnected?

 

The ST bus state isn't shown in the databook page 26, but page 27 shows ST on NMI.

 

When the CPU writes, the data bus makes sense. When it reads, the data bus is not valid.  It's 1502 . So it reads from ROM values WP=1502 and PC=1502.  The WP cycle announces that the WP is now 1502.  It saves the prior state to R13-R15 which start at 151C.

 

Then the first instruction comes from address 1502.  IAQ retrieves a 1502, which translates to JGT $+4.  False, so the PC counts by 2 indefinitely.  Lucky coincidence--all NOPs for a test.

 

So a lot of stuff is right.  I see the ROMEN signal during a read, but ROM is not putting anything on the data bus. 

 

[+FarmerPotato]

Front

 

For the logic analyzer, there are two tiers of headers soldered to the DIP40 under the 99105.

 

 

Back

 

 

[Jimhearne]

On 11/22/2023 at 3:48 PM, FarmerPotato said:

Do you recall if it was an input or output pin? (for the 244 at least) Curious. 

 

 

My TL0-866-II reported a fault on one or two pins with a 27C010.  Always the same pins. I tinkered with the ZIF and it got better... then it started failing tests on the 22V10C.  No problem in WINCUPL simulation!  Well simulation is not reality.  It was my programming error.  But I bought the T56. 

 

 

 

Well, that's a bit annoying.

I couldn't remember what pin it was failing so i just tried it again. 

Everything i tried is now passing 😞

I suppose at least it gives me a spare programmer / tester.

 

[+FarmerPotato]

 

I cleaned up some flux residue. The data bus gave me different random values for a while. Now its back to >1502.

 

ROMEN* problem in Decoder:

The 22LV10C output ROMEN* is stuck at 0 but 1.8V during reads. This is backwards, and 1.8V is no good.

WINCUPL device is correctly set to g22v10lcc. XGPro is correctly set at 22V10C(UES) for the PLCC. These are the correct settings for: pin 5 is an input, NOT power down. Device is not using any registers and pin2 is inferred to be input, not the CLK.

 

This is the LV device. Its Vcc is specified for 3.3 to 6V.  It has Voh minimum 2.8V, going up to Vcc-0.3.  It's worked for me in the last card.  So it's not necessary to have a 22V10C. (older 5V part.) Output of 1.8V is just bad.

 

ALATCH problem: it's not latching. Outputs of '573 address latches seem to be transparent.

 

L_A12 is the 573 output where input AD12 is latched on falling edge of ALATCH.  ( I number pins from 0 least significant, opposite of TI, where LSB was A15.)

L_A12 should latch the 0 in bus cycles 5, 9, 5, but latch a 1 in state C. Instead it continues to follow AD12.

 

 

 

Good: BST 5 is INTA, retrieving the RESET vector from 0000 then 0002. BST C is WP, outputs the value just read for WP from 0000.

AD is the address/data pins off the CPU. It shows the address while ALATCH is high. Ignore the LSB, it's not important here.

WR (WE) is probably a bad connection, it's always 0, but RD and RW are correct. (RW indicates if the cycle is Read/Write* before the RD or WR pulse. Garbage in other places)

 

Red probe trace is ALATCH measured at the 573, showing Voh > 4V.

 

 

Bad: Yellow probe trace is L_A12 output of 573. which is not latching. It should stay at 0.  It rises to 1 and matches A12 when 1502 appears on AD (floating).

In other words, the latch is always transparent.

 

This latch position had an accident in the reflow oven, but I threw away that chip, then put in a new one.  Priority to inspect this area.

 

 

Add LS612

Duh, there's still one chip missing. L_A15:13 don't go to memory chips, the mapper either passes them transparently or map bits on M_A24:15. Also all the 0s above M_A15.

 

Current: 500 mA. Fixes more floating inputs. Nothing improves.

 

Edited November 24 by FarmerPotato
Edit for clarity

[+FarmerPotato]

Today: I have gone over the whole board cleaning. Located some wiggly pins (not enough solder) and one short. 

 

ROM reads correctly now, for at least a few words.  Yay! Data on pins AD13 and AD14 coming back suffers from glitches.  I think RAM is not ok, because PC goes to 0 later. IDLE instruction is executing perfectly. But there were no IDLE instructions in my ROM.  

[+hloberg]

2 hours ago, FarmerPotato said:

Today: I have gone over the whole board cleaning. Located some wiggly pins (not enough solder) and one short. 

 

ROM reads correctly now, for at least a few words.  Yay! Data on pins AD13 and AD14 coming back suffers from glitches.  I think RAM is not ok, because PC goes to 0 later. IDLE instruction is executing perfectly. But there were no IDLE instructions in my ROM.  

enjoyed your presentation at the TI99 zoom meeting. looks like your making some impressive progress. THE GENEVE SHALL RISE AGAIN!  

[+FarmerPotato]

My friend Rich is a soldering perfectionist. And he has the skills. Rich cleaned up pads and reflowed  some caps. Reduced yucky flux residue. None of them were a major bug, but, now my logic analyzer is showing fewer glitches.

 

And my green Power light is back. (From Tvsat I got side-looking SMT LEDs, except their green turned out to be red.)

 

Then I spent two hours editing  my reference card. Need the card to have sorted instruction opcodes.  At least until I've memorized them all. I might have spent too much time making it pretty. 

 

Logic analyzer wires on AD14:13 were prone to false 1s when reading from some ROM addresses. They can be squeezed tighter, for temporary improvement. I checked every bus bit in a read cycle to prove this. 
 

When reading address 0054, I see the word from address 00D4. Found a short between ROM A6 and A7 that explains that. Not sure where the short is, tho I think one of the ROMs' A6 has too little solder. 
 

TLDR;

Actual nail-biting debugging session was like:

 

Addr Read comment 

0000 8000 workspace pointer (RAM, while in MODE_BOOT)

0002 0054 entry point, great

0054 76FC ?? should be 0300! LIMI 0!

004E ....

 

Why is it jumping to 4E?

 

Hmm, FC is the jump offset to 4E.

 

Now, why has it read 76FC from addr 0054? So I searched for all the 76 or FC bytes in even/odd ROMs. No match. 

 

But 16FC would be JNE >4E. 
 

There are several 16FC in the ROM. 

 

Aha, logic analyzer shows me false 1s on AD14:13 to make a 7. But... no false 1s show on the first two reads from ROM? No glitch either when CPU drives those lines.

One of the 16FC is found at ROM 00D4. That is 0054 plus false 1 on A7.  It did not happen when A6 was 0. There must be a short between A7 and A6.  Beep! It is. 
 

I went through this with my first PCB with ZIF socketed ROMs.  That had solder bridges on address pins, hidden under the ZIF. To find it, ruined that board & the ZIF socket. 
 

I'm going to reflow those A6 and A7 pins tomorrow. 
 

Getting board bring-up one pin at a time.

 

[+FarmerPotato]

Yay!  All the above bugs are cleared.  CPU runs MEMTEST!  Onward!

 

TLDR;

 

I removed 3 PLCC sockets (Surface mount type).  There was a solder bridge I just could not get to, hidden underneath the 2nd one.

By the way, the short between L_A6-L_A7 was within the 3rd PLCC socket, the as-yet-unpopulated Recognizer PLD. It was in plain sight.  

 

Cleaned all the pads, new paste, reflow with hot air.  My paste application is improving--no shorts or loose pins.  Running code looked great everywhere I checked.

It runs through MEMTEST then waits for serial input!

 

Working on serial port now...

[+Ksarul]

Progress! 

[Jimhearne]

Good news.

If you can I would really recommend assembling a new board in steps.

Just assemble the bare minimum of parts until you can test that section.

Them fit a few more parts and test that section.

Much easier than trying to debug a complete board at once.

I know it's much harder doing that with SMT parts than through hole.

Probably easier for me as i still fit SMT parts with normal soldering iron (0.5mm tip) a pin at a time.

Edited Tuesday at 10:26 AM by Jimhearne

[Stuart]

1 hour ago, Jimhearne said:

Probably easier for me as i still fit SMT parts with normal soldering iron (0.5mm tip) a pin at a time.

What size solder do you use, Jim? I really must get better at this for doing those CF connectors on the Mini-Cortex.

[Jimhearne]

I use 0.5mm solder for pretty much everything.

I do have 0.3mm but as it's so small there is so little flux in it i find it's only usable with added flux and I only usually it on the really fine pitch SMT

I use unleaded solder nowadays and actually prefer it to the old leaded but it has to be the stuff with 3% silver in it, the cheaper unleaded without silver is horrible to use.

This is the stuff i used, it's silly expensive but a reel that size would last a hobbyist a lifetime.

https://uk.farnell.com/multicore-loctite/631719/solder-wire-96-5-3-0-5-217-deg/dp/1257142?st=97sc

Luckily work pay for mine.

 

Despite soldering since I knew which end of the iron was hot, I've never mastered drag soldering. 😞

[RickyDean]

T

2 hours ago, Jimhearne said:

I use 0.5mm solder for pretty much everything.

I do have 0.3mm but as it's so small there is so little flux in it i find it's only usable with added flux and I only usually it on the really fine pitch SMT

I use unleaded solder nowadays and actually prefer it to the old leaded but it has to be the stuff with 3% silver in it, the cheaper unleaded without silver is horrible to use.

This is the stuff i used, it's silly expensive but a reel that size would last a hobbyist a lifetime.

https://uk.farnell.com/multicore-loctite/631719/solder-wire-96-5-3-0-5-217-deg/dp/1257142?st=97sc

Luckily work pay for mine.

 

Despite soldering since I knew which end of the iron was hot, I've never mastered drag soldering. 😞

I use .032 in or .8mm for everything, that could be part of my issues on the SMD soldering, that's all I've ever used.

The two initial IDE cards I have were my first foray into SMD soldering and that was using a griddle method and solder paste and they have never worked, think I over cooked the IC's.

The third SMD one, I hand soldered pin by pin and it didn't work till Shift838 reflowed it and changed out the SRAM, which came off one of the previous cards and was probably toast.

The final one I did myself and after a bit of trouble shooting, and reflowing, it is working great as of last night. I'm improving my SMD skills, pin by pin

[Jimhearne]

With large diameter solder it's hard to put the small amount you require into the joint. 

Also the tip size, lots of people on YouTube having trouble with soldering SMT and they are using huge tips, unless you are drag soldering you don't want a big tip (IMO)

 

 

[RickyDean]

22 minutes ago, Jimhearne said:

With large diameter solder it's hard to put the small amount you require into the joint. 

Also the tip size, lots of people on YouTube having trouble with soldering SMT and they are using huge tips, unless you are drag soldering you don't want a big tip (IMO)

 

 

Yeh, with my reflow station I got some small tip irons, so that is not an issue so much. I have gotten adept at dabbing the tip of the solder into the pin as I go letting a bit flow then pulling away, but it does sometimes put to much solder in place and I have to work it or use solder wick. I'll have to get some smaller diameter when I heal and get back to soldering. Viva La Geneve II.

[+FarmerPotato]

Hey, thanks, everyone, for the encouragement!

 

Still making progress.  Big job of compiling and testing Recognizer PLD, which glues everything together.   More work on reference card!

[+FarmerPotato]

 
I've fought and prevailed over WinCUPL.  The Recognizer PLD compiles. WinSim isn't crashing, and  20 test vectors pass.  Very close to .

To get WinCUPL to run stably, I tried very short paths. Hint: all Atmel example filenames never exceed 8.3.  Welcome, RECOGNIZ.pld!  We're calling from 1998!

 

Learned: field MSB=[A15..8] as a signal lets you type hex addresses as '83' instead of 10000011 in the test input file. But bits keep their place value in CUPL (I knew that from before).

 

GPL_PAD = MSB:'h'8300  /* true if address is in PAD */

 

Bad: WinSim GUI from 1990s.  Last updated for Windows 98. 
Ugly: pretty much anything about WinCUPL.  At least, the command line tools work as expected.

Good: commented vectors & MSG in your input .si, then rely on .so output file:

 

 

Spoiler

CSIM(WM): CUPL Simulation Program
Version 5.0a Serial#
Copyright (c) 1983, 1998 Logical Devices, Inc.
CREATED Wed Nov 29 21:57:32 2023

LISTING FOR SIMULATION FILE: RECOGNIZ.si

   1: Name     RECOGNIZ;
   2: PartNo   0;
   3: Date     11/05/2023;
   4: Revision 01;
   5: Designer Erik Olson;
   6: Company  Geneve2020;
   7: Assembly None;
   8: Location ;
   9: Device   g22v10lcc;
  10:
  11:
  12: FIELD LSB = [A7,A6,A5,A4,A3];
  13: FIELD MSB = [A15,A14,A13,A12,A11,A10,A9,A8];
  14: FIELD NYBBLE = [A7,A6,A5,A4];
  15: FIELD OUTS = [S2_FAULT,S1,S0];
  16:
  17: ORDER: MSB, NYBBLE, S2_FAULT, A3, GPL, MDOS, R_W, !DOP, !MMIO, !E_PAD, OUTS;
  18:
  19:

================================
                 BS             
                  2             
                  _      !      
                  F     !E      
                  A  M !M_      
                  U GDRDMP      
              NYB LAPO_OIA      
        MSB    LE T3LSWPODOUTS  
================================
0001: 000100010000L10001HHLLL
0002: 000100111000L10001HHLLH
0003: 101000000000L10001HHLHL
0004: 001000000100L10011HHLHH
0005: 001000000100H10001HHHLL
0006: 001000000000H10001HHHLH
0007: 001000000101H10001HHHHL
0008: 000111101100H10001HHHHH
0009: 000100111000L11001HHLLH
GPL UART
0010: 100000111110L01000HLLLL
GPL PAD
0011: 100000000000H01000LLHLL
GPL MAPPER WRITE
0012: 100000000000L01011LLLLL
GPL MAPPER READ
0013: 100001000000L01011HHLLL
GPL SOUND READ
0014: 100001000000L01000LHLLL
GPL SOUND WRITE
0015: 100010000000L01011LHLLL
GPL VDP READ
0016: 100011000000L01000LHLLL
GPL VDP WRITE
0017: 100100000000L01011LHLLL
GPL SPEECH READ
0018: 100101000000L01000LHLLL
GPL SPEECH READ
0019: 100110000000L01011HHLLL
                        ^
[0019sa] user expected (L) for MMIO

GPL GROM READ
0020: 100111000000L01000LHLLL
GPL GROM WRITE

 

 

Earlier:

Input:

 

ORDER: MSB, NYBBLE, S2_FAULT, A3, GPL, MDOS, R_W, !DOP, !MMIO, !E_PAD, OUTS; 

VECTORS:
'84'  '0' L01000LHLLL  /* GPL SOUND WRITE */
$MSG  "GPL SOUND WRITE";

 

 

Output:

0013: 100001000000L01011HHLLL
                        ^
[0019sa] user expected (L) for MMIO

GPL SOUND WRITE

 

 

Vector 10 tests that GPL WRITE PAD decodes properly.  With RECOGNIZ in GPL mode, the CPU sees a hole at 8300 with RAM shining through.  E_PAD* signals the mapper to open the RAM hole now.  A FAULT interrupt can also be raised if the CPU is supposed to react to changed data.  FAULT is how I implement the map registers and GROM address, in software. 

 

FAULT = !MMIO & S2_FAULT.  (Outputs S2,S1,S0 carry multiplexed data, saving 3 pins!)  The only FAULT=1 state in this test file is 11, GPL MAPPER WRITE.

 

 

[+FarmerPotato]

More about RECOGNIZ.pld . I'm calling it that now. DOS, baby.

 

I tested that RECOGNIZ emits the correct signals when the CPU writes to special addresses.  A FAULT interrupt can be raised if the BIOS is supposed to react to changed data.  FAULT is how I implement the map registers and GROM address, in software. 

 

When in MDOS mode, RECOGNIZ asserts E_PAD* when it sees an address that is RAM onboard the 9995. It also asserts E_PAD* when there is a write to the Mapper or to GROM ports.  E_PAD* causes the DECODER to open up a hole with RAM shining through.  In the case of Write Mapper or Write/Read GROM, RECOGNIZ tells Decoder to raise a FAULT, and a two-bit fault code gets latched.

 

Let's say MDOS writes a word to map registers at F110. RECOGNIZ opens a RAM hole, the two bytes drop in like a piece of mail, two bits of fault code are latched, and the FAULT interrupt occurs.   The interrupt handler figures out what to do.   The fault code tells it to look at the program's map registers in RAM.  It sees that the two bytes at F110 have changed.  Since these are 8-bit page numbers for Geneve 9640, it must convert them to physical pages which have 12-bit numbers.  This would be a lookup table.  The 12-bit physical page goes into the actual mapper register, and the fault handler is done.

 

GROM also depends on FAULT.  The fault handler figures out what to do, using the fault code and the values in those RAM holes.  If the code indicates GROM Read Data, it knows that the program used up the latest byte at GRMRD, so it must fetch the next byte, increment the GROM address, and stick new bytes into the holes for GRMRD and GRMRA.   If the code indicates GROM Read or Write Address, or Write Data, it does the expected grommish thing, updating all the RAM holes. So the next instruction that reads from them sees what it should.  In any case, the content of GROM comes from the pages where MDOS or GPL keep it.   It can't be any slower than actual GROM chips can it?

 

I thought I'd need to build hardware for GRAM emulation, but it looks like software is a lot easier.

 

This was one of messiest problems to solve.

 

GPL and MDOS modes both access the mapper this way (GeneveOS can also flip to GPL mode and write to 8000.)  It means they have protected memory. You'll have separate concurrent processes for  MDOS, GPL, Forth, whatever.  They can't possibly clobber each other's memory.  More or less of the onboard RAM 1.5 MiB might be allocated to the Geneve 9640 HAL. It doesn't even have to be contiguous pages.  (HAL = Hardware Abstraction Layer.)

 

If you want, you can imagine virtual memory based on this mechanism.  The fault handler could make MDOS think that it has full RAM, when it really doesn't, and pages are saved/loaded to Flash as needed (TI called this Roll Out in DX10.)  There are more uses for the mechanism. For inter-process communication, a physical page can be shared. (Think of a debugger!)  Multiple instances of the same program can share the original code pages--provided that there is hardware to support read-only pages and copy-on-write pages (COW).  You could avoid having to load a program back into memory again.

 

In the next board revision, I plan to implement more FAULT codes and memory trace.  I will use the same CRU locations that the 990/12 has.  I'm realizing that all the special CRU addresses in the 9995 or 99105 are consistent with the 990/10 or /12. 

 

 

Edited yesterday at 03:19 AM by FarmerPotato

[+FarmerPotato]

Tonight I'm working on serial, and I think there is another short, somehow.

 

I defined >1380 as the 9902 CRU address.  RECOGNIZ matches on this in order to assert the 9902 chip enable.  But I see the CRU cycles on the logic analyser going to address >1280 and up, and no chip select ever happens.   It's just one bit wrong, it must be a glitch?  No? Must be a loose pin, then, huh?

 

The real pins on the 99105 are definitely carrying >1280 and up.  I see the CPU fetch the instruction "LI R12,>1280" from the ROM, and then 1280 is everywhere.  I pulled and verified the ROM again.  1380.

 

Trying to guess what would cause this.  I haven't noticed any other bad reads, but it does lock up frequently.

 

Listing:

 

0155               * Set up the TMS9902
0156      0096     reset  equ  $
0157 0096 0300         limi 0
     0098 0000     
0158 009A 020C         li   r12,conr12              cru address of port rs232/2
     009C 1380     
0159 009E 1D1F     	   sbo  31                      reset 9902
0160               
0161               * wait minimum 11 clock cycles

....

0182               
0183               * all 4 register-load bits are set after a reset
0184               
0185 00BE 3220            ldcr @ser8n1,8   load the control register
     00C0 0084     
0186               *       ldcr @intvl,8    load interval register, but don't turn on the interrupt
0187 00C2 1E0D            sbz ldir         do nothing with the interval register
0188 00C4 3320            ldcr @br9600,12  load the the reception rate and emission rate
     00C6 0088     

     0094 0086     

 

The values come from:

 

0125 0084 83       ser8n1 byte rcl1+rcl0+sbs1   ldcr @ser8n1,8 addresses a byte
0143 0086 001A     br19k  data >001a    11 bits: baud rate 19200 @ 3 MHz
0144 0088 0034     br9600 data >0034    11 bits: baud rate  9600
0145 008A 0068     br4800 data >0068    11 bits: baud rate  4800
0146 008C 00D0     br2400 data >00D0    11 bits: baud rate  2400
0147      008E     bauds  equ $
0148 008E 008C            data br2400,br4800,br9600,br19k
     0090 008A     
     0092 0088     

 

UPDATE:

 

I poked Kynar wire into the vias along AD8, from CPU to the Land of ROM.  It is a dangerous, subterranean route, a river that twists through the wreckage where a metal-slide once demolished a '573 up top.  Pads and traces have been repaired with crude wires. Below the plane, the solder mask has buckled and bulged as if from a dragon's breath.  But the brave little continuity signals its health from every via!

 

It is interrupted between the top of the socket and the chip.  The chip outputs a '1' correctly (yellow trace).

 

 

I believe I damaged the contact with a PLCC extractor. Right next to it.   It's bent out of shape and off the pad.

 

But, repaired, it works again. (yellow = red)

 

 

 

 

 

[+InsaneMultitasker]