Freeing up GPIO pins and using multiple cores

[banman11]

Firstly I would like to say that this is a great project. The discussion I am starting is more a hypothetical question rather than a request or anything else for that matter. Nor do I wish to see any changes to an already mature development of a piece of great hardware.

I don't profess to know a great deal.
Please feel free to correct me or comment about anything I say. Maybe this is what is already happening in the Sidekick64 cartridge.

I understand that GPIO pins of the raspberry pi are in great demand.
I saw this interesting web site.....
https://www.pcbway.com/project/shareproject/3_line_to_32_line_output_expander_0e6b707b.html

From what I can determine this device has the ability to control 32 lines from 3 pins (4 pins if you include the VCC).
It looks like it's HC IC component based, which would have to be tackled. Possibly other issues as well.
Would a rasbperry pi controlling 4 pins free up GPIO pins to say allow the unused Rasbperry pi cores to be active on the remaining GPIO pins?
One core might briefly pause (freeze the state of play for that core) while another core comes into play...Core 1, core2, core3, core4...back to core 1.

The reaction speed and timing of the device will definitely have to be investigated.
I am not sure if this is even a thing or it is possible to achieve.

[frntc]

Shift registers are one way to extend the number of GPIOs, another option is to use (de)multiplexers. The problem with shift registers clearly is their speed, and the timing is absolutely critical (remember, a RPi is actually not made for what it's used here): On a C64 you have half-cycles of ~500ns, i.e. reading GPIOs and putting data to output must happen in significantly less time than that. Moreover, shift registers are unidirectional.

Sidekick64 is (de)multiplexing in a different way: some inputs use 2-input multiplexers, and some GPIOs-outputs are multiplexed "by hand" using parallel connected bus drivers and latches (the display and some less timing critical signals use the same GPIOs as the data lines). CPLDs and such would make things a bit easier, but I like the approach of not using programmable parts (simply build the SK and run).

The strict timing requirements also cause trouble when using multiple cores, simply speaking because a cache miss during bus communication must never happen, and this is more likely (according to my experiments) when using multiple cores. What is good about this: using only 1 core seems to keep current and temperature low :-)

[banman11]

Thank you for a very interesting and concise reply.

I now understand that the use of multiple cores and the use of unidirectional shift registers may cause unintentional timing issues. Timing is very important to the operation of the Sidekick64 cartridge.

I do like your approach of using jelly bean IC components. I think I knocked my first Sidekick64 cartridge out in an hour and a half and it worked first time. That is great for hobbiests like myself.

Definitely with my observations using a power bank connected to the Sidekick64 cartridge for 3 1/5 to 4 hours the raspberry pi CPU barely got warm to the touch on a 31C day. There was plenty of reserve power left in the power bank also.