Another Star Wars Divider error

douglasgb

Well-known member

Donor 11 years: 2012-2022
Joined
Nov 17, 2003
Messages
3,393
Reaction score
485
Location
Santa Monica, California
Got a board in for repair that comes up with divider errors on tests 24 and 25 as shown:
b10ed78d693e49d86334c644ff6fbf3e.jpg


There are two ways to identify the test numbers: count the missing (passing) lines 21, 22, 23 that don't appear above the two lines shown, or go by the NNNN FFNN which are the option switch settings to run the test individually per the Troubleshooting Guide.

NNNN FFNN means on, on, on, on, off, off, on, on
8765 4321 switches counting down for some reason. So that's test 24 shown on page 14 of the TS Guide.

It test for shorted bits in the divisor, and is supposed to take 2AAA and divide it by 2AAA to come up with 4000 which is what SW uses for the number one.
Test 25 does the same calculation using 5555/5555 to also get 4000.
 
Last edited:
But they are not getting an answer of 4000, nor are the answers even close.

I'd rather spend more time thinking than desoldering, so aside from the Guide's hint about shorted bits in the divisor, what can we learn from these test results?

Using the divider simulator spreadsheet to put in the data from the tests, we can see the bit patterns at various chips throughout the 15 cycles of the divider. More helpful, perhaps, is to input the dividend for test 24 (2AAA) into cell B5 but then enter the erroneous result (5397) as the Divisor into cell B10. Take the result of 20AA and plug back in to cell B10. The simulator now shows us 2AAA/20AA = 5397 which is what the board is actually doing. Looks like a shorted bit in the divisor: we have a zero instead of one of the As.

Anyone want to guess what the actual divisor in use that makes test 25 get its answer of 43FB?
 
Entering 5555 into cell B5 and 43FB into cell B10 shows that it's 5055. Using the spreadsheet to simulate 5555/5055 confirms the answer is 43FB. Looks like the same shorted bits in the divisor.

The spreadsheet also gives you a hint where to look. Comparing 20AA with 2AAA (or 5055 with 5555) shows that it's the last four bits of DVSRH (cell B12) that are all zeroes instead of being 1010 (A) or 0101 (5).

9a835ccc9d5ef9f73a4c94e4543ac70c.png
5ca25183703d7de6614ba31f6bbcea5d.png


3bdb4e0f50d5b587d2acfb3efb397648.png
.
f3b4db778ae2d465676d380b2cc5fd9b.png


The hardware shows the divisor on sheet 9A of the schematics.
 
Last edited:
The data bus of the Star Wars CPU is only 8 bits wide, but using an 8 bit divider would not be accurate enough to do all the 3D math. Therefore, a 16 bit divider was used, which is why we are working with 16 bit (2 byte) numbers such as 2AAA.

To load a 16 bit number into a 16 bit divider using only 8 bits, the CPU simply loads it in two stages. DVSHR stands for the high byte (2A) of the Divisor (2AAA) and DVSRL stands for the low byte (AA).

Our problem is with DVSHR, which is stored in chips 5P and 4P. Furthermore we know it's the lower half of the high byte, and that's chip 4P.

8d1bba84ac729549d68a1313c2367c2c.png
 
Testing the pins of 4P reveals that it has input coming in but its eight output pins are stuck. Only four of them are used, but all of them are stuck. This is important because we now much decide if it's 4P not doing its job, or the next chip (4N) refusing to listen.

The function of the LS175 at 4P is to monitor the four bits of data on DB0-DB3 and (when a pulse comes in on CK pin 9) to take a snapshot of those bits and remember (or 'latch') the values. DB0-DB3 can (and do) go on to do other things, but the latched values remain in 4P and are presented on the eight output pins: four of them just as the bits were and four of them as inverted values. The normal value output pins (Q) are not used (they are shown as unnumbered stubs) but the inverted values (/Q) go on into the chip at 4N.

It's not a foolproof method, but knowing this can help us to decide which chip to replace. If only the outputs that are connected to the next chip were stuck, while those without a connection were freely toggling, it would strongly suggest the next chip had its inputs shorted. If all the outputs are stuck, then it suggests 4P itself. But neither is conclusive. We have pins 2, 7, and 15 stuck low, pins 3, 6, and 14 stuck high, and pins 11 and 12 not showing any kind of output at all.

Another method to help decide is to temporarily force one of the stuck outputs into the opposite state. If there is no change to the reported divider errors, that implies the next chip is ignoring anything going to its input and we'd replace 4N. If there is a change, then the next chip is processing the input but 4P is just not sending it.

I hooked up a lead to GND and touched it to pin 3, then pin 6, then pin 11, then pin 14, and each time the wrong answer for the two failing tests changed to a different wrong answer (plus the other 3 tests failed). So let's replace 4P.
 
Entering 5555 into cell B5 and 43FB into cell B10 shows that it's 5055. Using the spreadsheet to simulate 5555/5055 confirms the answer is 43FB. Looks like the same shorted bits in the divisor.

Spreadsheet? Pfft... did this in PERL :)

Code:
mspaeth@ln-mspaeth 152 % ./starwars_div 2aaa 2aaa 5397
      Real    Calc    XOR
NUM:  0x2aaa  0x37b9  0x1d13  --  7 bits
DEN:  0x2aaa  0x20aa  0x0a00  --  2 bits
ANS:  0x5397  0x4000  0x1397  --  8 bits
mspaeth@ln-mspaeth 153 % ./starwars_div 5555 5555 43fb
      Real    Calc    XOR
NUM:  0x5555  0x5aa3  0x0ff6  --  10 bits
DEN:  0x5555  0x5055  0x0500  --  2 bits
ANS:  0x43fb  0x4000  0x03fb  --  9 bits

Low bit count shows where the most likely error is...



Code:
#!/usr/local/bin/perl

$num=hex($ARGV[0]);
$den=hex($ARGV[1]);
$ans=hex($ARGV[2]);

print "      Real    Calc    XOR\n";
$tnum=int($ans*$den/16384);
$xnum=$num^$tnum;
$cnum=cntbits16($xnum);
print sprintf("NUM:  0x%04x  0x%04x  0x%04x  --  %d bits\n",$num,$tnum,$xnum,$cnum);

$tden=int($num*16384/$ans);
$xden=$den^$tden;
$cden=cntbits16($xden);
print sprintf("DEN:  0x%04x  0x%04x  0x%04x  --  %d bits\n",$den,$tden,$xden,$cden);

$tans=int($num*16384/$den);
$xans=$ans^$tans;
$cans=cntbits16($xans);
print sprintf("ANS:  0x%04x  0x%04x  0x%04x  --  %d bits\n",$ans,$tans,$xans,$cans);

sub cntbits16 {
  my ($word)=@_;

  $cnt=0;
  for ($i=0;$i<16;$i++) {
     $cnt += ($word & 1<<$i) ? 1:0;
  }
  return $cnt;
}

Could CGI that into a webpage easily enough.
 
Spreadsheet? Pfft... did this in PERL :)
...
Could CGI that into a webpage easily enough.

Nice! NUM is aka the Dividend and one would suspect the DSR or DL, DEN is the Divisor/Adder/Difference Latch? Would low bits at the ANS point to the QSR?

I was waiting for someone to ask why bother with all the thinking when you could just bust out the logic probe but I don't think it's an XOR.

Here's a link to the spreadsheet, which also gives insight into the bit patterns during each cycle of the divider.
 
Back
Top Bottom