CPC ROM emulator using a Raspberry Pi Pico

[GUNHED]

Well, in this case... Why not just using the M4 expansion?

[matronica]

Hi @pollito . Thanks for your interest in my project. I'm not familiar with the M4 board, so I'm not sure if I could create anything compatible. The Pico has a limited number of IO pins, and they are currently all used, which means that I can't easily decode any other addresses to communicate between the Pico and the CPC.
I would like to make the loading of ROM images easier. I'm thinking of added USB drive support similar to this https://github.com/robinhedwards/A8PicoCart but a web interface would also be cool.

Let me know how you go with the build, and remember that D2 is shown the wrong way round on the silk screen.

[pollito]

Well, in this case... Why not just using the M4 expansion?

I do, but it's nice to have a lightweight, open source alternative.

[pollito]

Hi @pollito . Thanks for your interest in my project. I'm not familiar with the M4 board, so I'm not sure if I could create anything compatible. The Pico has a limited number of IO pins, and they are currently all used, which means that I can't easily decode any other addresses to communicate between the Pico and the CPC.
I would like to make the loading of ROM images easier. I'm thinking of added USB drive support similar to this https://github.com/robinhedwards/A8PicoCart but a web interface would also be cool.

Let me know how you go with the build, and remember that D2 is shown the wrong way round on the silk screen.

Many thanks for your reply. Regarding running out of pins, would it be possible to use the Pico's own micro USB port with an adapter for mass storage rather than using the add on board?

Maybe the ROMs could be stored in a folder on the USB drive along with some config files for different ROM board configurations?

I checked the A8PicoCart - do you mean when the Pico is plugged in, it would mount as storage to be able to upload and download ROMs?

I'm not sure if it helps, but there are some examples of using the M4's TCP/IP stack here. Alternatively, there is also the open source Cyboard which has a TCP/IP stack.

One thing I did notice looking at the board in the Github pictures is that the DIP switches seem to only have two combinations to enable or disable the board. I really like the idea, as it saves the board from having to be yanked, out and reinserted all the time, but would it be possible to replace the DIP switches with a single push button?

I will definitely keep you up to date with my build, but it will likely be a few weeks before the boards arrive from China. I'm currently repairing a very dead 464, and your board will come in handy for running the diagnostic ROM. Plus, if/when I bring the 464 back to life, it will double as an upgrade board.

Thanks again for sharing such a cool project 

[McArti0]

@matronica Can You check whats current is from 5V to GPIO(Input)?

[GUNHED]

Well, in this case... Why not just using the M4 expansion?

I do, but it's nice to have a lightweight, open source alternative.

Open source is a good point.

[matronica]

Many thanks for your reply. Regarding running out of pins, would it be possible to use the Pico's own micro USB port with an adapter for mass storage rather than using the add on board?

The USB board is not connected to the Pico, it's a completely separate circuit and can be left off the board. Decoding for the USB board is done via the 'LS698

Maybe the ROMs could be stored in a folder on the USB drive along with some config files for different ROM board configurations?

see above. There is no connection between the two. The Pico has plenty of flash space to store all the CPC ROMs I could find,.

I checked the A8PicoCart - do you mean when the Pico is plugged in, it would mount as storage to be able to upload and download ROMs?

yes

I'm not sure if it helps, but there are some examples of using the M4's TCP/IP stack here. Alternatively, there is also the open source Cyboard which has a TCP/IP stack.

Thanks. I'll take a look, but don't hold your breath for TCP/IP support

One thing I did notice looking at the board in the Github pictures is that the DIP switches seem to only have two combinations to enable or disable the board. I really like the idea, as it saves the board from having to be yanked, out and reinserted all the time, but would it be possible to replace the DIP switches with a single push button?

They could possibly be replaced by a double pole switch, but not a push button

[matronica]

@matronica Can You check whats current is from 5V to GPIO(Input)?

I'm not sure I understand what you are asking for. Could explain further?

[McArti0]

When GPIO is set as an input 3.3V and you apply 5V there, does any current flow there? You can check this with an ammeter in a multimeter. By applying the probes to 5v and the GPIO input.

