Creating a replacemant gate array

[Bread80]

I'm having a play at creating a replacement gate array using the new Raspberry Pi RP2040/Pico microcontroller. The first attachment shows the development board with the original 40007 and a pair of Picos. On the left are a bunch of jumpers for the output signals so I can select them between those from the original GA and the Picos. Jumper on right = GA, jumper on left = Pico.


As you can see all the basic timing signals are working, and I'm currently exploring the video output. I have video output running for all three video modes. The other attached photo shows the Mode 0 output. A few notes on this:
I'm currently passing the 3V outputs from the Picos straight to the Amstrad. I think this is why the blue channel is broken. Red and green are actually looking surprisingly good. And the current colours are either on or off with no HiZ mode, so only two colours per channel. And some of those lines are black to my eyes but the camera shows them with colour. My next board revision will buffer the outputs and also upgrade to 8-bit colour.


/SYNC should be trivially easy to generate but getting it to sync with the colour output will take more work.
I have some code for /RAMRD and /ROMEN on paper but it needs pins to be rearranged before I can test it.
/INTERRUPT is the one I'm not looking forward to.
The current code doesn't read any settings data (output from the z80). My next board revision will make this much easier.


PS. I'm currently using the Pico boards but it should be possible to shrink things to a just use the raw RP2040 chips and, hopefully, fit the whole think within a DIP-40 size package.
My original plan was to use a single RP2040 once I'd worked out how to multiplex the signals in some way to fit into the available pins. However, the lure of 8-bit colour is a tempting reason to keep it using twin chips. They're pretty cheap anyway so it's not really a cost problem. And there is already code available to generate a HDMI signal using a Pico. I'm not sure there's enough processor cycles to do everything though.


(Sorry, attachments aren't showing on the preview. Let's see if they're on the final post...)

[GUNHED]

Quite nice first results. Keep the work going. The Garry is what we need. 

[VintageAdvantage]

Great stuff!

[SkulleateR]

This looks promising 

[Sykobee (Briggsy)]

Good work, very interesting use of a microcontroller.


What would the purpose of 8-bit colour on the basic CPC? I presume that means RGB332?
Will you use an I2C DAC for this video output, as the Pico SoC doesn't have DACs, but lots of I2C?

[eto]

Just an idea: Would that make it possible to use the "abandoned" 5 colours? I love the CPC palette but I miss dark grey and brown tones. Colour 28-32 could give us e.g. 2 more shades of grey and 3 shades of brown/skin tone. Gone would be the need to paint faces in orange or dark scenes in blue and purple.

As colours 28-32 can already be accessed by software (even BASIC), I would expect this could easily be implemented. New software would not need to implement something that is not working on a normal CPC. It could select a slightly different palette if the new gate array is recognized or stick to the original palette for all unmodified CPCs.

[roudoudou]

Just an idea: Would that make it possible to use the "abandoned" 5 colours? I love the CPC palette but I miss dark grey and brown tones. Colour 28-32 could give us e.g. 2 more shades of grey and 3 shades of brown/skin tone. Gone would be the need to paint faces in orange or dark scenes in blue and purple.

As colours 28-32 can already be accessed by software (even BASIC), I would expect this could easily be implemented. New software would not need to implement something that is not working on a normal CPC. It could select a slightly different palette if the new gate array is recognized or stick to the original palette for all unmodified CPCs.

this will make incompatibilities with old softwares
there is NO free color, there are duplicated colors so assembly programms may use one or the mirrored color
also forget the idea of 0-26 color index, that's not hardware indexes, see http://www.cpcwiki.eu/index.php/Gate_Array#Palette_sorted_by_Hardware_Colour_Numbers

[TotO]

Not really a good idea to add arbitrary colours on the existing palette.
The best will be to support the Amstrad Plus features for all CPC, but the address lines will miss do to it.

[pelrun]

Nothing wrong with having alternative behaviour, since you can gate it behind an option. Nobody's suggesting it be permanently enabled.

[kolleykibber]

I wonder if you were to use a pi zero running RGBtoHDMI as the second board. Perhaps then you could then make use of the hdmi out?


Curious to know what level shifters you would use? Won't you need a lot of them?

[TotO]

Nothing wrong with having alternative behaviour, since you can gate it behind an option. Nobody's suggesting it be permanently enabled.

The magic option.

[roudoudou]

The magic option.

something like Asic unlock sequence? 
which open access to 4096 colors? 

[TotO]

something like Asic unlock sequence? 
which open access to 4096 colors? 

Sure, with the growing interest for the Amstrad Plus those last years, that will be the best.

[rexbeng]

Sorry, what is this 'Amstrad Plus'? Sounds like a healthcare program of some sort..?

[Sykobee (Briggsy)]

First get it working reliably. Then add a register to change the version of CRTC it emulates!


Then add extended palette, and hardware scrolling (Plus compatible registers, if possible), and as the Pico has lots of onboard RAM, a Sprite engine, but it might be missing some timing signals...


But few people would own it, so is it worth it? At some point you might as well just create a CPC++ dream FPGA system!

[eto]

But few people would own it, so is it worth it?

If it's compatible, I guess it's worth it. CPC repairs would be one aspect, as the gate array is a chip that is hard to source. But also the "upgrade" path to more PLUS features for a normal CPC would be an awesome achievement and maybe even a reason to upgrade with a working gate array.

[TotO]

Sorry, what is this 'Amstrad Plus'? Sounds like a healthcare program of some sort..?

It is the name of the Amstrad range of computers succeeding the Amstrad CPC.

[rexbeng]

It is the name of the Amstrad range of computers succeeding the Amstrad CPC.

So it is a healthcare program!

[TotO]

Sorry, it is true!

[roudoudou]

So it is a healthcare program!

CPC is a healthcare programm, see the website www.cpc.com

[Bread80]

To try and answer some of the comments:
The next board revision uses a 74LS/HCT245 and resistor DAC for the video out. It's using RGB332. The issue might be the blue channel, I'll need to use three of the available values for the standard 0%, 50%, 100% which means the fourth available value will be screwy in-between value. I'm not too sure what's available in DAC ICs. The available bandwidth of the Pico means that there would need to be a separate channel for each colour.


I would envisage emulating the standard palette out of the box with some kind of hidden command sequence to enable additional features. The 8-bit colour depth would enable custom palettes. It would also be possible to create additional video modes. At least within the limitations of the rest of the hardware.


Creating all the features of the Plus models wouldn't be possible due to the signals available to the gate array. However, a subset or modified feature set would be possible. I could envisage the ability to have some form of sprites. The challenge here may be getting the data in.


A Pi Zero would be an alternative way of doing this. The Pico should give a more compact and lower cost solution though.


Regarding level shifters: the original GA has 19 input lines and 16 output lines. I'm generating the 16MHz XTAL signal on board so don't need that line. For the other 18 I'm using (will be using) a pair of 74LVC244 For the couple of left over signals I can use a resistor divider or diode plus pull-up. For output a 74LS/HCT244 will buffer the video lines to 5V. For the rest of the signals the 3.3V output is compatible with 74LS logic already but something such as a diode and pull-up will be needed for the open-collector lines to protect the Pico from signals from external devices.


I'm not emulating the CRTC since that's a separate chip on the standard CPCs. I don't see any reason that a Pico couldn't emulate a 6845 though. After all it's mostly just counters. If you did that you could then play with custom modes, or switch versions etc. (Not that that's on my to-do list at the moment though).


