ACID chip inside

[nocash]

> as far as I remember, the ACID chip (or its absence) prevents
> acces to RAM or something like that.
Yes, its absence. But that's only the "what happens if it isn't there" part. Which is at best mildly interesting. It doesn't matter if the ASIC in the CPC+ scatters RAM or implodes the monitor or whatever.

The important part about the ACID is only the ACID. Which has really nothing to do with RAM. The ACID has only a few pins: A0-A7, CLK, NC, CCLR, SIN, /CE - that's all what counts, and should be trivial to reverse engineer how it works.

> I can translate the pages for you, send me a pm with the
> link to the page and I'll try to do it as soon as possible.
Which link? The link to the spanish forum? See above.

[TFM]

Since Amstrad was always trying to save some money, I don't consider the acid to be too complex. Maybe a good logical anayzer would do the job. However I don't have one.

[dragon]

The logic analyzer will attempt in the Spanish forum.

The signal SIN does not seem to follow any pattern.

If you run the same program many times.The SIN  signal is different every time.

http://amstradcpc.mforos.com/305097/7723493-que-hace-exactamente-el-chip-acid-de-los-cartuchos/?pag=5

[Grim]

I think the ACID is basically an LFSR with the peculiarity that it also takes external inputs (A0-A7 and /CE) into account to generate a new bit to feed it's internal shift register. The SIN signal is the output of the shift register. All the fun is to find out how the internal register (16bit wide I think) and the inputs are ANDed/XORed together to produce this one bit. A logic analyzer might help, but mine, located between my two ears, is very busy and slow

Also, I don't think cracking the ACID is necessary to produce new home-brew cartridge. A genuine ACID can be soldered to the back of the cartridge connector inside the Plus. This way, a cartridge would be a simple PCB with an EPROM on it and nothing else (I like KISS compliant solution). It obviously requires to modify the hardware tho, not mentioning it can't be done so easily on a GX-4000 too.

[dragon]

Interesting theory.The lfsr It has a forbidden state(all 0).

Then if it contains one, can not be initialized in this estate.If the lfsr enter in this state,It wolud remain here indefinitely.

I suppose that the acid will be designed internally to avoid this state.But if this depending on external inputs.Who knows, maybe it is possible to manually cause this condition.And check if it is a sflr.

Indeed, it is possible to construct a logical analyzer, with a simple parallel cable:

http://www.xs4all.nl/~jwasys/old/diy2.html
http://technologyinterface.nmsu.edu/winter97/computers/logic/logic.html

[MacDeath]

Can we know which company actually built those ACID for amstrad ?

It may still exist ?


Also, do we have a proper schematic of the cartridge ?
I mean, cpcWiki's pages include pictures of cartridge, yet no reall schematics/diagramms...

[dragon]

Nobody knows who the manufacturer is.But I have a theory.

In the book of the history of Alan Sugar.It is said that the original gate array.He was commissioned to Ferranti.

But they had problems with them.And in the end the gate array was fabricated by SGS.

If the relationship between enterprises continuous throughout the years.(the z80 is a sgs in plus).

It is possible that the acid and asic is a sgs gate array.I think the datasheet from SGS of the year 90 gate array are in the internet.

On the other hand I have seen that there are at least three different versions of the motherboard of the cartridges.

Although the basic design is the same.Change the silkscreen.For example I have one that does not put anything.

But if you see this other cartrige.This fully screenprinted.

http://www.cpcmania.com/Docs/GX4000/GX4000_02.jpg

And this is the other version:

http://www.vieuzordiland.fr/images/stories/gx4000/gx_02.jpg

[MacDeath]

ASIC and ACID being made by the same manufacturer would make sense of course, as both seem to have to run with each other...

Like a Key and a Lock.

Also as the only custom chips, those would apparently be done by the same.


Yet Do we have a proper schematic of the cartridges ?

Or even is this cartridge schematic added on the Mother board schematic ?
I mean, if connected, it's actually part of the motherboard then.


