Daedalian GB rom freezes

[klundry]

trafficstars

The Game Boy game Daedalian Opus loads to the title screen but once you press A or Start it freezes.

[ducalex]

I have investigated this issue and found the problem and I was able to get it working but I'm almost sure my fix will break other games...

A game-specific fix might be possible, but I don't know if it's worth it right now.

Explanation for my future self

The game loop waits for line 144 but the vblank interrupt handler runs before the check and when it returns line is now 145 so the condition is never satisfied. Tweaking lcd timings when in STAT 1 fixes the issue but I'm worried it will break other games.

--

Timings are not that clearly defined in the Game Boy CPU Manual. Will have to look into other emulators probably...

[josef2600]

@ducalex 👍 hi, sorry to bug you here! first i should say, wow! i love retro stuff, as i am old! any how, i may (or may not!) be able to help. as i understand so far, you are only using a pre-build gadget. (DISCONTINUED)ODROID-GO and, in my opinion, its bad. i had a very very fast look at the codes, and as i understand, it is all in C ?!! again, WOW! as the thingy problem in here, i don't know where or what are you talking about(!), but if i understand it correctly, you can do this: before line 144 , add something like this to wait for returning from vblank interrupt. bool vblank_interrupt_handler_runs = 0; ... while (vblank_interrupt_handler_runs) vTaskDelay(1); now run line 144

if the vblank interrupt handler runs, vblank_interrupt_handler_runs = 1. you can put it inside the vblank interrupt at the start of it, and at the end of it, vblank_interrupt_handler_runs = 0. since you are using RTOS, vTaskDelay(1) will only blocks the part it is in and allows the other parts to do their thing and catch up. or you can make the code to smaller parts,but it would be very hard. 1ms wouldnt effect anything, at least i dont think so! and you can put it only if it is in the Game Boy mode. and you do not want to mess with lcd. but if the lcd is SPI, well, there is nothing to mess with.

on another note, now we have ESP32-S3 with a lot of pins, and more peripherals, but NO DAC. they removed it! why? i don't know! it also supports parallel LCD's too. more internal RAM, and better chip. but it is a bit different than ESP32, they are going out of production. and S3 has a better memory and flash managment and is way faster! at least thats what datasheet say! now, instead of 80 MHZ clock for SPI RAM,it has 133 MHZ. and a new interface that we can not use for now! but speed can be higher. let me know if you like to know more, or need some one to create a new schematic and pcb for it. good luck. best regards, Josef.

[ducalex]

@josef2600 Yes a simple fix for this particular game is possible, but it will likely break many others.

The proper solution would be to arm yourself with a known good test rom and fix fails it until it passes. In our case it likely means rewriting lcd_emulate() entirely.

Edit: Their vblank_stat_intr-C.gb might be a good place to start. It currently fails badly.

[ducalex]

I believe I have fixed it but I want to make sure I didn't break anything else before releasing.

Please try https://github.com/ducalex/retro-go/actions/runs/5928759465 (scroll to artifacts) and report any issues, especially in other games!

[ducalex]

I think this is fixed as of 1.41 (and possibly earlier). At least I can't get it to freeze after several attempts.

Feel free to re-open if this is still a problem!