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...)
Quite nice first results. Keep the work going. The Garry is what we need. :) :) :)
Great stuff!
This looks promising :o 8)
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?
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.
Quote from: eto on 10:35, 30 April 21
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
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.
Nothing wrong with having alternative behaviour, since you can gate it behind an option. Nobody's suggesting it be permanently enabled.
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?
Quote from: pelrun on 11:14, 30 April 21
Nothing wrong with having alternative behaviour, since you can gate it behind an option. Nobody's suggesting it be permanently enabled.
The magic option.
Quote from: TotO on 12:51, 30 April 21
The magic option.
something like Asic unlock sequence? ;D
which open access to 4096 colors? :P
Quote from: roudoudou on 13:06, 30 April 21
something like Asic unlock sequence? ;D
which open access to 4096 colors? :P
Sure, with the growing interest for the Amstrad Plus those last years, that will be the best. ;)
Sorry, what is this 'Amstrad Plus'? Sounds like a healthcare program of some sort..?
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!
Quote from: Sykobee (Briggsy) on 14:57, 30 April 21But 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.
Quote from: rexbeng on 14:25, 30 April 21
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.
Quote from: TotO on 16:33, 30 April 21
It is the name of the Amstrad range of computers succeeding the Amstrad CPC.
So it is a healthcare program!
Sorry, it is true! ;D
Quote from: rexbeng on 16:42, 30 April 21
So it is a healthcare program!
CPC is a healthcare programm, see the website www.cpc.com
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 ;D [size=78%](although you'd have to replace to 4164s at the same time).[/size]
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.
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 :)
Amazing stuff!
This is really impressive :o 8)
Quote from: Bread80 on 17:12, 10 July 21I now have the revision 2 development board.
Would you be willing to share your design? I am curious how easy or hard it is to use a Pico with the CPC...
Schematics and software will certainly be open sourced. I'm haven't decided whether to open source the gerbers (when it gets reduced to a DIP-40ish size). In any case the PCBs won't be easy to hand assemble with the tiny components used.
I'm not sure what you mean about how easy the Pico is to use with the CPC. It needs level conversion for any signals into the Pico. The CPC uses 74LS chips so signal from Pico to CPC are okay as is. In software terms then it depends what you want to do with it. It's plenty fast enough to deal with a 4MHz Z80. (Things get tight with the 16MHz gate array though).
What's the current status Bread80 ?
@genesis8 , sorry for the slow reply.
I now have a smaller version which fits neatly into the DIP socket. It's using a pair of RP2040Stamp which is about as close as you can get to an raw RP2040 whilst still being able to hand solder.
There's still one or two issues with the board, and I need to finish updating the code be fully compatible with it.
I'll probably do another revision in this format before I try to miniaturise it.
2023-02-24 21.59.14Small.jpg
Thanks to keep us updated about your great advances.
A slow one is better than none :-)
Thanks.
Quote from: Bread80 on 11:37, 13 May 23I'll probably do another revision in this format before I try to miniaturise it.
You are not so far from that: https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/a-minimal-gate-array/msg198585/#msg198585
Quote from: genesis8 on 20:55, 14 May 23A slow one is better than none :-)
Thanks.
Sometimes thing look to be slow. But few know how much hard work is behind it. :)
Mine is a completely different design. No FPGA. All done with ARM processors. Probably a bit more technically complex, but far easier to reprogram and add extra features :)
Although mostly because I've got far to many projects on the go to devote enough time to any single one of them.
Those small ARM microcontrollers are really neat - fast enough to do in software what used to take hardware. Do you make use of the Pico's fancy I/O controllers to help with some of the video signal generation?
Quote from: Bread80 on 18:37, 16 May 23Mine is a completely different design. No FPGA. All done with ARM processors. Probably a bit more technically complex, but far easier to reprogram and add extra features :)
I know that. I mean about the integration, not the way to do it. :)
Quote from: Sykobee (Briggsy) on 17:25, 17 May 23Those small ARM microcontrollers are really neat - fast enough to do in software what used to take hardware. Do you make use of the Pico's fancy I/O controllers to help with some of the video signal generation?
Yes, lots of PIOs.
The system signals are almost exclusively PIOs and PWMs - the only thing there using CPU core is when the RAM/ROM enable changes. (The code writes the new settings to a PIO).
The video uses CPU core for the pixel decoding and I/O. There's also a bunch of PIOs and DMAs involved. I'd like to rewrite the video to use exclusively PIOs and DMAs, but doing it that way is exceptionally complex.
Since you use PWMs ... could it theoretically be possible to add more colors?
Quote from: GUNHED on 13:34, 18 May 23Since you use PWMs ... could it theoretically be possible to add more colors?
Video out is unrelated to the PWMs - they're just driving clock (etc) signals.
The video out is 8-bit RRRGGGBB, so 256 colour. There's a look up table in the code to convert decoded bytes to the CPC palette. So, yes, you could change the 'hardware' palette, or use additional colours.
One of my plans is to add an 'enhanced mode' for writing data to the gate array. That would allow you to access additional features beyond the standard 'command set'. The fun part will be making that compatible with the original firmware ROMs :)
That's great!!! I'm really looking forward to enhanced modes an will of course support them with my OS. Also for the Firmware it should be doable. The guys who created Firmware 3.x will surely be happy to add such features. If not a patch can be done hopefully in quick time. :) :) :)
@Bread80 any update on this?
Quote from: SerErris on 21:44, 05 September 23@Bread80 any update on this?
Not much progress recently. I'm getting too carried away on other projects, including a couple of CPC related ones :)