Some SKPico notes, still haven't totally given up...

[VanessaE]

After the fiasco last month trying to get that SKPico working, I basically just kinda pushed the whole system away for a while. I needed to "touch grass", as the expression goes, plus I was just plain burned-out.

I know I said I'd washed my hands of this project, but something stuck in my craw: @frntc , you said it's possible I'm missing something due some limitation of my TDS-420A oscilloscope (but I don't recall you saying what it could be). Fair enough.. it's an old piece of hardware, nearly as old as the computer itself, and I've been wanting to replace it for a number of years anyway.

So I did. Enter its successor: a brand new Rigol DS1054Z.

Of course what's the first thing I do with it (after taking time to learn how to use it)? Put it on the C128-DCR and get some readings with the SKPico installed...

Here are Phi2, R/W, SID /CS (SID socket pins 6, 7, and 8), and data line D0 (VIC-IIe pin 7) while playing a $D418 digi (actually my modplayer in "Mahoney" mode):

The trigger is set to pattern mode: Phi2=high, R/W=low, /CS = falling edge, D0 = don't care.

I saved that shot while in "run" mode, so that you could see the (imho low) overall noise level, timing variance, and D0 signal range by way of the scope's persistence feature. I picked D0 from the VIC-IIe because it's physically close to the SID socket, and it's easier to get the probe to grab on properly there.

All probes are brand new (the ones that came with the scope), set to 10X mode, and have been properly "compensated" (the industry needs to come up with a better term).

You may also notice the clock frequency at the top right. That's the scope's built-in hardware frequency counter, and as you can see, Phi2 is dead-on at 1.02272 MHz.

I do note that there's a lot of negative overshoot (or is that undershoot?) on falling edges on R/W, /CS, and D0, but I don't really know if that's real or if it's just an artifact of the much higher bandwidth being shown (this scope has the 100 MHz bandwidth capability enabled). Turn on 20 MHz limiting and the majority of that over/undershoot goes away. Here's a capture with that limiter turned on (on all channels):

Not shown in the above images, I measured the 0v-to-2v rise time of Phi2 at between 16 and 19 ns depending on where I set the starting point's cursor and whether bandwidth limiting is turned on (it's hard to be 100% certain given the level of noise, but that's a far cry from what the 420A was showing).

The machine is in its normal/default state -- I could put SID chips in and close it back up if I needed to -- and it has not been altered in any way since the last time you heard from me (except that I took out that temporary "clock amplifier" circuit of course).

The SKPico is in a not-working/silent state at the moment, but as in the past, I'm sure it would eventually "wake up" if I were to power-cycle the machine enough times.

[frntc]

@VanessaE maybe you could test this firmware -- it's not doing any SID emulation, but providing means to analyze the bus signals. You need to flash the firmware, then run the .PRG (when the LED is blue, the SKpico is ready for "measurements"; you can run the PRG multiple times).

Of course the transfer of the results back to the CPU requires bus communications. The timings for that are determined from the measurements. Let's see how this goes...

Ideally, you get an image similar to this one:

SKPicoTimingAnalyzer.zip

[VanessaE]

Please be advised: I have since bought an ARM2SID. Apart from one or two emulation-related bugs, it seems to work just fine.

Still, I do not like unsolved mysteries, so I put your firmware on the SKPico, installed it and turned the machine on.

I got lucky on the first try, the SKPico started-up with a progression of colors, ending with a blue LED:

Then, I power cycled the machine once, and the SKPico did not go through any color sequence on power-up (the LED simply remained off).

I ran the tool anyway just out of curiosity:

I'm going to assume none of that is legit 😛

I power-cycled a few more times just to see what happens, and most of the time, the SKPico appeared to do nothing (no LED), which seems consistent with all that testing I did before.

[frntc]

