What am I doing wrong?

[jonnypoko]

Made up a few of these beautiful boards and tried with two official RPi Pico H - both work fine (very excited) Then I tried with three RPi Pico RP240 clones (4M and 16M veresions, non LED) and none of them work - no sound and no config menu? all three of these boards work with the blink.uf2? what could I be doing wrong, I'm afraid my knowlege of RPi ends about here? Awesome project!! what is the difference between the LED and RGB uf2 files (where do I find that info? - sorry pretty new to github too)

[frntc]

I hope you did not try the purple clones? Because they have another pinout and won't work... (flash size 4M, 16M, ... does not matter)

LED = firmware that lets the status LED blink, RGB = firmware for clones with RGB LED on the PCB.

[jonnypoko]

purple as in pcb colour? mine are black? I have ordered a couple of the RGB LED ones as well and they should arrive soon.

[frntc]

Color aside :-) -- is the pinout the same as for the original Pi Pico?

Several people experience bad build quality for the cheap clones (wrongly soldered parts, solder bridges etc), so the best thing is to also try a "blink" example to see if it works at all

[jonnypoko]

Blink works on all of them, but you are correct the pinout is different??? why would they sell clones with different pinouts, it's a black board (both the 4M and 16M versions) which has some random pin config. I should have checked this I guess, but it is hard to decipher from the various order links on AliEx. So a WARNING TO ALL not all clones are created equally - even before you get to build quality issues. Is there a differnet RPIPico board they are trying to emulate with this pinout do you know? Anyway, the boards with the RGB on seem to be a match (arrived today) so I will try those tonight. Final Question - what are the minimum pins required to hook up the SidKickPico and the RPi board?

[jonnypoko]

I just wanted to add, thanks for the help and that I have never been more excited about a new project than after watching the "more fun fixing it" youtube video on the SIDKickPico - I ordered the boards that night...👍

[frntc]

you mean which GPIOs from the Pico (clones) are needed for the SKpico? all that are present on the original Pico :-)

[jonnypoko]

next phase of my journey from planet stupid - I got the new boards with the RGB LED on and the first one i have soldered works fine - sound, menu - but no RGB? I preesume the sidkick pico board is outputting the WS2812 to GPIO23 on pin 37?

[rsquared68]

I think the pinout is the same except for 3V3_EN, but I have no real Picos. https://github.com/initdc/YD-RP2040/blob/master/YD-2040-PIN.png I’m super interested in your projects because for a long time I wanted to experiment with C64 bus interfacing—your stuff is great! If you want I can send you detailed documentation of what I know so far, but using the v0.1 PCB in a PAL 326298 and Kawari clock I find the following (I don’t think this is the problem because friend reproduced similar behavior in a stock NTSC machine with the uf2 files in the 0.202 release): 1. V0.14 .uf2 gitHub release works perfectly 1. V0.20+ .uf2 gitHub release makes sound, but version string is trash, on initial entry configurator screen has some other garbage, save/load config doesn’t result in any changes, prg launcher screen is filled with garbage and crashes C64. However, it emulates some SID configuration and makes sound OK. It just seems when interacting with flash there is a problem. I tried several different .uf2 files from the release for both PCB versions. They all behave identically in this respect. 1. Because flash seemed implicated I wanted to investigate, and I tried to build from the .zip archive in the release—I did not clone the repo bc I am experimenting with sandboxing VSCode. Anyway, it would not build initially because RESET and bRESET are undefined but used, and extern resetEverything() is nowhere in that zip archive. On PCB v0.1 SID reset is connected to RUN so there is no way to define RESET or bRESET mask so I just commented out the offending stuff. I found resetEverything() in the firmware v0.10 archive. Builds OK but does nothing in the C64. 1. I next looked at the GPIO mapping to start to understand the interface—it was clear to me that there was no way the code could work because the code suggested that RESET was connected to a GPIO but in the circuit it was not. I discovered that in the .zip source release, the code had (for example) phi2 on GPIO 12 when it is actually on GPIO 9 (passing through the lower FET buffer) on the PCB I have. Someone gave me the boards and said they were from PCBWay; that’s all I know about the origin. It has the same silkscreen etc as the photos in your repo but maybe this design is somehow different? After probing around with a multimeter and logic analyzer, I had to redefine all of the GPIO mappings except for D0-7 and the LEDs. 1. After redefining the GPIO mappings the config menu started to work, but had the same corrupt version string and graphics, but also no sound. I increased the flash size in pico.h (actually created a new board definition) and rebuilt the pico-sdk. After increasing the size, all of the flash-related problems went away, no corruption of version or graphics, prg launcher menu works, etc. 1. Sound emulation (DAC and PWM) and the onboard LED do not work with my modified build yet. It’s weird because the config/launcher works, and even the paddles work. So either reSID isn’t running properly, or possibly RW is somehow stuck and the CPU can only read from the SIDkick. It’s possible that reSID is somehow not happy because of the workarounds I put in for RESET and bRESET, but the LED (not the RGB LED) doesn’t show activity either so maybe something else is stuck in runEmulation. The bus handling otherwise seems ok. When I rebuilt with the larger flash size, I only rebuilt the SDK. It occurs to me that the memmap copy to ram or whatever also has the wrong size hard-coded in it so maybe I should adjust. If you have any specific requests for things to try to further debug or for testing on weird machines let me know. Currently I have one mostly stock 64C from Germany (has a TOLB clock in it though), a US locale breadbin with a VIC-II^2 switcher ntsc and pal, and a US locale breadbin with a VIC-II Kawari. The friend that gave me the unpopulated PCBs probably has 30 more 😊 Once I get this to work I’m curious to see how it behaves with my own long-neglected project (https://github.com/rsquared68/schreckenstein64/releases/tag/rc1.0) – I added sound at the last minute and since I don’t fully understand hard-restart the gating is done with extreme violence at the moment. It also relies on OSC3 for fast random number generation, and some emulations really mess up the game progress if this isn’t working well. Best regards