The use case for this is really the fact that GAs are so are outside of a CPC and there needs to be some way to replace them as they fail. Also, I'd love to create a newer revision of the CPC hardware but pulling chips out of existing machines isn't really a viable option.


And if you have a replacement GA then you can also play around with the signal timing. Which means you might be able to slip in a faster z80    [size=78%](although you'd have to replace to 4164s at the same time).[/size]

[GUNHED]

About colors... the KC compact (CPC clone) got 32 of them. Then be compatible to it. 


And you know what? Have this as option (set a bit somewhere), so everybody is fine.


But let's build the basement first and after that the penthouse. It just would be AWESOME to have a 40010 replacement.

[Bread80]

Progress Update


I now have the revision 2 development board. Picos are generating everything except /ROMEN, /RAMRD, /SYNC and /INT.

Resistor DAC is temporary - allows me to play with other stuff. I'll be revising later to improve colour accuracy (which will also need to involve acquiring actual Amstrad monitors for testing).


Screenshots below show Picos versus Amstrad output for each display mode. Pico versions all show display glitches - pixels stretched or missing. This is due to the code occasionally missing input pixels or not sending output pixels in time. The current code is simply 'read pixels, process, output pixels'. I'll be updating the code to use DMA and buffer both input and output data which will fix these issues. It will also meaning generating SYNC from scratch, so I'll leave it for now and come back later. (And note that the /SYNC signal is still coming from the Amstrad gate array so the image is not totally aligned correctly).


The code is now generating border pixels so it's processing the VSYNC, HSYNC and DISPLAY_EN signals from the 6845.


My next step will be to read settings data from the CPU so I can change modes, palettes colours etc.

The screenshots show the Pico gate array versus the Amstrad equivalent for each mode. Pico versions have duller colours and display glitches

[abalore]

Amazing stuff!

[SkulleateR]

This is really impressive