Test Fails on Gameboy Player

[alyosha-tas]

I compiled this test with RGBDS v0.3.8 on windows using these 3 commands:

rgbasm -o main.o main.asm rgblink -o emu_detect.gb main.o rgbfix -C -v -p 0xFF emu_detect.gb

Running the resulting ROM on Gameboy Player gave a screen with TEST RESULT: BAD VALUE COPIED

For RESULT, it gives a black box. For EXPECTED, it has this: || ||

Is that symbol correct for the expected value? Did I compile it correctly? What hardware is this known to work on?

[ISSOtm]

Oh boy, I had forgotten outright I had this repo ^^' Arguably, the code is a mess, and it's been a while so I forgot about all the fine details, but here's what I remember:

This ROM was created after we noticed some kind of open-bus behavior using HDMA from echo RAM. I believe it yields different results on CGB and AGB?

I should clean up the code and make it compatible with current RGBDS, if it isn't. I may also have a compiled build somewhere on my other disk, I'll post an update in a few hours.

[alyosha-tas]

Any update on this? Even just knowing that I have a good ROM would help.

[ISSOtm]

Unfortunately, lockdown struck, and I don't have access to the disk anymore, nor to my consoles/flashcart. :T I don't know the test's specifics, goal, etc anymore; is it possible for you to run it on different consoles? (CGB, AGB, ...)

[alyosha-tas]

I only have a gameboy player, but no worries, I've got plenty of other things to work on, I can always return to this later.

[sczther]

Any news on this? :)

[ISSOtm]

Right; I scouted the hard drive, but there didn't appear to be any traces of this.

I found a emu_detect.gbc ROM on my EverDrive, but for some reason it's a demo of Mythri (I think this is due to a previous SD's FAT table getting corrupt somehow). However, I also found a hdma_from_exxx.gbc ROM, which appears to at least be based on emu_detect.

Given the different name, it may be doing something else entirely, I can't tell; but it reports success on my own Player.

[alyosha-tas]

Thanks for the follow up.

I ran hdma_from_exxx.gbc on my own gameboy player and got this result:

Is this what you get as well (particularly the 'RESULT' in 'HDMA RESULT')?

[ISSOtm]

No, this ROM appears to pass on my own Player with GBI-hf... uh oh.

[alyosha-tas]

Interesting, I am booting with GBI from SWISS v0.5. Not sure if any of that makes a difference. Maybe I should try with the original GBP disk (not here at the moment.) My GBP has these numbers on the bottom:

DOL-017 ACN 060 566 083 C/L-DOL-A-GP-1

[ISSOtm]

Note also that I'm using an EverDrive GB X5; @casualpokeplayer tested on his machine, and it almost matches yours.

DOL-017 C/L-DOL-A-GP-EUR

[alyosha-tas]

I'm just using a 32k flash cart.

I tried a couple of times through some resets (including some controller resets) and always get the same result.

[ISSOtm]

I'll try again with my old ED GB, see if anything differs, both normally and using the SD-less boot.

[ISSOtm]

Update: it's consistent for me as well with both cartridges.

[ISSOtm]

My current theory is that it's dependent on the cartridge; this should be verifiable by running the code from RAM instead, and testing with different cartridges (flashcarts, official carts, no cart) in the slot.

[alyosha-tas]

That would be really interesting if that is the case.

My cart is this one:

https://catskullelectronics.com/products/32k-gameboy-flash-cart

I'll still try to find my official GBP disk this week and test just to be sure.

[CasualPokePlayer]

Note also that I'm using an EverDrive GB X5; @CasualPokePlayer tested on his machine, and it almost matches yours.

To clarify, it appears that for me, the first 2 HDMA reads get "proper" open bus values, while later reads get 0xFF (pulled up values). For ISSOtm, none of the values appear to be pulled up, and for alyosha it appears as if it pulls up a bit sooner than for me.

My GBP: DOL-017 ACN 060 566 083 C/L-DOL-A-GP-1 CPU AGB-A

[ISSOtm]

IRC discussion about using the Game Genie as a passthrough lends more credit to the theory that this is cartridge-dependent:

<zear> issotm, it definitely influences the bus, even in the pass-through mode
<zear> I still get the "bad value copied" in the original rom, but with a different pattern than with the cart directly plugged in
<zear> the same pattern is produced on GB Boy Colour, further cementing that the cart type impacts those timings

[alyosha-tas]

Ok cool, so, any idea which one of these results represents an 'official' cart? Or might it even vary by cart even for the same type?

[ISSOtm]

Hard to say without a "plain" passthrough, I believe.

[CasualPokePlayer]

Using an actual official cart would be a decent solution. Although I could take a bet it would still depending on which cart. Also, the Everdrive seems to just never pull up, which seems to be very wrong in terms of open bus behavior (these results should be discarded for determining accuracy imo).

In terms of emulator development, this actually ties into SRAM open bus. Note, a single HDMA read is equivalent to a single double speed mode read. For alyosha and zear, the values pulled up after just a single HDMA read. For me, the values pulled up after two HDMA reads, or effectively the same as 1 single speed read. Running my own SRAM open bus testroms seem to indicate that the pull up speed is the same there (zear also ran these test roms too and it appears the same for their case too). This would indicate that how you would emulate this HDMA open bus emulation would be identical to SRAM open bus. And in practical context, some games rely on a least 1 single speed read, otherwise they crash, so doing 2 HDMA reads for open bus before pulling up to 0xFF is likely the best solution overall given current results.