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

[Brocky]

20Mhz SPI to emulate RAM/ROM

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

thats just for comms between the 2 microcontrollers... sure, it doesnt "need" to be that fast but it wont hurt..


i get that some of the pico2 pins are tolerant ... but not all..

genuine question....are the 3.3v signal levels coming from the pico, high enough to trigger the CPCs 5v busses 'reliably' every time?? (i guess they must be if theres already devices getting about! derp!)

[GUNHED]

Good to see that the card has MX4 format btw. 

Everything which can bring DMA features to the CPC if of great interest. Please keep us updated. 

[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

thats just for comms between the 2 microcontrollers... sure, it doesnt "need" to be that fast but it wont hurt..

20MHz at QPI is too SLOW... for CPC RAM ofcourse...

[McArti0]

genuine question....are the 3.3v signal levels coming from the pico, high enough to trigger the CPCs 5v busses 'reliably' every time?? (i guess they must be if theres already devices getting about! derp!)

crtc is 2,5V Hi level

[Brocky]

20Mhz SPI to emulate RAM/ROM

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

thats just for comms between the 2 microcontrollers... sure, it doesnt "need" to be that fast but it wont hurt..

20MHz at QPI is too SLOW... for CPC RAM ofcourse...

how? 400ns is like 2.5mhz... and the cpc system is running under 4mhz... surely 20mhz is plenty to get data from the esp32 and put it on the stm32 to do the read/writes to the CPC
40ns period = 20mhz .. that leaves 360ns for the stm32 to request the data from the esp32 and then send it back to the stm32..should be doable...


sorry Bread80.. i didnt mean to hijack the thread.. it just evolved that way...

[Gryzor]

***please keep this discussion clean and nice***

[Gryzor]

Thread cleaned again (and split). Do I really need to remind you to be kind and also not derail threads like that?

[Bread80]

For TTL the minimum level of a high is 2V. Amstrad specified 74LS or 74HCT series logic. The Pico is running at 3.3V. So that should shouldn't be a problem ... unless the signal gets degraded on the way to the CPC.

Also, some people use HC series logic when  they do repairs. HC series uses CMOS logic levels where a logic high is >3V. That's also incompatible with TTL output levels and bad practice so, in the real world, there will be incompatible machines.

[eto]

so, in the real world, there will be incompatible machines.

These machines have been repaired improperly. Maybe that should be the second question if somebody reports that his card is not working: "Has your CPC been repaired and were HC chips been used" (right after "did you clean the expansion port").

[McArti0]

Safety comes down to very fast voltage supply on IOVDD close to 3.63V. This provides tolerance up to 5.5V on all inputs. Since the tolerance on inputs is from minus 0.5V, I am thinking about connecting ground through a diode, then 3.3V on IO would give automatic FaultTolerant at 5V.

[pelrun]

The reset circuitry in the CPC will keep the system in reset for a quite a while after 5v is applied. WIthout actually testing it (although I'm clearly relying on it already in the hardware I've already built) I think there's  plenty of time to get IOVDD up to 3.3v before any of the signals on the expansion connector go to 5v. The question is if any of the active-low signals are pulled up independently of the reset on the driving IC, but it's easy enough to check.

[McArti0]

The RESET signal does not solve the problem because several lines have a pull-up to 5V or is Hi.

[pelrun]

I'm not concerned about the discrete pullups at all - the resistors themselves are sufficient protection.

It's the push-pull outputs of the IC's that could potentially drive a low-impedance 5V before the inputs are ready for it. I've checked datasheets and my 6128 schematic and most things are well behaved. The one notable exception is the /IORD and /IOWR signals which are driven directly from a 74-series gate and will therefore start out high.

I'm not actually that worried about it, because I have RP2040's directly attached to all these signals and I haven't blown a pad yet. Maybe I'll add a little bit more protection if I get anything to the publicly releasable stage just in case.

[FreddyV]

20Mhz SPI to emulate RAM/ROM

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

thats just for comms between the 2 microcontrollers... sure, it doesnt "need" to be that fast but it wont hurt..

20MHz at QPI is too SLOW... for CPC RAM ofcourse...

how? 400ns is like 2.5mhz... and the cpc system is running under 4mhz... surely 20mhz is plenty to get data from the esp32 and put it on the stm32 to do the read/writes to the CPC
40ns period = 20mhz .. that leaves 360ns for the stm32 to request the data from the esp32 and then send it back to the stm32..should be doable...


sorry Bread80.. i didnt mean to hijack the thread.. it just evolved that way...

No.

To read 8bit, more than 20 clock cycle is needed. Then, it is 1 uS for one read.

Even on the picoCPC with the pico overclocked at 350mhz and 130mhz qspi, it does not work
(Yet, because picoCPC use multiplexing) It use 17 gpio to do io, rom, ram