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.

[frntc]

That's weird (maybe I missed something), but readConfiguration is called after the Pico has startet, and in this state it's clocked slow enough so that the flash must work.

[rsquared68]

Until you wrote that, it didn't occur to me that of course the Pico should start with a normal clock and not have an issue, unless something is configured wrong in my SDK.

Maybe the actual issue is caused by what looks to me (Pico newbie) like an out-of-place SET_CLOCK_FAST in the writeConfiguration function

void writeConfiguration()
{
	SET_CLOCK_125MHZ
	//sleep_ms( 2 );
	DELAY_Nx3p2_CYCLES( 85000 );
	flash_range_erase( FLASH_CONFIG_OFFSET, FLASH_SECTOR_SIZE );

	uint16_t c = crc16( config, 62 );
	config[ 62 ] = c & 255;
	config[ 63 ] = c >> 8;

	flash_range_program( FLASH_CONFIG_OFFSET, config, FLASH_PAGE_SIZE );

	SET_CLOCK_FAST                // <---- why? if you immediately set it to 125MHz again

	SET_CLOCK_125MHZ
	DELAY_Nx3p2_CYCLES( 85000 );
	readConfiguration();
}

It's possible that on my HW, the DELAY isn't long enough for the 125MHz to take effect before it starts readConfiguration. This could happen when writeConfiguration is called from somewhere else, which if I remember happens in the config bus-handling part. That doesn't explain startup; maybe reset behavior? I actually only tested the SKPico in a 326298 board, which if you know it has a wonky reset circuit. I modified the board it to be more like the 250407 so EasyFlash 3 will work, but I don't rule out that the Pico could get an extra reset on powerup. If you like I can do further testing and send screenshots comparing how it looks corrupted/fixed with and without the extra slowdown and other options like removing the extra speed changes or increasing the delay, but it now all works well for me so I've set it aside.