The FireStarter: a WiP CPC to RP2350B (Pico) Board

[Bread80]

I realise everyone who is anyone is creating Amstrad to Pico boards at the moment but I can honestly say this has been in development since the first Pico was released and only ready now that we have the RP2350B with it's 48 GPIOs - and it's a little different to the others.

The FireStarter connects each of the Amstrad's 47 expansion signals to a separate GPIO pin on the Pico making it easy to work with compared to designs which multiplex them into a smaller Pico or only allow access to a subset of them.

I currently have input and output operations tested and working and it shouldn't be much more work to get memory emulation to function, whether that be ROM or RAM, plus some more advanced features.

Connecting every one of the Z80's pins directly to the Pico means it should also be possible to assert the Z80's BUSRQ signal and take complete control of the address and data busses, thus using the Pico as a DMA device to directly access memory and the CPC's hardware devices (taking care, of course, to respect any timing requirements).

# Hardware

The design has been deliberately kept simple to assemble using entirely through hole parts apart from the RP2350 Stamp XL which is large pitch surface mount but should be easily solderable for anyone who can manage through hole soldering.

The one caveat here is that the board contains no over-voltage protection for the Pico and no level shifters. This means that the Pico /could/ get damaged, although the chip so far appears to be pretty resilient.

Lack of level shifters might create an issue if a machine has been repaired with (eg.) 74HC series parts and, perhaps, with other add-ons (this will need testing).

The board also includes some buttons and an expansion connector. These can be solder linked in place of some of the more obscure CPC signals and used as required. A USB type B connector allows programming and communications with the outside world, and the SWD pins are exposed for debugging.

# Software/Firmware

On the software side I'm aiming to create a firmware library using the onboard PIOs which will make the Firestarter relatively simple to code for. The PIOs will raise an interrupt for I/O write, I/O read, memory write, memory read etc.

An I/O write (aka IO In to the Pico) only requires the end user code to read the address from the address PIO, the data from the data in PIO, mask and decode the address and, if it's the required one, process the data.

I/O read (aka IO Out from the Pico) requires the code to read the address from the address PIO, mask and decode and, if it's the required one, send the returned data to the data out PIO (and return it promptly enough for the Z80).

The PIOs handle all the messiness of listening for signals, reading address and data, setting pin directions and output data, and resetting pin directions afterwards.

This is still a work in progress and I'm calling it a Beta at the moment but I think there's enough here to release if anyone is interested. The entire design (hardware and software) will be open source, and you'll be able to adapt to your own custom designs if you have specific needs.

[McArti0]

RP2350 Stamp XL

...throw it away. 

https://www.aliexpress.com/item/1005008404804398.html

WeAct RP2350B pitch 2.54mm 5$

[eto]

https://www.aliexpress.com/item/1005008404804398.html

WeAct RP2350B pitch 2.54mm 5$

And how long do you think the WeAct RP2350B will be available? I would not base any design on something that might be gone in 4 months from now.

[McArti0]

that might be gone in 4 months from now

ok time start...

[pelrun]

It's trivial to rework the board for a different module if/when that is necessary. Or just integrate the pico directly. So I wouldn't worry about it.

[McArti0]

@Bread80
-JP2 - BUSRQ-----BUSRST
-JP3 - RFSH-------BUSRQ

-JP5 - BUSRST----RFSH

-JP6 - EXP -------- CURSOR
-JP8 - CURSOR----EXP

but what is in soft?

[Bread80]

@Bread80
-JP2 - BUSRQ-----BUSRST
-JP3 - RFSH-------BUSRQ

-JP5 - BUSRST----RFSH

-JP6 - EXP -------- CURSOR
-JP8 - CURSOR----EXP

but what is in soft?

That'll be me rearranging lines in the schematic and not updating the jumper labels. I've fixed them now. Silkscreen labels are already correct.

