CPCWiki forum

General Category => Amstrad CPC hardware => Topic started by: robcfg on 16:54, 12 April 16

Title: Gate array decapped!
Post by: robcfg on 16:54, 12 April 16
Hello everyone!


As I told in another thread, @Cpcmaniaco (http://www.cpcwiki.eu/forum/index.php?action=profile;u=23) and I sent 4 different Gate Array chips (40007, 40010, PreASIC and ASIC) to Sean Riddle (Sean Riddle's Home Page (http://www.seanriddle.com)) for decapping.


Today he sent me the first picture, which is the 40010 GA. I have to say it looks impressive, and finally we can have a peek at the inner working of the GA.


I uploaded the picture to the Gate Array wiki page (http://cpcwiki.eu/index.php/Gate_Array#Pictures).


Enjoy!
Title: Re: Gate array decapped!
Post by: Singaja on 17:06, 12 April 16
Could this be done with ASIC?
Title: Re: Gate array decapped!
Post by: dragon on 17:19, 12 April 16
My 3mb adsl is colapsed to view the foto. good work guys!!.
Title: Re: Gate array decapped!
Post by: robcfg on 17:19, 12 April 16
I guess so, that's why we sent him a PreASIC and an ASIC chip.
Title: Re: Gate array decapped!
Post by: dragon on 17:22, 12 April 16
Me da error la foto a pantalla completa os pasa a vosotros dice no se puede mostrar la imagen porque contiene errores.

Vale arreglado, la he descargado con el jdowloader jeje.
Title: Re: Gate array decapped!
Post by: Gryzor on 17:33, 12 April 16
It was probably a downloading error, the image is perfect - if it wasn't jDownloader wouldn't help :)


Amazing artwork for a wall print. I'm thinking this, an armchair, drugs. Duuuuude!
Title: Re: Gate array decapped!
Post by: gerald on 17:35, 12 April 16
Quote from: robcfg on 16:54, 12 April 16
I uploaded the picture to the Gate Array wiki page (http://cpcwiki.eu/index.php/Gate_Array#Pictures).
Is that the highest resolution available ? Some features are difficult to see.
Title: Re: Gate array decapped!
Post by: Arnaud on 17:42, 12 April 16
What can we do with it ? Improve emulation / FPGA ?
Title: Re: Gate array decapped!
Post by: gerald on 17:54, 12 April 16
Quote from: Arnaud on 17:42, 12 April 16
What can we do with it ? Improve emulation / FPGA ?
Yes. But I do not think there is much to be found on the 40010/40007
However, the ASIC picture would really help improving emulation, be it HW or SW.
Title: Re: Gate array decapped!
Post by: dragon on 18:01, 12 April 16
Quote from: gerald on 17:54, 12 April 16
Yes. But I do not think there is much to be found on the 40010/40007
However, the ASIC picture would really help improving emulation, be it HW or SW.

Diferent tecnology, if at the finish the 40007 is the ferranti 5000 documented in the book of zx spectrum.

Anyway i think it can be good specially to make new pre-asic chips to dead boards, and in the plus range, we can discover why the bugs of plus range.
Title: Re: Gate array decapped!
Post by: Gryzor on 18:15, 12 April 16
Quote from: gerald on 17:35, 12 April 16
Is that the highest resolution available ? Some features are difficult to see.


Might be due to jpeg compression? @robcfg (http://www.cpcwiki.eu/forum/index.php?action=profile;u=4) was kind enough to send me a 160MB version (though in GiMP format, no idea how this compares to TIFF etc), if anyone needs it I'll arrange something :)
Title: Re: Gate array decapped!
Post by: gerald on 18:37, 12 April 16
Quote from: Gryzor on 18:15, 12 April 16

Might be due to jpeg compression? @robcfg (http://www.cpcwiki.eu/forum/index.php?action=profile;u=4) was kind enough to send me a 160MB version (though in GiMP format, no idea how this compares to TIFF etc), if anyone needs it I'll arrange something :)
160MB is roughly the size of the image linked save in xcf (Gimp). So I guess this is the same resolution.
Title: Re: Gate array decapped!
Post by: robcfg on 18:52, 12 April 16
Same resolution but without compression artifacts.
Title: Re: Gate array decapped!
Post by: dragon on 18:57, 12 April 16
Is a channeled gate array?, So the cells are the in the rows and the space are the interconnecion between cells?.

Channeled Gate Array (https://inst.eecs.berkeley.edu/~ee244/fa97/Lectures/ee2441_1/sld030.htm)
Title: Re: Gate array decapped!
Post by: TotO on 19:07, 12 April 16
If I understand well, it is incredible to know that 40010 GA was designed in 1983 by LSI LOGIC and produced by SGS (ST Microelectronics).
Title: Re: Gate array decapped!
Post by: gerald on 19:20, 12 April 16
Quote from: robcfg on 18:52, 12 April 16
Same resolution but without compression artifacts.
Interrested  ;)
Title: Re: Gate array decapped!
Post by: ||C|-|E|| on 19:56, 12 April 16
This is amazing! If we had all the data for the ASIC it should be possible to do a perfect FPGA core and a perfect emulator...  :o
Title: Re: Gate array decapped!
Post by: robcfg on 20:39, 12 April 16
Some more info on the picture:


QuoteThat pic was composited from 156 pics taken using a 10x objective, and I scaled it down by about 1/2. I also took pics with a 20x objective, but there are 600 of those, so I need a faster way to composite them.


That's some serious amount of work!


Also:


QuoteI was able to figure out the pad numbering from that doc:
   5    36 
6        35




14        26
  15    25



The doc he's referring to is http://matthieu.benoit.free.fr/pdf/amstrad_videogate-array.pdf (http://matthieu.benoit.free.fr/pdf/amstrad_videogate-array.pdf)


@gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) , I sent you a PM  ;)


I'm eager to see the rest of the chips, hehe!
Title: Re: Gate array decapped!
Post by: robcfg on 20:47, 12 April 16
Quote from: dragon on 18:57, 12 April 16
Is a channeled gate array?, So the cells are the in the rows and the space are the interconnecion between cells?.

Channeled Gate Array (https://inst.eecs.berkeley.edu/~ee244/fa97/Lectures/ee2441_1/sld030.htm)


I cannot tell you for sure, as I'm no expert in the field. It looks like one, but I can be wrong.
Title: Re: Gate array decapped!
Post by: Bryce on 20:57, 12 April 16
Very nice work. He obviously knows what he's doing to have freed the metal layer that nicely without damaging it at all. In high-res this should be "decypherable". Massive amount of work though.

Bryce.
Title: Re: Gate array decapped!
Post by: dragon on 21:07, 12 April 16
And what happend with the 40008? i view is selling now alone in ebay. We can make a collect or something. To.have all chips decaped.

Quote

I cannot tell you for sure, as I'm no expert in the field. It looks like one, but I can be wrong.

I 'm not an expert  only supposed, if is this type one of the horizontal metal layers are vccc an the other ground.
Title: Re: Gate array decapped!
Post by: robcfg on 21:13, 12 April 16
Quote from: Bryce on 20:57, 12 April 16
Very nice work. He obviously knows what he's doing to have freed the metal layer that nicely without damaging it at all. In high-res this should be "decypherable". Massive amount of work though.

Bryce.


Indeed, but at least, we have a starting point, which is more than we had. Any suggestions on how should we start identifying anything on the image?


QuoteAnd what happend with the 40008? i view is selling now alone in ebay. We can make a collect or something. To.have all chips decaped.


Well, CPCManiaco spent quite some time digging through all the CPCs he has at hand, but he couldn't find a 40008.


Anyway, I expect the most changes to happen between 40007 and the other two, as 40008 and 40010 have the same pinout.


Of course, it would be nice to have them all decapped  ;)
Title: Re: Gate array decapped!
Post by: dragon on 21:16, 12 April 16
Yeah i suppose it we can buy one thats all :)

And no cpc sacrificed :)