I'll take a look at that.

[Grim]

Do we have a proper schematic of the cartridges ?

The attachment below is the schematic of the system cartridge (BASIC & Burnin Rubber in a 128K-27C1001 EPROM).

[MacDeath]

http://events.ccc.de/congress/2008/Fahrplan/attachments/1218_081227.25C3.HardwareReversing.pdf

Just a link on the matter of reverse engineering hardwares.

Perhaps we should simply "sand" an acid chip
A friend of mine work as a "metrologue".
His worrk is to measure mechanical pieces with greatest precision to tell producers if their pieces respect the specs.

But so he has access to a nice set of modern precision video system, with ability to do extra zoomed clear pictures...
Yet the "sanding a chip" is delicate and would awfully kill the list beast.



I'll be searching for other articles on the matter of reverse engineering microchips and integrated circuits.

Yet we also must remind that dating from 1990, the ACID chip is not the miniaturised bastard of the modern era such as a square128x128pined  BGA surface mounted component.
(totaling in 16384 pins...)

Let's say it must have a few copper layers with a few semiconductor spots between hard silicon...
Perhaps a small memory like stuff ?

Also there :
http://www.tmplab.org/wiki/index.php/Chip_Reverse_Engineering

There is a mention of Karsten Nohl (who did the document of my first link).
Perhaps we should contact this person ?
http://www.cs.virginia.edu/~kn5f/index.html
But he must have no time for us, he may see not point nor time in our Amstrad fanboyoism...

another article from the man.
http://www.flylogic.net/blog/?p=32

He 's actually German, graduated in USA... Yet seems to live/work in Berlin.

Can some german fellows here get in touch with him ?
Yet he seems to be a busy man and ACID and retrojunk may not be his cup of tea (of barrel of beer...mmmh...).

