03:02 <korvo> Huh, does anybody happen to recall how to deal with the rffi error: "should return a low-level type, got instead SomePBC(can_be_None=False, const=<function callback_with_jitdriver at 0x00007ffff3a30200>, subset_of=None)"?

03:04 <korvo> For context, this is a callback being assigned to a struct with type rffi.CCallback(), wrapped with @jit.jit_callback(). The callback function is a plain function in global scope. I'm just trying to pass a callback pointer to SDL.

03:46 <korvo> Okay, so it looks like a C shim does the trick. This is kind of quirky; I guess the toolchain recognizes that passing a function pointer as an arg to FFI calls is different from serializing it as a member in a struct.

03:46 <korvo> Here's what I ended up doing: https://bpa.st/6TPQ

08:14 <korvo> PyGirl now makes sounds on several demos. It's not *good* sound; it's flickery, blocky, and buzzy at best. It's also not complete; there are lots of gaps, and demos like nyan.gb are missing their music entirely.

08:15 <korvo> I have to figure out a timing issue that I don't fully understand. To cycle-accurately emulate the SPU, we want to gradually modulate its registers over time; but also, SDL (or JACK, etc.) wants to run audio in a separate thread and make callbacks to generate real-time samples.

08:16 <korvo> So I think I'm going to have to call Sound.emulate() from the audio thread, or somehow split it into an accounting of cycles in the main thread vs modulating the registers in the audio thread.

08:19 <korvo> Also I suppose that I'm assuming that the SPU's been faithfully emulated even though it's been dead code for a decade. I may have to look up the SPU's (reverse-engineered) datasheet and double-check that everything is faithful.

08:24 <korvo> ...Maybe I can simplify the timing issue. The SPU doesn't run at SOUND_CLOCK, but GAMEBOY_CLOCK / SOUND_CLOCK. SDL audio merely provides its own clock, so sampleRate / samples / SOUND_CLOCK should *also* emulate the SPU.

17:35 <korvo> Out of curiosity, has anybody thought about the "cores" pattern that shows up in emulators written in e.g. C++? In those languages, a cycle-accurate real-time emulator often consists of multiple active objects which each implement a "core" corresponding to a physical processing unit.

17:36 <korvo> The idea is that, once a "core" for a specific PU is written, it can be abstractly re-used anywhere else that that PU occurs. Or a "core" can be loaded on-demand, etc.

17:42 <korvo> ...Okay, I'm not going to look further in that direction, because I think it leads to reinventing COM/OLE or Akka in RPython.

20:15 <korvo> I'm putting my PyGirl fork on GitHub: https://github.com/rpypkgs/pygirl I'll let y'all know if it gets taken down for any reason. Note that I'm not putting "GameBoy" in the description or README precisely because I suspect some DMCA goons are searching for it.

21:25 <korvo> I want to be grumpy because the audio still sounds bad. But I'm trying to look on the good side of things. So: the audio is almost danceable on some demos, but very screechy and inconsistent in volume. I think the only problems left can be due to incorrect HW modeling, so I'll have to dig up a datasheet.

21:27 <korvo> I updated configuration for the `rpypkgs` Cachix cache and got CI working. So any downstream users just have to switch from github:rpypkgs/rpypkgs#pygirl to github:rpypkgs/pygirl#default.

21:28 <korvo> Finally, I also added more SDL bindings to rsdl. I don't know how I want to test or release the various support libraries and bindings, but it seems like it's possible to maintain them.