Amstrad 40008 | eBay (http://m.ebay.es/itm/Amstrad-40008-/252343051537?nav=SEARCH)

Yeah the 40007 probably share picture infrastructure with ula spectrum, i think the 40008 is made by lsi (without sgs).

I count 37 cells (it appeared agruped by two in two) *18 rows=666 jaja. counting it alone makes 74*18=1332 cells.

Title: Re: Gate array decapped!
Post by: Gryzor on 07:28, 13 April 16
Crowdfunding? :D


No idea about the industry, but isn't there any software that can help you decipher the whole thing?
Title: Re: Gate array decapped!
Post by: Octoate on 07:50, 13 April 16
Quote from: Gryzor on 07:28, 13 April 16
No idea about the industry, but isn't there any software that can help you decipher the whole thing?
You can use Degate (Reverse engineering integrated circuits with degate - Home (http://www.degate.org)). Btw, a nice tutorial on how to reverse engineer ICs can be found here (http://siliconzoo.org/tutorial.html).
Title: Re: Gate array decapped!
Post by: TotO on 08:55, 13 April 16
Quote from: Gryzor on 07:28, 13 April 16
Crowdfunding? :D
Those seven 40008 IC are on ebay months after months and nobody buy them for this price...
I suggest to contact the seller and ask him a more afortable price with shipping to the decapper address.
Title: Re: Gate array decapped!
Post by: Munchausen on 08:58, 13 April 16
Quote from: Octoate on 07:50, 13 April 16
You can use Degate (Reverse engineering integrated circuits with degate - Home (http://www.degate.org)). Btw, a nice tutorial on how to reverse engineer ICs can be found here (http://siliconzoo.org/tutorial.html).

Cool software!

Is this image high resolution enough? The screenshots on the Degate page look like they show more detail.
Title: Re: Gate array decapped!
Post by: arnoldemu on 09:09, 13 April 16
I have some 40010 and 40007 here that I was going to send to visual6502 for decapping but never did.
I will check if I have a 40008 (unlikely, but I will check).

Title: Re: Gate array decapped!
Post by: dragon on 09:36, 13 April 16
Quote from: Octoate on 07:50, 13 April 16
You can use Degate (Reverse engineering integrated circuits with degate - Home (http://www.degate.org)). Btw, a nice tutorial on how to reverse engineer ICs can be found here (http://siliconzoo.org/tutorial.html).

I read the tutorial, i understand the logic behind it +-, but i no view how applied it to this gate array.

The horizontal metal layers are vcc and ground(is vcc the up or the down?). A connected vcc or ground can be easly view because the horizontal metal layers in each vertical line have intermediate vertical lines (comparing the free  cells in the left upper corner, with full). But i dont understand the vertical pads  crossing the cell , because they have wires connected. I spected the wires be connect to.the red substrate, and vertical pads are the red in the tutorial,
If i supposed the 6 vertical barsin  one cell of the gate array. Are the red in the tutorial ,I little lost :-)

Is the down wire vcc and upper ground?
Title: Re: Gate array decapped!
Post by: robcfg on 09:47, 13 April 16
Good morning!


I just received the picture of the 40226 PreASIC metal layer, you'll find it along the 40010 pictures in the Gate Array (http://cpcwiki.eu/index.php/Gate_Array#Pictures) page.


Sean tells me that he removed the passivation layer and the top metal layer from both chips and will be taking a new set of pictures shortly.


Unfortunately the 40007 broke because of thermal stress, so we'll have to get another one.


Have a nice day!
Title: Re: Gate array decapped!
Post by: TotO on 10:05, 13 April 16
Quote from: robcfgUnfortunately the 40007 broke because of thermal stress, so we'll have to get another one.
I have some 40007 in stock. I can ship him one of them.

Title: Re: Gate array decapped!
Post by: Cpcmaniaco on 10:10, 13 April 16
Now. I get 1 40008 from ebay, for this experiment.
Title: Re: Gate array decapped!
Post by: Cpcmaniaco on 10:14, 13 April 16
@TotO (http://www.cpcwiki.eu/forum/index.php?action=profile;u=290)   I will bay you 2 40007, 1 for the experiment and 1 for me to replace the other.
Title: Re: Gate array decapped!
Post by: TotO on 10:35, 13 April 16
I have expected that you will require a replacement part too.  ;)
I will provide you free parts and ship them this afternoon!  8)
Title: Re: Gate array decapped!
Post by: dragon on 11:01, 13 April 16
Pre asic =lsi compact gate array. Sea of gates. It appear amstrad have pass in this life with all stages of new technology in gate arrays. It have reference books published.

Thats remember me. Also the acid is reverse enginered. What about sending one to complete the album of pictures of custom ic?

Hi found this curse, i think it can help to undersantd how works the logic of the 40010
https://www.google.es/url?sa=t&source=web&rct=j&url=http://www.csit-sun.pub.ro/courses/vlsi/VLSI_Darmstad/www.microelectronic.e-technik.tu-darmstadt.de/lectures/winter/vlsi/vorlesung_pdf/chap13.pdf&ved=0ahUKEwimjNbxy4vMAhVG1hQKHaHFD2sQFgg4MAk&usg=AFQjCNFARYhNwBskHOmvbPyYVAah9qc9WA&sig2=Gm_oFlQcbWiW22ptFgRHIw (https://www.google.es/url?sa=t&source=web&rct=j&url=http://www.csit-sun.pub.ro/courses/vlsi/VLSI_Darmstad/www.microelectronic.e-technik.tu-darmstadt.de/lectures/winter/vlsi/vorlesung_pdf/chap13.pdf&ved=0ahUKEwimjNbxy4vMAhVG1hQKHaHFD2sQFgg4MAk&usg=AFQjCNFARYhNwBskHOmvbPyYVAah9qc9WA&sig2=Gm_oFlQcbWiW22ptFgRHIw)
Title: Re: Gate array decapped!
Post by: TotO on 13:08, 13 April 16
Quote from: Cpcmaniaco on 10:14, 13 April 16
@TotO (http://www.cpcwiki.eu/forum/index.php?action=profile;u=290)   I will bay you 2 40007, 1 for the experiment and 1 for me to replace the other.
Just sent!  ;)
Title: Re: Gate array decapped!
Post by: gerald on 17:25, 13 April 16
Quote from: dragon on 11:01, 13 April 16
Pre asic =lsi compact gate array. Sea of gates. It appear amstrad have pass in this life with all stages of new technology in gate arrays. It have reference books published.

Thats remember me. Also the acid is reverse enginered. What about sending one to complete the album of pictures of custom ic?

Hi found this curse, i think it can help to undersantd how works the logic of the 40010
https://www.google.es/url?sa=t&source=web&rct=j&url=http://www.csit-sun.pub.ro/courses/vlsi/VLSI_Darmstad/www.microelectronic.e-technik.tu-darmstadt.de/lectures/winter/vlsi/vorlesung_pdf/chap13.pdf&ved=0ahUKEwimjNbxy4vMAhVG1hQKHaHFD2sQFgg4MAk&usg=AFQjCNFARYhNwBskHOmvbPyYVAah9qc9WA&sig2=Gm_oFlQcbWiW22ptFgRHIw (https://www.google.es/url?sa=t&source=web&rct=j&url=http://www.csit-sun.pub.ro/courses/vlsi/VLSI_Darmstad/www.microelectronic.e-technik.tu-darmstadt.de/lectures/winter/vlsi/vorlesung_pdf/chap13.pdf&ved=0ahUKEwimjNbxy4vMAhVG1hQKHaHFD2sQFgg4MAk&usg=AFQjCNFARYhNwBskHOmvbPyYVAah9qc9WA&sig2=Gm_oFlQcbWiW22ptFgRHIw)
Gate array was usually cheaper than an ASIC if you could get your logic in it. I would not be surprised that the plus Asic is also a gate array.
Title: Re: Gate array decapped!
Post by: arnoldemu on 19:16, 13 April 16
Quote from: arnoldemu on 09:09, 13 April 16
I have some 40010 and 40007 here that I was going to send to visual6502 for decapping but never did.
I will check if I have a 40008 (unlikely, but I will check).
I don't have a 40008.

If the 40007 that is being sent also fails to be decapped then I have another we can send and try.
Title: Re: Gate array decapped!
Post by: dragon on 19:24, 13 April 16
And probably made by sgs logic corporation :) .


Investigating I found a a free book about the history of lsi coporation.Curiosity the company begin in 1980.First copy(licensed) the standar Robert Lipp cell design in the 80 for cmos gate array, and later around 1982, they made a joint with thosiba  to desning an asic. They made a vdsli aplication using diferenten licenses.

The question is around 1983 (The c year in the gate array die). They finish with thosiba the LL5000 series gate array. Searching their datasheet  in LL5000 series, it said sgs is a second source with other company.

I autothinking if you are a second source company. And you want your product not have the original code of original manfacturer.But its a second source. Then you use the original number name, but your changue first original name.

So i search  lsi logic corp LL3000 array.

And i found a datasheet of a lsi LL3000 series. And it have and interesting table wihth all submodels.

And two of the submodel in the table are "misteriusly" LL3130 and LL3170 Remember the name of 40008 and 40010 in the service manuals? HSG3130 and HSG3170

As the datasheet says is a "H-CMOS Silicon Gate-Logic array"  HGS=abreviature of H-cmos Silicon Gate logic array ? :)

LL3250 ... - Datasheet Search Engine Download (http://www.datasheetarchive.com/dl/Scans-053/DSAIH00065990.pdf)


Pd: We need this book:


Databook and design manual : HCMOS macrocells, macrofunctions (Book, 1986) (http://www.worldcat.org/title/databook-and-design-manual-hcmos-macrocells-macrofunctions/oclc/22886464&referer=brief_results)
Title: Re: Gate array decapped!
Post by: pelrun on 05:53, 14 April 16
Looking at the patents a bunch of them have a diagram and description of the basic P/N transistor cell that you can see repeated in our GA. This one has it as Fig. 1:



http://www.google.com/patents/US5079614 (http://www.google.com/patents/US5079614)


One square each of P and N doped diffusion, overlaid by two strips of polysilicon to form transistors, and crossed by VDD and VSS power lines. On our GA there are only minor differences; the second cell has a crossover between the two wells, and the power lines are in the metal layer on top.
Title: Re: Gate array decapped!
Post by: dragon on 13:54, 15 April 16
The big problem as people say earlier, is its lack resolution, i can't watch really where are connected the cables :s.

Maybe is best make an alternative approach.

Take the base cell, and drawn in a paper the basic logicall cells, and,or,nand,nor, etc. Theoricall connected with the base cells.

And then try find these  "figures" in the picture. Then at least is posible find the basic gates, search the wires between cells is more easy. To form macrofunctions
Title: Re: Gate array decapped!
Post by: Gryzor on 14:08, 15 April 16
Can you circle, on the photo, where the problem lies? I'll see if it's on the original image...
Title: Re: Gate array decapped!
Post by: pelrun on 14:21, 15 April 16
I disagree about the resolution; I don't have any problem seeing where the metal traces are joined to the silicon layers, either in the large bus bars or in the finer interconnects. There's very rarely a join in the middle of a track, anyway (they branch off into a stub if there's room) - and even those are distinguishable.


Edit: only talking about the original GA here; the Pre-ASIC is much denser.
Title: Re: Gate array decapped!
Post by: dragon on 17:13, 15 April 16
Quoteauthor=Gryzor link=topic=11888.msg124813#msg124813 date=1460725733]
Can you circle, on the photo, where the problem lies? I'll see if it's on the original image...

Oh i think its not necessary, i can't simply interpret the pass from theory to the picture.


Quote from: pelrun on 14:21, 15 April 16
I disagree about the resolution; I don't have any problem seeing where the metal traces are joined to the silicon layers, either in the large bus bars or in the finer interconnects. There's very rarely a join in the middle of a track, anyway (they branch off into a stub if there's room) - and even those are distinguishable.


Edit: only talking about the original GA here; the Pre-ASIC is much denser.

If you can make an example with one of the cells of the picture. And a equivalence with the therory in paper. I (and others i suppuse :) be grateful, for example who do you distinghs where are connectwd vcc with the vertical lines in the power metal bars.

Why the vertical bar  in the middle are less fat that the other?

Where is connected the wires to the metal bars or transistors when they are in the bars
In the theory the vertical bars have  connections in the two sides around the power bars, but it have in these gate array?. I don't have view a wire connected  in the upper part of vcc vertical bar.

I mean i understand the theory in paper. But i can't interpret how is connected the cells, because i can't view the transistors where they are connected to compare the cell structure with the paper theory structure.

I'm sure bryce,gerald and you and other people  not have problems to figure how is connected, but i non an expert in hardware  at this level sorry :) i only try to learn about it.
Title: Re: Gate array decapped!
Post by: pelrun on 19:45, 15 April 16
You get one transistor everywhere there is a thin red line crossing one of the green squares - either an N-fet or a P-fet depending on how the square is doped. That gives you two transistors per square, sharing one pin. The red line is the gate, and the green areas to the sides are the source/drain (the fets are symmetrical, it doesn't matter which you call source or drain.) The red 'wire' is thinner in the transistor area because that affects the properties of the transistor; it's larger elsewhere to provide enough area to attach wires to. If you read the start of the patent I posted earlier, it describes this in a fairly straightforward manner.


As you've guessed, where the vcc/gnd bus bars are connected to the transistors shows up as vertical edges - there's an insulating layer between the top metal layer and the polysilicon below, and there are holes in this layer to allow the metal and polysilicon to touch. You're literally seeing the edges of the holes, as the metal layer drops into the hole and back up the other side.
Title: Re: Gate array decapped!
Post by: gerald on 14:03, 16 April 16
A good picture is better than thousand words :
Here is a inverter, implemented in the gate array. This is the 1st one on the 16MHz input clock path
[attach=2]
The metal on the left of the output is the input going somewhere else.
Title: Re: Gate array decapped!
Post by: ||C|-|E|| on 18:02, 16 April 16
It is extremely interesting, for somebody like me, too see these kind of jobs done and interpreted. A great, great opportunity to learn a lot  :-*
Title: Re: Gate array decapped!
Post by: robcfg on 19:18, 16 April 16
This is top notch stuff! Thanks @gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) !


Is it safe to assume that every other inverter on the gate array should look exactly the same as this one?
Title: Re: Gate array decapped!
Post by: ||C|-|E|| on 19:35, 16 April 16
It should be possible, once characterized the main functional units, to create a program to annotate all of them, right? You would probably need to "teach" it with a few examples, but it should work, since it is essentially the same I do to create a 3D structure from 2D projections of a particular protein complex. Although the reallity is more complicate in my case (you select a bunch of 2D projections rotated in different angles, then a 2D fourier transform is computed for all the projections, the you group them in class averages based on their fourier transform, and then you reconstruct the 3D model in the fourier space) a similar approach would probably work here, specially considering that we do not have different rotations but always the same view, something that simplifies the process a lot. I am the biologist in my lab, I work in the biochemical part preparing the samples and not coding the software, but I am convinced that it should really work. On the other hand, maybe there is something like this already, I do not know about reverse reverse engineering. In any case, if somebody would like to implement something like this I can submit you guys a tons of paper discussing the algorithms, everything is open source.

Title: Re: Gate array decapped!
Post by: gerald on 20:02, 16 April 16
Quote from: robcfg on 19:18, 16 April 16
Is it safe to assume that every other inverter on the gate array should look exactly the same as this one?
More or less  ;D
- The connection of the input / output port can change.
- There is also a strong inverter (made of 2 GA cells)

Title: Re: Gate array decapped!
Post by: Gryzor on 13:58, 18 April 16
Yes, but I guess that even with a program doing the grunt work you'd still need to double-check manually... not exactly easy :D
Title: Re: Gate array decapped!
Post by: ||C|-|E|| on 15:10, 18 April 16
It would actually be a titanic task for something like the ASIC in the Plus, even with the help of a proper tool  :-X . All the others would be very difficult as well...  :-X
Title: Re: Gate array decapped!
Post by: dragon on 15:43, 18 April 16
Quote from: ||C|-|E|| on 15:10, 18 April 16
It would actually be a titanic task for something like the ASIC in the Plus, even with the help of a proper tool  :-X . All the others would be very difficult as well...  :-X

Not necesarilly. The amstrad ciruit reencarnarion is not made from 0, is acumulative, it have changes because change in tecnology, but apart from that, if you pick the 40007 circuit, the 48000 is the same but adapted to a diferent tecnology. I supposed the 40010 was simply the same circuit rearranged to avoid the heat problems in 40008 using the same  gate array with more cells.

The preasic  probably have these circuit of 40010 embbed+ the other chips emulated connected with the outs pins of the old desing of the gate array.

The asic plus probably have  a copy of the schematic of the preasic inside but with the new features add in it.

Thats the resason in amstrad not made a 16bit computer. 16bit need made all from 0 and two years of work. but the plus, is the same with add logic.So mostly of the job is done in a few monts..


I thinks all time the grey bars are the the poly jeje, i read it at reverse .
Title: Re: Gate array decapped!
Post by: Munchausen on 16:17, 18 April 16
Yeah, this has been done before and is possible. See for example the acorn tube ULA for which a replacement has been produced by image processing and some manual intervention on scans of the Ferranti ULA design: Tube ULA Reverse Engineering - stardot.org.uk (http://stardot.org.uk/forums/viewtopic.php?t=8539)

The Amstrad ICs are harder because you are working from a photo of the actual chip, but the principle is the same: The software tries to match the connections for each gate, but some manual intervention will be required. Those guys actually developed their own software for the job...
Title: Re: Gate array decapped!
Post by: ||C|-|E|| on 16:33, 18 April 16
Quote from: dragon on 15:43, 18 April 16
Not necesarilly. The amstrad ciruit reencarnarion is not made from 0, is acumulative, it have changes because change in tecnology, but apart from that, if you pick the 40007 circuit, the 48000 is the same but adapted to a diferent tecnology. I supposed the 40010 was simply the same circuit rearranged to avoid the heat problems in 40008 using the same  gate array with more cells.

The preasic  probably have these circuit of 40010 embbed+ the other chips emulated connected with the outs pins of the old desing of the gate array.

The asic plus probably have  a copy of the schematic of the preasic inside but with the new features add in it.

Thats the resason in amstrad not made a 16bit computer. 16bit need made all from 0 and two years of work. but the plus, is the same with add logic.So mostly of the job is done in a few monts..


I thinks all time the grey bars are the the poly jeje, i read it at reverse .

If it is additive and not a redesign from the scratch then it would be actually very doable! With a lot of work, but very doable :). That would be actually great. Do not ask me why, but I always assumed that the ASIC from the Plus was a design not based in accumulative approach. I also thought that this was the main cause of the "bugs" it has. Great to know that it is not the case  :D
Title: Re: Gate array decapped!
Post by: dragon on 16:43, 18 April 16
Quote from: Munchausen on 16:17, 18 April 16
Yeah, this has been done before and is possible. See for example the acorn tube ULA for which a replacement has been produced by image processing and some manual intervention on scans of the Ferranti ULA design: Tube ULA Reverse Engineering - stardot.org.uk (http://stardot.org.uk/forums/viewtopic.php?t=8539)

The Amstrad ICs are harder because you are working from a photo of the actual chip, but the principle is the same: The software tries to match the connections for each gate, but some manual intervention will be required. Those guys actually developed their own software for the job...

I remember read steve gane(the asic harware developer), tell proably it have the tapes in sun of the asic in some place.But tell he drop it jeje. probalby he simply uses the lsi logic software to do that.

Anyway, what ula model the arcon bbc have?.Can this software works with the 40007?(5000r ula series)

Quote from: ||C|-|E|| on 16:33, 18 April 16
If it is additive and not a redesign from the scratch then it would be actually very doable! With a lot of work, but very doable :) . That would be actually great. Do not ask me why, but I always assumed that the ASIC from the Plus was a design not based in accumulative approach. I also thought that this was the main cause of the "bugs" it has. Great to know that it is not the case  :D

If i remember correctly. the bugs are in the new features, but not in the old cpc part :) . And i remember read about the preasic in the google groups the preasic principally is  made to subsitute the obsolete old ram access to the old ram,so  amstrad can  use the new ram chips in preasic and later in the asic.

A little advantage we know a little part of the circuit.(the acid  patent in the plus part).
Title: Re: Gate array decapped!
Post by: gerald on 16:45, 18 April 16
Quote from: ||C|-|E|| on 16:33, 18 April 16
If it is additive and not a redesign from the scratch then it would be actually very doable!
Unlikely to be additive, even for the 40008 to 40010. 5BTW, looking at LSI reference, the 40008 uses a bigger array)
The usual design is schematic entry, then the manufacturer tool suite place it where it fits on the gate array.

Toying with degate[nb]Sharp eyes will spot two different implementation of the inverter[/nb] :
[attach=2]

Title: Re: Gate array decapped!
Post by: dragon on 17:13, 18 April 16
And why do you think the 40008 have bigger array gerald?. The pdf say it have  1332 blocks(3130), and the other 1722(3170).

Is bad the numeration in the cpcwikiparts or so?.

Amstrad part numbers - CPCWiki (http://www.cpcwiki.eu/index.php/Amstrad_part_numbers)

Or you say simply is bigger?.(And i trasltate bad for english) :).
Title: Re: Gate array decapped!
Post by: gerald on 18:47, 18 April 16
Quote from: dragon on 17:13, 18 April 16
And why do you think the 40008 have bigger array gerald?. The pdf say it have  1332 blocks(3130), and the other 1722(3170).
Simply because the number of cell in the 40010 picture matches the LL3130 (18*74=1332)  ;)
Title: Re: Gate array decapped!
Post by: dragon on 19:16, 18 April 16
Oh men, this is really strange, i open the service manual of 664 and 6128 in the wiki.

In the ic says "amstrad 40010 hsg3130 or 3170".

All the info in the wiki was wrong. Exist two version of the 40010?

The pin compatible are the 40007 and the 40008 no?, not the 40008 and the 40010.

If it the 40007 and the 40008, are the two ferranti ics.And 40010 are provide with the same circuit in the two distints internal array chips depending of the disponibility?.
Title: Re: Gate array decapped!
Post by: robcfg on 19:25, 18 April 16
40008 and 40010 are pin compatible, the 40007 is not
Title: Re: Gate array decapped!
Post by: gerald on 19:33, 18 April 16
Quote from: dragon on 19:16, 18 April 16
Oh men, this is really strange, i open the service manual of 664 and 6128 in the wiki.

In the ic says "amstrad 40010 hsg3130 or 3170".

All the info in the wiki was wrong. Exist two version of the 40010?

The pin compatible are the 40007 and the 40008 no?, not the 40008 and the 40010.

If it the 40007 and the 40008, are the two ferranti ics.And 40010 are provide with the same circuit in the two distints internal array chips depending of the disponibility?.
Quote from: robcfg on 19:25, 18 April 16
40008 and 40010 are pin compatible, the 40007 is not
If these two picture are not fake, 40008 is 40007 compatible

http://www.cpcwiki.eu/imgs/6/69/CPC464_PCB_Top_%28Z70200_MC0002D%29.jpg (http://www.cpcwiki.eu/imgs/6/69/CPC464_PCB_Top_%28Z70200_MC0002D%29.jpg)
http://www.cpcwiki.eu/imgs/9/92/CPC464_PCB_Top_%28Z70200_MC0002D%29_GA40008.jpg (http://www.cpcwiki.eu/imgs/9/92/CPC464_PCB_Top_%28Z70200_MC0002D%29_GA40008.jpg)

And then we may think of 2 versions of 40010  :D

Title: Re: Gate array decapped!
Post by: dragon on 19:59, 18 April 16
Yes i think maybe we are wrong all time, comparing the font letter in the pictures of the 40007 and 40008.Are the same, and the two serial numbers begin with F, and add in the service manual in the 40007 motherboard draw say ferrat ic.


But i think this can be a problem, i remember reading in the spectrum ula book page took several ics to decapped it. It appears the ferranti ics are very sensible. And in the other hand  i remember robcfg telling 40007 was broken in the process....

So i think  maybe the 40008 can broke easily as the 40007 in the process.

Oh, you have compared the details in 40007 gerald. Maybe the have different rervisions to ?.

In the first picture a 464 have 40007-4 Fxxxx
But in the second picture the cpc have 40007-4x fxxxx

File:CPC464 PCB Top (Z70100) GA40007-4.jpg - CPCWiki (http://www.cpcwiki.eu/index.php/File:CPC464_PCB_Top_%28Z70100%29_GA40007-4.jpg)
http://www.cpcwiki.eu/imgs/0/0d/CPC464_Z70100_MC0001A_PCB_Top.jpg (http://www.cpcwiki.eu/imgs/0/0d/CPC464_Z70100_MC0001A_PCB_Top.jpg)

Or is part of the serial number?.
Title: Re: Gate array decapped!
Post by: gerald on 20:42, 18 April 16
Quote from: dragon on 19:59, 18 April 16
Oh, you have compared the details in 40007 gerald. Maybe the have different rervisions to ?.

In the first picture a 464 have 40007-4 Fxxxx
But in the second picture the cpc have 40007-4x fxxxx

File:CPC464 PCB Top (Z70100) GA40007-4.jpg - CPCWiki (http://www.cpcwiki.eu/index.php/File:CPC464_PCB_Top_%28Z70100%29_GA40007-4.jpg)
http://www.cpcwiki.eu/imgs/0/0d/CPC464_Z70100_MC0001A_PCB_Top.jpg (http://www.cpcwiki.eu/imgs/0/0d/CPC464_Z70100_MC0001A_PCB_Top.jpg)

That's the date code
8428 mean year 1984 week 28
8436 mean year 1984 week 36
Title: Re: Gate array decapped!
Post by: robcfg on 21:36, 18 April 16
Quote from: gerald on 19:33, 18 April 16
If these two picture are not fake, 40008 is 40007 compatible

http://www.cpcwiki.eu/imgs/6/69/CPC464_PCB_Top_%28Z70200_MC0002D%29.jpg (http://www.cpcwiki.eu/imgs/6/69/CPC464_PCB_Top_%28Z70200_MC0002D%29.jpg)
http://www.cpcwiki.eu/imgs/9/92/CPC464_PCB_Top_%28Z70200_MC0002D%29_GA40008.jpg (http://www.cpcwiki.eu/imgs/9/92/CPC464_PCB_Top_%28Z70200_MC0002D%29_GA40008.jpg)

And then we may think of 2 versions of 40010  :D


Damn! You're right! I've taken a look at the other boards, and 40007 and 40008 GAs go in the same socket and only 40010 goes in the other one.


Also, I've noticed an error in the Grimware's Gate Array page (http://www.grimware.org/doku.php/documentations/devices/gatearray), which says that the CPC664 had a 40008 GA. If you take a look at our pictures, the 664 come with a 40010 GA, and only the later 464 and earlier 6128 have slots for the different GA models.


It seems that the pin compatible ones are indeed 40007 and 40008.


And we thought we knew a lot about the CPC...  :D
Title: Re: Gate array decapped!
Post by: dragon on 22:21, 18 April 16
I have a theory how we can distinguis the 40010-a and 40010-b

Looking to the die, the internal number are different fron the code encapsulated, except by the "36 AA" is in the lsi copyright part.

I revised the picures of all boards, it appears all cpc have 36 AA  and other have "37 AA"

The other numbers vary from board in board, but these part have only two types and are continuosly numbers as the numbers in the datasheet.

I was think all my life the 664 has epecial and it have the 40008 jaja but hey it have a 37aa code.

In the other hand i think only 664 and first 6128(464 i not sure).mount the 3170. Maybe they discover later the circuit enter in a low cost gate array 3130.And swap to it or so.

PD:seriusly, i have found the gate array original schematic but used in the pc 1512 in a museum! :)

Objects (http://www.nationalmediamuseum.org.uk/scim/online_science/explore_our_collections/objects/index/smxg-8091148)

This confirmed these corner are part number and not serial number.
Title: Re: Gate array decapped!
Post by: gerald on 11:43, 19 April 16
Quote from: dragon on 22:21, 18 April 16
I have a theory how we can distinguis the 40010-a and 40010-b

Looking to the die, the internal number are different fron the code encapsulated, except by the "36 AA" is in the lsi copyright part.

I revised the picures of all boards, it appears all cpc have 36 AA  and other have "37 AA"

The other numbers vary from board in board, but these part have only two types and are continuosly numbers as the numbers in the datasheet.

I was think all my life the 664 has epecial and it have the 40008 jaja but hey it have a 37aa code.

In the other hand i think only 664 and first 6128(464 i not sure).mount the 3170. Maybe they discover later the circuit enter in a low cost gate array 3130.And swap to it or so.
Good find.
So we can externally identify the two 40010
- one using LL3170 and marked with 37AA ( appeared on 664 ?)
- one using LL3130 and marked with 36AA ( most of others ?)

Now we need to fix documentation referring the 40008 as pin compatible with the 40010s (@grim can you update the grimware ?)
Title: Re: Gate array decapped!
Post by: dragon on 12:33, 19 April 16
Maybe is a good idea made the grimware rasterization test to one gate array aa37?.

Maybe we can  view a suprise or not :) . but i not have these gate array.

Also cpcmaniaco i remember have 664 schneiders maybe robcfg can take a look at it to confirm they have aa37. And more 464 and 6128 1stgen.

Its only question of find it in a 464, and compare cpc serial dates with the 664. If not exist in the 464, it came out in 664, if 464 date are early that 664, then go out in 464.

well in the wiki the first 464 with double slot is z70200 mc0001a: File:Z70200 MC0001A TOP.JPG - CPCWiki (http://www.cpcwiki.eu/index.php/File:Z70200_MC0001A_TOP.JPG)

And the first 664 is mc0005a z70205, so 464 was prepared for the 400010 early 664 came out.But thats not mean it mount aa37, because amstrad can put 40008 first to eliminate stock existences. And when all 40007/40008 are put, then maybe put the aa36.

http://www.cpcwiki.eu/imgs/f/f2/CPC664_PCB_Top.jpg (http://www.cpcwiki.eu/imgs/f/f2/CPC664_PCB_Top.jpg)

One interesting think apart. The ic 125. This ic was ferranti in 464 and then change in the cpc doble slot gate array(to thosiba lsi partner), that proably means amstrad broke with ferranti and they not buy  it more chip, and these 40007 are rest of stock. And at the same time the z80 change to sgs. It is connected to xtal part of the 16mhz clock logic generated by the quarz to  the gate array.
Title: Re: Gate array decapped!
Post by: ||C|-|E|| on 14:41, 19 April 16
I see that is still possible to buy the 40489 ASIC as spare part (the ASIC from the Plus). It is expensive, around 75 euros per unit, but maybe we could try to decap this guy as well. How do you feel about that? We would probably need to buy two or three but it could be worth it. I would happily contribute to buy them.

Semiconductor: 40489 - AMSTRAD-IC GATE ARRAY - UK (GBP) (http://www.donberg.co.uk/descript/4/40489.htm)
Title: Re: Gate array decapped!
Post by: robcfg on 14:45, 19 April 16
We already sent one asic to Sean. We just need to wait him to decap and make the pictures out of it :D
Title: Re: Gate array decapped!
Post by: ||C|-|E|| on 14:49, 19 April 16
Jesus, I forgot!  :picard: With the ASICs from the normal CPC I forgot the other one!  :D
Title: Re: Gate array decapped!
Post by: MaV on 14:52, 19 April 16
If he has problems decapping the one ASIC and we need another one, I'll be happy to contribute as well!
Title: Re: Gate array decapped!
Post by: robcfg on 14:53, 19 April 16
Thank you very much!


He described the asic as being... toasty, but hopes we can get good pictures out of it.
Title: Re: Gate array decapped!
Post by: ||C|-|E|| on 15:11, 19 April 16
Let´s see, but yes, if more than one is needed here we are!  :D
Title: Re: Gate array decapped!
Post by: TotO on 15:40, 19 April 16
It is less expansive to buy a brand new GX4000 than an ASIC chip only...  :picard:
Sellers practice excessive prices... (they got them for around 10$ each)
Better to not buy to them, else the price will continue to grow!
Title: Re: Gate array decapped!
Post by: ||C|-|E|| on 16:31, 19 April 16
That is certainly a good point as well, a second hand GX4000 is quite cheap, the problem is that you feel bad for it unless you know that it is already broken but with the ASIC still fine  :)
Title: Re: Gate array decapped!
Post by: dragon on 19:39, 19 April 16
Ohh,i found another mystery.

In the 464 service manual the ferranti ic 125 is called "40008" ¿?¿?¿?
In the 6128 with the two gate array options the thosiba chip  in ic 125 is called "40008/A" But it not have the same function logic of the ferranti ic.

An then i found this  strage book about 80 computers called" "Electronic Dreams: How 1980s Britain Learned to Love the Computer"

it speak about amstrad a few pages, and it offers a different point of view about amstrad ferranti history.

Normally in the books it say. The problem with the ferranti are the pads are not connected to the ic, book this book tell in perry words. The amstrad team visited ferranti factory.The put the chip, and they discover it not work. And the problems was the onboard crystall oscilator won't oscillate, so it search and found a second source in italy instead of wait the fix from ferranti (the sgs aa37 italy)?

Maybe the 40008 have the fix from ferranti ?.


Title: Re: Gate array decapped!
Post by: gerald on 20:19, 19 April 16
Quote from: dragon on 19:39, 19 April 16
Ohh,i found another mystery.

In the 464 service manual the ferranti ic 125 is called "40008" ¿?¿?¿?
In the 6128 with the two gate array options the thosiba chip  in ic 125 is called "40008/A" But it not have the same function logic of the ferranti ic.
These are just Amstrad part number that repair services have to use to get part from Amstrad.
Amstrad put these number on they own designed part, but the the 40008 is just a 'standard' 4xNAND ic.
Title: Re: Gate array decapped!
Post by: dragon on 12:18, 20 April 16
Well i can fail, jeje the history around gate array in the history books don't is very clear.

One question robcfg. Can be a posbility of decapped a 40010 aa37?.
Title: Re: Gate array decapped!
Post by: robcfg on 12:46, 20 April 16
Sure, we'll be sending another 40007 and a 40008 to Sean for decapping, so if you have have a 40010 AA37 we can send them together.
Title: Re: Gate array decapped!
Post by: TotO on 12:56, 20 April 16
Quote from: robcfg on 12:46, 20 April 16
Sure, we'll be sending another 40007 and a 40008 to Sean for decapping, so if you have have a 40010 AA37 we can send them together.
I have some differents 40010... May be the AA37 too.
Title: Re: Gate array decapped!
Post by: dragon on 13:25, 20 April 16
Quote from: robcfg on 12:46, 20 April 16
Sure, we'll be sending another 40007 and a 40008 to Sean for decapping, so if you have have a 40010 AA37 we can send them together.

Oh i not have it. My 6128  is a pre-asic, 1 464 have 40010 36aa (the board is in the the wiki), and the other have one with heatshink so probably is a 40007.

I search it in the web to buy one but all appears be 36aa :(.
Title: Re: Gate array decapped!
Post by: TotO on 13:28, 20 April 16
Don't search to buy... I should have one. (or buy it to me!  :laugh: )
Title: Re: Gate array decapped!
Post by: dragon on 13:47, 20 April 16
Mmm, is a rare chip, this is my offer:

(http://historiasdelahistoria.com/wordpress-2.3.1-ES-0.1-FULL/wp-content/uploads/2012/02/100-trillion-dolars.jpg)

8)

Anyway can you mount it and try the grimware test first? is the last voluntair of the ic in her testament after we sacrafice it to the vulcan.
Title: Re: Gate array decapped!
Post by: Higgy on 12:27, 21 April 16
Hi guys,

I have a 40010 18509 37AA 'Made in Italy' which is dead. Is it of any use for this?  (this was in a 6128)

I would get the 'white screen & black borders' and the screen would continuously scroll/flicker upwards (or was it downwards).
Anyway I tried swapping CPU, PAL and then swapped the 40010 to a known working 36AA and then it worked  ;D   Just waiting for a replacement now. 174193
Title: Re: Gate array decapped!
Post by: dragon on 13:29, 21 April 16
Yes, is the teorically hsg3170 gate array. aa37 always are made in italy, and the part number begins with 18.aa36(the decapped) not have italy mark(as if it is made in other site) and part number begins with more far upper number.

What motherboard version you have in the 6128 the first release?.For stadistics.

Title: Re: Gate array decapped!
Post by: robcfg on 14:12, 21 April 16
Hi @Higgy (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1486) !


Even if it's broken it may serve its purpose of being decapped and pictured. So it would be nice if you could send it to me to be included in the next batch.


Please, send me a PM so we can work the details.


Cheers,
Rob
Title: Re: Gate array decapped!
Post by: Higgy on 17:56, 21 April 16
@dragon (http://www.cpcwiki.eu/forum/index.php?action=profile;u=251) - hopefully this pic works.

Part no. Z70210

[attach=2]
Title: Re: Gate array decapped!
Post by: dragon on 21:39, 21 April 16
Sounds like its the first motherboard MC0009A  so at the momet only this board and cpc 664 mount these gate array type.
Title: Re: Gate array decapped!
Post by: Higgy on 22:50, 21 April 16
From my picture the letter is hidden but looks like an A. When I open her up again for the 40010 replacement I will check.

The other motherboard is a MC0020C
Title: Re: Gate array decapped!
Post by: MacDeath on 01:01, 22 April 16
Quote from: dragon on 13:47, 20 April 16
Mmm, is a rare chip, this is my offer:

(http://historiasdelahistoria.com/wordpress-2.3.1-ES-0.1-FULL/wp-content/uploads/2012/02/100-trillion-dolars.jpg)

8)

Anyway can you mount it and try the grimware test first? is the last voluntair of the ic in her testament after we sacrafice it to the vulcan.
this was just your three cents...
Title: Re: Gate array decapped!
Post by: dragon on 01:23, 22 April 16
Really  is not in circulation from varius years ago is a colecionist billete because are the most bigger number expedited in the world.

So it cost used around the price of the ebay  40008 and uncirculated can cost the doble. :). It have a curius history.

I never view one phisically. But is the bigger number in the world, tecnically you can say you are multimillonary a very low cost. Alan sugar style.
Title: Re: Gate array decapped!
Post by: seanb on 10:58, 22 April 16
I bought a gold version of that note of ebay for a friend as a joke once.
Title: Re: Gate array decapped!
Post by: robcfg on 12:03, 25 April 16
Hi guys!


I just uploaded a new picture to the Gate Array page. It's the 40010 GA with the metal layer removed.


Sean also sent me a 16000x16000 picture of the 40010 metal layer, but it's way too big for the wiki...  ;D


If anyone is interested (maybe @gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) ) send me a PM for the link.


Cheers,
Rob
Title: Re: Gate array decapped!
Post by: dragon on 13:21, 25 April 16
I understand now why the s(from sgs) are lost in the musseum  picture, it lost when metal layer are removed.

If picture is bigger too the wiki, simply upload it to mega, and put the link in the wiki.More easy.

Title: Re: Gate array decapped!
Post by: ||C|-|E|| on 16:08, 25 April 16
I was checking the high res pictures now and they are really a beauty  :o They look like a huge carpet  :laugh:
Title: Re: Gate array decapped!
Post by: TFM on 16:10, 25 April 16
Quote from: gerald on 14:03, 16 April 16
A good picture is better than thousand words :
Here is a inverter, implemented in the gate array. This is the 1st one on the 16MHz input clock path
[attach=2]
The metal on the left of the output is the input going somewhere else.


So this is where Tron lives?

Title: Re: Gate array decapped!
Post by: robcfg on 16:53, 25 April 16
Heh...


I remember as kid watching the movie and then typing "TRON" on my CPC. I got quite shocked that it worked, hehe  :D
Title: Re: Gate array decapped!
Post by: TotO on 22:34, 28 April 16
I have only one 40010 37AA (Made in Italy) chip.  :-\
Title: Re: Gate array decapped!
Post by: Higgy on 07:50, 29 April 16
I will be posting a 37AA to Rob  ;D 108
Title: Re: Gate array decapped!
Post by: dragon on 12:23, 29 April 16
Quote from: TotO on 22:34, 28 April 16
I have only one 40010 37AA (Made in Italy) chip.  :-\

Its a strange species, in extintiction with the 40008.
Title: Re: Gate array decapped!
Post by: robcfg on 11:38, 04 May 16
Hello everyone!


Sean sent me a first picture of the 40489 ASIC (https://www.dropbox.com/s/20qkelnr0im21wn/amstrad3_metal.jpg?dl=0). It's not useful for getting anything out of it, but it's a first step  8)


The whole thing is covered by a brown plastic layer that Sean hopes will get away with nitric acid.


This one took 576 pictures...  :o


He will be taking 20x pictures soon.
Title: Re: Gate array decapped!
Post by: dragon on 11:55, 04 May 16
Thanks robcfg, so the  black hole are plastic?.

The chip appears divided in some parts, i think one of the type zones can be the asic ram. I not sure if it is a gate array or a asic. Anyway it not appear to have  name constructor on it

In service manual have note it have 10000 logic gates. Is 10x more that the gate array.

In the other hand can be more zoom in the future to the preasic too?.
Title: Re: Gate array decapped!
Post by: robcfg on 12:01, 04 May 16
Actually, the plastic is the brown square that cover almost everything.


Also, yes, several parts can be seen. I bet that the 16 identical areas are the sprites' ram.


Sean told me he'll be taking higher resolution pictures, but keep in mind that he has to take thousands of pictures, and then compose them together so be patient  ;)
Title: Re: Gate array decapped!
Post by: dragon on 12:15, 04 May 16
O.k robcfg, i think tha name chip is in a corner, but is to little to see it. With lucky we can view it at 16x later :) . Or simply tell sean take note of the code.

The chip appeared very well structurated.Steve gane made a good job.k

as you say, the chip have 16 squares 8 in upper and 8 in down part.+ 1 extra maybe to control it 1square=1sprite?

Or best, the two extra squares are connected to  the outside directly. Maybe is another thing as the dma sound part or so.

ah, i don't see it in the movil XD, but i can view it in pc the ic code is "c838002"
Title: Re: Gate array decapped!
Post by: gerald on 18:09, 04 May 16
Quote from: robcfg on 11:38, 04 May 16
Hello everyone!


Sean sent me a first picture of the 40489 ASIC (https://www.dropbox.com/s/20qkelnr0im21wn/amstrad3_metal.jpg?dl=0). It's not useful for getting anything out of it, but it's a first step  8)


The whole thing is covered by a brown plastic layer that Sean hopes will get away with nitric acid.


This one took 576 pictures...  :o


He will be taking 20x pictures soon.
Higher resolution is definitively needed if we want to get something out of it  ;)
Title: Re: Gate array decapped!
Post by: TFM on 19:19, 04 May 16
Quote from: robcfg on 11:38, 04 May 16
Sean sent me a first picture of the 40489 ASIC (https://www.dropbox.com/s/20qkelnr0im21wn/amstrad3_metal.jpg?dl=0). It's not useful for getting anything out of it, but it's a first step  8)


One can clearly see the sprite RAM, tooks lots of space...
Title: Re: Gate array decapped!
Post by: dragon on 20:15, 04 May 16
who is using more space for 8 sprites commodore ic or amstrad?.

Commodore 8565 VIC-II (http://visual6502.org/images/pages/Commodore_8565_die_shots.html)


Title: Re: Gate array decapped!
Post by: arnoldemu on 20:37, 04 May 16
Quote from: dragon on 20:15, 04 May 16
who is using more space for 8 sprites commodore ic or amstrad?.

Commodore 8565 VIC-II (http://visual6502.org/images/pages/Commodore_8565_die_shots.html)
commodore reads sprites from ram so no sprite data on the ic.

asic has sprites on the ic. So amstrad uses much more!
Title: Re: Gate array decapped!
Post by: TFM on 21:52, 04 May 16
So for the ASIC II...
- 256 sprite colors instead of 16
- 32 sprites instead of 16


Just in case there will be a 7128 Plus or something like that.  ;)
Title: Re: Gate array decapped!
Post by: dragon on 23:41, 04 May 16
I think i more probable a gate array plus.

Because the gate array is in soket so is cuestion of swap. In the rest you need unsolder/solder...

You can made a gate array with plus features.
Title: Re: Gate array decapped!
Post by: ||C|-|E|| on 11:00, 05 May 16
The Plus ASIC looks really pretty and well organized. I must confess that I was not expecting something like that, so simmetric. Actually, I was almost sure that it would be a much less organized design, where you could clearly see the CPU in a corner, some memory somewhere else, a section for the Plus features... much more like the PS4 APU .
Title: Re: Gate array decapped!
Post by: robcfg on 11:45, 05 May 16
I'd like to thank @Higgy (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1486) because the 37AA 40010 chip just arrived and will be on the next batch for decapping.


It will be nice to see if they have any difference.


So, thank you very much!  8)
Title: Re: Gate array decapped!
Post by: Higgy on 14:51, 05 May 16
No problem. Glad the timing worked out and I saw it would be useful. Otherwise it would have probably ended up in the bin  :doh:

Retro communities are a nice friendly bunch  so if I can help I like to.
It is also fun reading and learning about new systems. Next job is to add a reset switch and remove my Type 2 CRTC  :o
Title: Re: Gate array decapped!
Post by: arnoldemu on 09:10, 06 May 16
Quote from: Higgy on 14:51, 05 May 16
No problem. Glad the timing worked out and I saw it would be useful. Otherwise it would have probably ended up in the bin  :doh:

Retro communities are a nice friendly bunch  so if I can help I like to.
It is also fun reading and learning about new systems. Next job is to add a reset switch and remove my Type 2 CRTC  :o
send the type 2 for decapping! :)
Title: Re: Gate array decapped!
Post by: dragon on 11:33, 06 May 16
Quote from: arnoldemu link=topic=11888.msg125934#msg125934 dcpce=1462522241
send the type 2 for decapping! :)

I quote you to read you

(Expansion quote you know lol).

I can donate a broken cartridge board with a broken acid, it dies time ago in the process of transform it to a socket cartridge when c4cpc not exist. Probably it burn lol.Anyway the board have damaged too.

What other  chips have unkown die . pcw and  last spectrum anstrad made?. I think the autor of zx spectrum book not decapped it, it stop in amstrad.
Title: Re: Gate array decapped!
Post by: Munchausen on 20:18, 06 May 16
Quote from: ||C|-|E|| on 11:00, 05 May 16
The Plus ASIC looks really pretty and well organized. I must confess that I was not expecting something like that, so simmetric. Actually, I was almost sure that it would be a much less organized design, where you could clearly see the CPU in a corner, some memory somewhere else, a section for the Plus features... much more like the PS4 APU .

The CPU and RAM are actually still separate with the ASIC. I didn't actually realise that the sprite RAM was on board, I'd guess that might have been quite expensive. I wonder if that was just the cheapest way to do it while maintaining backwards compatibility (not changing the CPU timing by further RAM accesses from the "gate array", and not needing extra external RAM).

The developments in this thread are very exciting, it's always the first thread I check back to at the moment!
Title: Re: Gate array decapped!
Post by: TotO on 20:43, 06 May 16
Is really useful to send CRTC for decaping?
They are not CPC special circuits.
Title: Re: Gate array decapped!
Post by: ||C|-|E|| on 21:43, 06 May 16
Quote from: Munchausen on 20:18, 06 May 16
The CPU and RAM are actually still separate with the ASIC. I didn't actually realise that the sprite RAM was on board, I'd guess that might have been quite expensive. I wonder if that was just the cheapest way to do it while maintaining backwards compatibility (not changing the CPU timing by further RAM accesses from the "gate array", and not needing extra external RAM).

The developments in this thread are very exciting, it's always the first thread I check back to at the moment!

Thank you! I knew that the RAM and the Z80 were outside, but I was still expecting to see something like a "general" CPU inside among the other chips, stupid of me  :-\
Title: Re: Gate array decapped!
Post by: dragon on 22:54, 06 May 16
I read in the google groups time ago, the dma in asic is a little processor from people of amstrad. Thats because i tell if the two big square in the left near the other 8 sprites are the dma sound.

So maybe is true the asic have a cpu in some form :).
Title: Re: Gate array decapped!
Post by: gerald on 08:38, 07 May 16
Quote from: TotO on 20:43, 06 May 16
Is really useful to send CRTC for decaping?
They are not CPC special circuits.
Not CPC specific, but different behaviour of different version when used on CPC.
Could still be interesting to have all type reverse engineered at some point.
Title: Re: Gate array decapped!
Post by: TotO on 12:03, 07 May 16
Sure, while the guy is OK to do it for all the IC sent.  :)
Title: Re: Gate array decapped!
Post by: dragon on 12:24, 07 May 16
Fortunly we live in a epoque when you can made 500 pictures at not cost.


Inagine decapped the asic in the 80 with analogue photography.


Hi man of kodak shop i need send to reveal 500 pictures of a chip lol. (A dolar apear in eyes of man).
Title: Re: Gate array decapped!
Post by: Munchausen on 14:38, 07 May 16
Quote from: ||C|-|E|| on 21:43, 06 May 16
Thank you! I knew that the RAM and the Z80 were outside, but I was still expecting to see something like a "general" CPU inside among the other chips, stupid of me  :-\

Actually you may be right, it does have to do something like decode register -> do something, with RAM access etc too, so it may somewhat resemble a CPU.
Title: Re: Gate array decapped!
Post by: dragon on 19:26, 14 July 16
Just for curiosity any news obtaining the 40010 schematic or the other ics?
Title: Re: Gate array decapped!
Post by: robcfg on 11:04, 13 September 16

Hi guys!


I uploaded the 40010, PreASIC and ASIC 20x pictures to Mega.


The 40010 pictures are jpg and the 40226 and 40489 are in deep zoom format as they are otherwise unmanageable.


I included the OpenSeaDragon deep zoom viewer and created convenient html files. For viewing them from your disk, I recommend FireFox as Chrome is too picky with the data origin.


40010 Metal Layer: https://mega.nz/#!hkEwxLjA!ACfSH1p6Cp7QkbkdcA3NmPPB_bIdtaSz2TQdBmCt5ss (https://mega.nz/#!hkEwxLjA!ACfSH1p6Cp7QkbkdcA3NmPPB_bIdtaSz2TQdBmCt5ss)
40010 Metal Layer Removed: https://mega.nz/#!E0ljlKoK!nErCPUcuzMt8smAj_NWjx8wJmrIyL67qqdxx5Dz1eBQ (https://mega.nz/#!E0ljlKoK!nErCPUcuzMt8smAj_NWjx8wJmrIyL67qqdxx5Dz1eBQ)
40226 and 40489 Deep Zoom Images: https://mega.nz/#!o0dE1ATL!5eHANmjOS-aTHR2tiN0hLZw0AGeLvInTIcca-IooZJQ (https://mega.nz/#!o0dE1ATL!5eHANmjOS-aTHR2tiN0hLZw0AGeLvInTIcca-IooZJQ)


@Gryzor (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1) : I sent you an email a while ago, but seems to have been lost in the tides of time. Would it be possible to upload the Deep Zoom Images and the viewer to the wiki?If it's possible, I'd like to put proper credits first to the html files but you can try with the files I uploaded.

Quote from: dragon on 19:26, 14 July 16
Just for curiosity any news obtaining the 40010 schematic or the other ics?


@gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) was working on it. No easy task, so please be patient  ;)
Title: Re: Gate array decapped!
Post by: Gryzor on 12:32, 13 September 16
Hey mate,


I don't seem to have that email, this is the first time I hear about Deep Zoom :D But... are we talking about the 1.4GB file? I think it's a bit too much, though if enough people are interested I'll upload it to the server; not through the wiki though.
Title: Re: Gate array decapped!
Post by: gerald on 16:54, 13 September 16
Quote from: robcfg on 11:04, 13 September 16
@gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) was working on it. No easy task, so please be patient  ;)
Most of the job is done. I just need to check it against real HW.
Preliminary schematic attached.
I have VHDL code ongoing, but in standby for the last 2 weeks.
Title: Re: Gate array decapped!
Post by: Duke on 17:35, 13 September 16
Impressive work @gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) . And thanks @robcfg (http://www.cpcwiki.eu/forum/index.php?action=profile;u=4) for the images.
Title: Re: Gate array decapped!
Post by: Arnaud on 17:53, 13 September 16
Quote from: gerald on 16:54, 13 September 16
Most of the job is done. I just need to check it against real HW.
Preliminary schematic attached.
I have VHDL code ongoing, but in standby for the last 2 weeks.

You can directly translate the electronic shematic in VHDL ?
It's rather different from FPGAmstrad which is an adaptation of java emulation with Javacpc or it's finally the same "code" ?

Title: Re: Gate array decapped!
Post by: gerald on 18:12, 13 September 16
Quote from: Arnaud on 17:53, 13 September 16
You can directly translate the electronic shematic in VHDL ?
Reverse engineering have been done with degate. While it is supposed to generate a vhdl model of the 'extracted' design, it is rather buggy and did not let me add proper hierarchy to the design, which makes it unreadable. It has also some other bugs that make me use the old paper and pencil method.
With the paper schematics, I did the pdf one in Kicad, simplifying most of the equation to make them more human readable. The original design is optimised by using polarity optimisation wherever it's possible. This help reducing the number of transistors but make comprehension difficult.

Quote from: Arnaud on 17:53, 13 September 16
It's rather different from FPGAmstrad which is an adaptation of java emulation with Javacpc or it's finally the same "code" ?
Chances are quite low that the code is the same  ;)
The 40010 uses a lot of asynchonous tricks and these may have been implemented as synchronous logic.
Title: Re: Gate array decapped!
Post by: dragon on 20:14, 13 September 16
Quote from: gerald on 18:12, 13 September 16
Reverse engineering have been done with degate. While it is supposed to generate a vhdl model of the 'extracted' design, it is rather buggy and did not let me add proper hierarchy to the design, which makes it unreadable. It has also some other bugs that make me use the old paper and pencil method.
With the paper schematics, I did the pdf one in Kicad, simplifying most of the equation to make them more human readable. The original design is optimised by using polarity optimisation wherever it's possible. This help reducing the number of transistors but make comprehension difficult.
Chances are quite low that the code is the same  ;)
The 40010 uses a lot of asynchonous tricks and these may have been implemented as synchronous logic.

