Chuck(G)
25k Member
Part 1 of this series starts here.
A real-world example--the Sound Blaster CT1350B upgrade PAL (U12 on the board with a label that says 0048013500).
This is a PAL16L8, with the security fuse blown, so it's a perfect test case. The sample file from the little "brute force" board is SB20.BIN (attached below). Running this through tt16l8, we find that there are 10 inputs and 8 outputs--no big surprise. Taking this output and running it through Minilog, we get the following equations:
Note that Pin12 (S) is unused (0), but T is rather odd in that it's programmed so that pin 13 is programmed to produce a constant low level (remember that the 16L8 is active-low). Translating the equations to the format that EQN2JED expects, we get:
Burning a GAL16V8 with the resulting JED file yields an interesting result--when the CT1350B with the new GAL is inserted into a 5160 clone, the machine won't boot! Everything comes on, but no beep and no POST! What could be wrong?
A straightforward way of checking our work is to take the new GAL, stick it into the "brute force" sampler and compare the output to the original SB20 PAL dump--and there are differences! Looking at the two dump files, it seems that half the dump file on the original is different from the other half. But how can this be? We have only 10 possible inputs (1024 samples), so the sample pattern should repeat 64 times. But instead, we see this:
So, what's going on? On to part 11
A real-world example--the Sound Blaster CT1350B upgrade PAL (U12 on the board with a label that says 0048013500).
This is a PAL16L8, with the security fuse blown, so it's a perfect test case. The sample file from the little "brute force" board is SB20.BIN (attached below). Running this through tt16l8, we find that there are 10 inputs and 8 outputs--no big surprise. Taking this output and running it through Minilog, we get the following equations:
Code:
INPUT SIGNAL | OUTPUT SIGNAL REPRESENTATION
A : PIN11 F : PIN5 | S : PIN12 X : PIN17
B : PIN9 G : PIN4 | T : PIN13 Y : PIN18
C : PIN8 H : PIN3 | U : PIN14 Z : PIN19
D : PIN7 I : PIN2 | V : PIN15
E : PIN6 J : PIN1 | W : PIN16
MINIMIZED EQUATIONS
S = 0
T = 1
U = AHI'
V = F'H'I'
W = F'H'J'
X = E' + A'
Y = F'H'J' + F'H'I'
Z = FNote that Pin12 (S) is unused (0), but T is rather odd in that it's programmed so that pin 13 is programmed to produce a constant low level (remember that the 16L8 is active-low). Translating the equations to the format that EQN2JED expects, we get:
Code:
/pin13 = pin1+/pin1 ; output is always 0
/pin14 = pin11*pin3*/pin2
/pin15 = /pin5*/pin3*/pin2
/pin16 = /pin5*/pin3*/pin1
/pin17 = /pin6 + /pin11
/pin18 = /pin5*/pin3*/pin1 + /pin5*/pin3*/pin2
/pin19 = pin5Burning a GAL16V8 with the resulting JED file yields an interesting result--when the CT1350B with the new GAL is inserted into a 5160 clone, the machine won't boot! Everything comes on, but no beep and no POST! What could be wrong?
A straightforward way of checking our work is to take the new GAL, stick it into the "brute force" sampler and compare the output to the original SB20 PAL dump--and there are differences! Looking at the two dump files, it seems that half the dump file on the original is different from the other half. But how can this be? We have only 10 possible inputs (1024 samples), so the sample pattern should repeat 64 times. But instead, we see this:
Code:
000000 A1 A9 B1 BB BB BB BB BB-A1 A9 B1 BB BB BB BB BB
...
008000 A1 A9 B1 BB BB BB BB BB-E1 E9 F1 FB FB FB FB FBSo, what's going on? On to part 11