The first image looks perfect, all is working and it says you could try timings 12/1 (but the bars suggest that default timings (where the PHI2 value is >= 12 and READBUS is not excessively large) would work as well.

Second image: when the LED does not light up then the SKpico did not start at all (and the result is just values floating on the bus -- this is not "timings off" or "low voltages", just randomness, so we learned something from it!). To be absolutely sure I could compile one more version which always uses timings 12/1 for transfering the results, to eliminate the last doubt that just the transfer of the measurements is wrong.

The start process btw. does not depend on anything but power, i.e. if you'd provide 5V/GND to the SKpico you should see the LED. So maybe the 5V power at startup time is what causes problems (and other hardware copes with that better). In principle you could test this by supplying 5V to the SKpico from a separate source (of course connecting grounds), but this is some tinkering.

[VanessaE]

when the LED does not light up then the SKpico did not start at all [...] so we learned something from it!

That we learned something is the most important thing, I'd say. 🙂

Incidentally, I do seem to recall stating that all those times when it didn't work, it looked like the SKPico wasn't even starting up. So I was right?

The question now is, what would even cause that?

In principle you could test this by supplying 5V to the SKpico from a separate source

Doesn't seem like that would do much since the C128-DCR's primary power input is just a few centimeters from the SID socket, so there isn't much opportunity for power loss.

But just to be sure, I caught a power cycle where the SKPico's LED didn't light up, and probed the SKPico at pin 25. I show 45-50 mv of high frequency noise on the scope (the DCR's switch-mode PSU is probably the direct source of that, or it's just ambient RF noise, G*d knows there's gotta be plenty of THAT around here), and a steady 5.05 volts via my meter. For comparison, I got similar measurements at the Expansion Port.

[frntc]

For easier testing you could power the SKpico without the C128D (via pins 14 and 25), e.g. from USB, and see if it boots up properly every time.

[VanessaE]

You mean like plugging it in via the cable I use for flashing it, minus the "boot" jumper?

Okay. Took the SKPico out of the 128, plugged the USB cable in WITH the jumper, just to confirm that it's still alive.

Unplugged the SKPico end of the cable, removed the boot jumper, plugged back into the SKPico. Then I put a weight on that end of the cable to ensure it won't move.

Then I just sat there plugging/unplugging the other end of the cable (that is, where it plugs into my powered hub) multiple times, watching for the SKPico to react.

Across a few dozen or so tries, only a few times did it turn its LED on when I plugged it in (green each time). Roughly 1 in 10 tries, I'd say.

[frntc]

Ok, the LED should be on every time. This means that the SKpico is either defective from the beginning on (unlikely with 2 different ones though) or got fried somehow. I got a defective one produced once where the soldering of the uC was not OK... but yours have been tested before you received them, correct?

[VanessaE]

Well, the first one came from Retro8bitStore, the second came from @RevivingRetro. I do not recall if either was fully tested before sending.

I'm very careful handling electronics (gotta be, with this retro stuff), so if both failed due to something I've done, I can't explain how that could have happened, especially since both behave(d)/failed identically.

Is it possible the actual PCB fab used counterfeit chips?

[VanessaE]

Here's a magnified view of the component-side in case it's useful:

[RevivingRetro]

I tested my entire batch when I received it. In fact, I'm using several in my machines. I believe the original thread show that I also successfully tested on 8 different 128D systems - yours came from the same batch. PCBWay fabricated mine and they have always had high quality fabrication where I've been concerned.

…

-Alex @RevivingRetro

On Mon, Oct 13, 2025 at 2:45 AM Vanessa Dannenberg ***@***.***> wrote: Well, the first one came from Retro8bitStore, the second came from @RevivingRetro <https://github.com/RevivingRetro>. I do not recall if either was fully tested before sending. I'm very careful handling electronics (gotta be, with this retro stuff), so if both failed due to something I've done, I can't explain how that could have happened, especially since both behave/failed identically. Is it possible the actual PCB fab used counterfeit chips? — Reply to this email directly, view it on GitHub <#132 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BTHTAADZK5FBO2CKMX6AJDD3XNYFLAVCNFSM6AAAAACGZAD5XWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINRWGM4TGNY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[frntc]

Yes, it's a bit crowded... hot air might still work as long as the components are not blown away :-) A soldering iron with a lot of flux could also work if you're lucky.

[VanessaE]

A soldering iron with a lot of flux could also work if you're lucky.

PFFFFFFFFFF not with THESE fat fingers 🤣

[VanessaE]

I was chit-chatting with some folks online about counterfeit parts, just generally (not at all related to the RPi or SKPico), and one of the guys spoke of a soon-to-be-featured article he wrote for Hackaday: it turns out people are now making fakes of plain old BJT transistors, such as the 2N3094 and PN2222A. Can ya believe that?!

Something one of the others in the channel said piqued my curiosity... there exists the possibility that these two RP2040 chips or something they depend on are real, but have been salvaged by the PCB manufacturer from a scrapped run of some other device/board (i.e. some other Raspberry Pi derivative) and then re-used here and elsewhere.

He posits that the act of salvaging them either damaged them in the same way, or made them imperfect enough to fail when used as the SKPico does. I could see re-use leading to bad solder, as well.

[frntc]

If these SKpicos are not hand-made then the SMD components have been soldered by two PCB manufacturers who are reliable I'd say. One of them contacted me with a question on a replacement for a IC which was out of stock, and they are ordering from Mouser.

[VanessaE]

Well that rules-out that idea, then 🙂