Creating a replacemant gate array

[eto]

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

[Bread80]

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

[genesis8]

What's the current status Bread80 ?

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

You cannot view this attachment.

[GUNHED]

Thanks to keep us updated about your great advances.

[genesis8]

A slow one is better than none :-)

Thanks.

[TotO]

I'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

[GUNHED]

A slow one is better than none :-)

Thanks.

Sometimes thing look to be slow. But few know how much hard work is behind it. 

[Bread80]

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

[Bread80]

Although mostly because I've got far to many projects on the go to devote enough time to any single one of them.

[Sykobee (Briggsy)]

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?

[TotO]

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

I know that. I mean about the integration, not the way to do it.

[Bread80]

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?

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.

[GUNHED]

Since you use PWMs ... could it theoretically be possible to add more colors?

[Bread80]

Since 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

[GUNHED]

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. 

[SerErris]

@Bread80 any update on this?

[Bread80]

@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  

[Bread80]

With the release of the Raspberry Pi RP2350 (as used in the new Pico 2 board) I'm picking up this project again. The new chip has five volt (ie. TTL level) tolerant pins, 48 GPIOs, and enough PIOs and DMAs that it should now be possible to emulate the gate array on a single RP2350 with minimal additional hardware.

In the first article I give an analysis of the various pins on the gate array and group them into functional blocks ready for the implementation.
https://bread80.com/2024/08/11/pico-garry-2350-part-1-signals/

In the second article I do a deep dive into the implementation of the FSIGS block (signals with fixed timings) using a PIO, a DMA, and an array of signal levels in memory.
https://bread80.com/2024/08/25/pico-garry-2350-part-2-fsigs-fixed-signals/

I think this chip has huge potential for emulating hard to find vintage hardware. I hope my writings are useful to anyone who wants to know more about how it can be used in interesting ways.

[McArti0]

Maybe you are the first one within reach to make an 8MHz CPU version.
One read screen, one read/write memory per one 4 clocks cycle

[retro space]

You could also add an option for a custom palette.

[Bread80]

Maybe you are the first one within reach to make an 8MHz CPU version.
One read screen, one read/write memory per one 4 clocks cycle

That would be doable, but you'd probably have to swap out the original 200nS DRAMs to achieve that.

If you switch from DRAM to SRAM then it would be easy to use a 20MHz Z80 (but would require a redesigned motherboard to be practical).

You could also make performance gains by only issuing the READY signal when it's required. Ie. when accessing the on board RAM. It's not needed when reading ROM, expansion RAM, performing I/O, or any M cycle which doesn't access RAM. 

[Bread80]

You could also add an option for a custom palette.

I'm planning a 9-bit palette, three bits for each colour (512 colours). That will allow plenty of scope for tuning to match original colours. Adding some extra I/O registers to modify the defaults would be trivially easy.

[McArti0]

I have original 150ns DRAM. 

[Bread80]

I have original 150ns DRAM.

It would be interesting to see it would be possible with 150ns RAM. You'd have to tighten up the timings for the video part of the cycle. The question is whether that leave enough time for the CPU to make two memory accesses. It's probably worth adding that the original multiplexers are also pretty slow. IIRC they take something like 40-50ns to change state.

In the original timings the READY line is pausing the CPU about 75% of the time. Even if you could give the CPU 50% of the cycle that probably only gets you one CPU memory access per cycle at 8MHz, which is no better that you get at 4MHz.

The timings with DRAMs are tight. It really needs SRAM to get any meaningful improvements.