Best way to test?

[norrinr]

What is the best way to test the full functionality of a Sidekick64 cart/board?

[banman11]

Interesting question.
Are you wanting to know the full software features of this product or are you determining whether the unit has been correctly constructed and are ensuring that the PCB circuit is performing as intended?

[frntc]

if you want to test the hardware side, here's a rough check list

• if menu comes up (including OLED/TFT), then most of the signals are already working
• next try GeoRAM-emulation and some test program
• running a freezer cartridge and some Easyflash cartridges typically cover the rest
• run SID emulation and kernal replacement to verify the two special pins

[norrinr]

The reason I asked this is that sometimes I get random lockups with known good software and am worried about the cartridge itself. When I tried the instructions for the net kernel (using 4.8 firmware), I even sometimes get garbage on the screen in the menu. Net kernel entirely failed for me, crashing CCGMS after sending 2-3 characters IF it even gets that far, with both 4.8 firmware as well as latest.

[frntc]

I can't really tell much about the problems specifically related to the network kernel. But the standard one has to work. If it doesn't (in particular the tests above) you need to check contacts and soldering. Does it pass these tests (reliably)? If not, which one breaks?

[hpingel]

When I tried the instructions for the net kernel (using 4.8 firmware), I even sometimes get garbage on the screen in the menu. Net kernel entirely failed for me, crashing CCGMS after sending 2-3 characters IF it even gets that far, with both 4.8 firmware as well as latest.

@frntc should not be held responsible for what I might break in the network kernel. The network kernel is maintained by me and I have stated in the documentation for the network kernel that Swiftlink modem emulation with CCGMS is completely unstable at the moment: https://github.com/hpingel/Sidekick64/blob/net-rebase-on-v0.48/README_network.md#swiftlinkturbo232-modem-highly-experimental
I write: "A Swiftlink modem may be emulated (which normally would be connected to the expansion port). This is still highly experimental at the moment and will crash CCGMS after a couple of screens."
So your tests successfully confirm that. ;-) Besides the Swiftlink emulation, there are other features in the network kernel that work quite will. Having said that, when you are new to Sidekick64 you should stick to the "vanilla" kernel for a while to get a feeling for how stable Sidekick64 really is.

[norrinr]

Right, no implication about responsibility implied, just reporting results. I was able to upload a CRT and a D64 via the web interface, but st2014final.d64 locked up with the first file it tried to load. This hasn't been tested again with vanilla/latest kernel, which I should try.

[hpingel]

Launching D64 as a whole via built-in D2EF works for some D64 but not for all D64. Here I hope that vanilla kernel and network kernel should behave similar as D2EF is used in both cases.

[banman11]

Interesting.
There could be a few reasons for this. What types of IC's are you using on your Raspberry pi hat?
Some variants of IC are not suitable for this application (this is discussed in one on the threads on this project site outlining the non suitability of some types of IC components).
What C64 mainboard are you running, let us know?
Another could be timings. The different C64 mainboards will have different timing characteristics as well.
In the Sidekick64.cfg file under the C64 folder there are a set of timings used by the raspberry pi to communicate with the C64. This also might be a source of issues.

I have been trying to replicate the famous Super Zaxxon cartridge with dodgy Winbond EEPROM PLA substitute experiment. Unfortunately I only got it to work once out of numerous attempts.
I would imagine that adjustment of the timings in this sidekick64.cfg file would make the C64 more likely to become EEPROM PLA substitute glitch sensitive than it currently is on my system.

Just something totally unrelated...have you double checked the soldering on the IC components (especially the larger ones)? They may look like good connections when infact they are marginal. I had 2 boards like this. One would display just garbage on the screen. Go thru with a small probe or pin to see if they are anchored firmly to the PCB circuit board.

I could be totally wrong here. Please correct me if anything is missing or incorrect.

[frntc]

I would suspect some contact/soldering/IC (although it's mostly the 74LS30/HCT30 where you could use the non-suited HC30) issues. The timings (in particular those for the RPi 3A+/B+ have been untouched since the very beginning and every problem that was reported to me, had different issues -- nobody needed to touch the timings as long as the rest was ok).

[norrinr]

I used to know the mainboard version, but it's been a year since I opened it up.. Last time I superglued one of the screw poles in place and have been hesitant to open it up again. Good ideas here on the adjustments and tests. Here is a pic of the above and below.. admittedly they looked better on the smaller screen they were taken with :).

https://imgur.com/a/6ly5JIv

[banman11]

I totally understand about opening up your C64. These things are very old and can break very easily.
I notice a few things. You are running the Raspberry pi from the C64 power. Try powering your pi from an external USB cable power source (remember to start the raspberry pi before the C64).I noticed that some pins on U1, U2 & U3 look like they could use a little more solder.I had problems with these IC's on my build. These large IC's were shipped with legs that were not totally level. To my eye they looked good and flat, however some were slightly raised. Resulting in a poor connection to the PCB pad. 
See if that works.