[matronica]

When GPIO is set as an input 3.3V and you apply 5V there, does any current flow there? You can check this with an ammeter in a multimeter. By applying the probes to 5v and the GPIO input.

Ah OK. Well I'm not sure I can measure that on my board without lifting some traces, but you could do that with a stand-alone pico. It will probably vary if you have the input configured for pull-up/down
As mentioned on the project page, the input are not designed for 5V so they are working outside spec. There is a comment here https://hackaday.com/2022/09/25/pi-pico-w-does-pcmcia-gets-this-ibm-pc110-online/#comment-6516402 which indicates that it *may* be OK. But it's not guaranteed. That said, I have not had any problems (yet).

[pollito]

@matronica I finally got around to building the board, but am not having much luck.

I copy the firmware from the firmware folder to the Pico, and it reboots. The LED then flashes slowly, so I unplug the Pico, and plug the expansion into my CPC. Powering it on, the CPC power light goes on, but there is no display, and pressing DELETE doesn't cause the computer to beep. The Pico's LED flashes slowly, as before.

With the DIP switches in their off positions, the CPC boots as normal.

Just to confirm the positions - for on, I have the left DIP switch is set to the down (OFF) position, and the right DIP switch is up in the ON position. I was also careful to reverse the direction of the D2 diode. The reset buttons on the board behave as they should.

The SN74LS688Ns I ordered from AliExpress were clearly not new, so I swapped the IC twice, but I still get the same symptoms. It seems unlikely that all three would be faulty, or at least that they would cause exactly the same symptoms.

I checked for shorts on the board, and also checked continuity, but all seems good. I have also tried copying the firmware again. Do you have any idea what might be wrong?

[matronica]

Hi.
 looks like you may not have a valid set of ROMS on the board. Did you load any?
You need to use the romtool to create a UF2 file to flash along with the firmware.
I realise that this procedure is not really documented anywhere,  so I'll try to update the github page in the next couple of days.

[pollito]

@matronica many thanks for your reply - looking at the files sizes in the firmware directory now, I should have realised that something wasn't right!

I've looked at the makeroms.sh script now, and I see it uses xxd, so I've installed that. And I looked in the romtool directory too, and found the romtool.ini - I'm sure this is only an example, but I'm quite amazed to see how many ROMs and configurations can be stored on the Pico.

If you could add some instructions whenever you have time, it would be greatly appreciated. Meanwhile I will have a play around with the included scripts. It seems to be a case of copying some ROMs, converting them into headers, and then running the Python script to build the uf2 file.

One other query I have - I decided to try the optional USB module, but I'm not sure what the jumper configuration should be on the board. Would it be possible to add that information to the Github project too?

[matronica]

@matronica many thanks for your reply - looking at the files sizes in the firmware directory now, I should have realised that something wasn't right!

I've looked at the makeroms.sh script now, and I see it uses xxd, so I've installed that. And I looked in the romtool directory too, and found the romtool.ini - I'm sure this is only an example, but I'm quite amazed to see how many ROMs and configurations can be stored on the Pico.

If you could add some instructions whenever you have time, it would be greatly appreciated. Meanwhile I will have a play around with the included scripts. It seems to be a case of copying some ROMs, converting them into headers, and then running the Python script to build the uf2 file.

One other query I have - I decided to try the optional USB module, but I'm not sure what the jumper configuration should be on the board. Would it be possible to add that information to the Github project too?

@pollito  I've updated the documentation on github to cover building the rom image and flashing to the Pico. makeroms.sh is no longer needed - you use romtool.py - it should all be explained in the readme.

[pollito]

@matronica thank you for writing the instructions - I've now got a bit further, but am still not there yet.

First of all, I stripped the header from all ROM files that were 16512 bytes long like so:

Code Select Expand

dd if=romfile_original.rom of=romfile.rom bs=1 skip=128

I then created a roms/ directory, and copied all ROMs I wanted to use along with firmware/picorom.rom, into that directory. All ROM files were 16384 bytes long.

I edited the romtool.ini to be very simple, using only the following ROMs in a single CONFIG:

