- Top Stats

Top Posters Top Topic Starters Top Topics
Bryce 5279
TFM 2507
Gryzor 2255
arnoldemu 1273
TotO 1166
Bryce 90
arnoldemu 70
Gryzor 42
LambdaMike... 37
CraigsBar 35
Amstrad CPC WiFi - 282229 Views Duke 09:36, 07 May 16
CPC Plus cartr... - 207995 Views gerald 17:39, 01 November 14
ACID chip inside - 81366 Views MacDeath 15:52, 23 October 09
Gotek USB in a... - 69895 Views gryzor 18:01, 18 March 14
Pros & Con... - 58334 Views CPCIak 15:07, 11 May 10


Author Topic: Gate array decapped!  (Read 32119 times)

0 Members and 1 Guest are viewing this topic.

Offline Bryce

  • The Hardware Guy.
  • Supporter
  • 6128 Plus
  • *
  • Posts: 10.738
  • Country: wf
  • It's not broken, it just hasn't been fixed yet.
    • index.php?action=treasury
  • Liked: 3739
Re: Gate array decapped!
« Reply #200 on: 15:31, 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.
« Last Edit: 15:33, 25 November 16 by Bryce »

Offline dragon

  • 6128 Plus
  • ******
  • Posts: 1.325
  • Country: es
  • Liked: 558
Re: Gate array decapped!
« Reply #201 on: 12:08, 26 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.
« Last Edit: 12:19, 26 November 16 by dragon »

Offline robcfg

  • Supporter
  • 6128 Plus
  • *
  • Posts: 2.103
  • Country: se
  • 8-Bit Technomancer
    • index.php?action=treasury
  • Liked: 915
Re: Gate array decapped!
« Reply #202 on: 02:08, 19 November 17 »
Hi folks!


I just wanted to say that I uploaded the decapped ACID chip to the wiki page.


Cheers,
Rob

Offline Gryzor

  • Administrator
  • 6128 Plus
  • *****
  • Posts: 14.809
  • Country: gr
  • CPC-Wiki maintainer
    • CPCWiki
  • Liked: 2835
Re: Gate array decapped!
« Reply #203 on: 10:03, 19 November 17 »
Oh, you're the one who broke the db with this big beauty :D

Offline robcfg

  • Supporter
  • 6128 Plus
  • *
  • Posts: 2.103
  • Country: se
  • 8-Bit Technomancer
    • index.php?action=treasury
  • Liked: 915
Re: Gate array decapped!
« Reply #204 on: 10:13, 19 November 17 »
Everything’s legal!


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


 ;D

Offline Bryce

  • The Hardware Guy.
  • Supporter
  • 6128 Plus
  • *
  • Posts: 10.738
  • Country: wf
  • It's not broken, it just hasn't been fixed yet.
    • index.php?action=treasury
  • Liked: 3739
Re: Gate array decapped!
« Reply #205 on: 09:36, 20 November 17 »
Looks like a simple gate array.

Bryce.

Offline Gryzor

  • Administrator
  • 6128 Plus
  • *****
  • Posts: 14.809
  • Country: gr
  • CPC-Wiki maintainer
    • CPCWiki
  • Liked: 2835
Re: Gate array decapped!
« Reply #206 on: 09:37, 20 November 17 »
What should it look like?

Sent from my HTC 10 using Tapatalk


Offline Bryce

  • The Hardware Guy.
  • Supporter
  • 6128 Plus
  • *
  • Posts: 10.738
  • Country: wf
  • It's not broken, it just hasn't been fixed yet.
    • index.php?action=treasury
  • Liked: 3739
Re: Gate array decapped!
« Reply #207 on: 09:39, 20 November 17 »
Well it could have been an ASIC or a custom IC. This is the ACID, not the GA.

Bryce.

Offline Gryzor

  • Administrator
  • 6128 Plus
  • *****
  • Posts: 14.809
  • Country: gr
  • CPC-Wiki maintainer
    • CPCWiki
  • Liked: 2835
