SID Kick Pico2040 Mahoney mode and/or direct DAC access?

[VanessaE]

I just bought a SKP2040 from Retro8BITshop, and should have it in my hands in a few weeks. It will be going into a (metal) C128-DCR in which CR17 is bridged so that the SID socket gets the 12v it needs to feed a 6581. That machine currently has a pair of very old, first-version (!!) 6581's in it, courtesy of one of my stereo SID modules.

Given their age, I want to replace them with something cleaner, newer, etc. and then move them to one of my other machines. Enter the SKP2040.

I intend to use it for playing SID music of course, and being reSID-based I'm sure the SKP2040 is fine for that, but I also intend to use it for playing digital music via my ongoing mod player rewrite, as well as whatever else I happen to come across.

Right now, my program offers the usual SID 4-bit option, as well as what's called the "Mahoney" method, named for its inventor. That method works well on the aforementioned crusty old SIDs, and also works fine in VICE 3.8, producing roughly-7-bit audio on a 6581 (and 6-bit on an 8580).

In addition to that mode, my program can output sound through a pair of ordinary 8-bit DACs placed at consecutive memory addresses (for instance, $DE20/$DE21 for left and right speakers, respectively), or via the custom method I used in the original User Port DigiMAX.

That brings me to the title of this post, plus other questions:

1. The README says the SKP2040 uses some form of auto-detection to look for and react properly to special digi player methods like Vicious SID, but I don't see the Mahoney method mentioned. Does your device work with this method also?

2. Critical to making the Mahoney method work is that the user program needs to detect what kind of SID the machine has so that it can use the proper lookup table. Does the SKP2040 work correctly with SID type detection routines?

3. I see no information on programming for the SKP2040's DAC device. How do I feed digital audio directly to it from my program? Is this even possible?

4. My C128-DCR is equipped with an original CMD-issued SuperCPU v2/128, which means among other things that the player runs at a much higher sample rate than is normally seen on a C64/128 (by my maths, about 37.8 kHz), though of course the "chip" still only has to deal with the usual 1 MHz system bus. Will this speed be a problem for the SKP2040? Also, will it get in the way of running your built-in setup tool?

If you'd like to have a look at my player, or just see how its detection and output routines work, source and beta-test-grade binaries can be found here:

https://gitlab.com/VanessaE/modplay-64-128/-/tree/master?ref_type=heads

[frntc]

Hi, good choice ;-)

1. and 2. yes, Mahoney's technique and autodetection work (for the latter best use the "safe method": https://web.archive.org/web/20250211031012/https://codebase64.org/doku.php?id=base:detecting_sid_type_-_safe_method)

2. go to DAC mode:
   u8 x; do { PEEK( 0xd41d, x ); } while ( x != 0x4c ); POKE( 0xd41f, 0xfc );
   (replace 0xfc by 0xfb for stereo mode)

Then you simply POKE audio data to $d018 (and $d019 for stereo)

4. audio at that speed works. Setup tool: no idea what the SuperCPU does with the setup tool code (since I don't own one, I can't tell much). As long as you're not SYS'ing into that code nothing should go wrong

[VanessaE]

Sounds good. 😉 I already use that SID detection method in my program.

Incidentally, it's codebase64.net now. The domain changed, but the rest of the URL is the same.

[VanessaE]

I thought I'd make a quick report.. I wrote in my opening post:

My C128-DCR is equipped with an original CMD-issued SuperCPU v2/128, [...] Also, will it get in the way of running your built-in setup tool?

As it turns out, the menu/setup tool actually DOES work with the SCPU enabled, but it does not like running at 20 MHz. Sometimes it'll just throw up a timing error, or garbage. Start it while at 1 MHz and it seems to be fine (or at least as fine as my SKPico experiments have been, see #113).

I didn't test extensively, I was just doing a quick "I wonder if..." test - I was mostly curious if the SKPico-to-C64-RAM code download trick (or whatever you call it) works with this configuration, and it does.

Once the menu is up, if you then switch to 20 MHz, you just get the usual minor issues C64 programs often have when they use code that's cycle-counted for 1 MHz. For instance, the raster bars don't render correctly, the demo tune has note duration/sustain glitches, that sort of thing.

I imagine the same will hold true for machines like the new C64 Ultimate and its underlying Ultimate64 board as well.

Recommendation: add this to the very beginning of your menu code (or better would be at the beginning of the "download" routine that precedes it):

LDA #0
STA $D030
STA $D031
STA $D07A

The store to $D07A will force a SCPU into 1 MHz mode, and the other two stores should slow the Ultimate64/C64 Ultimate down regardless of which turbo selection mode is configured, as well as forcing a C128 into 1 MHz mode if somehow it's at 2 MHz. These stores shouldn't have any effect on stock machines.