You are a genius hardware guy gerald. Gate array was designed with paper and pencil method, and was reverse enginered with pencil and paper method. :).

Do you have thinking about made a gate array plus?. Compatible but with posibility of more colours in all modes.
Title: Re: Gate array decapped!
Post by: TotO on 21:21, 13 September 16
I personally expect to be able to restore the Gate Array's 64 colours original palette.
About displaying more colours per pixel, it is related to the CRTC frequency...
Title: Re: Gate array decapped!
Post by: PulkoMandy on 08:05, 14 September 16

"Restoring" the 64 colors is a matter of copy-paste (mostly in "ink registers" and "color mux" parts of the schematics, the 6th bit was removed there to save space I guess) and then finding a way to output them (we'll need 3 extra pins).More colors in all modes would be possible but tricky. There are two solutions inspired by the Thomson hardware. The first is to use 16-bit memoryt accesses, for example, 8 bit from main memory, and 8 bits from banked memory. This would not need this many changes to the Gate Array, but a major rework of the motherboard (and again, probably a chip with some extra pins). The other option is to use RAM which can perform multiple accesses in the same page very fast, as it was done in the Thomson TO8. And of course there's always the option of running everything at 8MHz to avoid all these changes.
Title: Re: Gate array decapped!
Post by: TotO on 08:15, 14 September 16
Quote from: PulkoMandy on 08:05, 14 September 16
"Restoring" the 64 colors is a matter of copy-paste (mostly in "ink registers" and "color mux" parts of the schematics, the 6th bit was removed there to save space I guess) and then finding a way to output them (we'll need 3 extra pins).
I have looked the schematics done by gerald yesterday evening. Yes, that will require this sort or work to be acheived. About the 3 extra pins, it is not really a problem as you can implement the 6-bit RGB DAC using resistors into the Gate Array's PCB replacement. So, the pins going to the socket doesn't change.

Title: Re: Gate array decapped!
Post by: dragon on 09:43, 14 September 16
So,probably in the Plus range they make copy paste to 12bits. :).

If more colours to Mode 0 1 and 2 is posible the best is the  method take less modificación in the motherboard.
Title: Re: Gate array decapped!
Post by: robcfg on 09:51, 14 September 16
More colors means more memory and more time needed to draw a frame.


For an adventure game it may not be a problem, but for any action game it's not going to work good.


Another thing would be to oveclock the machine...
Title: Re: Gate array decapped!
Post by: TotO on 09:53, 14 September 16
You may display more coulours w/o wasting the display or the memory by using attributes.
Title: Re: Gate array decapped!
Post by: Gryzor on 09:57, 14 September 16
Quote from: TotO on 21:21, 13 September 16
I personally expect to be able to restore the Gate Array's 64 colours original palette.


Wait - what?   
Title: Re: Gate array decapped!
Post by: pelrun on 10:00, 14 September 16
WOW. This is a truly amazing piece of work, and probably the most exciting bit of base-CPC hardware documentation news in years.
Title: Re: Gate array decapped!
Post by: robcfg on 10:03, 14 September 16
Quote from: TotO on 09:53, 14 September 16
You may display more coulours w/o wasting the display or the memory by using attributes.


You mean like the Spectrum?  ;D
Title: Re: Gate array decapped!
Post by: TotO on 10:07, 14 September 16
I just said that is a way to do...  ;D


Quote from: Gryzor on 09:57, 14 September 16Wait - what?

The INKR allow to set 6bit for the palette but only 5bit are used. By extending that, you come with a 64 colours RGB palette.
Title: Re: Gate array decapped!
Post by: Ast on 10:50, 14 September 16
Quote from: TotO on 10:07, 14 September 16
I just said that is a way to do...  ;D



The INKR allow to set 6bit for the palette but only 5bit are used. By extending that, you come with a 64 colours RGB palette.

Would it be able to to that workable ?
Title: Re: Gate array decapped!
Post by: TotO on 10:52, 14 September 16
I hope... The Aleste 520 and KC Compact does that if I'm not wrong.  ;D
Title: Re: Gate array decapped!
Post by: robcfg on 11:03, 14 September 16
I was wrong on the memory requirement, as it's no new graphic mode, you have only more colours to choose from.
Title: Re: Gate array decapped!
Post by: dragon on 11:05, 14 September 16
I don't remember now if this is finally solved early sorry.

Whith the schematic finished finally what is the cause of this in 40010/b?.

(http://www.grimware.org/lib/exe/fetch.php/documentations/devices/gatearray.pal/gatearray.rasterization.timings.screenshot.png)
Title: Re: Gate array decapped!
Post by: andycadley on 11:51, 14 September 16
Quote from: TotO on 10:07, 14 September 16
I just said that is a way to do...  ;D



The INKR allow to set 6bit for the palette but only 5bit are used. By extending that, you come with a 64 colours RGB palette.


It's actually something of a misnomer. The CPC was originally designed with 16 colours (using 4 bits) but later in the design it was spotted that a little hardware hackery and two extra bits to help control colour intensity could bump that up to 27 colours for very little additional cost. From a purely "digital" standpoint, it seems weird because 6-bit colour settings should give you as much as 64 colours but from a more analogue perspective the design makes sense. It's also why the "hardware colours" seem to contain a lot of duplicates.

Now you theoretically could build new hardware to "fill in the blanks" (i.e. replace some of those duplicate colours with something else) and produce a palette of 64 colours instead of 27, but the chances are fairly high that you'll get weirdness in some software which is using a different (but perfectly workable) hardware colour to get the same output as it'll suddenly start using some random other colour.

A better way of extending the palette is to forego the 6 bit colour selection method entirely, using it only as a shorthand way of changing real RGB colour registers. Which, unsurprisingly enough, is how Amstrad chose to do it on the Plus machines. The only real downside being that if you use more than 8 bit RGB values (such as the Plus 12 bit registers) you run into the problem that a Z80 can't make atomic colour changes.
Title: Re: Gate array decapped!
Post by: TotO on 12:02, 14 September 16
With only 1R, 1G, 1B, a "suposed" design without hi-Z can only produre 8 coulours (CGA). I have never read about a 16 coulours palette CPC based.
The INKR register is fully used on Alest 520 and KC Compact to handle a nice 64 coulours palette (EGA) w/o compatibility problem... Why ?
Because the hardware palette is not the software palette. The colours are remapped to match with the existing. (and I will use it)

If more coulours are required, yes you can do many things to improve that (as Pulko said)... Here is just an existing way to do.  :)
But... When you can't display more than 2/4/16 at once, a big palette is not really an advantage.
Title: Re: Gate array decapped!
Post by: arnoldemu on 13:16, 14 September 16
Quote from: TotO on 12:02, 14 September 16
...
The INKR register is fully used on Alest 520 and KC Compact to handle a nice 64 coulours palette (EGA) w/o compatibility problem... Why ?
Because the hardware palette is not the software palette. The colours are remapped to match with the existing. (and I will use it)
...
On KC Compact it has the potential for 64 colours. However, the EPROM (D09) translates it to 27 colours.
Replacing the EPROM should in theory (not tested) allow 64 colours to be used.

The Aleste can do 64 colours. it has a "msx mode" and a "cpc mode" which boils down to "MAPMOD" being 1 or 0.
Again an EPROM is used (D62) which gives differing values depending on mapmod and so enables 27 or 64 colour mode. The ROM could be modified to output 64 colours in CPC mode too.

Title: Re: Gate array decapped!
Post by: TotO on 14:35, 14 September 16
Sure, the EPROM act as a look-up table to set the good software palette.
But... What about directly using the KC Compact hardware palette ? Can you access the 64 colours?
Title: Re: Gate array decapped!
Post by: arnoldemu on 20:06, 14 September 16
Quote from: TotO on 14:35, 14 September 16
Sure, the EPROM act as a look-up table to set the good software palette.
But... What about directly using the KC Compact hardware palette ? Can you access the 64 colours?
No. You would need to modify the ROM or the PCB to do that.
Title: Re: Gate array decapped!
Post by: TotO on 20:18, 14 September 16
OK.  8)
Title: Re: Gate array decapped!
Post by: TotO on 20:25, 17 September 16
Thanks to gerald for his amazing work... I have started to redo the GA "core" into a CPLD using the schematic method.
The idea is to make working all things that are not related to the display. To confirm his work, I hope to be able to ring the bell!  ;D
Title: Re: Gate array decapped!
Post by: ||C|-|E|| on 20:54, 17 September 16
I really have no time for anything until the end of the next week, but I just wanted to pop in an say that this is and amazing collaborative work guys!!  :-* :-*
Title: Re: Gate array decapped!
Post by: Executioner on 08:36, 18 September 16
Quote from: Arnaud on 17:53, 13 September 16
It's rather different from FPGAmstrad which is an adaptation of java emulation with Javacpc or it's finally the same "code" ?

