RAD + (new) software, damage of HW possible?

[pottendo]

Hi,
thanks for this great project. I've started with RAD (and Sidekick) recently and now I'd like to hack around my own software experiments.
I read the general disclaimer about HW damages, so don't worry - the following questions are just for me to better understand what I need to take care of in order to reduce the risk of damaging any involved hardware hopefully to zero.
I connect only the RAD to the expansion port - no more carts or other devices in parallel.

1- Can it happen that due to a SW imposed conflict on the bus any involved HW can be damaged?
Background: On the user-port I read that one has to take care that parallel 'high' logical level on I/O ports from the CIA and from an external device connected to the user-port may lead to a damage of the CIA.

2- So on RAD, if I access the C64 memory from an application, do I need to take care of anything before doing so?

3- What would be the recommended pattern to occasionally write some data into C64 memory from the RPi?
(No need to be super-optimized as probably RAD-Doom is).
I thinking of a brief instruction on
a) need to initialize once at the beginning of the program
b) need to setup before doing a transfer (poke & peek)
c) which variant of the xxPOKE() macros to use for which use-case (POKE() vs. MPOKE() vs. SPOKE())
d) cleanup after the transfer, if needed

Alternatively I use Sidekick64, so my questions also would apply to software on the RPi/SK64 and even more for Sidekick20. I have the VIC20 adapter, a shiny VIC20 and some ideas to hack also VIC20 stuff on "Sidekick20-Steroids". Any comments on this are also very welcome.

Thanks for any advice in advance,
pottendo

PS: again, big Thanks for these projects - really cool stuff to keep the motivation to hack the retro world!
PPS: I'm proud owner of one of the 'OrangeCart's (credits to @zeldin). You may have a look on some of my projects there:
RVCop64 SMP + FPU
Zephyr on OrangeCart
...I even started to port Doom to the OrangeCart, but compared to RAD-Doom, failed miserably (so far). ;-)

[frntc]

Hi, just some quick answers for today:
You'll be communicating on the bus together with CPU, VIC etc. That is you have to obey to the rules such as checking BA to see whether the VIC wants the bus even in CPU cycles. Of course the CPU must be halted if REU/RAD uses the bus (keep in mind, even when pulling DMA the CPU completes possible write cycles).

A simple example is the checkForReadyPrompt-method. If hijacks the C64, reads some RAM, writes something, then releases the DMA. It is even simple when the CPU triggers some execution, e.g. by writing to IO1/2, because then it just finished a write operation and you can immediately take over (still need to check BA, but the macros in the framework do that for you -- look for PEEK and POKE)

For Sidekick64/20: these communicate via ROM/RAM-banking and IO1/2. That's very simple and you can just take, e.g. the GeoRAM example or simple cartridges as a starting point.

[pottendo]

hi,
thanks for this first feedback. Will read a bit into the source to get a better understanding.

The primary question is still: can I damage HW when not following the rules (e.g. check' BA)?

thx, pottendo

[frntc]

I think as long as you follow my implementation (and do not set weird timings): no.

I didn't manage to damage any HW during development, but of course I'll take no responsibility what others do to their Commodore ;-)

[pottendo]

sure!
I hacked alot on the user-port (modem based on esp32) with respective drivers on both sides. So I really took care...
...and soldered some resistors to protect the CIA. ;-)
thanx & happy hacking, pottendo