If someone has access to a sweet digital microscope, and is willing to sacrifacie an ACID chip (a GX4000 burnin'Rubber may be the cheapest solution, can buy it for 5 €uros...)
just unsolder the chip, glue it on a support/base.
Then find a proper way to sand if slightly and gently, take pictures often with the microscope of the different layers.


I don't think ACID to be a really complicated security Hardware.
just a few simple logic fonctions and a ROM like data key perhaps.

Of course doing the same with an ASIC would be great too, yet a bit more complicated and delicate of course.
Bigger chip, and a shitton of fonctions, also memories spaces (Ram for the sprites, perhaps for the sound processor too ?)

There are companies who do that professionally.
Just have to see how much would it cost, as we may not need a complete analysis, just getting the basic schematics as many of you are great electronicians with a deep knowledge of the Amstrad logic, enough to understand the schematic by ourselves...

Because they have the right machines to do that, just sanding and photograph the chip is a trivial job for them.
This would be a much fiable solution as amateurishly sanding a chip may not be that easy.

Would need a trainning on a useless microchip first just to get the hand on the proper force to put in the sanding and the right "sand-paper" grain (or a proper file tool...).


http://www.selfworld.net/room_medias/8#
"GSM Rainbow tables & microchip reverse engineering "


Of course the "black box" anaysis started by our español fellows are usefull too, perhaps, yet the "HardCore" way seems the...most able to produce actual results.

Also, perhaps helpfull videos :


http://vimeo.com/3081101


oh, out of topic, yet fun, I I found this new video host site with computer related videos :

http://vimeo.com/3082459
commodore64 history.
Would be great and neat to have a video like this on Amstrad CPC...


http://vimeo.com/2622333
A türk demoparty/retrocomparty with some of the peoples there having... Amstrad's computers.


http://vimeo.com/5270825
amstradcpc.com.
yet tis video seems more Amiga related, but the site exists, it is a türkish retrocomp site with an obvious name.
Strange this guy don't seems to come visit us but he may have good knowledge perhaps, yet my Türk sucks deeply.
(Hey Gryzor, you don't live fare from Türky, as they are your direct neighbours...)


Also, back to topic...
http://www.ccc.de/de/
German fellows Amstradists may look at this association perhaps, some poeple there would be willing to halp.
http://en.wikipedia.org/wiki/Chaos_Computer_Club

Pledging our cause may work for the sake of it, as Amstrad's PLUS' ACID and ASIC may even be trivial for them...and is some kind of symbolic as it would actually "save" the Amstrad Plus range.

[OCT]

> Spanish Amstraders are actually trying to analyse it properly.
If somebody should happen to want to donate a cartridge, and maybe even a gx4000, I am sure I could figure out how it works in 2-3 days - you can make jokes on me for the rest of my life if I can't :-)

The attachment below is the schematic of the system cartridge (BASIC & Burnin Rubber in a 128K-27C1001 EPROM).

So what goes in besides the clock and power lines is just CCLR plus the lower byte of the address bus, all combined somehow into one single SIN bit of output at a time.
If CCLR is a reset line, that might indicate a shift register. Otherwise the chip might just be performing logic operations, one byte at a time, or even await Yet Another Magic Sequence, but that would probably have been too easy to overcome even for its age.
Taking it apart physically would probably use a few dozen of these chips though (and yet we do know who's got hundreds in stock at 4 Euros apiece).
Either way, I'd find it hard to believe that given the limited amount of input and output involved, one couldn't figure things out with the memory and analyzers available today.
Can't help wondering what signals the Spanish forum has been looking at, though... (but anyone going to Spain next month, by all means do source the mold&maker of these marvelous ZIF-socket cartridges)

[MacDeath]

I shall spill the blood of a thouzand spanish amstradist to find it !!!


Yet this sweet and well done multieeprom cart seems to miss the LKs...
Has anyone tested the LKs ?
Would it blown up the Amstrad to do the wrong LK config ?

Also I think a proper testing Software is needed to actually test the cartridges, with for exemple 256Ko or 512Ko Roms, to find where Datas are stored and how to access them, with the different LK settings ..


I don't think so many ACID need to be sacrified to perform a Hardware retroengineering.
Professionnal would actually find it quite trivial as they may have the equipment to perform such task on modern highly miniaturized chips.
Yet it would be great to check such company to know the price of this.

And we must also check if the so called "ACiD stock" is a fact or a fiction...Buy some perhaps or even go directly too the company pretending to be selling some to verify if those are really what we expect.
(thus reducing the shipment fee perhaps)

[dragon]

And we must also check if the so called "ACUD stock" is a fact or a fiction...Buy some perhaps or even go directly too the company pretending to be selling some to verify if those are really what we expect.
(thus reducing the shipment fee perhaps)

The true vendor of acid is in netherland(ntronics is an intermediate):
http://www.brokerforum.com/electronic-components-search-en.jsa?originalFullPartNumber=IL03P1003&x=0&y=0&hasNoSearchCriteria=false&searchPartNoLabelValue=Search+Part+Number

Brokerforums support trival versión.If anyone is encouraged to register, it's easy to find out who really sells the chips.

What they do(ntronics) is see this page.

On the other hand, the ASIC contains 18,000 gates. (Puts it in the service manual).

Ah another new intermediate shop:

http://www.powercomponents.nl/webshop/index.aspx?a=3&artcode=IL03P1003

So what goes in besides the clock and power lines is just CCLR plus the lower byte of the address bus, all combined somehow into one single SIN bit of output at a time.

The cclr signal is a strange signal.It behaves differently if the acid is or not.

If the acid is present. the signal cclr is continuous.But if its not present.The signal produces periodic pulses.

[OCT]

On the other hand, the ASIC contains 18,000 gates. (Puts it in the service manual).
[...]
The cclr signal is a strange signal.It behaves differently if the acid is or not.

If the acid is present. the signal cclr is continuous.But if its not present.The signal produces periodic pulses.

Sounds to me like it is periodically trying to trigger a sequence of communications with the ACID, probably by resetting it. I'd venture a guess that even with the ACID present, CCLR will probably show at least one (series of) pulse(s) on startup, while putting a number of addresses on the bus and monitoring for SIN to say what a good ACID should.
The fact that CCLR keeps "blinking" periodically when no cartridge has been detected is a good sign, for it suggests the ACID won't lock itself down until the next power cycle/"hard reboot" for the whole system when a sequence fails (otherwise there'd be no point in retrying).
Does SIN keep changing even after the pulses on CCLR have ceased?
Whatever SIN is (logically rather than theologically ), it must be simple enough for the CPC+'s ASIC to pre-compute as well from the address (+maybe CCLR) bits and compare to that bit - so on an analyzer, running a few gigabytes (not actually if we're just talking 2^(8 or)9*length_of_register bits) through the circuitry with the clock and blips of CCLR applied might already do the trick.
But first of all, one should capture the address byte on every "blink" of CCLR while there is no ACID - maybe things are even easier than we think and the ASIC does actually try a magic sequence that always starts with the same address.
With the ACID connected again, counting the pulses per series (assuming there is at least one of these even then, and that CCLR is not a chip reset, in which case one would have to count the clock cycles until SIN stops changing) should indicate the length of the PRNG shift register (or whatever it is), i.e. the number of addresses evaluated as input.
At any rate, from the circuit diagram I doubt the RAM that the Spanish have focused on is involved in what goes on between ASIC and ACID - unlocking the hardware to the cartridge seems to be what the ASIC does after successfully verifying the ACID.

[nocash]

Hi! Got the cartridge from fano (thanks!) and started to work on it saturday. First day I've wasted on unimportant stuff, desoldering the chip, verifying the pin-outs, nothing really required, but it's a nice way to get familar with the hardware :-)