Re: Gate array decapped!
« Reply #208 on: 09:40, 20 November 17 »
Ah.

Sent from my HTC 10 using Tapatalk


Offline dragon

  • 6128 Plus
  • ******
  • Posts: 1.325
  • Country: es
  • Liked: 558
Re: Gate array decapped!
« Reply #209 on: 17: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?.

Offline gerald

  • Supporter
  • 6128 Plus
  • *
  • Posts: 1.342
  • Liked: 963
Re: Gate array decapped!
« Reply #210 on: 17:52, 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  ;)

Offline dragon

  • 6128 Plus
  • ******
  • Posts: 1.325
  • Country: es
  • Liked: 558
Re: Gate array decapped!
« Reply #211 on: 18:03, 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
« Last Edit: 18:15, 18 January 18 by dragon »

Offline gerald

  • Supporter
  • 6128 Plus
  • *
  • Posts: 1.342
  • Liked: 963
Re: Gate array decapped!
« Reply #212 on: 18:32, 18 January 18 »
Lastest posts

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  ;)

Offline dragon

  • 6128 Plus
  • ******
  • Posts: 1.325
  • Country: es
  • Liked: 558
Re: Gate array decapped!
« Reply #213 on: 21: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?

Offline robcfg

  • Supporter
  • 6128 Plus
  • *
  • Posts: 2.103
  • Country: se
  • 8-Bit Technomancer
    • index.php?action=treasury
  • Liked: 915
Re: Gate array decapped!
« Reply #214 on: 21:19, 18 January 18 »
That particular chip may be partially damaged.

Offline Duke

  • Supporter
  • 6128 Plus
  • *
  • Posts: 1.067
  • Country: dk
    • spinpoint.org
  • Liked: 1114
Re: Gate array decapped!
« Reply #215 on: 21: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 :)

Offline gerald

  • Supporter
  • 6128 Plus
  • *
  • Posts: 1.342
  • Liked: 963
Re: Gate array decapped!
« Reply #216 on: 22:15, 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:

Offline Bryce

  • The Hardware Guy.
  • Supporter
  • 6128 Plus
  • *
  • Posts: 10.738
  • Country: wf
  • It's not broken, it just hasn't been fixed yet.
    • index.php?action=treasury
  • Liked: 3739
Re: Gate array decapped!
« Reply #217 on: 09: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.

Offline jr

  • CPC464
  • **
  • Posts: 4
  • Country: de
  • Liked: 11
Re: Gate array decapped!
« Reply #218 on: 14: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

Offline jr

  • CPC464
  • **
  • Posts: 4
  • Country: de
  • Liked: 11
Re: Gate array decapped!
« Reply #219 on: 14: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].


Offline jr

  • CPC464
  • **
  • Posts: 4
  • Country: de
  • Liked: 11
Re: Gate array decapped!
« Reply #220 on: 14: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

Offline Gryzor

  • Administrator
  • 6128 Plus
  • *****
  • Posts: 14.809
  • Country: gr
  • CPC-Wiki maintainer
    • CPCWiki
  • Liked: 2835
Re: Gate array decapped!
« Reply #221 on: 14:22, 14 February 19 »
Man, that's a deep analysis.

Offline gerald

  • Supporter
  • 6128 Plus
  • *
  • Posts: 1.342
  • Liked: 963
Re: Gate array decapped!
« Reply #222 on: 18:14, 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.

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.

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.
« Last Edit: 18:29, 14 February 19 by gerald »

Offline jr

  • CPC464
  • **
  • Posts: 4
  • Country: de
  • Liked: 11
Re: Gate array decapped!
« Reply #223 on: 21: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

Offline gerald

  • Supporter
  • 6128 Plus
  • *
  • Posts: 1.342
  • Liked: 963
Re: Gate array decapped!
« Reply #224 on: 22:13, 18 February 19 »
   U304 = (S3 & !S6);   // AND instead of NAND
Confirmed

   CCLK = S2 & S5;   // AND instead of OR
I beg to differ  ;D It's a NOR.

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.
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.