Hi, starting from the fantastic GateArray decapping thread, I am going to design a CPLD replacement.
I am still figuring out some stuff, but I will report here and ask questions and would appreciate any feedback and recommendations.
So current plan is the following.
Using an Intel MAX V 128 LEs gives me enough gates to fully implement the GAs.
I am choosing Intel as I alread do have the development environment available because of FPGA stuff.
5M160ZE64C5N is about 3,68€ if I buy a single one, which sounds absolutely reasonable for the project.
For the level conversion I am looking at those devices (TTL to LVTTL) CY74FCT2827T which are 10 bit Buffers ... I originally thought I would need to convert any input, but learning now, that many PINs are actually pulled up in the gate array. So they would not require any conversion, as high is just what they gate array pulls them up to.
Inputs with Pullups:
WREQ
M1
RD
IORQ
Output with Pullups:
Ready
PHI (Z80 clock) (passive pull up? What does that mean?)
Interrupt
All the rest of the output input and output lines looks like driven by someone to high or low (e.g. RAM is driving to high and low).
Please correct anything I got wrong here.
Now some direct questions regards CPLD:
If I have an input Pullup ? Is there anything I need to select on the input?
Would I need to pull them up externally? I cannot see any pullup (or choices) on the MAX V.
Hi,
are you aware that @gerald (https://www.cpcwiki.eu/forum/index.php?action=profile;u=250) has a CPLD (or it may be an FPGA) replacement design already finished?
Bryce.
No I am not. All my googeling has not shown anything.
So we do already have a complete solution (PCB, programmable device, BOM + the code?)
I am aware of the code, but not aware there is anything ready to get produced.
Do you have a link ... if that is obsolete work, than I would stop it.
The only thing I found is this here:
https://forum.system-cfg.com/viewtopic.php?t=11695 (https://forum.system-cfg.com/viewtopic.php?t=11695)
But that is neither ready yet, nor is it public (you build or buy it).
https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/a-minimal-gate-array/msg198585/#msg198585
Not yet public, but completed.
Bryce.
Not public yet and due to the current component sourcing mess I can't make some for beta testing :picard: In the mean time, I am thinking of a way to update it from the CPC itself, in case of bug or future added features ;)
Ah okay ...
I do look at something like that now ..
ATF1504AS-7AX100
This is compatible with the old Altera EPM7064 and with 100 PINs has enough pins to have both - the normal logic and the JTAG programmer port available.
That should be a very cheap solution as you only need the CPLD on a carrier PCB for the DIP 40 PIN slot.
And you can programm it with JTAG even within the device if you have some JTAG programmer ...
Logic to program it from inside the CPC is too dangerous, because reprogramming the gate array within a running CPC is a little bit strange as you for instance will loss RAM access and other during the procedure. So you would need to put another microprocessor on the board and run a JTAG programmer in it (like an ESP or something alike). Not saying it is not possible, but maybe a little bit overloaded for just an FPGA. The only benefit would be, that you can change from 40007 to 40010 so USB port plus ESP + CPLD would form a "onsite" programmable item. But also not that cheap anymore.
I would opt for a relatively cheap solution. The Altera is a 5V type and seems available.
Well, if you redo the Gate Array, then it would be cool to have a 8 MHz version, so we can speed up the CPC.
One of mine runs well with 6 MHz, but it can't make it at 8 MHz because of the GA limitations.
Just imagine the awesome GFX. MODE 0 colors with MODE 1 pixel (ok, need 32 KB V-RAM, but that's fine). :)
That is a very simple option within the GA .. however something for a potential future feature list.
Goal 1:
Create a cheap solution, that plugs into the original slot and can be update by the user (JTAG required).
With the ATF150x chip I can do the whole setup with a single chip.
The 100 pin variant will also allow to have a jtag header on the PCB as well, so that it can be programmed in place (not within the CPC).
I have one question on timing ...
What gate propagation delay does the 40007 or 40010 have? Is that in anyway critical?
I mean for the 16mhz clock that would be a 62ns cycle time where 20ns is quite a large shift in the phase (30% actually) ..
However at 4mhz that is then not that relevant anymore ...
So if anyone know the propagation delay of the original gate arrays that would help to identify the correct speed for the CPLDs.
Ser
Okay, after checking that the chip is actually big enough to fit the design I decided for now for this the Atmel chip as it simplifies the design.
Unfortunately the only available option is the 7ns option for the 100 QFP package ... but it now has just two components. I could potentially fit a Powerselector Jumper, so you could program it inside the CPC without the need to pull it out of the CPC. You would just need to switch a jumper and then have it powered from JTAT.
For now not implemented yet.
Attached are some screenshots of the PCB design:
Ist evtl. das falsche Forum, aber kennt jemand einen KiCat Footprint für das Teil hier?
Habe das nicht gefunden und weiß auch nicht so recht wie ich danach suchen soll ..
Your issue with generating a faster CPU speed is going to be the RAM timings. I've done some back-of-the-envelope calculations and there's not a lot of spare time within each GA cycle to speed things up.
Yeah and you can not just pump up the clock to the gate array, as then video timings will be wrong. So it will be a lot of thinking involved to get it right.
But that discussion is maybe worth another thread focussing on it. If this idea has matured and such... I am happy to implemnt it in the CPLD if it fits into the module.
Thanks
Ser
Quote from: GUNHED on 02:02, 28 January 22
Well, if you redo the Gate Array, then it would be cool to have a 8 MHz version, so we can speed up the CPC.
One of mine runs well with 6 MHz, but it can't make it at 8 MHz because of the GA limitations.
Just imagine the awesome GFX. MODE 0 colors with MODE 1 pixel (ok, need 32 KB V-RAM, but that's fine). :)
I see something like a crippled Atari ST powered by a Z80 with a palette of only 27 colors. And the ST itself suffered from a lack of hardware scrolling.
Perhaps an emulator programmer can extend their emulator and emulate an 8Mhz CPC with 32k VRam and Resolutions of 320x200x16, 640x200x4, 640x400x2 to see how that works out.
Hmmm... looking at some other CPLD designs (not related to the CPC) I see a lot of small buffer caps on the vcc line. Do you think I do need to include some into the design? I do have plenty of space on the bottom side, where the 5V lines run and it is very easy to connect the lines with a small cap to ground. It is just more parts.
It looks like I did a huge mistake :-(
The size of the socket I used is actually a 1" socket and as far as I remember the GA is the same size as the Z80 and that sits in a 0.6" wide DIP-40 package ...
This is a big issue as the chip is to big for the DIP-40 0.6" slot ...
Okay late today, will work on that tomorrow...
Okay, I am back to Xilinx for now with this chip:
XC9572XL-10VQG64C
This is available in large quantities even today.
Now I need to figure out, if and what I need to do with the video outputs, which are the only ones that might be critical in terms of voltage ...
However I do not understand how the 50% signals are generated from a single digital output pin. @gerald (https://www.cpcwiki.eu/forum/index.php?action=profile;u=250) can you give me some insights on this?
Okay I think I did understand the logic on the color output.
The output is actually a threestate output and 50% it means it is kept floating 0 is 0 and 1 is 100%. The external pullup is doing the rest. Sometimes it is really good to look at the schematics + the hardware :-)
Can someone confirm, that this is correct?
Quote from: SerErris on 11:30, 29 January 22
XC9572XL-10VQG64C
Too small ;)
The ink/border registers already require 17*5 bit = 85 DFF. You only have 72.
My first prototype used a XC2C256.
Quote from: SerErris on 12:08, 29 January 22
Can someone confirm, that this is correct?
Confirmed.
And the next issue is - the package is to large ...
This is really painful .. Finding something that can actually get delivered .. and get programmed without cost for the design software and is at best 5V tolerant on the input ... ARGL.
I'm keeping my fingers crossed....
How many pins do you need?
Also take into account that ATF150XAS are compatible with EPM7XXXSLC and that can be programmed with a 3$ USB Blaster
Those EPMs can be found in aliexpress as "NEW (from dumpster)" ;D .
Yep, they are all to large.
If there would be a 68 Pin TQFP Package that would be great, but the size (#of MacroBlocks) from Atmel/Microchip required just comes in a TQFP 100 package with a size of 14mm x 14 mm. That does barely fit between the pins and you cannot fit the connectors and the connection leads on the PCB anymore.
We need 35 free assignable pins + the 4 JTAG pins. Depending on the CPLD you also need e additional pins to reproduce the three color outputs.
I am now trying the 5M160Z from intel. That is the MAX V series and still in production. On the downside I need to implement voltage converters for the inputs (20 pins).
The plan is to use simple LVC 8bit transceivers, that will do the down conversion. For the output I do only need to take care of the RGB outs, which I will do with a quad 3-state buffer in normal TTL configuration.
But I do need two LDO voltage regulators, one for the cpld core voltage 1.8V and one for the the CCio 3.3V
The benefit on the intel chip: it does support 68 pin tqfp and will fit on the small PCB.
But I am asking to this round: would you be okay with a overlapping pcb that has the space for the CPLD on the side of the actual socket?
This variant could be build on a ADF1508 and would make the setup much easier. No LDO and potentially I also can remove the output buffers, because the ADF1508 could directly drive it.
I can post a picture tomorrow on my thoughts.
Benefit of the solution is:
1. Cheap
2. Simple - just one component.
3. Easy to maintain.
Downsides:
Relies on old technology
The PCB will hang over to one side to allow for enough space to fit the CPLD.
/Edit: Cleanup - typed it yesterday on my iPhone ..
Quote from: gerald on 12:53, 29 January 22
Too small ;)
The ink/border registers already require 17*5 bit = 85 DFF. You only have 72.
My first prototype used a XC2C256.
Okay, thanks for the input, I did not have any tool to check if it fits, and also did not know what the driving factor is. That is much clearer now.
What speed grade did your prototype run on? Is the cpld speed critical? Or would it run even on a 20ns grade?
If there's any route in the final logic after PnR (which is a heuristic search, so the results are not entirely determined by the input design) that takes longer to settle than the clock period, you'll have problems. Since it depends entirely on what logic is generated; the only way to know for sure is to set the timing constraints in the Xilinx tools and have it check timing closure.
I do not think this is a problem, as all the CPLDs in question are in general supported to run with >133Mhz ... This design is pretty slow in running only at 16mhz clock speed.
So I do not think that this is a real issue, but will definately double check in the timing simulation.
Also the Fitter does some work to optimize that as well, but for that it needs to undertand the timing constrains.
Slower clocks make it easier to achieve, but in and of itself isn't sufficient to guarantee timing closure for all designs. I could write HDL that synthesizes a massively long chain of combinatorial logic that exceeds the timing constraints even on really slow clocks. Which is why you generally want to go wide instead of deep when designing programmable logic, and things like one-hot encoding (which trades off combinatorial logic for increased flipflop use) are preferred. I don't think the GA has anything particularly like that, but the point is it's not hard to get the computer to guarantee it before settling on a part.
Quote from: gerald on 12:53, 29 January 22
Too small ;)
The ink/border registers already require 17*5 bit = 85 DFF. You only have 72.
My first prototype used a XC2C256.
strange ...
@Gerald how many registers does your implementation require when fully implemented?
Mine is 166 .. but I remember (maybe wrong) that it supposed to be 88 ... ???
Something is massively weird with my implementation.
Is it possible that the compiler is acutally adding registers/latches unwanted?
I need to count the registers from the schematic...
Quote from: SerErris on 21:43, 01 February 22
Mine is 166 .. but I remember (maybe wrong) that it supposed to be 88 ... ???
88 is only the ink/border registers. There are many others ;) 166 is in the right range.
Okay .. I counted the schematic.
166 is the exact number of registers (flip-flops).
However Quartus has created 169 out of it ..
In the compilation it first does the analysis and says it is 166, but the final build states 169 ... strange. So the compiler added 3 registers to it, which is propably an unwanted effect, and I need to find out why...
/Edit: The registers getting added by quartus optimzation ... not a concern as long as there are enough logic cells and registers available.
As I a currently compiling on a Cyclone 5 FPGA for code testing, I have plenty of registers and LEs to run this ;-) .
Dedicated logic registers 171
-- By type:
-- Primary logic registers 165 / 112,960 < 1 %
-- Secondary logic registers 6 / 112,960 < 1 %
-- By function:
-- Design implementation registers 166
-- Routing optimization registers 5
Okay, gentlemen, I still do not have a solution that gives me all the things I want:
1. Fit in the footprint of the DIP-40 socket - the PCB should not be much bigger and directly in there.
2. Support V5 directly without buffers - they are making it even more expensive due to board complexity and additional components requried.
3. Enough PINs on the package (@5V 35 IO pins + 4 JTAG pins (+VCC,GND etc).
4. User programmable without extra components (would make it more expensive).
I have solutions for 3 out of 4, but I cannot get anything together that fits all.
5V is a problem nowadays, so I would most likely need to go with a 3.3V solution, that is at least capable of driving all the control signals. It would still require input buffers (2x10bit) to convert 5.5V down to 3.3V and depending on the CPLD/FPGA device I also would need a second voltage (1.1-1.8V). That creates a lot of components on the board (1-2 Voltage Regulators + the 0.1 caps).
One solution in my mind (now juggling with it) would be based on a Efinix Trion T8 (https://www.efinixinc.com/products.html) or T4 FPGA. It comes in a 5x5 mm housing providing some 5x IO pins but needs an external flash module. Also it needs two voltages (3.3V and 1.1V).
However it is a small FPGA with a lot of power ... (much more than required). And the package size of it actually allows for small PCB. However it also requires 4layer PCB (or you cannot route all the PINs.
So what I want to say .. it will take a little bit longer to have a working design.
A design based on the old EPM7256AE will also work but requires a larger design. It has the benefit of allowing direct integration into a 5V system without any other things to consider.
I think I will make one prototype of that for me to validate the implementation, but that is also not possible on large scale due to non availabilty of the chips in large scale at low price.
Interesting,
after having paused all that for month, because I could not get my hands on anything reasonable, I now looked at the ICE40 and the XO2.
Both come in a QFN48 package and delivering up to 40 I/O Pins.
XO2 - cannot get any
But ICE40 you can get. However it requires some additional hardware:
1. Serial Flash EEPROM for the FPGA code
2. 2 Voltage Regulators (to get 3.3V and 1.2V)
3. Level converters (2x 10) for inputs + either 2x10 or 4x1 with output enable for just the graphics parts. I think the rest is not critical and will work.
The interesting part in the ICE40 is, that it is available in numbers. I am pretty much surprised. However as I said the downside is - need a serial Flash, and that needs a complete different approach of programming, but can be programmed with a very simple UART converter for USB and some code.
Also it is very low power ... so Actually I think it could be much less power consumption than the original electronic heater we had in the 464s ... aka 40007
The last option I now recognized is a gowin FPGA.
That does a lot of stuff out of the box (e.g. no S-FlashEEPROM, 3.3V core voltage) ... so it would need less parts. On the downside .. no idea how to program that thing. Anyone has any experience with it?
I work with the ICE40 series, and I would be happy to work with you on the design of a 4 layer PCB with 5V to 3V3 translators, and the regulators required...
I have a full SMT line so I could also manufacture a small number of PCB's...
IMO the ICE40 range of FPGA's is a really great solution...
Hi, thanks for the offering.
I do think a collaboration makes sense - if we match up.
E.g. it needs to be on KiCad - as I do have no interest into investing another learning curve into anything else. In the end it is an hobby.
Also I think it needs to be a 2 layer design. A 4 layer design is just very expensive in a small manufacturing volume and esp. prototyping will kill you with cost.
So 2 layer design it is - which also rules out BGAs. They are in the size we need them by far to small to route them on a 2 layer board (including power and GND as well). So it needs to be the QFN48 package. But that will fit on a small board.
If you could start with a very typical schematic for the ice40 - including the two voltage regulators and the flash circuitry (e.g. resistors required and what not), that would be already of great help.
I can then add all the stuff around the 40007 (voltage translators and buffers where required).
A github repository would be nice (I can create one if required).
Suggestions?
Why not using 64 colors instead of 32?
Color selection actually uses &40-&5F, the values &60-&7F are free and could be used.
Imagine a CPC with 64 colors. All the brown and gray we miss. :)
Quote from: SerErris on 13:56, 20 October 22Hi, thanks for the offering.
I do think a collaboration makes sense - if we match up.
E.g. it needs to be on KiCad - as I do have no interest into investing another learning curve into anything else. In the end it is an hobby.
Also I think it needs to be a 2 layer design. A 4 layer design is just very expensive in a small manufacturing volume and esp. prototyping will kill you with cost.
So 2 layer design it is - which also rules out BGAs. They are in the size we need them by far to small to route them on a 2 layer board (including power and GND as well). So it needs to be the QFN48 package. But that will fit on a small board.
If you could start with a very typical schematic for the ice40 - including the two voltage regulators and the flash circuitry (e.g. resistors required and what not), that would be already of great help.
I can then add all the stuff around the 40007 (voltage translators and buffers where required).
A github repository would be nice (I can create one if required).
Suggestions?
WRT 4 layer PCB cost I suggest you take a look at jlcpcb :-
https://cart.jlcpcb.com/quote?orderType=1&stencilLayer=4&stencilWidth=54&stencilLength=20&stencilCounts=10
US$13 for x10 4 layer PCB's (54mm X 20mm) - based on the size of the DIL40 packaged.
Its going to cost you so much extra in design time working with only 2 layers - its not wort the cost IMO.
I use Labcenter electronics ARES / ISIS PCB CAD software - sorry KiCad would take me to long to learn, and if its ANYTHING like Altuim I have to sometimes work with I'd rather shoot myself in the head...
I use JLC PCB all the time and would never go back to expensive European based PCB company's. The PCBs typically arrive a week after issuing the Gerbers - depends on your country's customs clearance / when the weekend falls etc...
Then it does not make sense too much.
I do understand all your concerns, but also will not move from mine.
4layer PCB is still too expensive compared to 2layer. Time for the design is not a problem but actual hardware cost is just too high. You still need the other components.
I will work on it.
Thanks still for asking.
Quote from: GUNHED on 16:12, 20 October 22Why not using 64 colors instead of 32?
Color selection actually uses &40-&5F, the values &60-&7F are free and could be used.
Imagine a CPC with 64 colors. All the brown and gray we miss. :)
The problem is not the gatearray, but the voltage levels we do have available.
Currently we actually have 3 different voltage levels. 0V, 2.5V and 5V. And this for 3 colors generates in total 3^3 = 27 colors. If you closely follow the documentation, you will identify that some colors are repeats of others so 27 is correct in the maximum of colours the CPC can support.
So it does not only depend on the gatearray, but also would require a mod of the CPC mainboards.
Thanks for the information. So the voltage levels come from outside the GA.
And probably it's hard to get additional voltage levels inside the new GA, right?
Somehow the KC compact has 64 colors possible, I did hear. Don't know if this is real or a rumor though.
Quote from: GUNHED on 15:22, 25 October 22Somehow the KC compact has 64 colors possible, I did hear. Don't know if this is real or a rumor though.
It has a 2bit DAC per colour but it can only produce 3 different voltage levels so unfortunately it will also only produce 27 different colours.
For my gate array I'm using the following circuit. The resistor values have only been very roughly trimmed for the main colours but otherwise look good. You're welcome to copy.GA_DAC.png
Wow this is interesting. Could you sandwich 2 PCB's together to make a double sided PCB that plugged together and double the volume? I have some contacts in the electronics business.. my main client is a contract electronics mfg in Wales.... know a couple of dudes who do crazy stuff (they use JTAG/Coldfire equip/ICT all that sounded familiar. I'm not an electronics buff myself). Also I have contacts in sourcing for checking availability of items, they owe me a favour or two
But on more important matters Retro, who is that girl in your avatar?!
Won't a godhil fit?
Quote from: GUNHED on 15:22, 25 October 22Thanks for the information. So the voltage levels come from outside the GA.
And probably it's hard to get additional voltage levels inside the new GA, right?
Somehow the KC compact has 64 colors possible, I did hear. Don't know if this is real or a rumor though.
The CPC in total has three different voltage levels per color. It has no additional brigthness or something.
EE wise that is getting generated via a tri-state buffer in the gate array. So the gate array can output 0 or 5V (two states) or disconnect the output and let if floating (so call High-Z or high impedance). That is when the pull up resistor on the CPC main board kicks. In the situation that the color output (for each channel individually) from the gate array is HighZ the pull up pulls it up to 2.5V (roughly). So the gate array itself actually has only 2 states for each colour, but paired with the feature to controlled cut off the output completely it is actually having thee different output levels.
So there is no easy way (without a DAC or anything alike) to create more colors. We would need a 4bit output per color to get to 64 colors in total. The registers in the gate array could do that. But we would need two options for a mod:
1. Remove the CPC mainboard from the equation and directly wire the GA to the video port (no resistors or path from the mainboard is getting used).
2. Remove the resistors from the mainboard and make it a direct path.
Both are actually changing the CPC to something different (which was not the aim here) and also 2 would not be reversable.
1. Could be implemented by just pulling some new wires from the GA pins to the video port. That could be reversed very easily as the replacement gate array could just not use the pins on the socket.
2. Would be a permanent change and I think that is not a good thing, as it is very hard to reverse.
However even it would work, it would not be compatible with existing software. The first 32 coulours should not change for compatibility reasons, however the new colours will fall in between. You can simply see that we currently already have black (color off) and pure color 100% (e.g. red). And we do have a 50% red level. So we would now move the 50% red level to 25% red and create a new 75% red level.
In essence that would mean, that the original colors would be different (so calling color 27 will not result in the same color) and also the would be different in brigthness as there is simply no 50% color anymore.
I think there would be no interest in here to start programming everything from scratch and in complete different color scheme.
Summary:
For all of that reason, I think we will never get any better color than we always had. The gate array replacement will not improve on that, as it is in the first order a replacement of the existing model and needs to be in first priority 100% compatible.