Uzebox Bootloader V5

[Artcfox]

I tested it and it keeps saying "Insert SD Card" no matter what I try. I tried 3 different sd cards. Could the resistance in the breadboard be messing it up?

How stable is your power source?

[ry755]

How stable is your power source?

I'm using an Arduino Uno as power. I had a breadboard 9v battery adapter, but that made things worse. (at least it did with the old bootloader.)

[Artcfox]

How stable is your power source?

I'm using an Arduino Uno as power. I had a breadboard 9v battery adapter, but that made things worse. (at least it did with the old bootloader.)

Do you have any phone chargers that put out 5V over USB? You can just cut the end off an old USB cable and use a multimeter to identify the + and - wires. That should get you a regulated 5V source with a bit more current behind it. Obviously measure it first, and remove your voltage regulator.

On that note, you aren't trying to put the Arduino's 5V source through a 5V regulator are you? If so, that might be the problem.

Don't try to power it from a computers USB port, that might not give you enough current.

[ry755]

I'm working on a cable right now. Couldn't I just power the Uno with a phone charger? Or does the on-board regulator take the current down?

[D3thAdd3r]

Not sure what your wiring looks like or which regulator you are talking about, but if you built out the regulator/power section exactly like the schematic then 5v is going to drop once it goes through the Uzebox regulator. The regulator suggested in the schematic is looking for about 9-12V. If you did not build out the power section like the schematic, then perhaps a phone charger will do it.

@Jubatian wow, this is incredible, I will be testing it!

[ry755]

I'm not using the Uzebox one from the schematic. I'm just using the 5v and 3v3 outputs from the Arduino. No other regulators.

My breadboard version seems to be nothing but problems. I think I'll just buy a PCB and solder the components to it. I already have everything, so no reason to pay $70 for stuff that I mostly already have.

[D3thAdd3r]

I had some troubles originally on breadboard also, and the video was never very good no matter what I did. You will be glad you went with the PCB.

[Jubatian]

I did some further testing. I also have an E-Uzebox now with a quite weak SD socket (I couldn't get a successful programming with the old bootloader). I burned my loader on it, and then it started to work all right. So it indeed can work itself around such problems.

However I also found that the weird disappearance of the display with that certain .uze file happens even on the E-Uzebox which can at least rule out the AD725 (as the E-Uzebox doesn't have it). The bootloader certainly runs the video interrupt which certainly tries to generate the signal (if the interrupt wasn't running, it wouldn't even be able to start as it uses it even for a boot-up power stabilization timing counting some VSyncs, moreover it reads the controller within the interrupt which it is reacting to). So the code seems to be wholly functional doing everything it should be doing normally, but its output for some reason disappears.

I could think of two things which I will try to check. One is that somehow this case the whole thing runs at a lower frequency (internal oscillator maybe or some divider), so the signal is there, but it is wrong (this case the bootloader would still be completely operational, just slower). Another is that somehow the sync output is getting masked. If someone has an o-scope or anything suitable to do such measurements, I would be glad to hear what happens! (I attached the particular .uze file which causes this).

To recover from it, the easiest is probably to put a single .uze on a card, plug that in and reset. Then the bootloader will flash it, and everything will again work fine. You can also rather plug in any other card with games, hold down a button at reset (to make sure the bootloader starts even if it is set "game"), then hit Start or Select to ask it to program whichever game is selected.

How stable is your power source?

I'm using an Arduino Uno as power. I had a breadboard 9v battery adapter, but that made things worse. (at least it did with the old bootloader.)

So your setup works with the old loader but not with this one. I will do some cross-checks between them, but it may be that the different SD init protocol causes this. The old loader goes through an MMC init which doesn't check for power levels. The new loader does what is required for an SDHC card including a power level check (or some alike mumbo-jumbo whatever), which might cause the SD card shutting down due to inadequate power. I sent you a test program in your Uzebox on a Breadboard! topic.

Question, what CUzeBox changes have occurred since June?

I think it is this commit: https://github.com/Jubatian/cuzebox/com ... 40dff311a2 , without a working ACMD41 emulation, an SDHC compatible init sequence can't complete.

12 bytes free? Wow. What about something like checking the binary and the flash data to detect a game difference then offering like a 5 second countdown before auto flash?

You almost have that already: you can hold down a controller button at reset to bypass. I wouldn't be able to output a message since that would cost about 100 bytes or so (it likely needs a completely new screen), so until you realized why the screen is blank, it would be too late. I think it is an unlikely scenario that you insert a card with one .uze and you don't want it being flashed when resetting (why replace the current card with one such card otherwise? - you don't have any better place than the Uzebox's socket to keep that card, and worry about losing it? ) So right now I can't imagine a realistic useful use-case for this feature.

[Jubatian]

This is just getting even more weird with the disappearing display.

I did a test with flashing the LED to see whether the frequency is all right. Frequency is OK as far as my eye can tell, so it can't be running from anything else than the 28.6MHz crystal at 28.6MHz (there is no other clock source any near this, and dividing would be easily noticable as it would halve the frequency). The clock to the AD725 is ruled out by that the symptom also appears with the E-Uzebox. That leaves only the sync pin.

Then studying the disassembly of the old bootloader I did a last-resort check: adding delays. When I add a 30ms delay after port init before releasing the global interrupt disable, it works. What the hell... (shorter delays makes it sometimes working sometimes losing display). I can not imagine what kind of hardware behavior I am facing here. It only happens with that specific .uze (which really have got nothing special apart from a half-broken SD library), and it is consistent.

If anyone could reproduce this, I would be glad to hear about it! If anyone has an oscilloscope (or any other device which could be used to sample PB0), that would be very interesting to see!

[Jubatian]

I think I found some clues.

I was tampering with Megatris, that game specifically since it uses the same Mode 1 like that half-broken SD library test. I was testing the soft-reset, noticing that I can achieve a weird thing with having several controller buttons down while booting. The screen is noticeably shaky then, and remains so. Like if the frequency wasn't stable.

I think there could be some conditions when frequency just isn't stable, and possibly delaying, that is, preventing the CPU to switch pins pushing voltages around might help it stabilizing.

I changed my AVR's fuse bits to the following:

• Lo: 0xF7 (was 0xD7). This adds a boot-up delay of 65ms for the oscillator to stabilize by changing the SUTx bits.
• Hi: 0xD2 (no change)
• Ex: 0xFC (was 0xFF). This enables the brownout detector at ~4.5V, possibly keeping the CPU in reset for more.

It seems to help, but it doesn't entirely removes the behavior, it just seem to happen less often (and I can still get a shaky screen with Megatris). Anyway, it would be great if someone could reproduce this and pinpoint what happens using an oscilloscope.

(Note: What I did with Megatris doesn't relate the bootloader used. It neither causes this new bootloader to lose display, at least so far with this game I never experienced it happening, like neither with any other game except that broken SD library test)

EDIT: This is getting weirder and weirder.

I could confirm that removing the power wipes whatever memory the ATMega has of the "bug". It only doesn't work if you have the programmer plugged in (apparently it survives from the programmer).

Adding about 50 milliseconds delay before letting the interrupts go changes the behavior. Then I consistently get alternating results . Program the .uze, reboot, bootloader has display. Program (or pretend to as no further programming happens), reboot, bootloader has no display. Program, reboot, again it has display. Program, reboot, again no display. Consistently.

I am very much tempted to "accidentally" drop that SD card in the toilet, and "accidentally" flush it...