…

________________________________ From: frntc ***@***.***> Sent: Wednesday, July 17, 2024 11:34:19 PM To: frntc/SIDKick-pico ***@***.***> Cc: rsquared68 ***@***.***>; Comment ***@***.***> Subject: Re: [frntc/SIDKick-pico] What am I doing wrong? (Discussion #39) As long as the pinout is the same, these YD-RP2040 boards should work (do you have a link?). The flash size does not make any difference, no need to recompile the firmware. (I'm mostly using 16MB boards.) — Reply to this email directly, view it on GitHub<#39 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BFFUBRORSLHHHWZRZ6Y6YJDZM5OWXAVCNFSM6AAAAABF5N7CHGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMBYGA3DMMY>. You are receiving this because you commented.Message ID: ***@***.***>

[frntc]

Just a quick answer for today: the Pico-clone pinout is fine, I'm using the same ones here. The problem you describe is certainly not the flash size, as I'm using different flash sizes. The size you can change in the source is just to amount of flash reserved for PRGs. And yes, RESET is connect to a GPIO, depending on the hardware revision... (also there are more hw revisions existing than those that I've made available so far ;-)).

The most likely reason (if I gathered the information right) for your problems (it plays, but config menu doesn't work) is that the bus communication is unstable -- I know that I need to touch the config tool because of some NTSC machines, and the Kawari is said to cause different timings on the bus than the original VIC (but I don't have one myself).

My recommendation is: first experiment with the timings, you can do that with SKpicopatch.exe. For everything else: we should maybe take this offline, you'll find my mail address in the source.

[rsquared68]

I'll follow up--I found by building from the source that my specific problem with the released .uf2 was related to flash memory speed and everything else was a red herring. The memcpy from flash commands in readConfiguration() didn't work properly for me when the clock is 300MHz—maybe the flash is slower on this clone board. The code listing in the source .zip archive does SET_CLOCK_FAST after the memcpy, but nothing performs a SET_CLOCK_125MHZ before. Maybe the slowdown macro had been in the code at some point and got deleted as unnecessary, but I still need it for things to work. Slowing the clock down before the memcpy fixed all the save/load problems and issues with corrupt strings etc. in my case. It works great and I'm quite happy with it.

[Bigi74]

Hi, I have the same problems with the trash in the configuration menu, everything is mixed up and I can't save the configuration, the version I have in the pico is the latest SKpico2_DAC_PWM_RGB.uf2 on firmware hw ver.0.2 fw0.21 in mono version. I use C128 Pal. Music and RGB work but without any control and it seems to me that it occasionally hiccups, for me menu for prg files works without the trash and I put a one program for testing, after shutting down and restarting the program is in first place and works without problems. I also have Action Replay VI installed but even without it I have the same symptoms, maybe I'm also bothered by the too fast flash on the clone pico?
Can you send me the processed flash so I can try it with it and by the way I'll also check what revision the motherboard is and it seems to me that it has a German keyboard layout.
Sorry for the long post and best regards and awesome project Frntc

[rsquared68]

These builds are what I'm using and built with only LED and no RGB; one is PWM-only and the other DAC-only:

r2-build.zip

Consistent with the above discussion I'm not sure why these work but they do work for me. If the flash starts behaving better (trash in menu gone, save/load works, PRG menu works) but you have other problems you'll still need to tune the timings with the patcher. Notably, in my case everything worked except the Flex tune accessed by hitting 'p' in the menu would not play until I adjusted the timings. In my case judging by my shell history I used .\SKpicopatch.exe .\SKpico202-DAC-LED-RJR.uf2 10 11

If this works I can rebuild for you with more features enabled. Note if you also use the RAD Expansion it probably won't properly detect these builds because I think the version string is different.

[frntc]

I you really think there is a problem with the flash -- please take a photo of your Pico (clone) so that we can see the flash IC model.

But: if there are problems launching the menu, then please follow the trouble shooting section and adjust the timings!

[rsquared68]

I just got around to upgrading my clone to v0.21 tonight, and I encountered the same problem that I had with the earlier versions similar to what various folks are describing where the flash access causes issues with garbled screens and lockups when using the release build, independent of any timing settings. Since I had a "solution" from experimenting with the FW earlier versions I just implemented it again and rebuilt from source--and v0.21 now works perfectly. I totally agree with you that my "fix" of adding another SET_CLOCK_125MHZ at the start of readConfiguration() shouldn't do anything but this time that was all I changed and that fixed it for my build. I've attached shots of what the bad behavior looks like before the change, and my version of SKpico.c that works for me so you can diff it to see what I did. It's just strange that this makes it work, but I'm happy with the result. This is the black YD-RP240 clone, and the SPI flash is marked as a Winbond 25Q32JVSIQ part with datecode 2135. I've scanned the timing settings and for me phi2=10 and read_bus=11 is the middle of the "where it meets timing" matrix, so I probably hardcoded that in the attached source.

SKpico.zip

[Aelius00]

Hi, I'm still a bit too new at this to recompile the uf2. If you're willing and have time to recompile the DAC_PWM_RGB led enabled with your updated code and make a uf2 file for me. I'd like to give it a go and flash it to my pico. I'd truly appreciate.

[Bigi74]

Thanks for flash,i will try and post results. i dont have RAD only AR VI and epyx fastload but most of time use arVI thanks again for helping me. pet, 15. stu 2024. u 00:30 rsquared68 ***@***.***> napisao je:

…

These builds are what I'm using and built with only LED and no RGB; one is PWM-only and the other DAC-only: r2-build.zip <https://github.com/user-attachments/files/17758987/r2-build.zip> Consistent with the above discussion I'm not sure why these work but they do work for me. If the flash starts behaving better (trash in menu gone, save/load works, PRG menu works) but you have other problems you'll still need to tune the timings with the patcher. Notably, in my case everything worked except the Flex tune accessed by hitting 'p' in the menu would not play until I adjusted the timings. In my case judging by my shell history I used .\SKpicopatch.exe .\SKpico202-DAC-LED-RJR.uf2 10 11 If this works I can rebuild for you with more features enabled. Note if you also use the RAD Expansion it probably won't properly detect these builds because I think the version string is different. — Reply to this email directly, view it on GitHub <#39 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BM6HUTBMWAMH2PMJBNRORP32AUXB3AVCNFSM6AAAAABF5N7CHGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRWGA4TANY> . You are receiving this because you commented.Message ID: ***@***.***>

[Bigi74]

Hi, in pico now is "SKpico2_DAC_RGB.uf2" firmware i try today difrent timings from c64 floppy and found that if 11 replace with 3 i got better menu but not all is perfect on other side i replace 15 with 10 and i got better results, then i become impatient and set timings to 3 and 5 then pico freezes and no sound and cant call menu or use timing prg, tomorow unscrew 128 and reflash :) where is official firmware to use for auto diagnose Frntc?is one from your package? and btw i ordered 1 more from restore store today
Sorry for bother you Frntc.

[frntc]

you can try small values for both timings (if one needs to be smaller, than the other one typically as well). The diag is part of the normal firmware (latest version). As said, it's not absolutely failsafe, but typically displays a warning if something is wrong (at least it did for all the testers)

[Bigi74]

Update: I have with c128,2 c64 and board on one have sid socket and after reflash i insert pico in c64 and same problems like on c128 lookslike meybe is cold solder pin, i dont belive that both mbo have timing problem and i notice that right channel most of time is much lover in volume than left if is configure on $d420. if is $d400, right channel have same strong volume like left from speakers.
Any hint from your expirience where to start refresh solder pico? or sidkick? frntc?

[frntc]

If the menu is not working reliable (despite adjusting timings) then one of the two CBTD3861 (or their soldering) might cause the problem. Both are required for the bus communication so there's no priority which one to test first.

If you configure a 2nd SID at $d420 (or any address other than $d400) then the maximum volume is not reached by a single emulated SID, i.e. single-SID tunes are played with lower volume. This is because when you set both to $d400 you get 2 SIDs playing the same tune.

Which SKpico-PCB do you have and how do you output the sound? (external DAC or built-in?)

[Bigi74]

version 0.2 with dac builtin and sound is connected to 2.1 pc speaker

[Bigi74]

[frntc]

Ok, I was asking because with this version you could route the right channel through the mainboard (but that's not recommended, and I assume you're not doing that, correct?)

[Bigi74]

Correct. sri, 20. stu 2024. 22:05 frntc ***@***.***> je napisao:

…

Ok, I was asking because with this version you could route the right channel through the mainboard (but that's not recommended, and I assume you're not doing that, correct?) — Reply to this email directly, view it on GitHub <#39 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BM6HUTEJCVDMTCN625S7ZVL2BT2TNAVCNFSM6AAAAABF5N7CHGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMZSHA3DOOI> . You are receiving this because you commented.Message ID: ***@***.***>

[frntc]

Ok, then you should double and triple check the soldering and that the pins tightly fit into the SID-socket. I think it's unlikely that one of the CBTD3861 is defective.

[Bigi74]

Ok,thanks for help 👍🏻 sri, 20. stu 2024. 22:10 frntc ***@***.***> je napisao:

…

Ok, then you should double and triple check the soldering and that the pins tightly fit into the SID-socket. I think it's unlikely that one of the CBTD3861 is defective. — Reply to this email directly, view it on GitHub <#39 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BM6HUTBCN4QVVHJIAWDOOML2BT3FPAVCNFSM6AAAAABF5N7CHGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMZSHA3TCNA> . You are receiving this because you commented.Message ID: ***@***.***>

[Aelius00]

Hi, I've been searching everywhere for an answer. My pico was working fine but I decided to use Mssiah and add Pin7 for adding $de00. It worked well... However... Now almost every time I go in to the SIDKick menu it's garbled. Even overwrites settings by itself. Hitting F8 sometimes stabilizes it. I unsoldered the pin and reflashed it but the problem still persists. I have no idea what's gone wrong. I think it keeps thinking it's got a conflict with the expansion port. Perhaps the CBTD3861is fried? lol

Maybe the auto detection goes nuts somehow? Hmmpf.

It's the same black board as pictured above. Leds work. It actually worked perfectly before I added $de00.

Edit: I see another post with the same issue. Seems to maybe be a hardware fault? In that case maybe it might be better to flash the pico without a menu but already with the required SID options pre-set in the chosen uf2. Because so far It does seem to retain the SID settings as long as you don't enter the menu.

[frntc]

The configuration is overwritten with default once you flash the firmware again. Also cartridges do influence the bus signals, I think you should try different timing values first.

[Aelius00]

I've tried many different values. All of them seem to make it worse. Small increments to large.

Edit: Hmm. Seems to get worse and worse the more I try to enter the menu. Even on default values it now just freezes up the entire computer. Sometimes wont even enter the menu. Sound becomes really nasty too.

[frntc]

Can you try a different Pico (clone)? You're using one of the black clones, right? I'm asking because of the build-quality issues...

[Aelius00]

Sadly, I don't have a desolder gun anymore at the moment. It died last month. I also don't have any spare SIDkick boards to build a new one. If user rsquared68 is willing to compile a new uf2 with the updated setting with DAC_PWM_RGB enabled, I'd be willing to give that a go. Perhaps you could compile it? I don't trust my knowledge enough yet not to brick something.

[frntc]

Independent of your SKpico variant you can try the firmware he posted above (just to check if the menu comes up). But as @rsquared68 mentioned, I have no idea why that redundant line of code would change anything, if at all, I'd increase the waiting time for the flash which should have the same effect.