This is an alternative
Clone t`engineering design using the NV SRAM. It is approximately half the size of the original though most of the space is wasted. It uses less than half the components though only the SRAM array and power circuitry has been concatenated. And it is a quarter of the cost though it still is using DIP packaging. And all of this without a radical departure from B. Yahya's original design! (Yay progress!)
A casual glance at the schematic shows I have opted not to wire the address lines in normal order; this shuffling of the address lines creates new problems when programming this board. Including having to make an adapter for your logic analyser/bus sniffer if it has a hardwired hat. Needing to store the ROM image in that peculiar byte order. Debugging if it was a programming or image processing error causing a software malfunction. Having your most fastidious colleagues complain
* that you badly screwed up the design of the project citing the prefered logical order for the ICs in question, shouting that it can't possibly work.
However, this approach has strong advantages over fixed logical ordering. First: it eliminates the need for vias to satisfy an artifical ordering requirement. Second: if a
competitor dumps the ROM without
reverse engineering the board the image will appear corrupted
. Third: Gives you something to write about. Fourth: the satisfaction of saying "I told you it would work" to you colleagues after a job well done.
Shuffling, not to be confused with stacking:| VPP | 27256 | VDD | | A12 | A14 | | A7 | A13 | | A6 | A8 | | A5 | A9 | | A4 | A11 | | A3 | OE | | A2 | A10 | | A1 | CE | | A0 | D7 | | D0 | D6 | | D1 | D5 | | D2 | D4 | | VSS | D3 |
| | VPP | mutant | VDD | | A0 | A1 | | A2 | A13 | | A3 | A4 | | A14 | A5 | | A6 | A7 | | A8 | OE | | A9 | A10 | | A11 | CE | | A12 | D7 | | D0 | D6 | | D1 | D5 | | D2 | D4 | | VSS | D3 |
|
| Difficult hardware, hard software. |
From the above we see that the address line order {A
0-20} is now
{12,11,9,8,6,14,3,2,4,5,10,7,0,13,1}. We can reason that the value stored in 0x0000 is now read from 0x0000, but the value in 0x0001 is now read from 0x0004, 0x0002 is now read from 0x0001, 0x0004 from 0x01000, etc.
The ROM chip is read externally out of order while internally the image is stored sequentially {00, 01, 02...}. The image must be distorted/mutated to match the read order else it won't be read back correctly. One method is to build an adapter for our programmer that would shuffle the address lines for us; however some ROMs do not behave well if written to non-sequentially and every design would require a different adapter. Making this a physical hardware adapter would either exaust our resources, or require constant reconfiguration, leading to inevitable calamity from loose/misplaced connections.
//Advanced Hex Editor script, does not work!
//address[write]=2^[read]
a[0]=2^12;
a[1]=2^11;
a[2]=2^9;
a[3]=2^8;
a[4]=2^6;
a[5]=2^14;
a[6]=2^3;
a[7]=2^2;
a[8]=2^4;
a[9]=2^5;
a[10]=2^10;
a[11]=2^7;
a[12]=2^0;
a[13]=2^13;
a[14]=2^1;
// base betweeen iterations, avoids an inner loop/summation.
B[0]=0;
B[14]=0;
ii=0; //because I don't feel like calculating an index for a sequential read.
D[0]=0; //Image holder.
D[32767]=0;
for(i[0]=0;i[0]<a[0];i[0]+=a[0])
{B[0]=i[0];
for(i[1]=0;i[1]<a[1];i[1]+=a[1])
{B[1]=B[0]+i[1];
for(i[2]=0;i[2]<a[2];i[2]+=a[2])
{B[2]=B[1]+i[2];
for(i[3]=0;i[3]<a[3];i[3]+=a[3])
{B[3]=B[2]+i[3];
for(i[4]=0;i[4]<a[4];i[4]+=a[4])
{B[4]=B[3]+i[4];
for(i[5]=0;i[5]<a[5];i[5]+=a[5])
{B[5]=B[4]+i[5];
for(i[6]=0;i[6]<a[6];i[6]+=a[6])
{B[6]=B[5]+i[6];
for(i[7]=0;i[7]<a[7];i[7]+=a[7])
{B[7]=B[6]+i[7];
for(i[8]=0;i[8]<a[8];i[8]+=a[8])
{B[8]=B[7]+i[8];
for(i[9]=0;i[9]<a[9];i[9]+=a[9])
{B[9]=B[8]+i[9];
for(i[10]=0;i[10]<a[10];i[10]+=a[10])
{B[10]=B[9]+i[10];
for(i[11]=0;i[11]<a[11];i[11]+=a[11])
{B[11]=B[10]+i[11];
for(i[12]=0;i[12]<a[12];i[12]+=a[12])
{B[12]=B[11]+i[12];
for(i[13]=0;i[13]<a[13];i[13]+=a[13])
{B[13]=B[12]+i[13];
for(i[14]=0;i[14]<a[14];i[14]+=a[14])
{B[14]=B[13]+i[14];
D[ii]=get1u(B[14]); //Gets 1-byte unsigned value at offset
ii+=1;
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
for(ii=0;ii<32767;ii+=1)
{set1u(ii,D[ii]);}//overwrite original.
The above script uses nested loops to represent each bit of the address line. It sequentially reads the bit and stores it in the correct 'shuffled' location.
I acknowledge that there are some operands not represented in Kahei or C that would allow for a more efficient program. And that using a matrix would be far faster and more efficient. However such an approach would be far less flexible and difficult to understand. And the effort required to build one I cannot justify especially for a program that would normally only be used once. But I am a hardware guy, an expert programmer may not have the same difficulty.
Before I get complaints that I am being unfair to the original designer let me point out that there has been 18 years of technological development since it was created; B. Yahya had the courage (and ethic) to publish this design at a time when many companies were terrified to; The original design itself was so well done that unaltered it is possible, though not commercially viable to produce it today; And the autorouter jab is fair game as vias should not be inside an array, except where lines cannot run parallel or for thermal reasons; Also,
the original was a success; wasn't it?