Probably not, JEMU/JavaCPC, like most other emulators, doesn't use GA shift registers and a 16 MHz pixel clock (although it probably should to be totally accurate :) )
Title: Re: Gate array decapped!
Post by: DaDMaN on 21:38, 19 September 16
Hi! One guy Ash Evans has coded a 40010 Verilog implementation based on @gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) PDF. I've been talking this afternoon with Ash about this project and this is the results.

Here is the source code:
[VeriLog] // // Amstrad CPC 40010 Gate Array implementation in Verilog. // // (http://pastebin.com/ZQyL68Hv)

:D
Title: Re: Gate array decapped!
Post by: dragon on 21:55, 19 September 16
One cuestión is posible create a pre-sic  fpga replacement?. Knowing the other sources as crtc have verilog implementación.
Title: Re: Gate array decapped!
Post by: robcfg on 06:35, 20 September 16
It should be possible but you'll have to extract the gates and connections from the picture first (which is a huge job) and then create a vhdl or similar model.

You'd have also the problem of soldering the replacement on the board, as the preAsic has a lot of tiny pins and the replacement chip would be probably bigger.
Title: Re: Gate array decapped!
Post by: PulkoMandy on 08:47, 20 September 16
The main problems you will have with an FPGA:
- It is hard to find parts with 5V supply or even 5V-tolerant I/Os. You can't easily use a 3.3V part.
- An FPGA is volatile (like RAM), so it needs something to load code on it. Some FPGAs have a bootstrap system and they can load code from an external serial ROM.


FPGA is not "magic chip that can replace everything".


You will have better chances with fitting the gate array implementation in a CPLD (which is more like EEPROM), if you can find one large enough to fit everything.
Title: Re: Gate array decapped!
Post by: dragon on 09:19, 20 September 16
Quote from: robcfg on 06:35, 20 September 16
It should be possible but you'll have to extract the gates and connections from the picture first (which is a huge job) and then create a vhdl or similar model.

You'd have also the problem of soldering the replacement on the board, as the preAsic has a lot of tiny pins and the replacement chip would be probably bigger.

I not speaking about made a clone Gate by Gate of the pre-asic. If not made a own alternative  implementación of the  pre-asic  to salve the cpc dead.

Gate array in pre-asic. Have a diferent memory controller to the New ram managent. But the computer not used these  ram from factory uses the older.

So if we have a vhdl of the Gate array and we have a vhdl of the 6845 crtc. And vhdl of pal.  I speaking about only connet the three implementations between It internally  into a cpld/fpga pin compatible or to board adapter compatible.

Arnold 6 or So.


But yeah. Solder It should be a nightmare  :)
Title: Re: Gate array decapped!
Post by: gerald on 12:10, 20 September 16
Quote from: PulkoMandy on 08:47, 20 September 16
The main problems you will have with an FPGA:
- It is hard to find parts with 5V supply or even 5V-tolerant I/Os. You can't easily use a 3.3V part.
- An FPGA is volatile (like RAM), so it needs something to load code on it. Some FPGAs have a bootstrap system and they can load code from an external serial ROM.


FPGA is not "magic chip that can replace everything".


You will have better chances with fitting the gate array implementation in a CPLD (which is more like EEPROM), if you can find one large enough to fit everything.
You will also have hard time tring to solder your replacement FPGA board to the 100 fine pitch footprint on the PCB. Not impossible, but a lot of trouble ahead.

Regarding CPLD,  you will have to go for the biggest. The GA does not fit a XC95144XL as it require 166DFF/Latch + glue.
It would fit the XC95288XL which is the large CPLD xilinx offer with 5V tolerant IO.

BTW, CPLD (at least xilinx ones) also need to be initialized at power up, but the configuration is stored internally and init done automatically. Bigger is the PLD, longer is the init phase.
Title: Re: Gate array decapped!
Post by: Bryce on 13:25, 20 September 16
So you'd have to modify the CPCs reset circuitry to allow for the long init time?

Regarding the soldering. It might be easiest to solder a 100pin PLCC socket to the PCB and then make a PLD solution that can plug into this?

Bryce.
Title: Re: Gate array decapped!
Post by: gerald on 17:50, 20 September 16
Quote from: Bryce on 13:25, 20 September 16
So you'd have to modify the CPCs reset circuitry to allow for the long init time?
May be. On early 464, the reset is short enough to prevent sampling of IO on rising edge of reset signal in my ram/flash:CF extension.
That is, the reset is released before the PLD is configured.
That's not happing on later CPC models.
That's how I discovered that init time.

Quote from: Bryce on 13:25, 20 September 16
Regarding the soldering. It might be easiest to solder a 100pin PLCC socket to the PCB and then make a PLD solution that can plug into this?
The pre-asic package is quite exotic to today standard. I doubt it's easy to find a socket, and custom ones cost an arm.
Title: Re: Gate array decapped!
Post by: freemac on 20:39, 20 September 16
Quote from: Executioner on 08:36, 18 September 16
Probably not, JEMU/JavaCPC, like most other emulators, doesn't use GA shift registers and a 16 MHz pixel clock (although it probably should to be totally accurate :) )
It's the same. FPGA is a reprogrammable CPLD. GateArray is a CPLD.
I'm currently experimenting some vhdl testbench extract from JavaCPC in order to compare vhdl (or verilog) gatearray each other.

Ok, let's catch them all : FPGA-GA - CPCWiki (http://cpcwiki.eu/index.php/FPGA-GA) (entry list)  ;)

If you succeed extracting original GateArray vhdl/verilog, you can poke me :)

Extracting CRTC1 shall interest me (CRTC0 also, but it is really too hard to implement in small FPGA yet)
Title: Re: Gate array decapped!
Post by: freemac on 20:44, 20 September 16
Quote from: PulkoMandy on 08:47, 20 September 16
The main problems you will have with an FPGA:
- It is hard to find parts with 5V supply or even 5V-tolerant I/Os. You can't easily use a 3.3V part.
- An FPGA is volatile (like RAM), so it needs something to load code on it. Some FPGAs have a bootstrap system and they can load code from an external serial ROM.


FPGA is not "magic chip that can replace everything".


You will have better chances with fitting the gate array implementation in a CPLD (which is more like EEPROM), if you can find one large enough to fit everything.
Old components are 5V but they speaks each others at 3.3V in fact :D

FPGAmstrad - CPCWiki (http://www.cpcwiki.eu/index.php/FPGAmstrad#Test_of_a_real_Zilog_80) Test of a real Zilog 80
Title: Re: Gate array decapped!
Post by: Bryce on 08:26, 21 September 16
Quote from: gerald on 17:50, 20 September 16
The pre-asic package is quite exotic to today standard. I doubt it's easy to find a socket, and custom ones cost an arm.

Oh yeah, I forgot that. It's one of those rectangular ones isn't it? Not square. Pain in the arse.

Bryce.
Title: Re: Gate array decapped!
Post by: dragon on 12:10, 21 September 16
Quote from: Bryce on 08:26, 21 September 16
Oh yeah, I forgot that. It's one of those rectangular ones isn't it? Not square. Pain in the arse.

Bryce.

Is a 30x20 pin. But i unkown the inch of the pads.

Maybe is a qpf(100p6p-e)?.

http://www.ebay.com/p/software-survo-microcomputers-vcr-7770-series-gemstar-m37777m7a253gp-30x20-qfp/1857944337

http://www.glyn.de/data/glyn/media/doc/100s_u.pdf


Adapter to dip : p

http://vi.raptor.ebaydesc.com/ws/eBayISAPI.dll?ViewItemDescV4&item=171251434317&category=36327&pm=1&ds=0&t=1474458097460#&panel1-3
Title: Re: Gate array decapped!
Post by: robcfg on 10:41, 18 October 16
More awesome news from decapping land!


Here you have the metal layer pictures of 40007 gate array (https://mega.nz/#!NgMQgDoL!Yn-4Reta-twO7D1KGC0FDo4syp2cwbWcxHwco64mYq8), 40008 gate array (https://mega.nz/#!01UxgK7B!ueyVlczNcMjYPAr1zYOrlbMyJfzCiKIK3dEBHL2bpzo) and the infamous ACID chip (https://mega.nz/#!Nl0E0JJI!8Sofxqhle-eDN5TIQh3VztZd-_SKo9MNDI7b4qu-QLc).
Title: Re: Gate array decapped!
Post by: Gryzor on 10:48, 18 October 16
Ok, question: who's got a source to make poster prints out of these beauties?
Title: Re: Gate array decapped!
Post by: robcfg on 10:50, 18 October 16
Indeed, they look beautiful.


My favourites are the 40010 and 40008, hehe  :D
Title: Re: Gate array decapped!
Post by: Bryce on 11:14, 18 October 16
Quote from: Gryzor on 10:48, 18 October 16
Ok, question: who's got a source to make poster prints out of these beauties?

I have a source that can even print these onto banner cloth, so you can hang it as curtains :D

Bryce.
Title: Re: Gate array decapped!
Post by: Gryzor on 11:18, 18 October 16
Eh... I don't think she'd go for it :D
Title: Re: Gate array decapped!
Post by: dragon on 11:24, 18 October 16
Quote from: Gryzor on 10:48, 18 October 16
Ok, question: who's got a source to make poster prints out of these beauties?


You can make a parasol(i unkown the english word) for car, then all pople can view it :)


Downloading...
Title: Re: Gate array decapped!
Post by: Gryzor on 11:32, 18 October 16
Ah you mean for the windshield, right? That's an idea! :D
Title: Re: Gate array decapped!
Post by: Bryce on 11:40, 18 October 16
I think he means a complete car cover: http://www.5starshine.com/images/coverking/carcoverbigenzo.jpg

Bryce.
Title: Re: Gate array decapped!
Post by: robcfg on 11:51, 18 October 16
Nope, but would be awesome indeed!  ;D


He refers to a windshield shade.
Title: Re: Gate array decapped!
Post by: dragon on 11:57, 18 October 16
Yeah some like these lateral, or frontal, or in the back:

Is very easy find sites do it :

http://www.getsingular.com/parasoles-coche-personalizados.html (http://www.getsingular.com/parasoles-coche-personalizados.html)

Title: Re: Gate array decapped!
Post by: dragon on 12:05, 18 October 16
So the 40010-A is the misterius reserved to the finish right? :).
Title: Re: Gate array decapped!
Post by: Bryce on 12:08, 18 October 16
Yeah, but get the Plus ASIC version printed, it has more colours :)

Bryce.
Title: Re: Gate array decapped!
Post by: dragon on 12:26, 18 October 16
One chip per window, the acid in front then you are more protected.

First open 40908 suprise surprise is a thosiba ic. Other gate array new to the family. time to investigate thosiba ics .Maybe the asic manufactuirer is thosiba.

In the 40007 my theory is correct is the ferranti ula 5000R series. If you take in the zx spectrum book the figure 5-24 :R series matrix cells (page  60).

The cells in the ic are exactly equal :)

The 40008 as my theory (yepahhh!!). Is another ferrenti ic chip from 5000r(same model ic?) or maybe 6000r series ula.

Pages 59-70 in zx spectrum book covers 40007 and 4008 strtucture :)
Title: Re: Gate array decapped!
Post by: robcfg on 12:34, 18 October 16
Quote from: dragon on 12:05, 18 October 16
So the 40010-A is the misterius reserved to the finish right? :) .


I have good news for you (https://mega.nz/#!txMRSAJZ!EeVmLFNuLglKwgo5T0T63x0whLQt6ExDQmjXqzdbFxE).  8)
Title: Re: Gate array decapped!
Post by: dragon on 12:54, 18 October 16
You can count the files x cell please , my pentium 4 is so slow with the picture is more bigger that the other?.
Title: Re: Gate array decapped!
Post by: robcfg on 13:53, 18 October 16
I'm astonished!


40010-36AA has 18 rows and 74 coumns (37 pairs), while 40010-37AA has 21 rows and 82 columns (41 pairs)...


Now, I don't know if @gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) will have the time (or the will) to check them for differences.


Another Amstrad fact learnt today  :D
Title: Re: Gate array decapped!
Post by: Bryce on 15:11, 18 October 16
Quote from: robcfg on 13:53, 18 October 16
I'm astonished!


40010-36AA has 18 rows and 74 coumns (37 pairs), while 40010-37AA has 21 rows and 82 columns (41 pairs)...


Now, I don't know if @gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) will have the time (or the will) to check them for differences.


Another Amstrad fact learnt today  :D

That doesn't necessarily mean that they function differently, it may just be a different die with the same mask.

Bryce.
Title: Re: Gate array decapped!
Post by: dragon on 15:23, 18 October 16
Quote from: Bryce on 15:11, 18 October 16
That doesn't necessarily mean that they function differently, it may just be a different die with the same mask.

Bryce.

But my theory was right. :) . And now the name in schematics pins compatibility have sense. And is a mystery anyway :)

The model should be in the gate array pdf i put time ago.

The other mistery is the 40007-40008, i think is the same ula. So amstrad made changes to the circuit  to eliminate the heat.

About the acid thosiba makes sense remember the joint  history of thosiba-lsi
Title: Re: Gate array decapped!
Post by: Bryce on 15:32, 18 October 16
Hot spots can occur if lots of fast switching transistors are physically close to each other on the die. To reduce this you spread them around the die by shifting functions from one area to another, but this can force you to re-assign the I/O pins. This can still even happen with modern CPLDs/FPGAs and it's a pain in the arse when you need to do it late in a program. Something like this was probably the reason for the pinout changes.

Bryce.
Title: Re: Gate array decapped!
Post by: 1024MAK on 16:12, 18 October 16
One problem with some ULA chips is that the gate propagation delay changes significantly as the chip temperature increases. This affects the higher speed sections of a design.

That's the problem that Acorn had with the ULA used as the Videoproc in the BBC Micro (hence why a heatsink was fitted to early ULA chips).

In the ZX Spectrum, the vertical lines on the display when inverting, or flashing the character cells is also a propagation delay issue.

Most ULA chips from Ferranti have logic that operates at a lower voltage than the supply. So the chip includes many series regulators around the outside of the logic area. These produce a fair bit of the heat in the chip.

Mark
Title: Re: Gate array decapped!
Post by: gerald on 17:12, 18 October 16
Quote from: Bryce on 15:11, 18 October 16
That doesn't necessarily mean that they function differently, it may just be a different die with the same mask.

Bryce.
My bet is just a trade-off between time to market and cost.
37AA version (biggest) done as fast as possible.
36AA version (smallest) is just a re-layout of the same logic on a smaller array to reduce cost once the functionality has been validated.
A quick look show that the overall floor-plan is identical (even the layout of the top-left corner).
The 37AA has far more un-used cells. My bet is that the netlist are identical, but I am not sure I will check it ;)

I may give a shot at 40007/40008 just to understand what has been fixed between the 2 version. The GA used is the same for both (and confirm the 40007/40008 are footprint compatible)
Title: Re: Gate array decapped!
Post by: dragon on 18:04, 18 October 16
Only say the count made by robcfg  21X82=1722 In the pdf=LL3170  Match perfect with the hsg3170 changing the initials to sgs nomenclature.

And of course the other ic count 18x74=1332 in the pdf=LL3130 Hsg3130 with sgs nomenclature.

:)

Title: Re: Gate array decapped!
Post by: ||C|-|E|| on 20:08, 18 October 16
Aaah... Toshiba, the same brand that made my TV is also the one behind the evil ACID?  :-X
Title: Re: Gate array decapped!
Post by: dragon on 22:35, 19 October 16
Quote from: gerald on 17:12, 18 October 16
My bet is just a trade-off between time to market and cost.
37AA version (biggest) done as fast as possible.
36AA version (smallest) is just a re-layout of the same logic on a smaller array to reduce cost once the functionality has been validated.
A quick look show that the overall floor-plan is identical (even the layout of the top-left corner).
The 37AA has far more un-used cells. My bet is that the netlist are identical, but I am not sure I will check it ;)

I may give a shot at 40007/40008 just to understand what has been fixed between the 2 version. The GA used is the same for both (and confirm the 40007/40008 are footprint compatible)


About year 95 Roland Perry tell this in amstrad group.


"I happen to know that the first chips were Ferranti ULAs made exactly to Amstrad's design, while later models were SGS custom chips which were plug compatible, but not identical at the gate level, allegedly."




I not know what chips they  speak in the part of diferent at gate level.


40008/10 or aa37 aa 36

Title: Re: Gate array decapped!
Post by: RichTW on 12:10, 23 November 16
Hi all!


I just joined up because I've always been fascinated by the unusual video specifications of the CPC and wanted to congratulate all involved in putting together the schematics for the gate array!


I'd always wondered how the hardware palette colour order came to be - I could never determine the logic behind it (even though there appeared to be some order), and was curious about why those particular duplicate colours dropped out of the logic.  So with these schematics, finally it's possible to see exactly how it works, and it's as fascinating and yet as obscure as I might have hoped!  :)   The tristate logic was definitely an unusual feature.


I think I've spotted a small error in the schematic: in the Colour number to RGB decoder, gate U1806 is inverting the wrong input: it should be inverting COLOUR2, not COLOUR0 - this then produces the same results as the hardware colour numbers.


Out of interest, why is there the popular view that originally a 64 colour palette was intended?  Seems to me this would require a really different design - tristate logic would no longer be an option, for a start.  The 27 colour palette seems like a hack which comes from exploiting the tristate outputs without requiring a lot of extra logic to achieve it, compared to a binary (on or off, 8 colour) palette.
Title: Re: Gate array decapped!
Post by: TotO on 13:15, 23 November 16
Quote from: RichTW on 12:10, 23 November 16Out of interest, why is there the popular view that originally a 64 colour palette was intended?  Seems to me this would require a really different design - tristate logic would no longer be an option, for a start.  The 27 colour palette seems like a hack which comes from exploiting the tristate outputs without requiring a lot of extra logic to achieve it, compared to a binary (on or off, 8 colour) palette.
As you said, it look to be a hack to exploit the tristate outputs.
With that, the GA require 3 less pin to display the coulours and the bit5 of the colour register was left unused.
Title: Re: Gate array decapped!
Post by: arnoldemu on 14:00, 23 November 16
Quote from: RichTW on 12:10, 23 November 16
Out of interest, why is there the popular view that originally a 64 colour palette was intended? 
There is space in the register for 2 bits for each of r,g and b making 64 colours.

I think that is the only reason this view is held.



Title: Re: Gate array decapped!
Post by: gerald on 17:31, 23 November 16
Quote from: RichTW on 12:10, 23 November 16
I think I've spotted a small error in the schematic: in the Colour number to RGB decoder, gate U1806 is inverting the wrong input: it should be inverting COLOUR2, not COLOUR0 - this then produces the same results as the hardware colour numbers.
Well spotted !
That's a miss in the 'simplification' process.
Updated version attached. There is also a fix in the color decode mux (label where missing on output bus).
Title: Re: Gate array decapped!
Post by: PulkoMandy on 10:57, 24 November 16
that 64 colour theory is somewhat coming from my own speculations. What I *think* could have happened is:
- The registers for the gate array were initially designed with 64 colors in mind (2 bit of each red, green, blue) - there is still space for it in the register map, with 1 bit being unused.
- This would have required 6 output pins from the gate array to generate the video signal
- People kept adding features to the chip, and at some point it did use all the 40 pins of the largest package they could get
- They had to free some more pins for other features, and at some point had to settle for video output on just 3 pins
- Fortunately, by using the high impedance trick, this results in 27 colors, instead of just 8, making it a not so bad tradeoff