(The rearrange was when I added the buttons, so they'd be on the lines that are (probably) least likely to be used.

[Brocky]

excellent!
one suggestion tho.. there needs to be some pins free on the pico to connect extra sensors, mcus, etc..
id put the data bus on a bi-directional shift register and free up enough pins for SPI and/or I2C/I2S (probably not SPI as it requires CS pin on each device)

[McArti0]

Correct.

[pelrun]

I mean, you could add latching buffers (not shift registers, believe me you do *not* have enough time to feed them.) It does add quite a bit of complexity for not a great amount of benefit.

Because there's already a ready made bus with dedicated pins and the capability to run multiple devices right there. Unfortunately Bread80 put a USB B socket on it

[krusty_benediction]

So, if I have well understood, it is technically feasible for the device to registers all signals from the cpc and then produce a twin of the cpc with a snapshot where all crtc (as well as other chips) counters/registers  are identical to the cpc?
And thus ease debugging

As a 100% cross developer, I think  any card should be able to communicate in a wireless way with a computer (either in serial or wifi, that does not matter). Is it the case of this device?

[Bread80]

excellent!
one suggestion tho.. there needs to be some pins free on the pico to connect extra sensors, mcus, etc..
id put the data bus on a bi-directional shift register and free up enough pins for SPI and/or I2C/I2S (probably not SPI as it requires CS pin on each device)

As @pelrun says, shift registers are way too slow. And previous revisions have used various registers and transceivers both for data and level conversion and they've all been a major PITA. My aim here is to do as much code as possible using PIOs, and PIOs are very limited in their abilities. Trying to switch pin directions, output data then enable and latch that data into external chips is challenging.

And once the PIOs etc. become complicated that tends to feed through into the core code you need to write to use them, and one of my major focusses here is to create a library of PIOs which makes coding on this as simple as possible.

The current design does have free GPIOs is you're prepared to sacrifice some CPC signals. But, maybe the answer is to connect those obscure CPC signals via (eg.) the shift register. But the aim, at least on this revision, is to be simple. There may be scope for an SMT revision with extra features and proper level shifters included.

[Bread80]

Correct.

I stand corrected. Yes BUSRQ and BUSRST were swapped on the silkscreen. Thanks for finding the issues.

 

[Bread80]

So, if I have well understood, it is technically feasible for the device to registers all signals from the cpc and then produce a twin of the cpc with a snapshot where all crtc (as well as other chips) counters/registers  are identical to the cpc?
And thus ease debugging

As a 100% cross developer, I think  any card should be able to communicate in a wireless way with a computer (either in serial or wifi, that does not matter). Is it the case of this device?

As in sniffing the signals to drive an emulation? Then yes, that should be possible (depending on CPU power to drive the emulation), although there's not much data available on the expansion bus regarding CRTC and video status to be able to ensure the emulation is in sync. But using INTERRUPT should be helpful there.

It would, however, be possible to pause the Z80 and read the memory and hardware state which should be useful for debugging. Using the FireStarter to trace execution, create breakpoints, or track reads/writes to selected memory addresses would also be possible. You could probably even inject code into the Z80 to read out the current register state.

I agree wireless would be useful and it may well make it onto a later revision in some form, as would an SD card.

Regarding cross development, one of my use cases for this is to be able to inject code (etc) directly into the CPC's memory. Thus, you could compile/assemble the binary and send it to the FireStarter which would write it to the CPC and start the code running.

[McArti0]

will there be an interface for carrier pigeons? 

btw. On Aliexpress  Stamp XL called RP2350B-Tiny XL ~8E

[genesis8]

Hello,

about to write about this card, could you state the features you want to add to the card right from the start ?

[Brocky]

excellent!
one suggestion tho.. there needs to be some pins free on the pico to connect extra sensors, mcus, etc..
id put the data bus on a bi-directional shift register and free up enough pins for SPI and/or I2C/I2S (probably not SPI as it requires CS pin on each device)

As @pelrun says, shift registers are way too slow. And previous revisions have used various registers and transceivers both for data and level conversion and they've all been a major PITA. My aim here is to do as much code as possible using PIOs, and PIOs are very limited in their abilities. Trying to switch pin directions, output data then enable and latch that data into external chips is challenging.

And once the PIOs etc. become complicated that tends to feed through into the core code you need to write to use them, and one of my major focusses here is to create a library of PIOs which makes coding on this as simple as possible.

The current design does have free GPIOs is you're prepared to sacrifice some CPC signals. But, maybe the answer is to connect those obscure CPC signals via (eg.) the shift register. But the aim, at least on this revision, is to be simple. There may be scope for an SMT revision with extra features and proper level shifters included.

yeah yas are right..i forgot about most shitregs being too slow.. (edit: i swear that was a typo! im gonna leave it there for the LOLz!)

we need moreeee GPIOs tho!... ive been looking at STM32 discovery boards with 80odd gpios... they dont have much ram, but with the extras it would be easy to add a PSRAM like chip...
sure..a little more complex, but look to what can be done in the future with an all-in-one board like this, it needs room for expansion..

ideally what id like to see is an all-in-one board that does (or can be made to be done with updates to code) everything... RAM/ROM, I/O decoding and interfacing, DMA, audio chip emulating and audio amp,MIDI, video out, floppy and mass storage emulation via SDcard, wifi network via esp32, real FM radio/mp3,webradio, and all the other features you can think of rolled into one card. (possibly with header to spare gpios to add more things in future) i guess like symbface card? but with everything, and possibility to expand with some C/++ code and spare gpios..

after some more thoughts...maybe, easier and cleaner to add a 2nd pico (A variant? or even STM32 blue/blackpill) that communicates over fast SPI with the main decoder pico, to do expansion to extras, like more (above the 512kb) ram with spi bus, sensors, audio emulation etc etc.. on that 2nd board freeing up the main interface.. 

[McArti0]

You just got a user friendly SOC with 48 GPIO 5V pitch >=2mm, For pennies.
like YOU'VE NEVER HAD! 

[Brocky]

You just got a user friendly SOC with 48 GPIO 5V pitch >=2mm, For pennies.
like YOU'VE NEVER HAD! 

is the Pico/Pico2 A or B really best? its pins are not all 5v tolerant so level shifters will be needed eventually.....its also not the fastest on the block!

but.. ive been talking with Grok for the last few hours trying to come up with a simple solution...
it seems it maybe best to use an STM32F401 (cheap blackpill) as the connection to the CPC as all its pins are 5v tolerant, and then use a ESP32 connected at 20Mhz SPI to emulate RAM/ROM, and provide access to other GPIOs and DACs for audio, video, network, floppy/mass storage etc etc... both are cheap and can be found in board/module form, and are very simple to program using arduino.. both are much faster than the pico2 aswell..

[pelrun]

> [Pico] pins are not all 5v tolerant

With some specific caveats, all the non-ADC pins are.

> not the fastest

On the RP2040/2350, the PIO can trigger on an edge and read 32 GPIO pins into the dma buffer in a *single clock cycle*, and can output just as fast. Just reading the GPIO on the other chips will cost you a huge number of cycles. It's also possible to get the PIO to handle all the bus transaction logic (with a couple of tricks) leaving the cores with basically all their cpu time free for shenanigans.  

[McArti0]

20Mhz SPI to emulate RAM/ROM

How many time do you need to read byte from this RAM? CPC needs it in 400 ns

[Bread80]

Clearly there are other chips available each with there own price/feature benefits. The Pico is a device I know very well and I know how to get the best from it. Personally I'll leave other devices to others.

[Bread80]

Hello,

about to write about this card, could you state the features you want to add to the card right from the start ?

I'm largely viewing this as a platform from others to develop software on. My current focus is towards creating a set to firmware and libraries to make it easy to code against. That's also the reason I've made it easy to assemble. I currently have to it emulating I/O devices and and I'm working on ROM and RAM emulation. Once that's done there will be enough there for people to start creating their own devices with it, and that's the point I plan to open source the project. I can then start playing with advanced concepts such as using as a DMA device.

[eto]

Once that's done there will be enough there for people to start creating their own devices with it, and that's the point I plan to open source the project

That is absolutely amazing. Exactly what I would be looking for. 

[Bread80]

> [Pico] pins are not all 5v tolerant

With some specific caveats, all the non-ADC pins are.

On the RP2350 the pins are 5V tolerant once powered up. If the device is powered on before the CPC there should be no conflicts. If the device is powered by the CPC then the issue is the point between the Pico powering on and the GPIOs being powered up. I *think* the ADC issue only applies if the pin is being used as an ADC.

BTW the RP2040 had no 5V tolerance at all and people seem to have been able to use it with 5V devices without issue so I'm expecting the RP2350 will be at least as robust but only time will truly tell.