So what processor was used in the Brick Game games? / Hebrew

So what processor was used in the Brick Game games? / Hebrew

I was prompted for this little research by a recently published article on Habre, in which the author suggested that the famous “Tetris” from the 90s could have used a 4-bit microcontroller Holtek HT1130. I was very surprised (and motivated) that, apparently, the ROM has not yet been dumped and, accordingly, an emulator for this line of games has not been written.

The assumption that the Brick Game is built on the Holtek HT1130 has one weakness – in the HT1130 the display driver can only control 128 segments, and in a typical Brick Game only the playing field consisted of 200 (10×20) segments. Where did the information about Holtek HT1130 come from? After a little googling, I found the original source, this is an article from 2015, in which the author says that he found a datasheet for one of the Brick Game variations – “Super Brickcal 9 in 1”, which works on the HT113LA and differs from the classic ones with a smaller playing field. He notes that the Holtek HT113LA is a private variant of the Holtek HT1130, on which, in addition to Super Brickcal, many simple portable games with an LCD screen are built.

But I’m interested in the more common versions of the Brick Game – in a recognizable body with a bend in the middle, usually marked with the letter E and a few numbers. For example, ES-118 and E-88 as in the photo below:

Research objects

I specially bought these types of specimens for preparation. E-88 was declared by the seller as defective, besides, it is one of the classic versions in the narrow circles of Brick Game connoisseurs, so I’ll start with it.

Her life was not easy

1 hour 5 rubles ๐Ÿ™‚ this is a joke, was anyone really willing to pay for an hour game of Tetris?!

“Welcome to Americana”

Whoah Inside, a view of the rich inner world of the previous owner suddenly opens up. Punk not dead!

And here is the crystal that I am interested in, shining under the textolite:

Main board E-88

Main board E-88

The black drop of the compound reliably protects the microcontroller crystal from the surrounding reality and freeing it is a rather non-trivial task. The most reliable would be to dissolve it in nitric acid, but such methods at home do not inspire me. Therefore, I chose a simpler, but less reliable method of decapsulation – thermal.

Decapsulation

The essence is this – we separate the entire drop together with the crystal from the textolite, then heat it over an open fire, as a result of which the compound becomes brittle, and the main part of it can be removed mechanically. The remains of the compound from the surface of the crystal are removed with dichloroethane (which are usually sold as adhesives for plastic).

The lower side of the silicon crystal is surrounded by a compound