Of course, I can be wrong and the 27 colors tricks may have been planned from the start. We would have to check with the people who designed the hardware to be sure.
Title: Re: Gate array decapped!
Post by: andycadley on 22:56, 24 November 16
The way I always heard it back in the day is that the original design called for 16 colours, then the designers got clever and spotted the tristate hack could be done pretty much for free and so extended the register design to allow it to work.
Title: Re: Gate array decapped!
Post by: RichTW on 23:01, 24 November 16
That sounds feasible.  I can imagine they might've been going for an RGBI type palette, like the Spectrum, and realised that if they had to have tristate outputs, they may as well find a way to control each one individually instead of all-full or all-half.
Title: Re: Gate array decapped!
Post by: 1024MAK on 13:24, 25 November 16
I suspect that the hardware designers took inspiration from the other existing home micros. You had the ZX Spectrum with 15 colours (7 full intensity "bright" colours, 7 "normal" intensity colours plus black), the BBC model B had 8 colours, the C64 had 16 colours, so the minimum that the CPC should have was 16 colours. But going up to 64 colours may have increased the cost too much (remember the market it was aimed at).

But could they do any better? Well, Sinclair, with their design of ZX81 ULA video circuity had already demonstrated that digital logic could output three voltages instead of just two digital logic levels (low = sync, medium = black signal, high = white level). So presumably someone had a light bulb moment!

The result is the 27 colour system  :D

Mark
Title: Re: Gate array decapped!
Post by: dragon on 14:20, 25 November 16
At the time of cpc release, the majority of enginners was graduate recentlly. Mej electronics was found litte time early.

Its nornal the take a look a other systems as reference.

Anyway at the finish of the day these years. The final especification was conditioned to the space in the ula/cost.

Really, i think if in these days. Amstrad go first with sgs instead of ferranti. We can have a totally diferent especification in the gate array. Sgs apperars have more gates  at same cost.
Title: Re: Gate array decapped!
Post by: Bryce on 14:31, 25 November 16
Quote from: dragon on 14:20, 25 November 16
At the time of cpc release, the majority of enginners was graduate recentlly. Mej electronics was found litte time early.

The university subject "electronics" may have been new, but there were certainly lots of electronics experts that had been around for years, just that their course had been called electrical engineering. Commercial electronics started before the 30's, more than 50 years before the CPC arrived.

Bryce.
Title: Re: Gate array decapped!
Post by: dragon on 11:08, 26 November 16
Quote from: Bryce on 14:31, 25 November 16
The university subject "electronics" may have been new, but there were certainly lots of electronics experts that had been around for years, just that their course had been called electrical engineering. Commercial electronics started before the 30's, more than 50 years before the CPC arrived.

Bryce.


Electronics in general yes, but i not speak about it,  i speak about design a home computer. the industry in these time was very new, taking apart the big room industrial computers.


I mean not how build the electronics part, if not the overral design of  how the computer works. how screen is accesed, bus configuration. etc etc.. resolution modes etc..


Mej electronics/amstrad go for the easy part. they take reference of what it exist and take this  reference to desing the computer.

For example video modes are a  a variant of cga.
Title: Re: Gate array decapped!
Post by: robcfg on 01:08, 19 November 17
Hi folks!


I just wanted to say that I uploaded the decapped ACID chip to the wiki page (http://www.cpcwiki.eu/index.php/Amstrad_Cartridge_Identification_Device#Pictures).


Cheers,
Rob
Title: Re: Gate array decapped!
Post by: Gryzor on 09:03, 19 November 17
Oh, you're the one who broke the db with this big beauty :D
Title: Re: Gate array decapped!
Post by: robcfg on 09:13, 19 November 17
Everything's legal!


The image is under the 20 MB size limit...


;D
Title: Re: Gate array decapped!
Post by: Bryce on 08:36, 20 November 17
Looks like a simple gate array.

Bryce.
Title: Re: Gate array decapped!
Post by: Gryzor on 08:37, 20 November 17
What should it look like?

Sent from my HTC 10 using Tapatalk

Title: Re: Gate array decapped!
Post by: Bryce on 08:39, 20 November 17
Well it could have been an ASIC or a custom IC. This is the ACID, not the GA.

Bryce.
Title: Re: Gate array decapped!
Post by: Gryzor on 08:40, 20 November 17
Ah.

Sent from my HTC 10 using Tapatalk

Title: Re: Gate array decapped!
Post by: dragon on 16:37, 18 January 18
So then what is that history about gate array 40010-28710 incompatible with the m4?.

I was thinking that part are a serial number amstrad made gate array subversions?.
Title: Re: Gate array decapped!
Post by: gerald on 16:52, 18 January 18
Quote from: dragon on 16:37, 18 January 18
So then what is that history about gate array 40010-28710 incompatible with the m4?.

I was thinking that part are a serial number amstrad made gate array subversions?.
Where did you get that info ?
If there is an incompatibility issue, I would say M4 is incompatible with 40010-28710, not the other way  ;)
Title: Re: Gate array decapped!
Post by: dragon on 17:03, 18 January 18
Quote from: gerald on 16:52, 18 January 18
Where did you get that info ?
If there is an incompatibility issue, I would say M4 is incompatible with 40010-28710, not the other way  ;)

Lastest posts

https://www.amstrad.es/forum/viewtopic.php?f=36&t=4388&sid=67d37bf02c4f8b5ee4e1ea0f7c4b0dfc&start=315 (https://www.amstrad.es/forum/viewtopic.php?f=36&t=4388&sid=67d37bf02c4f8b5ee4e1ea0f7c4b0dfc&start=315)
Title: Re: Gate array decapped!
Post by: gerald on 17:32, 18 January 18
Quote from: dragon on 17:03, 18 January 18
Lastest posts

https://www.amstrad.es/forum/viewtopic.php?f=36&t=4388&sid=67d37bf02c4f8b5ee4e1ea0f7c4b0dfc&start=315 (https://www.amstrad.es/forum/viewtopic.php?f=36&t=4388&sid=67d37bf02c4f8b5ee4e1ea0f7c4b0dfc&start=315)
interesting. However, swapping the gate array is not a solution.
The M4 is doing/inducing something wrong (likely a timing problem) and this should be fixed. Only a proper analysis with a logic analyser could tell us.
BTW the 28710/28544 are manufacturing date code  ;)
Title: Re: Gate array decapped!
Post by: dragon on 20:04, 18 January 18
Yeah, but if all gate arrays are the same is so strange 28710 fail in three diferent  cpcs. Maybe fault batch?
Title: Re: Gate array decapped!
Post by: robcfg on 20:19, 18 January 18
That particular chip may be partially damaged.
Title: Re: Gate array decapped!
Post by: Duke on 20:55, 18 January 18
I have asked to buy the particular GA, it's still unclear to me if its just one GA with fab code 28710, which makes it less interesting to put time into, as robcfg says, it could have some damage.
If it's really 3, then of course I would like to put it under the LA.
Also I haven't got reply if my beta 9 works with it, which doesn't use the GA signals for timing at all and thus are a significant amount of nano seconds faster asserting romdis and driving the datalines.
Anyway time will tell :)
Title: Re: Gate array decapped!
Post by: gerald on 21:15, 18 January 18
Quote from: dragon on 20:04, 18 January 18
Yeah, but if all gate arrays are the same is so strange 28710 fail in three diferent  cpcs. Maybe fault batch?
Faulty batch ? Why ?
There are obviously some dispersion in IC characteristics, but these are tested to match the manufacturer requirement.
If these have been mounted in a CPC, that mean they passed the qualification test. And the CPC is working fine with them (and without M4)
We need to identify why they fail with the M4.

What I find strange is that one guy have 3 CPC with 3 GA from the same batch  :o :laugh:
Title: Re: Gate array decapped!
Post by: Bryce on 08:28, 19 January 18
The M4 timing is probably too tight and because of that it's not working on chips on the edge of the tolerances.

Bryce.
Title: Re: Gate array decapped!
Post by: jr on 13:11, 14 February 19
Hi all, first I would like to thank for all the information you gathered around the CPC world.
In particular the Gate Array analysis is quite impressing.

After looking into the schematics from gerald and the Verilog implementation from Ash Evans (posted by DaDMaN) I would like to share my findings.
I am not sure, if these topics have been discussed before in another thread, thus I publish them here hoping that the information might be helpful.

Any comments welcome.

Thanks,
jr
Title: Re: Gate array decapped!
Post by: jr on 13:13, 14 February 19
Schematics

I found some things, that do not match my expectations.

Page 2: RESET is an active high signal, i.e. U202 can only be active while RESET is active
    Is this the intended behaviour ?


Page 8:
    U804 is an OR-gate, instead of an AND-gate
    U822 is !HSYNC, i.e. same as output of U801

    My understanding is:
        If PAD_HSYNC is low, U808, U813, U818 and U824 are kept in reset.
        As soon as PAD_HSYNC is high U808, U813, U818 and U824 start counting with CCLK.
        After 4 CCLK clocks, output of U818 is high, which inverts NSYNC via U828.
        After 4 further CCLK clocks, U824 gets high and keeps U808, U813, U818 in reset state.

        This causes the NSYNC output to be active for exactly 4 CCLK clocks starting 4 CCLK clocks after rising edge of PAD_HSYNC.
        Polarity is defined by U806 (high while HCNT<4, i.e. first 4 HSYNC pulses after VSYNC rising edge, low otherwise).


    Comment to U817 function
        U817 is set for one CCLK when HCNT changes from >=4 to <4, e.g. HCNT is reset from 28 to 0
        Assume that HCNT>=4, i.e. U806=0, latched into U812.
        Upon reset of HCNT to 0, U806=1 and U817=1 for one CCLK clock cycle.
        This aligns the interrupt counter to the VSYNC signal, because HCNT changes from 28 to 0 with rising edge of VSYNC (see below).
       
    HCNT counts number of HSYNC rising edges, starting from 0 after VSYNC rising edge
        It stops counting, when HCNT=28 (U802=1).
        Counter is reset by rising edge of VSYNC (U810).


Page 11
    The numbering of CIDX[3:0] should be U1109, U1129, U1119, U1139, i.e. CIDX1 and CIDX2 swapped


Page 13-16 (Colour bit multiplexer)
    U1x04 and U1x17 (x=3..6) are exchanged, i.e. U1x04 negated path should be the "left" wire ("upper" input to U1x05..U1x12) und non-inverted the "right" wire ("lower" input).
    Then CIDX[3:0]=0..15 selects INKRx[0..15].

Title: Re: Gate array decapped!
Post by: jr on 13:21, 14 February 19
Verilog file

a. Resets are missing or are implemented synchronously instead of asynchronously, which is mandatory for proper operation
- U814, U820, U825, U829 (HCNT): U809 is kept in reset, as soon as HCNT[4:2]="111", i.e. no more clocks for the other FF
- U808, U813, U818, U824 (nsync)
- U815, U821, U826, U830, U832, U825 (INTCNT[0:5])
- U708

b. Some copy-paste errors
- U802: HCNT stops counting at HCNT[4:2]="101"
- U1110, U1115, U1120, U1125, U1130, U1135, U1140: Video shift register

c. missing assignments (CIDX)

d. Changes in schematic v0.2
- Verilog file is based on v0.1 and U1806 changed betwen v0.1 and v0.2



Below are the changes I did to the Verilog file, incl. my interpretation of the schematics.
Note, I have (almost) no knowledge about Verilog, but tried my best with help of some online tutorials.
--- "Amstrad CPC 40010 Gate Array implementation in Verilog_pastebin_2019-02-12.v"    2019-02-13 19:47:48.626881209 +0100
+++ "Amstrad CPC 40010 Gate Array implementation in Verilog_only_fixes.v"    2019-02-13 20:14:24.678781786 +0100
@@ -570,7 +570,7 @@
wire U707 = !M1_N | U705_REG;

reg U708_REG;
-always @(posedge MREQ_N)
+always @(posedge MREQ_N or negedge U707)
     if (!U707) U708_REG <= 1'b0;    // Reset.
     else U708_REG <= 1'b1;            // Else, Clock in a "1".

@@ -633,7 +633,7 @@
wire U831 = U816 | U817 | IRQ_RESET;

wire U801 = !HSYNC;
-wire U804 = U801 & U824_REG;
+wire U804 = U801 | U824_REG;


// INTCNT [045] Register...
@@ -645,14 +645,14 @@
wire INTCNT4_CLK = !INTCNT[3];
wire INTCNT5_CLK = !INTCNT[4];

-always @(posedge U801) if (U831) INTCNT[0] <= 1'b0; else INTCNT[0] <= !INTCNT[0];                 // U815 reg.
-always @(posedge INTCNT1_CLK) if (U831) INTCNT[1] <= 1'b0; else INTCNT[1] <= !INTCNT[1];            // U821 reg.
-always @(posedge INTCNT2_CLK) if (U831) INTCNT[2] <= 1'b0; else INTCNT[2] <= !INTCNT[2];            // U826 reg.
-always @(posedge INTCNT3_CLK) if (U831) INTCNT[3] <= 1'b0; else INTCNT[3] <= !INTCNT[3];            // U830 reg.
-always @(posedge INTCNT4_CLK) if (U831) INTCNT[4] <= 1'b0; else INTCNT[4] <= !INTCNT[4];            // U832 reg.
-always @(posedge INTCNT5_CLK) if (U831 | U827) INTCNT[5] <= 1'b0; else INTCNT[5] <= !INTCNT[5];    // U835 reg.
+always @(posedge U801 or posedge U831) if (U831) INTCNT[0] <= 1'b0; else INTCNT[0] <= !INTCNT[0];                 // U815 reg.
+always @(posedge INTCNT1_CLK or posedge U831) if (U831) INTCNT[1] <= 1'b0; else INTCNT[1] <= !INTCNT[1];            // U821 reg.
+always @(posedge INTCNT2_CLK or posedge U831) if (U831) INTCNT[2] <= 1'b0; else INTCNT[2] <= !INTCNT[2];            // U826 reg.
+always @(posedge INTCNT3_CLK or posedge U831) if (U831) INTCNT[3] <= 1'b0; else INTCNT[3] <= !INTCNT[3];            // U830 reg.
+always @(posedge INTCNT4_CLK or posedge U831) if (U831) INTCNT[4] <= 1'b0; else INTCNT[4] <= !INTCNT[4];            // U832 reg.
+always @(posedge INTCNT5_CLK or posedge U831 or posedge U827) if (U831 | U827) INTCNT[5] <= 1'b0; else INTCNT[5] <= !INTCNT[5];    // U835 reg.

-wire U822 = !VSYNC;
+wire U822 = !HSYNC;


// HSYNC? Reg...
@@ -665,10 +665,10 @@
wire U818_CLK = !U813_REG;
wire U824_CLK = !U818_REG;

-always @(posedge CCLK) if (U804) U808_REG <= 1'b0; else U808_REG <= !U808_REG;
-always @(posedge U813_CLK) if (U804) U813_REG <= 1'b0; else U813_REG <= !U813_REG;
-always @(posedge U818_CLK) if (U804) U818_REG <= 1'b0; else U818_REG <= !U818_REG;
-always @(posedge U824_CLK) if (U822) U824_REG <= 1'b0; else U824_REG <= !U824_REG; // !VSYNC (U822) resets this reg.
+always @(posedge CCLK or posedge U804) if (U804) U808_REG <= 1'b0; else U808_REG <= !U808_REG;
+always @(posedge U813_CLK or posedge U804) if (U804) U813_REG <= 1'b0; else U813_REG <= !U813_REG;
+always @(posedge U818_CLK or posedge U804) if (U804) U818_REG <= 1'b0; else U818_REG <= !U818_REG;
+always @(posedge U824_CLK or posedge U822) if (U822) U824_REG <= 1'b0; else U824_REG <= !U824_REG; // !VSYNC (U822) resets this reg.

wire U828 = U806 ^ U818_REG;
assign NSYNC = U828;    // NSYNC, not "HSYNC". ;)
@@ -677,7 +677,7 @@


// HCNT reg...
-wire U802 = HCNT[2] & HCNT[2] & HCNT[4];
+wire U802 = HCNT[2] & HCNT[3] & HCNT[4];
wire U805 = RESET | U802;

reg U803_REG;
@@ -696,11 +696,11 @@
wire U825_CLK = !U820_REG;
wire U829_CLK = !U825_REG;

-always @(posedge U801) if (U805) U809_REG <= 1'b0; else U809_REG <= !U809_REG;    // U809_REG
-always @(posedge U814_CLK) if (U810) U814_REG <= 1'b0; else  U814_REG <= !U814_REG;    // U814_REG
-always @(posedge U820_CLK) if (U810) U820_REG <= 1'b0; else  U820_REG <= !U820_REG;    // U820_REG
-always @(posedge U825_CLK) if (U810) U825_REG <= 1'b0; else  U825_REG <= !U825_REG;    // U825_REG
-always @(posedge U829_CLK) if (U810) U829_REG <= 1'b0; else  U829_REG <= !U829_REG;    // U829_REG
+always @(posedge U801 or posedge U805) if (U805) U809_REG <= 1'b0; else U809_REG <= !U809_REG;    // U809_REG
+always @(posedge U814_CLK or posedge U810) if (U810) U814_REG <= 1'b0; else  U814_REG <= !U814_REG;    // U814_REG
+always @(posedge U820_CLK or posedge U810) if (U810) U820_REG <= 1'b0; else  U820_REG <= !U820_REG;    // U820_REG
+always @(posedge U825_CLK or posedge U810) if (U810) U825_REG <= 1'b0; else  U825_REG <= !U825_REG;    // U825_REG
+always @(posedge U829_CLK or posedge U810) if (U810) U829_REG <= 1'b0; else  U829_REG <= !U829_REG;    // U829_REG


assign HCNT[4] = U829_REG;
@@ -720,7 +720,7 @@
wire U836_CLK = !INTCNT[5];

reg U836_REG;
-always @(posedge U836_CLK) if (U834) U836_REG <= 1'b0; else U836_REG <= 1'b1;
+always @(posedge U836_CLK or posedge U834) if (U834) U836_REG <= 1'b0; else U836_REG <= 1'b1;

wire U837 = !U836_REG;
assign INT_N = U837;
@@ -859,7 +859,7 @@
// Bit 1...
wire U1106 = SHIFT & U1104_REG;    // Input from previous bit reg.
wire U1107 = LOAD & VIDEO[1];
-wire U1110 = KEEP & U1104_REG;
+wire U1110 = KEEP & U1109_REG;

wire U1108 = U1106 | U1107 | U1110;

@@ -869,7 +869,7 @@
// Bit 2...
wire U1111 = SHIFT & U1109_REG;    // Input from previous bit reg.
wire U1112 = LOAD & VIDEO[2];
-wire U1115 = KEEP & U1104_REG;
+wire U1115 = KEEP & U1114_REG;

wire U1113 = U1111 | U1112 | U1115;

@@ -879,7 +879,7 @@
// Bit 3...
wire U1116 = SHIFT & U1114_REG;    // Input from previous bit reg.
wire U1117 = LOAD & VIDEO[3];
-wire U1120 = KEEP & U1104_REG;
+wire U1120 = KEEP & U1119_REG;

wire U1118 = U1116 | U1117 | U1120;

@@ -889,7 +889,7 @@
// Bit 4...
wire U1121 = SHIFT & U1119_REG;    // Input from previous bit reg.
wire U1122 = LOAD & VIDEO[4];
-wire U1125 = KEEP & U1104_REG;
+wire U1125 = KEEP & U1124_REG;

wire U1123 = U1121 | U1122 | U1125;

@@ -899,7 +899,7 @@
// Bit 5...
wire U1126 = SHIFT & U1124_REG;    // Input from previous bit reg.
wire U1127 = LOAD & VIDEO[5];
-wire U1130 = KEEP & U1104_REG;
+wire U1130 = KEEP & U1129_REG;

wire U1128 = U1126 | U1127 | U1130;

@@ -909,7 +909,7 @@
// Bit 6...
wire U1131 = SHIFT & U1129_REG;    // Input from previous bit reg.
wire U1132 = LOAD & VIDEO[6];
-wire U1135 = KEEP & U1104_REG;
+wire U1135 = KEEP & U1134_REG;

wire U1133 = U1131 | U1132 | U1135;

@@ -919,13 +919,14 @@
// Bit 7...
wire U1136 = SHIFT & U1134_REG;    // Input from previous bit reg.
wire U1137 = LOAD & VIDEO[7];
-wire U1140 = KEEP & U1104_REG;
+wire U1140 = KEEP & U1139_REG;

wire U1138 = U1136 | U1137 | U1140;

reg U1139_REG;
always @(posedge CLK_16M_N) U1139_REG <= U1138;

+assign CIDX = { U1109_REG, U1119_REG, U1129_REG, U1139_REG };

endmodule

@@ -1057,14 +1058,14 @@
wire U1317 = !U1303;


-wire U1305 = (U1301 | INKR[7])  & (INKR[3] | U1304);
-wire U1306 = (U1301 | INKR[15]) & (INKR[11] | U1304);
-wire U1307 = (U1301 | INKR[5])  & (INKR[1] | U1304);
-wire U1308 = (U1301 | INKR[13]) & (INKR[9] | U1304);
-wire U1309 = (U1301 | INKR[6])  & (INKR[2] | U1304);
-wire U1310 = (U1301 | INKR[14]) & (INKR[10] | U1304);
-wire U1311 = (U1301 | INKR[4])  & (INKR[0] | U1304);
-wire U1312 = (U1301 | INKR[12]) & (INKR[8] | U1304);
+wire U1305 = (U1304 | INKR[7])  & (INKR[3] | U1301);
+wire U1306 = (U1304 | INKR[15]) & (INKR[11]| U1301);
+wire U1307 = (U1304 | INKR[5])  & (INKR[1] | U1301);
+wire U1308 = (U1304 | INKR[13]) & (INKR[9] | U1301);
+wire U1309 = (U1304 | INKR[6])  & (INKR[2] | U1301);
+wire U1310 = (U1304 | INKR[14]) & (INKR[10]| U1301);
+wire U1311 = (U1304 | INKR[4])  & (INKR[0] | U1301);
+wire U1312 = (U1304 | INKR[12]) & (INKR[8] | U1301);


wire U1313 = (!U1302) ? U1305 : U1306;
@@ -1072,8 +1073,8 @@
wire U1315 = (!U1302) ? U1309 : U1310;
wire U1316 = (!U1302) ? U1311 : U1312;

-wire U1318 = (U1303 | U1313) & (U1314 | U1317);
-wire U1319 = (U1303 | U1315) & (U1316 | U1317);
+wire U1318 = (U1317 | U1313) & (U1314 | U1303);
+wire U1319 = (U1317 | U1315) & (U1316 | U1303);

wire U1320 = INK_SEL & CIDX[0] & U1318;
wire U1321 = INK_SEL & CIDX[0] & U1319;
@@ -1117,7 +1118,7 @@

wire U1804 = COLOUR[1] & COLOUR[2];
wire U1805 = COLOUR[1] | COLOUR[2] | COLOUR[3] | COLOUR[4];
-wire U1806 = COLOUR[2] & !COLOUR[0];
+wire U1806 = !COLOUR[2] & COLOUR[0];
wire U1811 = U1804 | !U1805;
wire U1812 = U1806 | COLOUR[1];