The cartridge pin-outs are the same as the known A1-A18 and B1-B18 pin-numbers. Though counted differently (odd pins: CartPpin1..35 = CpcPinB18..B1, and even ones: CartPin2..36 = CpcPinA18..A1.

The six LKs are for A15,A17,A18 (address lines, of course, not the "A1-A18" pins).
  VCC ---LK1--- EPROM.A18---LK2---CPC.A18
  VCC ---LK3--- EPROM.A17---LK4---CPC.A17
  VCC ---LK5--- EPROM.A15---LK6---CPC.A15
My cartridge PCB doesn't have any LKs installed, instead, the etched circuit has hardwired connections between some of them. One could scratch them off, and then use the LK soldering points to reconfigure the board for eproms of other size.

----

Okay, now to the ACID. The pin-outs listed on cpcwiki are correct, not much new new there. The two GND pins are really both GND (they are interconnected with each other inside of the chip). The NC pin seems to be always high.

For testing I've simply wired the chip to the parallel printer port on my PC. A0-A7=Data0-7, OE=SELECT, CLK=STB, CCLR=INIT, SIN=BUSY.
Of course, the PC's I/O waitstates are making the transfer a bit slower than on the CPC, instead of 4MHz, I can't get CLK faster than 200kHz or so. Been a bit worried that it could cause problems (in case there'd by any stuff like dynamic refresh going on). Fortunately, it works 100% stable, I can even run a mp3 player in background.

SIN outputs the serial data stream to the CPC. CCLR is an input, setting it to LOW does reset the chip, which is (on a CPC) probably done only once at power-up to sync ACID and ASIC, or in case of errors (which would explain why people reported it to toggle on/off when cartridge is connected).

Aside from synchronizing, CCLR is (sometimes) also needed to get the ACID to output anything at all. I had a funny situation where SIN did output data all fine, then switched off the computer for a while - and when I wanted to continue SIN didn't output anything but zeros :-) took me quite a while to figure out why it didn't work anymore (needed to drag CCLR=LOW for a moment, then it started to send data).

----

Now to the data stream - after reset via CCLR, it outputs 16 high levels on SIN (one per CLK), and then starts to output "random" bits. So it's quite obvious even at first glance that the ACID is some simple shift-xor stuff, ie. as used in noise generators in sound chips.

Only problem is that one sees only one bit at a time (not the whole value in the shift register). Which made it a bit difficult to find out how it works: The shift register is 17bits wide, one bit is output on SIN, four bits are XORed with each other, shift occurs once per CLK cycle, and the XORed bits are shifted in at the top (or bottom, whatever you turn it around).

My test proggy can calculate the data stream by software, and it matches up perfectly with the data coming from the ACID chip. So that part is solved.

----

The other part - that I've more or less ignored for now - is the 9bit data bus, fed by the A0-A7 and /OE signals. The interesting part here is that the hardware is more or less ignoring it, too.

After CCLR=LOW, the first some thousands bits on SIN are usually always the same, no matter what is injected on the 9bit data bus. In many cases its even the complete data stream (not just only the first thousands bits) unaffected by the data.

Checking what is going on there will be my next step. My current bet is that the hardware does something like
"IF ValueOnDataBus = ValueInShiftRegister THEN toggle some bits"
which would explain why it reacts to incoming data only once every some thound cycles. If it that simple, then I am about half done with reverse engineering :-)

Cu, Martin

[redbox]

Hi! Got the cartridge from fano (thanks!) and started to work on it saturday.

Even with my very limited electronics knowledge, this is really interesting to read.

Keep us updated as you try and crack it. 

[Grim]

Could you confirm that the feedback fonction is :
feedback=b0 XOR b4 XOR b7 XOR b16

with b16 being the SIN value and feedback being the bit shifted in the register (in b0). Please?

Thank you!

[MacDeath]

[nocash]

> Could you confirm that the feedback fonction is :
> feedback=b0 XOR b4 XOR b7 XOR b16
> with b16 being the SIN value and feedback being
> the bit shifted in the register (in b0). Please?

I am shifting right (other way around), so, in that way, your values would be:
  newbit16 = oldbit16 xor oldbit12 xor oldbit9 xor oldbit0
yup, that are the same bits as the ones I am using.
I am using oldbit1 (aka newbit0) for SIN,  though that just matters on whether you do the calculation before or after the CLK pulse.

How did you find the bits? Did you connect the ACID chip to a PC, too? Thought I'd have been the first one having that idea, then on the other hand it's so obvious to do it, that other people probably had the idea too :-)

