I wish there was a service manual I can look at, because I'm comfortable poking at it with a multimeter. Worst case I still have a few other servers of the same configuration I can just swap everything over to, but I don't really want to trash all that compute due to a few faulty components.

I initially thought it might be CPU2, but with how many different components are being affected, I don't think it's localized to the CPU, unless it's just shorting out and dragging everything else with it.

Read through the repo, you tell me what you think is missing. It's the research folder one. There's some things that have not been fully discovered with regards to content, but there should be sufficient information for doing things with the prongs.

You don't need a microcontroller, just a UART adapter.

It's unknown how unique the device key is. Currently it's the same at least across a manufacturing batch. The P-Com is a microcontroller that wraps the protocol, but is frankly not worth considering due to its proprietary and needlessly complex implementation.

It's in the encrypted part of the firmware. I made a decrypter, which requires the device key, which you can extract with the microcontroller's UART console or SWD (which is disabled in the firmware but enabled when there is no valid firmware).

There's a description of the hardware connection as well.

It's all in or referenced by the repo. You've got the base transport protocol and a reference implementation (but you'll have to find your own transfer secret), a description of the playdate flow, and a description of the gifting flow. Downloads are just bulk files and have no special flow.

All you need is a UART adapter and some software to play the part, so yes, an ESP32 should work. Any microcontroller with a UART peripheral should work as long as you have software to run the protocol.

*keeps the antlers for my collection*

I'd like to get one, though can't right now. Will this be available again some time in the future?

I more or less repacked one of the DLCs with a new sprite and some string edits. Not quite ready for prime time, I want to know how the animations work first.

Here's the code for generating that hash. Way too much SHA256 and SHA512 IMO, they could probably have made this simpler. Or used an HMAC.

Bonus: parameter hashing on the API. When you're calling the API, it expects a hash under the `x-bambi-hash` header that hashes the parameters passed to the endpoint. This is probably to make sure only authorized clients can call the API, but is kind of weak.

And that's pretty much it. The core of it is an xorshift32 RNG with a fixed seed generating a sequence of tiles to draw.

The generate scramble map function takes an array, and then using xorshift32 assigns a number to each element. It then sorts the array by that generated number and returns the sorted array.

The xorshift32 function is also a generator. It puts the seed into a Uint32Array to ensure range.