@@ -1128,14 +1129,14 @@
wire U1814 = U1808 | COLOUR[3];


-always @(posedge CLK_16M_N) if (U1809) BLUE_OE_N <= 1'b0; else BLUE_OE_N <= U1810;
-always @(posedge CLK_16M_N) if (U1809) BLUE <= 1'b0; else BLUE <= COLOUR[0];
+always @(posedge CLK_16M_N or posedge U1809) if (U1809) BLUE_OE_N <= 1'b0; else BLUE_OE_N <= U1810;
+always @(posedge CLK_16M_N or posedge U1809) if (U1809) BLUE <= 1'b0; else BLUE <= COLOUR[0];

-always @(posedge CLK_16M_N) if (U1809) GREEN_OE_N <= 1'b0; else GREEN_OE_N <= U1811;
-always @(posedge CLK_16M_N) if (U1809) GREEN <= 1'b0; else GREEN <= U1812;
+always @(posedge CLK_16M_N or posedge U1809) if (U1809) GREEN_OE_N <= 1'b0; else GREEN_OE_N <= U1811;
+always @(posedge CLK_16M_N or posedge U1809) if (U1809) GREEN <= 1'b0; else GREEN <= U1812;

-always @(posedge CLK_16M_N) if (U1809) RED_OE_N <= 1'b0; else RED_OE_N <= U1813;
-always @(posedge CLK_16M_N) if (U1809) RED <= 1'b0; else RED <= U1814;
+always @(posedge CLK_16M_N or posedge U1809) if (U1809) RED_OE_N <= 1'b0; else RED_OE_N <= U1813;
+always @(posedge CLK_16M_N or posedge U1809) if (U1809) RED <= 1'b0; else RED <= U1814;


-endmodule
\ No newline at end of file
+endmodule
Title: Re: Gate array decapped!
Post by: Gryzor on 13:22, 14 February 19
Man, that's a deep analysis.
Title: Re: Gate array decapped!
Post by: gerald on 17:14, 14 February 19
Quote from: jr on 13:13, 14 February 19
Page 2: RESET is an active high signal, i.e. U202 can only be active while RESET is active
    Is this the intended behaviour ?
I don't think so  :D
But that's how it's implemented. I more than triple checked that since it did not looks right.
However, if you test with a real 40010 you'll see that the sequencer does not care about reset.

Quote from: jr on 13:13, 14 February 19
Page 8:
    U804 is an OR-gate, instead of an AND-gate
    U822 is !HSYNC, i.e. same as output of U801
U804 : I need to check that. [edit] Correct. My note and VHDL confirm, but the schematic is wrong.
U822 : good spot, it's a transcription error when passing from my notes to the schematic. [edit2] well, I already spotted it. My local schematic and VHDL reflect it.

Quote from: jr on 13:13, 14 February 19
Page 11
    The numbering of CIDX[3:0] should be U1109, U1129, U1119, U1139, i.e. CIDX1 and CIDX2 swapped


Page 13-16 (Colour bit multiplexer)
    U1x04 and U1x17 (x=3..6) are exchanged, i.e. U1x04 negated path should be the "left" wire ("upper" input to U1x05..U1x12) und non-inverted the "right" wire ("lower" input).
    Then CIDX[3:0]=0..15 selects INKRx[0..15].
I've fixed that 2 years ago, but did not publish the updated schematic as I was still validating my VHDL port. And than real life took over  :blank:
I currently have VHDL implementation that works except on some demo, and U804/U822 may be the cause.
I need to find some time to :
- re-compile degate so I can double check that at gate level
- re-install the 40010 PLD test setup
[edit2] BTW, there is missing an inverter on NSYNC ouput on page 8.
Title: Re: Gate array decapped!
Post by: jr on 20:29, 18 February 19
Thanks gerald for the confirmation of my analysis, so far.
The hint with NSYNC will become handy, if I ever should try to connect a monitor to the system.

I have the same problem with real life: It never leaves sufficient time to play around with other stuff.
But it is more important for me ;-)

That's why I will have to pause again for a while with this interesting topic.
To not forget the outcomes of my efforts, I post it here, where it it might of help to others as well.


Seems I found another two issues in the schematics, that you can probably verify easily:

   U304 = (S3 & !S6);   // AND instead of NAND

   CCLK = S2 & S5;   // AND instead of OR


Looking at the schematics, I tried to figure out some aspects of the implementation

Page 1:
   Gate U202 can never become high during operation for two reasons:
      - RESET='0'
      - M1_n, IORQ_n and RD_n will never become active at the same time. Interrupt Acknowledge is M1_n='0' and IORQ_n='0'. RD_n is not active.
   If RESET='1', then M1_n, IORQ_n and RD_n are high impedance, so unsure what happens here.

   Synchronization between S[7:0] to CPU state seems to happen automagically with the wait states inserted by the GA (PAD_READY).
   Note:
      If you use T80 FPGA implementation for the Z80 cpu, you have to align PAD_READY to the rising edge of the T80 clock
      The original Z80 samples WAIT#-signal with the falling clock edge of T2, while T80 samples it half a clock cycle later with the rising edge end of T2.

Page 7:
   The logic around RESET, M1_n, PHI_n, MREQ_n (top input to U710) seems to filter out the MREQ_n used for refresh cycle.
   Note: falling edge of PHI_n is rising edge of Z80, as there is an inverter on the CPC mainboard.
   After M1_n='0' the Z80 always inserts one refresh cycle with MREQ_n='0' (and RFSH_n='0'), which must not be used to assert CAS_n,
   because this could lead to erroneous writes to the RAM.
   Note: RAM is active, if RAS_n='0' and CAS_n='0' and MWE_n=!RD_n when CAS_n='0' during CPU memory access.
   This would result in a memory write to the refresh address, if the refresh MREQ_n-signal would be used, as well.

Another copy-paste error in Verilog file:
   wire U710 = !U708_REG | MREQ_N | !S4 | S5;


jr
Title: Re: Gate array decapped!
Post by: gerald on 21:13, 18 February 19
Quote from: jr on 20:29, 18 February 19
   U304 = (S3 & !S6);   // AND instead of NAND
Confirmed

Quote from: jr on 20:29, 18 February 19CCLK = S2 & S5;   // AND instead of OR
I beg to differ  ;D It's a NOR.

Quote from: jr on 20:29, 18 February 19Page 1:
   Gate U202 can never become high during operation for two reasons:
      - RESET='0'
      - M1_n, IORQ_n and RD_n will never become active at the same time. Interrupt Acknowledge is M1_n='0' and IORQ_n='0'. RD_n is not active.
   If RESET='1', then M1_n, IORQ_n and RD_n are high impedance, so unsure what happens here.

   Synchronization between S[7:0] to CPU state seems to happen automagically with the wait states inserted by the GA (PAD_READY).
   Note:
      If you use T80 FPGA implementation for the Z80 cpu, you have to align PAD_READY to the rising edge of the T80 clock
      The original Z80 samples WAIT#-signal with the falling clock edge of T2, while T80 samples it half a clock cycle later with the rising edge end of T2.
I am wondering if these were not used for chip testing. By applying this pattern, they make sure the sequencer was initialised to a known state.
Using reset only would prevent the other clock generation that the Z80 / CRTC  need.
I've attached the latest version of the schematic.
Title: Re: Gate array decapped!
Post by: rpalmer on 13:57, 14 May 19
Gerald,
The current version of the Gate Array Decapped (both the PDF and verilog) will not work with a CPC6128, but could work with the 464/664.

People will ask what make me say this?
Well checking the the Gate Array PDF and subsequent verilog code shows it DOES NOT output the data lines for the PAL chip as seen on the 6128 schematic. The schematic does not show these as being latched, so it must be within the Gate Array and issued by the Gate Array when accessing memory. The verilog ONLY has the data lines defined as "input" which is the main reason why it will not work as expected on a 6128.