Apropos, anybody seen this one?
  http://v3.espacenet.com/publicationDetails/biblio?CC=GB&NR=2243701A&KC=A&FT=D&date=19911106&DB=&locale=
  link to a patent rumoured to be ACID's patent.
Guess (hope) everybody who ever made a CPC+ program will say:
"Errrr, no, that's something well known, and it's really not ACID." :-)

About the data inputs, /OE is simple. If it's high, then the data stream advances in normal way. If it's low, then the A0-A7 are somehow compared with the shiftregister, and if the values do match, then some bits are modified.

How the comparision & modification works exactly is still unclear to me. I can reproduce the effect for a dozen of values, and hoped I could calculated the remaining values from them. Ie. hoped that, if I know the effects on address=01h and on address=08h, for example, then address 09h should have the two ones XORed together - but that theory didn't worked, or I did something wrong :-)

[MacDeath]

This patent talks a lot about the locking and unlocking of Extra Plus features.
it talks about a new computer having to be compatible with ancient computer but having also additionnal features, yet those additionnal features should be locked in order to run old computer's programms...


Do you think the ACID has a role in this ?
We know it is possible to unlock the Extra PLUS features, but Amstrad said at the release of Plus range that only cartridges/cartridges games enabled Plus features.

Yet we know it isn't true, yet after all, running a PLUS still needs an ACID...
So running PLUS features may too.

[Grim]

How did you find the bits? Did you connect the ACID chip to a PC, too? Thought I'd have been the first one having that idea, then on the other hand it's so obvious to do it, that other people probably had the idea too :-)

