My Interest

[odflor]

Hi Everybody!

I'm interested in two things:

1. Use the SideKick64 as a graphic and main co-processor to allow Commodore to support more advanced games (like a Amiga 500 capabilities)
2. Sometype of api to manage the SideKick64 capabilities to allow to activate features before run a program without user interaction (like a Windows 3.1 .pif file)

Is there some kind of documentation to do that?

Best Regards

[frntc]

Hi,

1. you mean you would like to run an emulation and use the C64 for input devices and output? When using Sidekick64 for this, you would need code running on the 6510/8500 to handle the communication (there are two videos where I used the RPi for 3D graphics). The RAD (see the Doom experiment) can do everything by itself via DMA.

2. many of the emulations are mutually exclusive, so it's not simply enabling/disabling individual features. Still some control from the outside would be easy to do -- what use case do you envision?

[odflor]

1. The "terminal emulation" aproach could be cool (I think that the idun cartridge works like that), the program (like a game or a GUI desktop) could be executed on the RBi and the Commodore just show the captured frame on the screen. Good 3d graphics games can be made this way. I don't know how the Doom experient works. I have not the RAD. Time ago, I did a little experiment with this aproach using a wifi modem but is too slow for something different than text screens, I think that using the sidekick64 could be very more fast. Normally I use a c128 because I like the VCD and the improved memory and processor capability of this computer.

2. I think in a use case when need to use de ram expansion plus the FM SID emulation together when I press ENTER over a program that needs this two expansions at same time. Like the custom-logo is a separate file, the configuration file could be a separate file with .pif extension.

[frntc]

I see. RAD-Doom works a like what you said (but the 6510/8502 is completely stalled). However, this means that someone has to modify or write programs making use of that. I was also thinking about having a terminal initially, but somehow everything else was more fancy :-) Maybe some "API" could be useful solving the chicken-egg problem, but so far this seems like a niche demand.

Regarding 2): yes, this makes sense, but as said, many extensions are mutually exclusive, and in particular FM/SID-emulation is something that completely trashes RPi-CPU-caches, eventually causing problems with other emulations.

[odflor]

1. If I can execute a program (maybe a console program) on the RPi, that process some stuff (without screen output) at the speed of the RPi, instead of the 6502 and I can access the result of his execution even accessing a memory range or reading a file on the RPi file system is enough for me. I want to use the RPi as co-processor for generating screens or mathematical co-processor for large calculations, like the points of a circle.

Use case 1) I want to draw full circles dancing on the Commodore screen at high resolution, then I use the RPi as as double buffer and ask him to draw the frames I want to show on the screen, but in his memory. The Commodore only needs to copy the frames result on his screen.

Use case 2) I want to ask a http request to a web service and show the result on the screen of the Commodore like a weather cast or the result of a primary or DOW current values. Stuff like that.

You mentioned very times the RAD project, maybe I'm facing the wrong project.

[frntc]

I'd say hardware-wise you could do this with both the SK64 and the RAD. The main difference is that the RAD can do (fast) DMA transfer, while the SK64 transfers memory slower (e.g. running on-the-fly created speed code). In any case you'd need to run code on the 6510/8500 and sync with the RPi (during network transfers it most-likely cannot guarantee reliable bus communication).