Code Select Expand

[INPUT]
romdir=../roms
[OUTPUT]
romfile=../build/roms.uf2
configfile=../build/config.uf2
combined=../build/roms+config.uf2
[ROMS]
2=OS_6128.ROM,CPC 6128 OS,L
12=BASIC_1.1.ROM,Basic 1.1 (6128)
24=albireo.rom,UniDOS Node for Albireo
25=unidos.rom,UniDOS
26=unitools.rom
30=picorom.rom
[CONFIG0]
DESCRIPTION=CPC 6128 with UniDOS
LOWER=2
BANK0=12
BANK6=30
BANK7=25
BANK11=24
BANK14=26
ACTIVE=1

Then, in a terminal, I switched to the romtool directory, and ran python3.11 ./romtool.py which appeared to complete successfully:

Code Select Expand

Added rom # 2 at offset 0x00009000: type 0x40, size 16384 CPC 6128 OS
Added rom #12 at offset 0x00031000: type 0x80, size 16384 Basic 1.1 (6128)
Added rom #24 at offset 0x00061000: type 0x02, size 16384 UniDOS Node for Albireo
Added rom #25 at offset 0x00065000: type 0x01, size 16384 UniDOS
Added rom #26 at offset 0x00069000: type 0x01, size 16384 UNITOOLS
Added rom #30 at offset 0x00079000: type 0x01, size 16384 PICO ROM
Start address is 0x1001e000
image size is 512000
created ../build/roms.uf2
Adding CONFIG0
Start address is 0x101ff000
image size is 4096
created ../build/config.uf2

According to the instructions, three files should be created, although only two are listed, and indeed only two exist in the build/ directory:

config.uf2 (8K)
roms.uf2 (1000K)

The roms+config.uf2 specified in the romtools.ini config file is not created.

The instructions go on to say that the cpc_rom_emulator.uf2 must be written to the Pico first. I started the Pico with BOOTSEL held down, and copied cpc_rom_emulator.uf2 onto it. It immediately ejected itself. I unplugged it, plugged it back in but nothing, so I reinserted the cable it with BOOTSEL held down, and copied the config.uf2. The Pico ejected itself again, and I had to reconnect it with BOOTSEL held down once more to copy the final roms.uf2 file.

When I plug to PicoROM into my 464, I can see that it is doing something, as the 6128 ROMs are loaded. But, none of the other ROMs are shown on boot, and none of the PicoROM's RSX commands work.

I tried the same process several times, but it always leads to the same outcome. Do you have any idea what might be wrong?

[eto]

pollito  I've updated the documentation on github to cover building the rom image and flashing to the Pico. makeroms.sh is no longer needed - you use romtool.py - it should all be explained in the readme.

Hi @matronica

I just (again) stumbled across this yesterday and I think it's an awesome piece of hardware. Open source, easy to build, extremely cheap - and simple for anyone to build it. It definitely should deserve much more attention!

A couple of questions appeared though:

• As the README has been updated is it save to assume it's now possible to just drop the ROM images into the root folder?
• I also recognized that the |CFGxxx commands have been removed. Will they come back?
• Does the PicoROM remember the last selected config or will it switch back to default if it's turned off?
• what does the USB part do? The doc only mentions "start emulating a USB drive. CPC will stop working".

From a hardware perspective I have a few more  questions:

• When disabling the PicoROM why do you set ROMDIS to high? Wouldn't it be sufficient to just set ROM to low? I guess a permanent ROMDIS could interfere with other expansions.
• Would it be feasible to connect BRST to RUN (via diode) instead of a GPIO? I think that would then reset the PicoROM and could then free a GPIO which could e.g. be used to add a switch that selects between default.cfg and the last selected cfg.
• And last but not least, would you be fine with me creating a new PCB that is smaller, doesn't contain the USB and allows to either connect to the expansion port directly or to an MX4 board? I would of course keep the reference to the original project on the board.

Really awesome... a sub 10€ open source, flexible ROM board solution.

[Philippe Lardenois]

