Funnyplaying FPGBC FPGA based Gameboy Color not working

[peymanfard]

Funnyplaying FPGBC FPGA based Gameboy and GB Color not working
Tested on 0.90 stock firmware, 1.04 firmware and firmware 1.06, with either core (GB and GBC)

Gets stuck on "Waiting for game..." screen

Original GB works ok (OBS/Windows 11)

[Staacks]

Interesting, I have never heard of those. Unfortunately, this means that I cannot do much about this at the moment except adding it to the list of incompatible devices. Are there variants or is "Funnyplaying FPGA-based Game Boy" precise enough?

[peymanfard]

I think so… AFAIK there are two hardware revisions, I’ve tested V1.1

Here it is: https://funnyplaying.com/products/fpgbc-kit

[Staacks]

ok, thanks, I have added it to the list. Hopefully it falls into my lap one day, so I can check why it isn't working.

But after all I am not that surprised about problems with third-party Game Boy clones as the GB Interceptor interprets a lot of additional stuff visible on the memory bus that the Game Boy technically is not required to expose on the bus. I am still a bit surprised on how close the Analogue Pocket is to the real device with only a small deviation (which I still have to fix, too).

[Unessential]

I just received an interceptor today (where i love ordering the pcb costs about the same as buying a random assembled one)

Tested it with GBA SP, and my FPGBC. (GBA SP was a tight fit, didn't want to try my NDS cuz it was even tighter)

If I were to hazard a completely uneducated guess. (I watched your YT video and remember you made some exceptions for problematic syncing). It would be that the FPGBC is known to be inaccurate in terms of speed.

It has several speed settings, and the closest one to actual hardware is slightly too fast. (less than 1%, perceptible from having actual hardware beside it and letting it run the same sequence and seeing the actual hardware fall behind).

IIRC the default speed is much, much too fast. but I might be remembering wrong, (there's no way that I can see to return to default settings so I can't confirm)

The other difference is that the FPGBC uses a custom logo and not the nintendo logo and bypasses the antipiracy with a hack. While that may ALSO interfere with syncing, I loaded mine up with custom firmware that uses the original logo. (was having problem starting GB games with custom palettes with GBC mode because they didn't apply the anti piracy hack for the colour mode changes)

There are other slight inaccuracies that causes some anomalies in certain games, but I doubt those would be distinguishable via a device connected to the cartridge slot...

my FPGBC is on 1.08

If I am right and it's mainly a speed issue, hopefully it will be something that resolves itself as FPGBC gets more accurate (that's assuming the devs even think it's worthwhile to correct)

Still, it would be useful and fun to have some way to slow the interceptor down (don't know how feasible it is to speed it up) just for some experiments. It might be an interesting way to test edge cases assuming you have another way to capture the original output not through the interceptor (which, I actually have plenty -- I got the interceptor more for the concept rather than functionality)

[Unessential]

I just remembered that the Super Game Boy also runs fast. but I don't know by how much. Seems like a good way to test my theory to see if i'm on the right track. Gonna pull that out, and see if the game syncs.

edit: I thought I had both a Super Game Boy AND a Super Game Boy 2 but I could only find the 2... I swear I have an original... But the 2 synced fine. But the 2 runs at proper speed.

I'll keep looking for the original SGB which I know i have laying around SOMEWHERE...

edit again: can't find it. I give up. Maybe someone else with a SGB give it a try?

edit 3: found your compatibility list rofl. I wasted my time. I noticed the analogue pocket not working either and you had an explanation with the access patterns being different. I wonder if that's how FPGBC works too... I wonder if the documentation these FPGA systems based themselves on are inaccurate...

Give the thread a ping whenever you get around to fixing the analogue pocket issue. I'll test with the FPGBC.

[Staacks]

Thanks for your thought. Since I do not have that system, I can only speculate, but here is what I think:

Speed

The Interceptor can indeed get into trouble if the system is running too fast, simply because at some point the rp2040 cannot keep up. This, however, depends on the sequence of commands that the Game Boy executes. Some of the Game Boy's CPU instructions are very easy to emulate and others take many more cycles for the rp2040. In some cases this indeed is really close to the limit and I would not rule out that 1% could push it over the edge, but this would then be a problem in specific games or specific situations of a game where the Interceptor would be thrown of. I do not think that 1% would throw it off entirely.
Besides, as you mentioned, the Super Game Boy works fine.

Custom logo

This is actually the reason that the Interceptor does not have a problem with different speeds as long as it does not get too fast. It uses the clock signal during the start to measure the speed of the device. So, while the Game Boy is busy showing the logo, the Interceptor only builds a little statistic about the ratio of its own clock and the Game Boy's clock. It only starts to worry about the actual instructions when the Game Boy requests the starting address of the game. At that point the logo is gone, so the Interceptor does not really care about what is going on before that. It might only be a problem if there was no clock signal at all during the boot sequence, which is only possible if the device does not even do the logo check. (Not entirely sure why they even need to circumvent any anti piracy, tbh. A simple ROM game should not care about the order data is requested. Are there games that check if the logo check has been made?)

The issue with the Analogue Pocket

So, instead I think that it is simply not sending the stuff to the cartridge that does not have to be sent there to begin with. From a technical point of view, the Game Boy only needs to set the pins of the cartridge if it needs to read/write from/to the cartridge. For any operation involving the Game Boy's internal RAM, VRAM, I/O etc. there is no need to disclose any of this to the cartridge. It should probably keep the clock signal active and make sure that the address pin and or CS pin are set such that the cartridge knows that it is not being addressed, but that's it.

But the original Game Boys reveal much more. The cartridge gets the full address of every operation even if it is not targeting the cartridge. This includes addresses for code that is executed from RAM (most of the time) or the address of the stack pointer during function calls. The Interceptor relies on those for some edge cases (like telling a function call to an interrupt address from an actual interrupt) and will assume an error state if it does not see those.

As mentioned above, I was quite impressed to see all these details on the bus in case of the Analogue Pocket. It just shows the stack pointer addresses on cycle earlier (or was it later) than the original hardware. I can see why the original Game Boys would reveal them, but for a modern system that just emulates this behavior, there is no reason to do it this way, especially as I do not think that there is any other application or special cartridge that would need this behavior. So, I think the Funnyplaying FPGA system just reads the cartridge instead of replicating the entirely unnecessary extra info on the memory bus - or if it does replicate the rest, there simply is a little deviation.