I've put the ACID on a breadboard and connected it to the printer port of my CPC (taking the +5V from the expansion port). I wrote a small MC program to simulate the CLK, perform the CCLR initialization and then read/transmit the SIN pattern to the PC with a CPCBooster (RS232). It takes about 5 minutes to record 2-MByte of data.

The first 3 bits of the feedback function were easy to find by just looking at the first bits of the SIN pattern. But it took me a while to figure out the 4th bit because for some reason I assumed a 16bit wide shift register... missing one bit :)

Now I'm also trying to find out how the 9bit inputs affect the shift register. Right now I'm focusing on two SIN recordings; one that I can exactly reproduce with the feedback function, and another one which was recorded with some input bits set so the pattern differs at some point.

I intend to perform an almost-smart-brute-force attack to find out the relation between the inputs and the bits of the shift register. Dunno if it will work and how much time it will take to compute (It's written in PHP :).

This patent talks a lot about the locking and unlocking of Extra Plus features.

This patent describes the locking mechanism of the RMR2 register (allowing to page in/out the ASIC registers and ROM stuff). It has nothing to do with the ACID.

[nocash]

Got it! Fixed some mistakes in my proggy, found out that one of the 17 bits is ignored in the comparisions. And now the compare/adjust stuff is working fine :-)

   @@xlat macro nn,cmp_val,xor_val
     test byte ptr ds:[lpt_data],1 shl nn
     jz   short @@skip_&nn
     xor  dword ptr ds:[@@cmp_val],cmp_val
     xor  dword ptr ds:[@@xor_val],xor_val
    @@skip_&nn:
   endm
   ;---   bit,compare,xor
   mov  dword ptr ds:[@@cmp_val],13596h
   mov  dword ptr ds:[@@xor_val],0c820h
   @@xlat 0  ,0000ch ,00004h
   @@xlat 1  ,06000h ,06000h
   @@xlat 2  ,000c0h ,00080h
   @@xlat 3  ,00030h ,00020h
   @@xlat 4  ,18000h ,08000h
   @@xlat 5  ,00003h ,00000h
   @@xlat 6  ,00600h ,00000h
   @@xlat 7  ,01800h ,00800h
   test word ptr ds:[@@dat],100h ;OE=High
   jnz  short @@not_here
   mov  eax,dword ptr ds:[@@cmp_val]
   xor  eax,dword ptr ds:[@@shift_reg]
   and eax,not 100h
   jnz  short @@not_here
   mov  eax,dword ptr ds:[@@xor_val]
   xor  dword ptr ds:[@@shift_reg],eax
  @@not_here:
;---now advance shift reg
@@mod macro nn
  mov  ebx,dword ptr ds:[@@shift_reg]
  shr  ebx,nn
  xor  eax,ebx
endm
xor  eax,eax
@@mod 0
@@mod 9
@@mod 12
@@mod 16
and  eax,0001h
shl  eax,17
xor  dword ptr ds:[@@shift_reg],eax
shr  dword ptr ds:[@@shift_reg],1
;---isolate SIN
mov  eax,dword ptr ds:[@@shift_reg]
and  eax,0001h

That should be all about the ACID chip. I think everything is reverse engineered now, there should be no further secrets.

Let's see, 13th-16th February, 4 days altogether. Hmmmm, I claimed I could do it in 2 days, damn :-) but it's been a funny action-research time. Didn't do that kind of stuff for a while. Maybe I should go on with the NES, it has a similar chip - does somebody know if it's still unknown how the lockout chip in NES works?

[OCT]

Got it! Fixed some mistakes in my proggy, found out that one of the 17 bits is ignored in the comparisions. And now the compare/adjust stuff is working fine :-)

Congrats! This looks a lot like it wants to become a PAL/PIC/AVR/whatever...

[dragon]

nocash I only can say.You are a monter.

[Octoate]

Congrats! Great to see the secrets of the last chip seems to be determined .

nocash: is it possible that you can write how it works in a kind of pseudocode or do a small diagram of it (if you have time to do that)? Not all users (especially me ) are able to read x86-ASM.