Gate array decapped!

[VintageAdvantage]

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.

[Bryce]

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.

[CaptainRon]

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.

[CaptainRon]

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

[Bryce]

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.

[CaptainRon]

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.

[SerErris]

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

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

And this is how it looks like for the simulation see attachement

[SerErris]

Another question to the same above.

I pondering with the description on schematics for the sequencer.

It reads:

Sequencer 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]

[gerald]

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.

35 IO to be precise 

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?

Which source file are you looking at ?

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

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  .

[SerErris]

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


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.

[SerErris]

@Bryce @gerald 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
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 ...

[gerald]

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)

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.

[Bryce]

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.

[rpalmer]

Yes, 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

[gerald]

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.

[robcfg]

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.

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

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

[pelrun]

@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?

[gerald]

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

[rpalmer]

@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?

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

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

[pelrun]

Now people both of you are wrong!

So you don't understand how the circuit works, but you're convinced we're wrong? 

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.

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.

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.

[Bread80]

This image shows the GA signals during an IO read:




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

[Animalgril987]

@gerald  @pelrun  and @Bread80  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.

[dragon]

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)[/size]

[rpalmer]

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.