Could the Sidekick potentially emulate a full c64 on a vic20?

[sergemarx]

Would be super cool to plug in a cart and turn a Vic into a c64 or 128. I realise it's not in scope this project, but I'm curious if it's feasible?

[delMar43]

This is what you’re looking for: https://youtu.be/twbt9VBtxdk?si=FERRLB_2hFd-lCdr

it‘s a dedicated pcb for bmc64 that uses the c64‘s keyboard and joystick.
output is via the raspberry hdmi

[sergemarx]

It would certainly add an extra benefit for VIC20 owners if possible. It's a bit personal for me... Dad bought us a Vic just as all my mates got C64s. In my stupid kid brain I always thought commodore should have made an upgrade cartridge so I too could play ghost busters... Now that it's kinda possible, would be nice to see.

[fanoush]

In principle this would not be hard to do: let the RPi run BMC, plus some code on the VIC20 (or other original system) which reads keyboard and gameport(s).

this is great idea, so do you think bmc64 could run on sidekick64 pi3a or zero2w and still run some cartridge emulation on one CPU that would send some prg to c64 at reset and then read keyboard/joystick data passed to it? Not sure how the communication c64->sidekic64 could be done but I imagine reading some cartridge area could send data via the address low byte an the high byte 8x-9f could be command (read/write/whatever).

I briefly checked the cartridge kernel and it looks like it runs on single CPU? However I am not sure about the timing and cache when bmc64 will run on other cores.

Oh, actually when googling the idea someone already made it but not with sidekick64 pcb https://www.lemon64.com/forum/viewtopic.php?t=78464 so the communication is done via separate CPU

[frntc]

I've seen this post a while ago, is this published somewhere? Not sure what's on the PCB, looks like some flash or SRAM (maybe dual-port, which would make data exchange easy) and a CPLD or uC.

Yes, Sidekick64 is using a single-core, I tested multiple cores only briefly without success. One would have to squeeze in the communication in between the emulation.

[fanoush]

I tested multiple cores only briefly without success.

That is what I feared. Anyway I have one sidekick64 on a way to me and need to fix my C64 power supply but then I'll try. I hope the most timing critical is returning data to C64 over data bus(?) so matching just address reads without returning correct data could be easier?

If I would just use cartridge emulation initially (with bmc64 stopped) to load code into C64 ram and then stop full crt emulation and in c64 just scan keyboard/joysticks and do reads e.g. on 0x9fxx where xx is keyboard scancode (lda $9f00,x) without expecting to get anything sensible back then it may not be that timing critical so it could be part of bmc64 emulation running? c64 would probably get some random garbage from the bus loaded into A but that doesn't matter.

I've seen this post a while ago, is this published somewhere?

did not find anything except forum posts and youtube video with posts below it suggesting contacting via email

looks like some flash or SRAM (maybe dual-port, which would make data exchange easy) and a CPLD or uC.

from the photo here https://postimg.cc/WDGsPy8J my guess was buffer/level shifter and some MCU - maybe atmega328 running from 5v and level shifter into RPI

[frntc]

Running CRT initially and then disabling it makes sense. Forwarding scancodes by reading: might go wrong this way (or be delayed) when your BMC<->C64 sync misses the same reads again and again.

re MCU: apparently someone didn't want us to read the markings ;-)