News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Creating a replacemant gate array

Started by Bread80, 18:11, 29 April 21

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

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.  :) :) :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2024.10.27)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

VintageAdvantage


SkulleateR


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

#6
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
My pronouns are RASM and ACE

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.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

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

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.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

roudoudou

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
My pronouns are RASM and ACE

TotO

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. ;)
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

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

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.

TotO

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.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

rexbeng

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!

TotO

"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

roudoudou

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

My pronouns are RASM and ACE

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  ;D  [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.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2024.10.27)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

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


SkulleateR


Powered by SMFPacks Menu Editor Mod