As I already mentioned, this method is not very reliable (plus I have no practice) and, unfortunately, in the process of separating the compound, the crystal cracked, falling into two parts: (In addition, the main damage “successfully” fell on the area with the ROM to remove the dump this time I didn’t succeed. Here he is, the brain of Brick Game E-88 (in full resolution):

The marking of the HT-943E5 crystal with the production date of the mask in 1994 and a small chip art in the form of the Holtek logo immediately catches the eye.

Marking and date

Holtek branding and logo

It turns out, we can confirm that the classic Brick Game of the mid-90s runs on a Holtek microcontroller. It remains to find out which one exactly.

Of course I immediately googled HT-943. And the closest thing I found was the 8-bit HT-948, but it doesn’t quite match what we see in the DIE-photo – 16kb ROM vs 4, 3328 bits of RAM vs 640, again the number of controlled LCD segments doesn’t match , and the 4-bitness of Super Brickcal suggests that we are dealing with a 4-bit processor here as well. In general, probably someone more experienced could easily determine the bit rate of ALU from a photo, but I am a complete layman in microelectronics.

In the end, I went ahead and downloaded all the datasheets for 4-bit Holtek microcontrollers that I could find (good thing there are only a couple dozen of them in the public domain), and still found a perfectly suitable option, the HT443A0.

Judge for yourself: the number of segments (40) and general conclusions (8) of the LCD driver coincides with what can be recognized in the photo of the crystal, 160 nibbles of RAM plus 80 RAM of LCD too. And most importantly, the documentation shows the positions of the crystal’s conclusions and its size, which exactly matches our specimen.

Now I’m going to try to be a homegrown Ken Shirriff and sign what I recognized on the crystal. Let me remind you once again that I have a very superficial understanding of microelectronics and could make mistakes in my assumptions (it would be great if people who understand the topic corrected and supplemented me in the comments).

Let’s consider the ROM in more detail:

1/16 part of the PZP

On the grid of transistors, the inhomogeneities that encode individual ROM bits are clearly visible. In simple words, where the horizontal line (doped layer) crosses the pink section of the vertical line (polysilicon layer) – 1, where the green section – 0. On the left you can see the decoder of the 6 most significant bits of the address (the decoder of the 6 least significant bits is located between the upper and lower parts of the ROM in the damaged place and it is not visible in the photo). If you look closely, all the horizontal lines converge in the upper left corner – from here, one bit of the byte located at a certain address goes to the data bus. That is, each ROM area similar to the one carved above (8 in total) and its mirror image to the right contain every nth bit of all 4096 bytes of ROM. And this is bad, because it turns out that the destroyed bits are from the middle of each ROM byte. Even part of the dump cannot be removed from this crystal.

And while new donors are coming to me for decapsulation, we have a whole ROM of melodies, let’s try to decipher at least it.

Melody ROM

From the documentation, you can tell that the HT443A0 supports 16 separate melodies, each of which can be a set of tones, noises or beats. Melodies 1-12 support up to 32 notes, and 13-16 up to 64. Unfortunately, it is not said what bit rate the notes have, but we can easily calculate it: visually, you can count 4480 bits in the ROM of the melodies, and the total notes stored in documentation 640 , It turns out 4480 / 640 = 7 bits per note.

To read a ROM, you need to determine how bits map to specific notes, and notes map to melodies. To do this, you can try to analyze the decoders that control the selection of notes and melodies.

Melody ROMs with dedicated note and melody decoders

The 5-bit decoder, which selects one of 32 pairs of vertical lines, is marked in red. It is logical to assume that each of the 32 notes is stored in one pair of vertical lines. Highlighted in blue is a 4-bit decoder that selects 1 of 16 sets of 7 (the number of bits in a note) horizontal lines. Another 1-bit decoder, highlighted in green, allows you to address an additional 32 notes of double-sized melodies.

I will try to illustrate this confused explanation by reading the first note of the first melody. To begin with, you need to digest the metallization, because it hides part of the ROM from us. For this, I used a flux for low-temperature soldering of aluminum (its composition is unknown). Unfortunately, etching also affects other layers of the integrated circuit, which leads to a non-uniform color change (depending on the thickness of the layer) and it becomes quite difficult to read the ROM. No automation, all 4480 bits should be noted manually ๐Ÿ™

ROM mez of the metallization layer

In the photo, the bit value of the first note of the first melody is marked, the order of reading from older to younger is indicated by arrows.

And here is the whole first melody:

1010110
1101011
0110101
1011010
1101101
1110110
1111011
0111101
1011110
1101111
0110111
0011011
0001101
1000110
1100011
0110001
1011000
0101100
0010110
1001011
0100101
1010101
1101001
1110100
0111010
1011010
1101110
1110111
0111011
0011101
1001110
1100111

Notable sequence, expected to see just numbers for the frequency divider here, but it looks like the output of a shift register with linear feedback. I vaguely remembered that the already mentioned Ken Shirriff has the reverse side of the musical microcircuit of the postcard with the melody, checked – indeed there is a completely similar representation of the notes. So you can read the details at the link, and in short – the frequency divider is determined by the number of steps of the RSLOS operation until the value of 1000000 is obtained.

For example, the note 1111111 is shifted by 8 steps:

1111111
0111111
0011111
0001111
0000111
0000011
0000001
1000000

The base frequency of the sound is determined by the clock frequency divider, which is set by a mask at the factory, and its exact value is unknown to me. But I measured the sounding frequency of this note on a live specimen and it turned out to be ~4200Hz. So the base frequency of 32768Hz is suitable for us – with this value, the note 1111111 will correspond to 4096Hz (some discrepancy is explained by the inaccuracy of the HT443A0 resistor, which sets the clock frequency)

Now you can understand which sound contains the first melody – it is the sound that is played when the figure is moved horizontally in Tetris.

And what about Korobeyniki? It occupies two 64-note melodies, the 13th and 14th. Here is the beginning of the well-known frequency-signed melody:

0111010 - 1092ะ“ั†
0111010 - 1092ะ“ั†
0111010 - 1092ะ“ั†
0111010 - 1092ะ“ั†
1100011 - 819ะ“ั†
1100011 - 819ะ“ั†
0101100 - 886ะ“ั†
0101100 - 886ะ“ั†
1010010 - 993ะ“ั†
1010010 - 993ะ“ั†
1010010 - 993ะ“ั†
1010010 - 993ะ“ั†
0101100 - 886ะ“ั†
0101100 - 886ะ“ั†
1100011 - 819ะ“ั†
1100011 - 819ะ“ั†
1101111 - 728ะ“ั†
1101111 - 728ะ“ั†
1101111 - 728ะ“ั†
0000000
1101111 - 728ะ“ั†
1101111 - 728ะ“ั†
0101100 - 886ะ“ั†
0101100 - 886ะ“ั†
0111010 - 1092ะ“ั†
0111010 - 1092ะ“ั†
0111010 - 1092ะ“ั†
0111010 - 1092ะ“ั†
1010010 - 993ะ“ั†
1010010 - 993ะ“ั†
0101100 - 886ะ“ั†
0101100 - 886ะ“ั†

It can be seen that the duration of the note is given by simple duplication, and the absence of sound by bankruptcy.

In addition to the ROM of melodies, there is another, smaller one, which also refers to the musical scheme:

I haven’t looked into it yet, but apparently it contains a divider that sets the tempo for each melody, the type of “instrument”, and probably something else.

In the near future, I will still try to extract the entire crystal from under the compound and remove the firmware dump. And there is already not far from the emulator.

Related posts