really nice project. Cheap, and easy to build.
So I did some and design a 3d Box for it.
Would be nice to expand the capabilities (like loading disks or bigger roms) - I would like to have the capabilities but old age...
https://ibb.co/0sMdY2k

https://ibb.co/9pwZmXh

Thanks anyway.
Phil

[Fran123]

This is really, really interesting.

If that turns out to be a general case, the Pico might be a great choice for other projects too, e.g. a graphics card.

That could be possible.  The main limitation is the number of available io pins. I'm going to try creating some form of mass storage device next. (Using a second pico)

It might be interesting to make a mini-mx4 for several rpi-pico based boards.

And, could you emulate RAM expansion with this?

[matronica]

I tried the same process several times, but it always leads to the same outcome. Do you have any idea what might be wrong?

Hi @pollito , I have made major changes to the firmware to make the process easier. I suggest you try the latest firmware on github. It allows you to copy ROMs via an emulated USB drive. Sorry for the late reply!

[matronica]

@eto 

• As the README has been updated is it save to assume it's now possible to just drop the ROM images into the root folder?
  
  

yes

• I also recognized that the |CFGxxx commands have been removed. Will they come back?

No. They are replaced by ROMSET

• Does the PicoROM remember the last selected config or will it switch back to default if it's turned off?

No. It always goes back to default

• what does the USB part do? The doc only mentions "start emulating a USB drive. CPC will stop working".

The |PUSB command makes the Pico emulate a USB drive, which you can attach to your modern PC to update ROMs,config. Whilst doing this, it can emulate ROMs for the CPC, so the CPC stops.

• When disabling the PicoROM why do you set ROMDIS to high? Wouldn't it be sufficient to just set ROM to low? I guess a permanent ROMDIS could interfere with other expansions.

Setting ROMDIS high re-enabled the internal ROMS.

• Would it be feasible to connect BRST to RUN (via diode) instead of a GPIO? I think that would then reset the PicoROM and could then free a GPIO which could e.g. be used to add a switch that selects between default.cfg and the last selected cfg.

Probably not, since the Pico need to be able to reset the CPC (e.g. when swapping ROM configurations)

• And last but not least, would you be fine with me creating a new PCB that is smaller, doesn't contain the USB and allows to either connect to the expansion port directly or to an MX4 board? I would of course keep the reference to the original project on the board.

Sure, as long as you make it open source

[matronica]

really nice project. Cheap, and easy to build.
So I did some and design a 3d Box for it.
Would be nice to expand the capabilities (like loading disks or bigger roms) - I would like to have the capabilities but old age...
https://ibb.co/0sMdY2k

https://ibb.co/9pwZmXh

Thanks anyway.
Phil

Nice!

[matronica]

I am working on a version 2 of this. Not sure if/when it will see the light of day, but current plans are to support IO devices such as the floppy disk controller. It uses a Pico clone board which exposes all 30 GPIO pins, and a couple of buffer chips to multiplex the address bus. This gives me more available IO so that I can hook up all the address and data lines, plus hopefully enough control signals from the Z80, and an SD card for storage.

I did look at adding RAM expansion but this is unlikely because a) the Pico only has limited RAM available  b) I don't fully understand how some of the RAM expansions work e.g. C3 RAM
I was thinking about a 64K RAM upgrade to take a 464 to 128K, but I think it's not worth the effort.

[matronica]

@Philippe Lardenois 

Would be nice to expand the capabilities (like loading disks or bigger roms) - I would like to have the capabilities but old age...

What do you mean by bigger ROMs? I though that all CPC expansion ROMs were 16KB?

[McArti0]

a) the Pico only has limited RAM available 

Good info is that Pico2 has RP2350 with 520KB. This is your natural straight path. Good luck!

[matronica]

a) the Pico only has limited RAM available 

Good info is that Pico2 has RP2350 with 520KB. This is your natural straight path. Good luck!

yes, but I'm not aware of any dev boards with 30 GPIO. The RP2350B has 48 GPIO. Which is great, but I don't fancy soldering the tiny QFN package.
I guess that boards with the RP2350B will start to appear at some point.