Another issue I have seen with the whole breakdown of the GA is that the 4 MHZ and 1 MHz clock signals do not need to be via the "sequencer". It can be generated through 4 flip-flops. I suspect the sequencer should only be for the handling of reading/decoding and displaying video data.
Attached if a reformatted version (less the 31 colors stuff) with comments where the initial issue lies.
rpalmer
Title: Re: Gate array decapped!
Post by: slingshot on 13:51, 27 January 20
1. I'm playing with the schematics and a Verilog translation in a simulator (Verilator). As I see, the sync_n generator doesn't filter out any vsyncs, only shorten it to a duration of 4 hsyncs, if it's too long. But emulators are implementing filtering, like they doesn't start a new frame if there weren't at least about 240 lines. Some demos are depend on it, for example the 4-SINS of the Unique Megademo. You can even notice the blanking mid-frame because of the VSYNCS (the demo issues VSYNCs in 80 lines, and expects 4 such sections in one frame). My question is why does it work on the hardware?
2. Various sources says that VSYNC out is delayed by 2 HSYNCS from the CRTC VSYNC and lasts for 2 lines. However U806 triggers just after 4 hcnts and turns off after 7. Is it right? Looks like it's value is doubled.
3.@rpalmer (https://www.cpcwiki.eu/forum/index.php?action=profile;u=379) why should the GA output data? All registers are write-only. Nothing can be read from the GA. It reads from the CPU bus when N244E asserted, otherwise from the RAM.
Title: Re: Gate array decapped!
Post by: slingshot on 12:05, 29 January 20
Here's a simulation waveform when CRTC issued a vsync (actually a CRTC wasn't wired in, it's just an artifical signal). The length of the vsync in the composite sync seems to be identical to this one:
https://electronics.stackexchange.com/questions/432345/rgbs-sync-signal
Maybe somebody has a waveform capture showing the relation of the CRTC vsync and the GA one?
Title: Re: Gate array decapped!
Post by: slingshot on 13:31, 04 July 20
To answer myself, I didn't spot that those counters are not simple binary counters, but follows a strange sequence, because the 3rd stage gets the non-negated output from the previous one.At the end, a Verilog implementation of the GA is finished, and a working core on the MiST and MiSTer FPGAs are released.
Title: Re: Gate array decapped!
Post by: robcfg on 15:42, 04 July 20
That's great news!
Title: Re: Gate array decapped!
Post by: slingshot on 18:48, 04 July 20
Here's a corrected waveform capture, which shows the relation of the CRTC VSYNC and the GA VSYNC (and CSYNC) outputs. It can be seen that the HCNT counter looks weird.
Title: Re: Gate array decapped!
Post by: VintageAdvantage on 20:46, 17 April 21
Now, how about this idea: if the progress on reconstruction / reengineering is a bit stuck, why  don't we reach out to MEJ

https://ch.linkedin.com/in/markericjones (https://ch.linkedin.com/in/markericjones)

the original designer... also, the first prototypes used 74LSxxx chips. Anybody know if the first TTL Gate Array was 100% compatible with the later 40007? If so, and we have the 74LSxxx GA schematics (maybe from MEJ), it should be relatively easy to reproduce the whole thing in Verilog / VHDL.

Has this avenue been pursued already? I believe we even have an original TTL GA CPC in the community somehwere... didn't somebody acquire the working CPC 464 prototype, some community member? Reengineering of the GA should be straight forward with that machine!

I don't understand what the current uphold / obstacle is, given the resources available to us: existing TTL prototype, AND original designer still alive (MEJ link above). 

Sorry for my ignorance, I didn't read the whole thread.

EDIT: Likewise, given that there is a Verilog file available, has somebody put that in a chip and in a real CPC to check if it works?  Has the reconstructed / decapped GA logic been confirmed to be 100% authentic? Has this been compared with the "official TTL GA"?
Title: Re: Gate array decapped!
Post by: gerald on 10:06, 18 April 21
Nothing is stuck.
Everyone does it at its own pace 

For a FPGA re-implementation from the GA decapping : https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/a-minimal-gate-array/msg198585/#msg198585
As for the verilog version, I don't know. I only use my own VHDL version  ;D

But since you seem to have a lot of energy to spare, why don't you contact the TTL proto and/or owner yourself ?
Title: Re: Gate array decapped!
Post by: VintageAdvantage on 18:54, 18 April 21
Quote from: gerald on 10:06, 18 April 21
Nothing is stuck.
Everyone does it at its own pace 

For a FPGA re-implementation from the GA decapping : https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/a-minimal-gate-array/msg198585/#msg198585 (https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/a-minimal-gate-array/msg198585/#msg198585)
As for the verilog version, I don't know. I only use my own VHDL version  ;D

But since you seem to have a lot of energy to spare, why don't you contact the TTL proto and/or owner yourself ?
I think you missunderstood the intent of this question, @gerald (https://www.cpcwiki.eu/forum/index.php?action=profile;u=250) - there was no intent to push anybody, but to get an understanding of the status and progress.

This is a long thread with a lot of technical details. My questions were on a higher level:Yes, I might reach out to MEJ and ask him for the TTL GA schematics if we don't have them.  I don't know, this is why I asked!

Decapping and reengineering seems to be a desperate last step - especially if the designer has not been asked? He must have been asked before going down this rabithole?
Title: Re: Gate array decapped!
Post by: tjohnson on 19:09, 18 April 21
Maybe MEJ doesn't have the schematics, worth asking I guess, he might respond, you never know.
Title: Re: Gate array decapped!
Post by: VintageAdvantage on 19:14, 18 April 21
Quote from: tjohnson on 19:09, 18 April 21
Maybe MEJ doesn't have the schematics, worth asking I guess, he might respond, you never know.
Indeed! This is what I was suggesting... why go down this crazy decapping rabit hole business BEFORE ASKING.

Now, without trying to offend or push anybody to do anything here - I'd suggest that somebody who is familiar with the current state of the GA reengineering to talk to MEJ. I myself would not be the right person, because I don't know enough about it.

At that state, it's all guesswork, and "the CPC public community" doesn't even know IF MEJ has been asked. That's what I would like to know. Has he been asked, and if so, what was the result? There is no record of this communication.
Title: Re: Gate array decapped!
Post by: tjohnson on 20:45, 18 April 21
You got the contact. Write to him, tell him the issue, provide and link and ask.  No harm in trying he could just ignore you.
Title: Re: Gate array decapped!
Post by: VintageAdvantage on 21:01, 18 April 21
Will do!
Title: Re: Gate array decapped!
Post by: gerald on 07:29, 19 April 21
Quote from: VintageAdvantage on 18:54, 18 April 21do we have the Gate Array TTL schematics - if so, where? I don't see them.
The 40010 is a CMOS gate array. So  no TTL schematic  :D .
But if you look in the thread, you will find a logic schematic.
Title: Re: Gate array decapped!
Post by: VintageAdvantage on 07:32, 19 April 21
Quote from: gerald on 07:29, 19 April 21
The 40010 is a CMOS gate array. So  no TTL schematic  :D .
But if you look in the thread, you will find a logic schematic.
Yes, but the 40007 started as TTL... that should have (had) schematics (somewhere, at some point in time).
Title: Re: Gate array decapped!
Post by: eto on 11:14, 19 April 21
I was just wondering if the Russian and East-German engineers already did most of the analysis work for us. Both the KC compact and the Aleste 520EX contain logic for the GateArray based on standard logic chips.

I saw that these computers are mentioned in this thread but I think it was not discussed if that logic could be reused. Would it be possible to recreate the gate array from the KC compact schematics? I do not really know much about electronics but the schematics look much simpler to me than the picture of a decapped GateArray. Maybe this question is utterly stupid (which I would understand as I have absolutely low understanding of electronics), then sorry for bringing it up.
Title: Re: Gate array decapped!
Post by: RetroCPC on 14:18, 19 April 21
Quote from: gerald on 07:29, 19 April 21
The 40010 is a CMOS gate array. So  no TTL schematic  :D .
But if you look in the thread, you will find a logic schematic.

Has the Schematic been confirmed correct? Has the Verilog code been verified in real hardware?

I've been teaching myself Verilog since the start of the year and it could make a good project...
Title: Re: Gate array decapped!
Post by: VintageAdvantage on 16:50, 19 April 21
Quote from: RetroCPC on 14:18, 19 April 21I've been teaching myself Verilog since the start of the year and it could make a good project...

I saw a picture on a spanish CPC website where a guy had a Xilinx FPGA or CPLD for the Gate Array. There is also a Google Sheet somewhere that shows what was working and what wasn't (I remember Batman demo was working). Not sure if this was Gerald's code that was in his CPLD / FPGA.

I think it would be great if somebody tried with the current Verilog code and put it into a chip to see what it does. But then, only @gerald (https://www.cpcwiki.eu/forum/index.php?action=profile;u=250) and others more knowledable on that subject than I can say if that even makes sense at this point, or if it is too early for that.

I must say the Schematics and the Verilog code look quite comprehensible and well documented, great job so far, everybody! Really impressive!
Title: Re: Gate array decapped!
Post by: TotO on 17:34, 19 April 21
Anybody taking the gerald pdf schematic and redraw it (ISE for Xilinx), can auto-generate the description code in Verilog or VHDL and next clean/rearrange it... Nobody does anything before this reverse engineering work.
Title: Re: Gate array decapped!
Post by: gerald on 17:55, 19 April 21
Quote from: VintageAdvantage on 16:50, 19 April 21
I saw a picture on a spanish CPC website where a guy had a Xilinx FPGA or CPLD for the Gate Array. There is also a Google Sheet somewhere that shows what was working and what wasn't (I remember Batman demo was working). Not sure if this was Gerald's code that was in his CPLD / FPGA.

I think it would be great if somebody tried with the current Verilog code and put it into a chip to see what it does. But then, only @gerald (https://www.cpcwiki.eu/forum/index.php?action=profile;u=250) and others more knowledable on that subject than I can say if that even makes sense at this point, or if it is too early for that.

I must say the Schematics and the Verilog code look quite comprehensible and well documented, great job so far, everybody! Really impressive!
I cannot comment on the verilog source. I only noticed that has been produced (literally) from the early schematic (which had some errors). I already had the VHDL version started ... and I am not fond of verilog anyway  :P

Was it used for the mcleod_ideafix FPGA's, I can't tell nor bother. The schematic is there for everyone to see an use.

The latest schematic is in line with the VHDL that runs on the board linked above.
On the few issues I had, I came back to the full schematic (paper one, unpublished) and the decapped picture to double/triple/quad check  ??? where I messed up. So I am quite confident that it is a close implementation of the original 40010.


Note that the google sheet seems to relate to a full CPC FPGA implementation, so not something related to the gate array alone.

Title: Re: Gate array decapped!
Post by: VintageAdvantage on 19:31, 19 April 21
Quote from: gerald on 17:55, 19 April 21
Note that the google sheet seems to relate to a full CPC FPGA implementation, so not something related to the gate array alone.

This is this one:

https://www.zxuno.com/forum/viewtopic.php?f=59&t=1624 (https://www.zxuno.com/forum/viewtopic.php?f=59&t=1624)
Xilinx XC95216
https://www.xilinx.com/support/documentation/data_sheets/ds068.pdf (https://www.xilinx.com/support/documentation/data_sheets/ds068.pdf)
There doesn't seem to be anything else on this board... just the pin mapping.

In principle I would also have the equipment to do this... maybe a smaller CPLD with PLCC socket could also do, not sure how many cells it needs. I have used XC9572 before and have the programming equipment (WebISE and platform cable and such). 


Title: Re: Gate array decapped!
Post by: revaldinho on 19:54, 19 April 21
There is an FPGA version of the Amstrad CPC which runs on the MiST platform:


https://github.com/sorgelig/Amstrad_MiST (https://github.com/sorgelig/Amstrad_MiST)


The code is nicely organized in this repository, with all of the gate array modules in its own folder. The code looks like it's a straight implementation of Gerald's excellent schematics.


I just downloaded it and synthesized the GA and the results look promising for a standalone CPLD implementation. Not too many warnings after some minor porting of SystemVerilog code to Verilog, and it fitted easily in an XC95288XL target (~25UKP ea), but it's too big for an XC95144XL (~9UKP ea).




cpldfit:  version P.20131013                        Xilinx Inc.
                                  Fitter Report
Design Name: ga40010                             Date:  4-19-2021,  7:38PM
Device Used: XC95288XL-10-TQ144
Fitting Status: Successful
*************************  Mapped Resource Summary  **************************
Macrocells     Product Terms    Function Block   Registers      Pins           
Used/Tot       Used/Tot         Inps Used/Tot    Used/Tot       Used/Tot       
187/288 ( 65%) 400 /1440 ( 28%) 380/864 ( 44%)   130/288 ( 45%) 50 /117 ( 43%)



 
Title: Re: Gate array decapped!
Post by: TotO on 20:19, 19 April 21
Exactly. The GA core of the MIST and MiSTer are based upon the gerald's schematic (provided into the directory).
Sorgelig does a great job to improve the CPC emulation, as usual for the other systems.
Title: Re: Gate array decapped!
Post by: VintageAdvantage on 22:23, 19 April 21
Quote from: revaldinho on 19:54, 19 April 21
There is an FPGA version of the Amstrad CPC which runs on the MiST platform:


https://github.com/sorgelig/Amstrad_MiST (https://github.com/sorgelig/Amstrad_MiST)


The code is nicely organized in this repository, with all of the gate array modules in its own folder. The code looks like it's a straight implementation of Gerald's excellent schematics.


I just downloaded it and synthesized the GA and the results look promising for a standalone CPLD implementation. Not too many warnings after some minor porting of SystemVerilog code to Verilog, and it fitted easily in an XC95288XL target (~25UKP ea), but it's too big for an XC95144XL (~9UKP ea).




cpldfit:  version P.20131013                        Xilinx Inc.
                                  Fitter Report
Design Name: ga40010                             Date:  4-19-2021,  7:38PM
Device Used: XC95288XL-10-TQ144
Fitting Status: Successful
*************************  Mapped Resource Summary  **************************
Macrocells     Product Terms    Function Block   Registers      Pins           
Used/Tot       Used/Tot         Inps Used/Tot    Used/Tot       Used/Tot       
187/288 ( 65%) 400 /1440 ( 28%) 380/864 ( 44%)   130/288 ( 45%) 50 /117 ( 43%)




Oh, good job...  dare to "connect the pins" and put it into a real CPC?

I have some PLCC prototyping boards, gonna see if I can find a large enough Xilinx CPLD in that packaging format, then I could also try it.


Title: Re: Gate array decapped!
Post by: revaldinho on 08:39, 20 April 21
Quote from: VintageAdvantage on 22:23, 19 April 21
Oh, good job...  dare to "connect the pins" and put it into a real CPC?

I have some PLCC prototyping boards, gonna see if I can find a large enough Xilinx CPLD in that packaging format, then I could also try it.


The XC95288XLs are only available in TQFP packs as far as I know. They're also 3.3V parts with 5V tolerant IOs, so they need a small carrier board PCB with a voltage regulator and decoupling at least.


It's a mini-project, but not one I'm going to take on just yet. I have a few other things in the pipe ahead of that.
Title: Re: Gate array decapped!
Post by: VintageAdvantage on 09:00, 20 April 21
Quote from: revaldinho on 08:39, 20 April 21
It's a mini-project, but not one I'm going to take on just yet. I have a few other things in the pipe ahead of that.

Same here. I have learned by now how to do SMD, so it would be a good exercise, but... later :-) I guess you will get to it first.
Title: Re: Gate array decapped!
Post by: Bryce on 14:05, 20 April 21
Quote from: revaldinho on 08:39, 20 April 21

The XC95288XLs are only available in TQFP packs as far as I know. They're also 3.3V parts with 5V tolerant IOs, so they need a small carrier board PCB with a voltage regulator and decoupling at least.


It's a mini-project, but not one I'm going to take on just yet. I have a few other things in the pipe ahead of that.

You'd need a carrier board no matter what, and sorting the voltages isn't an issue either. Take a look at the NeatPLA for the C64 PLA replacement where this was done extremely well: https://www.amibay.com/showthread.php?111794-neatPLA-The-best-looking-PLA-for-fixing-your-C64-)

Bryce.
Title: Re: Gate array decapped!
Post by: CaptainRon on 22:57, 24 August 21
I was able to write the Verilog code to a Spartan6 FPGA with only a few warnings. Does anyone know where I can find a main board file for Eagle or some other software or even a Gerber of the CPC main board. I want to build up a CPC464 to test the FPGA in.
Title: Re: Gate array decapped!
Post by: CaptainRon on 08:25, 28 August 21
I am laying out a carrier board for the FPGA/CPLD 40010 replacement. Do you think "Texas Instruments TXB0108  8-Bit Bidirectional Voltage-Level Translator with Auto-Direction Sensing and ±15-kV ESD Protection" level shifters will switch fast enough? I am primarily concerned with the CLK signals especially the 16Mhz CLK. I had hoped to use my Spartan6 dev board but the max voltage input is 4v, will the RMS voltage of the CLK pins exceed 4v? if not I can just use the raw clk signals and level shift everything else.

If the clocks will be a problem I can just layout a
XC95288XL CPLD board, It has 5v tolerant inputs for the clocks, and then level shift everything else.

Included below is a link for the TXB0108 datasheet. If these chips don't seem fast enough, what would be a better solution? Could I get away with a voltage divider for the clocks?

What are your thoughts?

John

https://www.ti.com/lit/ds/symlink/txb0108.pdf (https://www.ti.com/lit/ds/symlink/txb0108.pdf)
Title: Re: Gate array decapped!
Post by: Bryce on 11:36, 28 August 21
Really, that's a serious question? Of course it will be fast enough! It's made for modern circuits, 16MHz is slow motion for this part.

Bryce.
Title: Re: Gate array decapped!
Post by: CaptainRon on 12:30, 28 August 21
Nice, I'll just use 5 of those on a pcb and level shift everything for testing and see if I can get something working with the spartan6 dev board.
Title: Re: Gate array decapped!
Post by: SerErris on 15:03, 24 January 22
Quote from: revaldinho on 19:54, 19 April 21cpldfit:  version P.20131013                        Xilinx Inc.
                                  Fitter Report
Design Name: ga40010                             Date:  4-19-2021,  7:38PM
Device Used: XC95288XL-10-TQ144
Fitting Status: Successful
*************************  Mapped Resource Summary  **************************
Macrocells     Product Terms    Function Block   Registers      Pins           
Used/Tot       Used/Tot         Inps Used/Tot    Used/Tot       Used/Tot       
187/288 ( 65%) 400 /1440 ( 28%) 380/864 ( 44%)   130/288 ( 45%) 50 /117 ( 43%)

I do have one question regarding the implementation.

AFAIK The gate array has a 40PIN DIP case and has from the schematic exactly 36 IO Pins.

I looked at the verilog from MISTer and it does have 50 IO Pins defined, which I simply do not understand. Why are they needed?

Also as others in here I totally struggle about the Sequencer and the reset structure ... I also do struggle that my simple (just the secuencer implementation) test does not delivers what it is supposed to deliver.

In the v3 schematic is written for the sequencer, that it is not getting initialized. So it will start with a random number in S. But I cannot simulate that, as S is allways X (unknown)  and as the reset funktion never works ... I am not getting any reasonable output ever.

I have a eda playground test running here:
https://www.edaplayground.com/x/u6mH (https://www.edaplayground.com/x/u6mH)

And this is how it looks like for the simulation see attachement
Title: Re: Gate array decapped!
Post by: SerErris on 15:57, 24 January 22
Another question to the same above.

I pondering with the description on schematics for the sequencer.

It reads:
QuoteSequencer is
- free running on 16Mhz clock
- not initialised at power up
- initialized to S[7:0] = 11111111 when
  - S7=0 and S6 = 1
  - Z80 is acknowledging an IRQ


Okay as we did discuss here already, the Reset statement from Z80 acknowledging an IRQ will never happen ... This is because the RESET line is never low (that would be a real reset) and the IORQ and RD lines are never active at the same point in time. ... To reset on an IRQ it would actually require ~reset AND ~IORQ AND ~M1_

Second part in it .. it does not reset to FF. It actually resets to 7F, 7E or to FE or FF depending on the value of S at reset time.


It simply depends on two bits before the reset happens:



This is Bit 6 and Bit 7.

If [7:6] is, then the result after reset is:
00 => 0111 1111 (7F)   (next is then FF because of [7:6]=01)
01 => 1111 1111 (FF).  (this is also the turnaround point, to restart the sequence)
11 => 1111 1110 (FE).  (FF missing but #2 Sequence element then continuing from here)
10 => 0111 1110 (7E).  (next also FF, because [7:6]=10). 


What the reset really does is, getting the sequence in order, however that is never required as it by itself will get into the correct order without anyone doing anything from outside with the sequence restart.

The worst case is if by chance the sequence starts with 2 ... then it takes 6 cycles (16MHz) to actually get to the first element from the sequence: [2,5,B,17,2F,5F,FF]
Title: Re: Gate array decapped!
Post by: gerald on 17:45, 24 January 22
Quote from: SerErris on 15:03, 24 January 22I do have one question regarding the implementation. AFAIK The gate array has a 40PIN DIP case and has from the schematic exactly 36 IO Pins.
35 IO to be precise  ;)

Quote from: SerErris on 15:03, 24 January 22I looked at the verilog from MISTer and it does have 50 IO Pins defined, which I simply do not understand. Why are they needed?
Which source file are you looking at ?


Quote from: SerErris on 15:03, 24 January 22Also as others in here I totally struggle about the Sequencer and the reset structure ... I also do struggle that my simple (just the secuencer implementation) test does not delivers what it is supposed to deliver. In the v3 schematic is written for the sequencer, that it is not getting initialized. So it will start with a random number in S. But I cannot simulate that, as S is allways X (unknown)  and as the reset funktion never works ...
As said on previous message, the reset function is likely to be a manufacturing test function to make sure the system is in a know qnd synchronise state for pattern test. Within a CPC, the gate array MUST deliver the different clock during the reset so the other IC can do they proper initialisation.
Regarding you simulation, you better start will all 0. As you noticed, putting U or X is propagated endlessly unless you put the magic pattern on (reset / ioreq, rdn, m1n) for at least 3 clock cycles, then you will then be in 7F state.
Regarding the comments on the schematics, these are cold comment I put while making the schematics, there might be some correction to add like the Z80 ack, not being an ack (due to the RDn required to be low)
Also, since there is no functional reason to encounter the "reset" sequence in real world, I did not investigate further.
Also, it is likely that all the sequencer start at 00 state. Ink register are alway 0 at power up, and give us the gray screen of dead RAM  ;) .




Title: Re: Gate array decapped!
Post by: SerErris on 19:12, 24 January 22
Yes 35 it is ..


I am using the implementation from MISTERfpga from here:
https://github.com/MiSTer-devel/Amstrad_MiSTer/blob/master/rtl/GA40010/ga40010.sv (https://github.com/MiSTer-devel/Amstrad_MiSTer/blob/master/rtl/GA40010/ga40010.sv)


module ga40010 (
input  clk,
input  cen_16,
input fast, // CPU won't WAIT


`ifdef VERILATOR
input  clk_16,
`endif


input  RESET_N,
input [15:14] A,
input [7:0] D,
input  MREQ_N,
input  M1_N,
input  RD_N,
input  IORQ_N,
input  HSYNC_I,
input  VSYNC_I,
input  DISPEN,

output CCLK,
output CCLK_EN_P,
output CCLK_EN_N,
output reg PHI_N,
output reg PHI_EN_N,
output reg PHI_EN_P,

output reg RAS_N,
output CAS_N,
output READY,
output reg CASAD_N,
output CPU_N,
output MWE_N,
output E244_N,
output ROMEN_N,
output RAMRD_N,
output ROM,

output [1:0] MODE,
output HSYNC_O,
output VSYNC_O,
output SYNC_N,
output reg INT_N,
output VBLANK,

output BLUE_OE_N,  // BLUE   50%
output BLUE,       // BLUE  100%
output GREEN_OE_N, // GREEN  50%
output GREEN,      // GREN  100%
output RED_OE_N,   // RED    50%
output RED         // RED   100%

);I could now identify that they did the coupling of the colors and the output enables outside the GA .. (good that we are working in enclosed system :-) ). And we do have the clock output with positive and negative edge ... not sure why. So this is already 6 lines that should not be there.. There is for instance a Mode output .. (2bit ? ) ..


In summary it looks like they added some extra signlas for the emulator that do not exist in the real world. For instance they want to put the current mode out to something ... not used in the amstrad hardware but maybe they need it for the MISTER main part. Same for the input fast ... get some additional control from the parameters of MISTER.
Title: Re: Gate array decapped!
Post by: SerErris on 13:17, 27 January 22
@Bryce (https://www.cpcwiki.eu/forum/index.php?action=profile;u=225) @gerald (https://www.cpcwiki.eu/forum/index.php?action=profile;u=250) I have another question you might be able to answer.


Looking at the schematic, it clearly states that D[7:0] is Input (not Tristate or Input/Output). So even if it sits on a data bus it will never drive the bus with anything, is that correct?

Looking at this site however it says Input/Output.
https://www.grimware.org/doku.php/documentations/devices/gatearraydo=export_xhtml (https://www.grimware.org/doku.php/documentations/devices/gatearraydo=export_xhtml)
Looking at a CPLD, would that require any special handling?

And fruther looking at CPLD and the problem of gettin a truly 5V Tolerant (without any additional components around it) nowadays, I need to put in a coverter for the Inputs and also for the Video outputs, maybe for the clock outputs, I will try without clock outputs first.

So esp. for the data lines, would that even work?

I am trying to get my head around all that.


Maybe a good idea to start another thread just on the development of the CPLD ...
Title: Re: Gate array decapped!
Post by: gerald on 17:00, 27 January 22
Quote from: SerErris on 13:17, 27 January 22
Looking at the schematic, it clearly states that D[7:0] is Input (not Tristate or Input/Output). So even if it sits on a data bus it will never drive the bus with anything, is that correct?


Looking at a CPLD, would that require any special handling?
Yes, the data bus is input only.  There is no way to read from the GA.
On the PLD, your code defins wether its a input, output, bidir, tristate. So, no it does not requires special handling. Just proper schematic / coding (verilog/vhdl)

Quote from: SerErris on 13:17, 27 January 22
And fruther looking at CPLD and the problem of gettin a truly 5V Tolerant (without any additional components around it) nowadays, I need to put in a coverter for the Inputs and also for the Video outputs, maybe for the clock outputs, I will try without clock outputs first.
Most PLD / FPGA big enough for the gate array are limited to 3.3V IO. 5V tolerant is fine, but it has its own constraints (sometime you need to make sure you never ever exceed 5.25V, which is something you might not be able to control on a CPC).
I personally use levelshifter on all (or most) signal. Video tristate use external buffer running on 5V, so you need to output 2 signal per color instead of 1.
Title: Re: Gate array decapped!
Post by: Bryce on 20:43, 27 January 22
Quote from: gerald on 17:00, 27 January 22
Yes, the data bus is input only.  There is no way to read from the GA.
On the PLD, your code defins wether its a input, output, bidir, tristate. So, no it does not requires special handling. Just proper schematic / coding (verilog/vhdl)
Most PLD / FPGA big enough for the gate array are limited to 3.3V IO. 5V tolerant is fine, but it has its own constraints (sometime you need to make sure you never ever exceed 5.25V, which is something you might not be able to control on a CPC).
I personally use levelshifter on all (or most) signal. Video tristate use external buffer running on 5V, so you need to output 2 signal per color instead of 1.

Zener Diodes are your cost effective best friend when it comes to ensuring that 5.25V (or whatever threshold you have) is not exceeded.

Bryce.
Title: Re: Gate array decapped!
Post by: rpalmer on 21:04, 27 January 22
Quote from: gerald on 17:00, 27 January 22Yes, the data bus is input only.  There is no way to read from the GA.

For the 6128 GA this is wrong as the GA also has to also issue the memory management data to the PAL chip, so the data bus on the GA is bi-directional.

rpalmer
Title: Re: Gate array decapped!
Post by: gerald on 21:26, 27 January 22
Quote from: rpalmer on 21:04, 27 January 22
For the 6128 GA this is wrong as the GA also has to also issue the memory management data to the PAL chip, so the data bus on the GA is bi-directional.

rpalmer
Did ever you had a look at the 6128 schematic  ?
Memory extension management is solely done by the PAL, which is connected to the Z80 for its register (same IO port as the gate array, but with D[7:6] high) and just intercept the A[15:14]/cas/ wr signal to the DRAM to handle the ramdis (lacking in a 464/664), split cas in cas0/cas1 for each bank, and the RAM mapping.

There is no, and no need for, bidirectional data between the GA and the PAL.

Title: Re: Gate array decapped!
Post by: robcfg on 00:11, 28 January 22
There are 464 and 6128 boards supporting both 40007/8 and 40010 gate arrays, so they don't have anything to do with memory management, that's the PAL function.
Title: Re: Gate array decapped!
Post by: rpalmer on 04:10, 28 January 22
Quote from: gerald on 21:26, 27 January 22Did ever you had a look at the 6128 schematic  ?
Memory extension management is solely done by the PAL, which is connected to the Z80 for its register (same IO port as the gate array, but with D[7:6] high) and just intercept the A[15:14]/cas/ wr signal to the DRAM to handle the ramdis (lacking in a 464/664), split cas in cas0/cas1 for each bank, and the RAM mapping.

There is no, and no need for, bidirectional data between the GA and the PAL.

I do not think you fully understand how the 6128 GA works.
So how does the 6128 PAL get the data to know what bank of memory is in play? ???
It certainly does not comes from the Z80 (as it has no idea about memory management on ANY system) and there is no latch of &7Fxx anywhere on the schematic for a 6128!

rpalmer
Title: Re: Gate array decapped!
Post by: pelrun on 06:02, 28 January 22
@Gerald is right, there is no communication from the GA to the PAL. *Both* devices are enabled by bus IO writes when A15 is 0 and A14 is 1; which one is actually affected is determined by the values of D7 and D6. The schematic shows the PAL is connected to all of these signals; there is zero need for external decoding because the PAL can do that all internally.

"It certainly does not come from the Z80" is a nonsense, *all* hardware configuration comes from IO writes done by the Z80! How else does software work?
Title: Re: Gate array decapped!
Post by: gerald on 08:18, 28 January 22
Quote from: rpalmer on 04:10, 28 January 22
I do not think you fully understand how the 6128 GA works.
So how does the 6128 PAL get the data to know what bank of memory is in play? ???
It certainly does not comes from the Z80 (as it has no idea about memory management on ANY system) and there is no latch of &7Fxx anywhere on the schematic for a 6128!

rpalmer
Have a look there : https://www.cpcwiki.eu/index.php/PAL16L8
The Q equation translate to a DFF containing bit D[2:0] of the RMR Register). These 3 Q signal are driving the 3 unconnected pad of the PAL. You may check by yourself.
They keep the minimum information required to do the 64k extension memory management (ie ignoring the bank number).
Title: Re: Gate array decapped!
Post by: rpalmer on 11:15, 28 January 22
Quote from: pelrun on 06:02, 28 January 22@Gerald is right, there is no communication from the GA to the PAL. *Both* devices are enabled by bus IO writes when A15 is 0 and A14 is 1; which one is actually affected is determined by the values of D7 and D6. The schematic shows the PAL is connected to all of these signals; there is zero need for external decoding because the PAL can do that all internally.

"It certainly does not come from the Z80" is a nonsense, *all* hardware configuration comes from IO writes done by the Z80! How else does software work?

Quote from: gerald on 08:18, 28 January 22Have a look there : https://www.cpcwiki.eu/index.php/PAL16L8
The Q equation translate to a DFF containing bit D[2:0] of the RMR Register). These 3 Q signal are driving the 3 unconnected pad of the PAL. You may check by yourself.
They keep the minimum information required to do the 64k extension memory management (ie ignoring the bank number).

Now people both of you are wrong!

See attached schematic portion showing the PAL.
You can see the there is data lines going into the PAL (no argument there to control memory configuration).

So where does these come from?

A Z80 I/O write for the memory configuration is with:

out &7fxx,&C0 + configuration_bits_0_to 5

Where is this data captured? There is no specific latch so you guessed right and its the GA.

Now when the GA controls accesses of memory on a 6128 it issues the PAL data during the RAS-CAS processing (specifically the RAS half, see word doc).
Thus the GA needs bi-directional data lines!!!!!
Title: Re: Gate array decapped!
Post by: pelrun on 12:50, 28 January 22
Quote from: rpalmer on 11:15, 28 January 22
Now people both of you are wrong!
So you don't understand how the circuit works, but you're convinced we're wrong?  :picard2:
Quote
You can see the there is data lines going into the PAL (no argument there to control memory configuration).
So where does these come from?

A Z80 I/O write for the memory configuration is with:

out &7fxx,&C0 + configuration_bits_0_to 5
No, only 3 bits are captured, D0-D2. The memory configurations are &C0 to &C7, D3 and D4 are not set in any of them. External memory expansions disable the internal upper 64k entirely and replace it with their own.

Quote
Where is this data captured? There is no specific latch so you guessed right and its the GA.
INSIDE THE PAL. It can describe flip-flops (and Gerald even pointed you right at the equations), not just combinatorial logic. Holding 3 bits is trivial.
Quote
Now when the GA controls accesses of memory on a 6128 it issues the PAL data during the RAS-CAS processing (specifically the RAS half, see word doc).
Thus the GA needs bi-directional data lines!!!!!
As stated, ALL the state the PAL needs it already has. The only control the GA does of memory accesses is generating the timing signals, the PAL supplies A14OUT and A15OUT itself which ultimately determine which memory chips are selected.
Don't pick and choose what parts of the schematic you're taking as gospel - the directional arrows on the bus signals are just as authoritative as the rest of the diagram.
Title: Re: Gate array decapped!
Post by: Bread80 on 18:34, 28 January 22

