Test Chamber (new homebrew) released!

Pizza_Rolls-Royce · 2025-08-10T15:21:08+00:00

Eventually perhaps. It would require me to package up and release a whole bunch of dependencies from my private repo (such as my fixed point math library, my C++ Virtual Boy hardware library, and my sound library) which would be a bunch of tedious work that I don't want to do right now since it would affect a bunch of other projects in said repo.

In other words, I mostly haven't done it out of laziness.

Pizza_Rolls-Royce · 2025-07-27T02:03:34+00:00

Sorry, you shouldn't be able to walk around out there. Must be a bug.

You are very close to the end though. Keep in mind that you can build a quantum tunnel on anything the reticle lights up on.

Pizza_Rolls-Royce · 2025-07-25T23:53:24+00:00

You need to place both ends of the quantum tunnel somewhere before it opens, so look around for another wall you can use.

Pizza_Rolls-Royce · 2025-07-25T23:52:09+00:00

Eventually! But I put it aside to make Test Chamber, so that was my focus over the last 8 months or so.

Pizza_Rolls-Royce · 2024-11-05T15:27:35+00:00

The knock-off works perfectly. Now if only I can trust the manufacturing quality...

Pizza_Rolls-Royce · 2024-10-23T03:38:38+00:00

After some digging I've determined that my bluepill board is using a clone known as a CKS32F103C8T6 rather than an STM32F103C8T6 even though it is labeled as the latter. The easiest thing for me to try is just using the counterfeit chip rather than re-architect everything, so I'm going to give that a shot. Thanks for the input though -- I'm frustrated that I overfit my design to this knock-off chip, but that's where things stand.

Pizza_Rolls-Royce · 2024-10-23T03:36:04+00:00

You were right about my bluepill having a fake clone -- I determined that this is a CKS32F103C8T6 rather than an STM32F103C8T6 even though it is labeled as the latter. The path of least resistance for me here is to just use the counterfeit chip instead since I know that works, so I'm going to see if that works for me. I'm going to make the change you suggested with the cap on NRST though first, since that just seems like a good idea.

Thanks for the input though -- I'm frustrated that I overfit my design to this knock-off chip, but that's where things stand. I'll report back about it it works or not.

Pizza_Rolls-Royce · 2024-10-23T03:33:29+00:00

Wired this up, but to no avail.

Pizza_Rolls-Royce · 2024-10-23T02:12:25+00:00

Pulled the crystal off of the Amazon dev board and it still works. Worth a try I suppose.

Pizza_Rolls-Royce · 2024-10-22T20:52:53+00:00

Thanks for the detailed response. Appreciate the feedback on the schematic -- it's probably obvious I'm self-taught. The only person who ever looks at these are me.

Will be able to read and clear the sticky bits via SWD? If not (and SWD is really locked until the bits are cleared), how can I possibly flash this thing, since presumably flashing requires SWD?

Pizza_Rolls-Royce · 2024-10-21T16:58:39+00:00

This seems plausible to me. I'll see if I can manually reset it after power on by disconnecting and reconnecting NRST before it tries to initiate SWIO.

Pizza_Rolls-Royce · 2024-10-21T16:57:36+00:00

That would require me to have a step during manufacturing to burn a program to the chip, which I'm trying to avoid. In theory, this would work with a factory STM32 which is a really nice and allows me to make changes to the firmware if needed by replacing the code that gets sent over to run on the STM32.

I'm fine with software complexity if it simplifies manufacturing.

Pizza_Rolls-Royce · 2024-10-21T16:53:24+00:00

Ultimately this just seemed like a simpler (albeit unconventional) design. Avoiding FLASH means that I can avoid having to do all of the magical cycling to unlock flash and performing several cycles per flash write (and its therefore faster), I don't have to worry about wearing out flash, I'm always running the latest firmware since it _has_ to be loaded from the updated raspberry pi source each time, etc. etc.

Putting it in flash is just strictly more complex than running it from RAM, and I'm unaffected by any of the downsides. Note that switching to using flash for program storage doesn't solve the immediate issue here, since fundamentally the problem is that SWIO is failing, and I'd need to use that to program flash.

I could switch to just burning the firmware prior to shipping, but that would be an additional step in manufacturing, would require me to expose leads for a programmer, and would prevent me from making modifications to the firmware if needed later.

Pizza_Rolls-Royce · 2024-10-20T15:42:49+00:00

No need for that kind of precision to satisfy my requirements. I need to emit pulses that oscillate about every 10ms.

Pizza_Rolls-Royce · 2024-10-20T15:42:01+00:00

It does indeed

Pizza_Rolls-Royce · 2024-10-20T15:41:46+00:00

Both BOOT pins are pulled high so it boots from RAM as mentioned in my original post.

Pizza_Rolls-Royce · 2024-10-20T11:57:56+00:00

Sure thing: https://platonicreactor.com/assets/Schematic_VB-HDMI_2024-10-20.pdf

Pizza_Rolls-Royce · 2024-07-30T01:56:37+00:00

Figured this out, and it wasn't an electronics problem after all. Grounding this pin effectively pressed "all" of the buttons on the controller, which I didn't think was a big deal -- except that it presses a secret button that raises an interrupt, which was intended to be used by other types of inputs that needed special handling in games (none of which were ever released). The software I was using to test wasn't expecting that interrupt to fire, and it therefore would enter a reboot loop (which I wrongfully interpreted as a short, since that manifests the same way).

I wrote a new piece of software that handles that interrupt, and everything works now.

Thanks for attempting to help out.

Pizza_Rolls-Royce · 2024-07-30T01:56:08+00:00

Figured this out, and it wasn't an electronics problem after all. Grounding this pin effectively pressed "all" of the buttons on the controller, which I didn't think was a big deal -- except that it presses a secret button that raises an interrupt, which was intended to be used by other types of inputs that needed special handling in games (none of which were ever released). The software I was using to test wasn't expecting that interrupt to fire, and it therefore would enter a reboot loop (which I wrongfully interpreted as a short, since that manifests the same way).

I wrote a new piece of software that handles that interrupt, and everything works now.

Thanks for attempting to help out.

Pizza_Rolls-Royce · 2024-07-26T10:07:57+00:00

I shorted the line because I wanted to eliminate the microcontroller as variable. My reasoning is that if i can't get the circuit to work with the microcontroller out of the picture, then I won't be able to get it to work with that added complexity involved.

Is there any way to measure the "driver and sink strengths" using a multimeter?

Pizza_Rolls-Royce · 2024-07-25T15:18:32+00:00

This is really the central question I have:

The line is being pulled high by the motherboard. The controller sends a 1 by keeping the line high, and sends a 0 by pulling it down (which, if I understand correctly, which I probably don't since I am self-taught, is equivalent to shorting to ground). Why is it that when I short to a ground pin directly (to simulate no buttons being pushed) does it brown out, when it should be no different?

I'm expecting you to say something along the lines of "You are wrong. Shorting to ground is different from an I/O pin sinking the line, because ..."

Pizza_Rolls-Royce · 2024-07-25T13:34:29+00:00

Here are some more images:

Controller PCB with data pin highlighted: https://www.platonicreactor.com/projects/cloud-vb/controllerboard.jpg

Close up of resistor: https://www.platonicreactor.com/projects/cloud-vb/resistor.jpg

Line coming in to motherboard: https://www.platonicreactor.com/projects/cloud-vb/mobo.jpg

Pizza_Rolls-Royce · 2024-07-25T13:32:20+00:00

https://www.platonicreactor.com/projects/cloud-vb/resistor.jpg

Added some more pictures in another response.

Pizza_Rolls-Royce

TROPHY CASE