This image shows the GA signals during an IO read:
(https://bread80.com/wp50/wp-content/uploads/2021/05/RigolDS33IORQRead-768x410.png)



(From my article at https://bread80.com/2021/06/03/understanding-the-amstrad-cpc-video-ram-and-gate-array-subsystem/ )

If the GA where to output data then it would need to drive /RAMRD low to latch the data into IC114. And, in any case, it issues a /244EN signal for /any/ IO operation - read or write - which would mess up any data being sent by the GA.

And if the RAM address decoding where being done by the GA then there wouldn't be any need for the HAL. They'd just need to add the /CAS0 and /CAS1 signals (on place of /CAS).

And, if the HAL isn't latching any data, ask yourself why it need a RESET input.
Title: Re: Gate array decapped!
Post by: Animalgril987 on 19:05, 28 January 22
@gerald (https://www.cpcwiki.eu/forum/index.php?action=profile;u=250)  @pelrun (https://www.cpcwiki.eu/forum/index.php?action=profile;u=1106)  and @Bread80 (https://www.cpcwiki.eu/forum/index.php?action=profile;u=4222)  are correct.
D0, D1 and D2 going into PAL come from Z80 data bus, not GA.
The line "D6 and D7" come from an AND gate gate that combines the Z80 D6 and D7 lines, so that the PAL only listens to  I/O when GA doesn't.
Title: Re: Gate array decapped!
Post by: dragon on 22:00, 28 January 22
This  nothing to do with the cpld discussion.


I have found a catalog from ferranti in 1984.


The catalog have the 20RA specification.


[size=78%]Ferranti Quick Reference Guide 1984, ULA Section (archive.org) (https://ia902903.us.archive.org/3/items/FerrantiQ.RefULA1984/Ferranti%20Q.%20Ref%20ULA%201984.pdf)[/size]
Title: Re: Gate array decapped!
Post by: rpalmer on 00:40, 29 January 22
ok people, I have just read the PDF for the PAL and find it does clock its data, so it is my bad thinking that since there there was no latch in the schematic and assumed that the data could only come form the GA.
I am thanking those to put me in the correct place to understand the subject.
Title: Re: Gate array decapped!
Post by: SerErris on 12:06, 29 January 22
@gerald (https://www.cpcwiki.eu/forum/index.php?action=profile;u=250)

Looking at the schematics from you again and comparing to the verilog code in MISTER implementation (which is a port from the schematic) I realize a difference, I like to understand.


Topic: Registers and where do the flipflops get its clock signal from.


Looking at the schematics it looks like that the registers are build by D-FlipFlops with Set and Reset (not all signals are connected) and clock is "enable". So they are not really clocked in terms of directly clocked by the 16mhz clock. Instead they are clocked by the sequencer (+ some other conditions) by U401.

So in essence as S0 and S7 are only high turing one cycle of the sequencer (FFh), they are actually clocked at 1mhz with a 1/16th active time. That makes sense as the data is only valid for that amount of time (4 clocks of the Z80 for any operation) which runs at 4MHz. ...

So I think I did understand how the GA works internally.


However looking at the code from MISTER it clocks much higher (16MHz).




////// REGISTERS /////

reg  [4:0] inksel;
reg  [4:0] border;
reg  [4:0] inkr[16];
wire       irq_reset;
reg        hromen;
reg        lromen;
reg        mode1;
reg        mode0;

wire       reg_latch = (S[0] & S[7]) | (fast & ~E244_N);
wire       reg_sel   = reg_latch & ~IORQ_N & ~A[15] & A[14] & M1_N;
wire       ink_en    = reg_sel & ~D[7] & ~D[6];
wire       border_en = reg_sel & ~D[7] &  D[6] &  inksel[4];
wire       ctrl_en   = reg_sel &  D[7] & ~D[6];
wire       inkr_en   = reg_sel & ~D[7] &  D[6] & ~inksel[4];

assign     irq_reset = ctrl_en & D[4];

always @(posedge clk) begin
    if (ink_en) inksel <= D[4:0];
    if (reset) border <= 5'b10000; else if (border_en) border <= D[4:0];
    if (reset) {hromen, lromen, mode1, mode0} <= 0;
    else if (ctrl_en) {hromen, lromen, mode1, mode0} <= D[3:0];
    if (inkr_en) inkr[inksel[3:0]] <= D[4:0];
end

assign MODE = {mode1, mode0};
So I think that again has to do with the "FAST" mode they implemented in the FPGA CPC version. But for my CPLD I think it should more look like that:

////// REGISTERS /////

reg  [4:0] inksel;
reg  [4:0] border;
reg  [4:0] inkr[16];
wire       irq_reset;
reg        hromen;
reg        lromen;
reg        mode1;
reg        mode0;

wire       reg_en = (S[0] & S[7] & ~IORQ_N & ~A[15] & A[14] &M1_N;
wire       ink_en    = ~D[7] & ~D[6];
wire       border_en = ~D[7] &  D[6] & inksel[4];
wire       ctrl_en   = D[7] & ~D[6];
wire       inkr_en   = ~D[7] &  D[6] & ~inksel[4];

assign     irq_reset = ctrl_en & D[4];

always @(posedge reg_en) begin
    if (ink_en) inksel <= D[4:0];
    if (reset) border <= 5'b10000; else if (border_en) border <= D[4:0];
    if (reset) {hromen, lromen, mode1, mode0} <= 0;
    else if (ctrl_en) {hromen, lromen, mode1, mode0} <= D[3:0];
    if (inkr_en) inkr[inksel[3:0]] <= D[4:0];
end

assign MODE = {mode1, mode0};
I know it is pretty much analog, but more direct implementation of the schematic with some simplifications (e.g. the inkr_en directly derived from the original signals than  doing all the real logic like in the chip)

Title: Re: Gate array decapped!
Post by: gerald on 13:05, 29 January 22
Quote from: SerErris on 12:06, 29 January 22
Looking at the schematics from you again and comparing to the verilog code in MISTER implementation (which is a port from the schematic) I realize a difference, I like to understand.
In the GA the registers are implemented a latches (hence the enable input), which requires less gate to be implemented and are OK for their purpose.
In the mister code, the use a DFF with an enable. Using latches in FPGA is not recomended.
Title: Re: Gate array decapped!
Post by: SerErris on 10:34, 01 February 22

@gerald (https://www.cpcwiki.eu/forum/index.php?action=profile;u=250)


I am not sure if that has been mentioned, but there is a small bug in the latest schematic (v3 afaik).


On the overall cover sheet there is one wire missing from VSync to ColourDecode. It is in both individual schematics of the modules, but missing in the overall GA module.


Signal is hcntlt28 and it also missing on the outputs list of the VSync module.


All on Page 1/18.


Not sure if you have this already corrected in a later version. So if done so - disregard my input :-)
Title: Re: Gate array decapped!
Post by: gerald on 18:41, 01 February 22
Quote from: SerErris on 10:34, 01 February 22
Not sure if you have this already corrected in a later version. So if done so - disregard my input :-)
Well spotted. I'm wondering how I got this ,missing. Fixed in the kicad file. I'll upload the fixed pdf later.
Title: Re: Gate array decapped!
Post by: slingshot on 16:26, 20 February 22
Quote from: SerErris on 12:06, 29 January 22

However looking at the code from MISTER it clocks much higher (16MHz).

The schematics cannot be translated to FPGA 1:1. Async logic won't pass timing closure, and will have erratic behavior. It had to be translated to synchronous logic, which might need changes like "thinking ahead" what will happen on the next cycle. But I left the original logic also in the source code, to cross-check in a simulator. However Verilator also not designed to deal with asynchronous logic fully, so there might be some unexpected glitches even when the circuit is simulated.
PS: I did the GA for MiST (and MiSTer) from Gerald's schematics (40010-simplified_V03.pdf - is this the latest?).
Title: Re: Gate array decapped!
Post by: gerald on 18:36, 23 February 22
Quote from: slingshot on 16:26, 20 February 22The schematics cannot be translated to FPGA 1:1. Async logic won't pass timing closure, and will have erratic behavior. It had to be translated to synchronous logic, which might need changes like "thinking ahead" what will happen on the next cycle. But I left the original logic also in the source code, to cross-check in a simulator. However Verilator also not designed to deal with asynchronous logic fully, so there might be some unexpected glitches even when the circuit is simulated.
Async logic in FPGA is mainly a tool support issue. For sure, timing closure is a mess as you have tons of different clocks and modern design is full synchronous for good reasons, mainly predictable timing and tests.
It's not a big deal to convert an asynchronous design to synchronous. Converting latches to DFF may sometime lead to functional differences.

Quote from: slingshot on 16:26, 20 February 22PS: I did the GA for MiST (and MiSTer) from Gerald's schematics (40010-simplified_V03.pdf - is this the latest?).
Yes. The only fix I did is that missing wire on the top level page.
Title: Re: Gate array decapped!
Post by: slingshot on 21:38, 23 February 22
QuoteAsync logic in FPGA is mainly a tool support issue. For sure, timing closure is a mess as you have tons of different clocks and modern design is full synchronous for good reasons, mainly predictable timing and tests.
It's not a big deal to convert an asynchronous design to synchronous. Converting latches to DFF may sometime lead to functional differences.

I don't fully agree. During the old days, they even checked timings manually on the mylar sheet by measuring traces length. In an FPGA synthesis, you must write very complicated sdc files to achieve this. And FPGAs has dedicated clock networks, if you're (ab)using dozens of clocks, they'll surely exhausted.
Converting sometimes is not straightforward, e.g. acting on a generated clock edge in a master clock domain need to think ahead about what will happen in the next cycle. And it's OK until there's no external signal, which affects the result, but if there is (like a CPU written register value), then things can easily go complicated.

QuoteYes. The only fix I did is that missing wire on the top level page.
Great! I want to say thanks for your work.
Title: Re: Gate array decapped!
Post by: slingshot on 21:50, 23 February 22
I remember one particular think, which was very tricky: MODE_SYNC
As it's a clock generated by a ripple counter, it was really a mess how it worked with a simultaneous clear signal on the same D-flip-flop (U818). It's happening when the hsync length from the CRTC is 2 clock wide, then MODE_SYNC just produces a very short pulse. It's a nightmare and totally unpredictable if you implement it 1:1 in FPGA.
Title: Re: Gate array decapped!
Post by: slingshot on 22:39, 23 February 22
Quote from: SerErris on 19:12, 24 January 22And we do have the clock output with positive and negative edge ... not sure why. So this is already 6 lines that should not be there.. There is for instance a Mode output .. (2bit ? ) ..
Those are clock enables for synchronous external modules in a SoC design. If you don't need those - then don't use them. The actual clocks are also exposed. If you check them out in a simulator, you can see the clock enable relationship with the original clocks (one master cycle earlier than the clock edge).
Title: Re: Gate array decapped!
Post by: SerErris on 16:15, 24 February 22
Thanks @slingshot for coming back to me on that.

Anyhow I can only experiment a little as there is no way to aquire a suitable CPLD right now. Non of them can get delivered. They are either to small or far to large (footprint wise)... 
Title: Re: Gate array decapped!
Post by: issalig on 11:47, 01 June 22
I have just discovered this functional Gate Array project (warning:work in progress). Not sure if the author is someone from here.

https://github.com/codedchip/AMSGateArray
Title: Re: Gate array decapped!
Post by: CaptainRon on 05:44, 23 July 22
Is there any real difference between the 40010 and 40007 logic? I assembled some of Darren Johnstone's boards that @issalig posted above and it is so close but not quite right. I'm wondering if there is some slight difference in timings or something else that could account for the issue? I have documented the issue a bit on the Github page ( https://github.com/codedchip/AMSGateArray/issues/4 ). I have now tried with two CPLD chips and made sure to do excellent solder work with quality 2% silver bearing solder under a Meiji EMZ-5 inspection microscope, especially on the second one. Both chips gave the same result on my Schneider CPC464. People are reporting success on the 40010 but I seem to be the first to test the 40007. Any ideas?

(https://user-images.githubusercontent.com/109708692/180115535-bef9d79a-8842-429b-8644-c50525f497c8.jpg)

(https://user-images.githubusercontent.com/109708692/180115661-8c90e8f2-cd8c-4143-925e-bd39d47ad391.jpg)

(https://user-images.githubusercontent.com/109708692/180129230-4b2d6ba5-f3fe-4eda-b74d-96e773fc5a91.jpg)
Title: Re: Gate array decapped!
Post by: robcfg on 08:29, 23 July 22
In theory, the only difference between gate arrays is the fabrication process and the pin assignments.

That is, you could take a 40010 and make an adapter to make it fit the 40007 socket, and it should work exactly the same.
Title: Re: Gate array decapped!
Post by: dragon on 09:06, 23 July 22
You have rehused a mainboard that originally have a 40010?.

There are slightly diferencies en resistance valors.when one or other gate array are mounted.

Check this service manual.

https://acpc.me/ACME/DOCS_TECHNIQUES/SERVICE_MANUALS/CPC464_neue_Platinenversion_SCHNEIDER_Service_Manual%5BENG%5D%5BGER%5D%28acme%29.pdf
Title: Re: Gate array decapped!
Post by: issalig on 09:26, 23 July 22
I have built the 40010 version and it works on a 6128. The 40007 just seems to have a different pinout
Title: Re: Gate array decapped!
Post by: CaptainRon on 10:18, 23 July 22
My original 40007 works perfectly. I have checked the pins.ucf_40007 file against the 40007 pinout here at cpcwiki and against the gerber file. everything looks correct. I originally thought it might be a low voltage issue but I checked voltages on pins 9 and 38, both are 5v, and the CPLD is getting 3.5v. When I power it on I get a lot of garbage on the screen and sometimes it stays running long enough to test good for beep with the delete key or enter a few characters before it resets or freezes. sometimes it tries to initialize the cassette drive with a relay click, or shows ***program failed to load***. I tested with a different CRTC also with the same results. 

I wonder if it is an issue with logic levels on the old LS series vs. HC series, or if there is some slight timing issue? I am fairly certain it is not an issue with the assembly of the board because it did the same with two different CPLD chips. I have some from a different batch but I hate to keep using these expensive chips unless someone thinks it is possible that I got a bad batch. they programed with no issues though  
Title: Re: Gate array decapped!
Post by: CaptainRon on 10:43, 23 July 22
@dragon it is an old Schneider 464 with 40007 from factory and still works perfectly with the original chip. Which resistors are you referring to in the manual? I thought this was interesting

 Amendment to CPC464: 16.5.85
1. IC 125 LS7400E. It has been changed to 74HCUO4.

Mine has an old Ferranti hex inverter, I can't find much info on it but my guess is it is probably an LS series chip. I wonder if the 3.5v logic levels of the CPLD are just barely enough to trip the gates and its just twitching out between high and low? I have some Texas Instruments level shifter chips here, what signals are necessary to shift between 5v and 3.5v? Maybe I can try to dead bug wire some shifters between the CPLD board and a set of pin headers?
Title: Re: Gate array decapped!
Post by: dragon on 11:01, 23 July 22
In page 4 in the upper left there is a little table that tell mk4 ferranti resistors value and sgs (40010) resistors value.

Also in the last page at finish there is another table.

If you need know details about the ula was a ra043 the 5000 series ferranti  ula, it's described in the book of the zx spectrum how build a micromputer

That's another thing just curious. How your cpld works with VRAM Rasterization timings?.

https://www.grimware.org/doku.php/documentations/devices/gatearraydo=export_xhtml

(go to the finish part of the page there is a program there to test it).


Title: Re: Gate array decapped!
Post by: CaptainRon on 11:33, 23 July 22
It is not stable enough to run more than a few seconds before locking up. every once in a while I can type a few characters or test the beep with the delete key, but that is it. I cant type in the program before it will lock up. I can connect a logic analyzer or o-scope if there are any specific signals you are interested in.
Title: Re: Gate array decapped!
Post by: robcfg on 18:21, 23 July 22
LS and HC have different activation levels, that could be definitely an issue.
Title: Re: Gate array decapped!
Post by: Bread80 on 17:40, 24 July 22
LS series logic requires a signal higher than about 2V to register a logic high.
For HC series that requirement is 3.15V when running at 4.5V, and will be higher at higher supply voltages.
And, having just checked, that HCU04 requires a signal of over 3.6V. Although the 6128 schematics show a pull up to 5V - R140 (1k), but maybe that changes on different board revisions.

And I've only just noticed that the schematic okays both LS and HC logic. In that case any GA replacement will need to be outputting 5V to work properly across all machines.

Title: Re: Gate array decapped!
Post by: CaptainRon on 10:28, 26 July 22
I ordered a replica 464 and 6128 board from Rob Taylor (PeepoUK). My plan is to build up the 2 replica boards and test the CPLD gate array on both. I will put my original 464 back in stock condition and keep it put up. These old CPC computers are rare as hen teeth here in the USA, so I will just use the replica boards for the tests when they arrive. I will post here again with my results
Title: Re: Gate array decapped!
Post by: codedchip on 13:38, 04 August 22
Quote from: Bread80 on 17:40, 24 July 22LS series logic requires a signal higher than about 2V to register a logic high.
For HC series that requirement is 3.15V when running at 4.5V, and will be higher at higher supply voltages.
And, having just checked, that HCU04 requires a signal of over 3.6V. Although the 6128 schematics show a pull up to 5V - R140 (1k), but maybe that changes on different board revisions.

And I've only just noticed that the schematic okays both LS and HC logic. In that case any GA replacement will need to be outputting 5V to work properly across all machines.


From my checking on a 464 I have managed to get hold of I'd say that I should have incorporated level shifters on the board to get to a 5V output. That's likely all that's wrong with it. I'll spin another revision incorporating those.

That said, as I mentioned in GitHub, the purpose of the boards is to test the verilog. I'm now pretty confident that works and I'm sure someone else would be able to do a better job of the physical boards anyway. The verilog source for my purposes has moved beyond the prototype boards and is now part of a bigger project I'm working on to make a replacement motherboard, where I can control the logic chips and also use the "opened up" GA to provide expansions.

So, I'll create a new revision with level shifters and try it on a 464 and publish it on GitHub. I'll also convert to kicad while I'm at it.
Title: Re: Gate array decapped!
Post by: revaldinho on 17:00, 04 August 22
QuoteSo, I'll create a new revision with level shifters and try it on a 464 and publish it on GitHub. I'll also convert to kicad while I'm at it.
Thanks for making all of this work available on GitHub.

If you're making a small batch of these revised boards then I would be interested in getting one.

I have a request though - could there be an additional row of in-line pins, say 5 or so, to give direct access to unused CPLD IOs ? It would be handy/fun for experimenting with customizations of the GA to be able to bring in other signals which aren't in the standard pin-out.

Also, in the schematic there is only one 220nF cap on VCCIO with nothing at all on VCC. Xilinx recommend one 0.1uF cap per VCC pin close to the CPLD for high speed designs. Now this isn't a 100MHz+ design, but even so, it would be good to have a couple more closer to the CPLD with dedicated caps on both VCCIO and VCC. Perhaps make pads available on the back of the board if otherwise there are restrictions on single-sided assembly.
Title: Re: Gate array decapped!
Post by: codedchip on 18:55, 04 August 22
No problem. I can do that. Thanks so much for the feedback. PM me, I'll be happy to send you a test board.

Title: Re: Gate array decapped!
Post by: CaptainRon on 17:18, 06 August 22
@codedchip This is great news, I can't wait to see more of your work! I'm looking forward to the Kicad/Eagle replacement board files with CPLD integration too.

I'm currently building out the new boards I ordered from Rob Taylor (PeepoUK). I want to rule out any issues with old marginal components not playing well with the current CPLD gate array. 
Title: Re: Gate array decapped!
Post by: CaptainRon on 00:20, 07 August 22
OK I just finished building up the new 464 board. I can confirm that the issue persists using a replica 464 #270100 board. It works fine using an original 40007, but has the exact same issue as before with the rev.1 CPLD gate array. I think that rules out some marginal component issue, although I did pull 2 logic chips (74ls273, and 74ls244), ROM, and the PIA from the original board because I am still waiting on spares. Everything else was ordered new from Mouser and whatever I couldn't get from them I found on ebay. I will test again when I get enough spares so that nothing from the original system is reused, but at this point I am convinced it is an issue of level shifting that will be corrected on @codedchip next revision. 
Title: Re: Gate array decapped!
Post by: issalig on 14:52, 08 August 22
@codedchip , I built a (non smd, see photo) 40100 replacement and I have some tips for future versions of the pcb

I have a 6128 version MC0020H, and there is a metal pin down the 400010 that slightly touching the cpld pcb. Could you make the pcb 1 mm smaller?

You can take a look at the cpc 6128 pcb in the link below
https://www.cpcwiki.eu/imgs/0/0b/Z70290_MC0020H_PCB_Top.jpg

I used an easy to source ams1117 instead of the mcp , I think it could be a good idea to also include the footprint for ams1117

Title: Re: Gate array decapped!
Post by: codedchip on 15:05, 08 August 22
Thanks for the feedback @issalig. I'll make the PCB smaller in the next version.
Title: Re: Gate array decapped!
Post by: GUNHED on 15:03, 10 August 22
You can buy it here:

https://www.sellmyretro.com/offer/details/62319
Title: Re: Gate array decapped!
Post by: TotO on 18:24, 10 August 22
Currently, it is more interresting to buy a real 40010.
Title: Re: Gate array decapped!
Post by: GUNHED on 21:55, 10 August 22
Right, but I couldn't find any stock of that chip on the net.
Title: Re: Gate array decapped!
Post by: dragon on 22:12, 10 August 22
Quote from: GUNHED on 21:55, 10 August 22Right, but I couldn't find any stock of that chip on the net.
https://www.icompplus.com/es/circuitos-integrados/12619/40010-ic-dip-40-1011944

https://www.icompplus.com/es/circuitos-integrados/32243/40007-ic-dip-40-1030173
Title: Re: Gate array decapped!
Post by: eto on 22:29, 10 August 22
Quote from: dragon on 22:12, 10 August 22
Quote from: GUNHED on 21:55, 10 August 22Right, but I couldn't find any stock of that chip on the net.
https://www.icompplus.com/es/circuitos-integrados/12619/40010-ic-dip-40-1011944

https://www.icompplus.com/es/circuitos-integrados/32243/40007-ic-dip-40-1030173
Has someone ever ordered them there? If they really have almost 200 40007 and almost 300 40010, why does everybody think there is a shortage of these chips?

Title: Re: Gate array decapped!
Post by: dragon on 23:48, 10 August 22
Quote from: eto on 22:29, 10 August 22
Quote from: dragon on 22:12, 10 August 22
Quote from: GUNHED on 21:55, 10 August 22Right, but I couldn't find any stock of that chip on the net.
https://www.icompplus.com/es/circuitos-integrados/12619/40010-ic-dip-40-1011944

https://www.icompplus.com/es/circuitos-integrados/32243/40007-ic-dip-40-1030173
Has someone ever ordered them there? If they really have almost 200 40007 and almost 300 40010, why does everybody think there is a shortage of these chips?


Hey eto, no but they are in my city. If it's false I can go to the polygone and give them a good rant with the gx4000 hockey stick :laugh:
 
Or I can order something and pick up  in person. But I don't need a gate array. 

Title: Re: Gate array decapped!
Post by: CaptainRon on 04:38, 13 August 22
@dragon I will order a 40010 and a 40007 if you can pickup local and test if they are legitimate for us. They want between 40€ and 75€ just for shipping to USA so that's not gonna work for me, but they do have free local pickup. We have all been wondering for a long time if this supplier is for real, so this is a chance to find out once and for all.
Title: Re: Gate array decapped!
Post by: dragon on 11:07, 13 August 22
I can, but don't now. Mostly because they are closed from vacation from 10-22 august.
Title: Re: Gate array decapped!
Post by: dragon on 22:32, 13 August 22
How much does 40007 and 40010 weigh?
Title: Re: Gate array decapped!
Post by: CaptainRon on 00:49, 14 August 22
a few grams
Title: Re: Gate array decapped!
Post by: dragon on 23:02, 16 August 22
I need ask how export works(if is need  paid something extra and so.).

But apart of that I think with the tricky of use certificate letter.  Can be sended for 10e o less to USA. Weight dependant.



https://www.correos.es/content/dam/correos/documentos/atc/tarifas/2022/TARIFARIO-WEB_Peninsula-Baleares_2022.pdf

Check page 05 right corner down.
Title: Re: Gate array decapped!
Post by: CaptainRon on 03:28, 17 August 22
Yes, I'm sure it should be fairly inexpensive to post. I'm most interested in determining if this supplier is legitimate or not. With the new CPLD option it will certainly ease the necessity to source original chips, but it would be nice to see if the source actually is legitimate and has a good stock of chips available.  
Title: Re: Gate array decapped!
Post by: dragon on 13:24, 19 August 22
They open this Monday when do you want. 
Title: Re: Gate array decapped!
Post by: CaptainRon on 21:55, 19 August 22
I can go ahead and place the order for a 40007 and a 40010 then send you the invoice for pickup if you like. Or you can let me know what works best for you, anytime is fine by me. 
Title: Re: Gate array decapped!
Post by: dragon on 09:41, 20 August 22
Place the order and send me the in voice. I'll go  when I can next week at the end of the week

Ahh and  do another thing please.

The web page tells that you can send it a message for any product and request the datasheet. So please request the datasheet of the gate arrays!.

"You can request the datasheet of any electronic component that you find in our store, we will send it to you in less than 24H."
"
Title: Re: Gate array decapped!
Post by: CaptainRon on 08:18, 21 August 22
@dragon their page is giving me errors when i try to checkout and is not letting me complete the transaction :picard:

I also sent a message asking for datasheets.

lets continue this in private messages until we have a firm answer if the chips are legitimate. I think sourcing old stock is off topic for this thread about reverse engineering the GA.
Title: Re: Gate array decapped!
Post by: CaptainRon on 21:03, 07 September 22
Good news, we can confirm that the original 40010 supply is real. @dragon hasn't been able to test the 40007 yet, but I'm sure when he does he will make a follow up post. 
Title: Re: Gate array decapped!
Post by: TotO on 08:38, 08 September 22
Good price for the 40007, insane for the 40010. It is old stock, no reason to be fake ICs.
Title: Re: Gate array decapped!
Post by: dragon on 16:24, 08 September 22
They include 3 month warranty in case they don't work.






Powered by SMFPacks Menu Editor Mod