Gameboy Player PCB

Right, but if you get close enough the mismatch will occur with a period of minutes instead of every 5 seconds or whatever the exact period is, which would be a major improvement and could lead to more sophisticated mods in the future.

And it is possible to special order crystals with a frequency close enough to do that in theory, but as I detailed in post #20 I couldn't get any standard crystals to work at all, it just acts weird

You're obviously much more experienced than me. Can you provide any insight into my results?

Maybe... I don't think we know enough to say for sure one way or the other. But most of use don't have the skill to reverse engineer the software so all we can do is hack away at the hardware and hope for the best.

 

Not necessarily, the entire thing could be a software quirk.

Xtals are tuned at the factory with a specific oscillator topology in mind and with specified load capacitance. If you take a random Xtal and plop it into a circuit you won't achieve ideal results. Different crystals can have different impedance characteristics as well which may prevent oscillation if the circuit relies on them.

 

The video patch author for Swiss (a GameCube homebrew program) says that the 240p mode of the GameCube runs at 59.8261Hz. I feel that this will be closer enough to the GBP's refresh rate to see if the theory that a closer value will mean less hiccups is valid or not.

Only problem is 240p forcing on the GBP is not currently working! So we've got to wait for the authors to fix that before we can see.

 

^ I do hope emu_kidid makes the change needed in SWISS, even if it's just to rule out this possibility....

 

I asked him if it would be difficult to add multi-DOL patching for disc games and he said it would be a bit tricky. Hopefully he doesn't hit too many road bumps. I know it's listed on the source code page as a high-priority enhancement.

Worst case scenario is that the software for the GBP is hard-coded to expect the Gamecube at 59.94 Hz, and forcing 240p, with its lower refresh rate, actually breaks it and the two desync. That would royally suck since it means back to looking at component cables for 480p.

 

By my calculations that should more than double the frame mismatch period, which would be easy to see and a very useful test.

 

It would probably be a lot easier to patch the startup disc instead of implementing a generic recursive patching scheme (if that's what's meant by multi-dol patching).

Can you ask him about that?

A software fix would be ideal. On the other side of things, if there's going to be a hardware solution I guess we need a volunteer who can figure out the specs of Y1 and analyze the surrounding circuitry.

Either way I don't think I have anything left to contribute other than blah blah blah.

 

Emu_kidid is the main dev of Swiss, so I'd assume that takes up most of his time. Multi-DOL patching just means that if a disc's main DOL (program, basically like a .exe in case you didn't know) later loads a second DOL, the second DOL will have patches applied to it as well. So like with the Zelda Collector's disc, the main menu can be forced into 240p, but then once you choose a game and it loads its DOL, the patch isn't applied to it and video switches back to 480i.

From what I've read, there's no simple HEX code changes you can make to force a game into another resolution, like say on the Xbox or PS2. Presumably the only way is to hook into video call routines and modify them, which is what Swiss does. The original proposed method of forcing 240p for the Gameboy Player was to patch an iso of it, and that went nowhere (the thread on gc-forever is over a year old and hadn't had responses for months). It was only when the Swiss patch developer stepped in, a fellow by the name of Extrems on the forum and metaradil on the Google Code project page, that anything got anywhere.

So to sum it all up, there's likely no method of patching the boot disc's .iso to enforce a resolution, and if there are, emu_kidid isn't really the guy to be looking at it, as he's busy already working on implementing a feature that should do the same thing in Swiss. His response in that same gc-forever thread was "Good luck, it's not so easy."

 

Thx for the detailed explanation.

This looks like the thread you're talking about in case anyone else wants to read it

http://www.gc-forever.com/forums/viewtopic.php?f=3&t=1371

They don't sound too confident about matching the GBP v.freq either but it's not like we have any other options at this point.

[this post will probably show up late due to moderation]

 

Well I guess it never hurts to ask, because the Gameboy Player disc was specifically patched to get 240p working. And it works phenomenally.

It of course looks wonderful, but the biggest news is that the slightly different 240p refresh rate does in fact DOUBLE the amount of time between frame repeats, from every 5 seconds to every 10 in my rudimentary testing. I hardly notice it at all, but if the community could find a way to change the refresh even more then the duplicate frames could probably be eliminated entirely (that is, unless Swiss is doing something more than resolution forcing under the hood).

Also, played Wario Land 4 for 30 minutes straight and there was no desyncing, so the software adapted just fine.

 

^ any info on how to patch the GBP disc? I want to try it also

edit: now I see that SWISS latest build is used to get 240p , gonna try it

 

Great news! I never thought this would be accomplished so early. Will have to test this. Thanks for all the people from here who helped to make it happen ( even thru asking)

 

Sorry about that, should've said it was implemented in the latest version. It was 2 am when I saw they added it and I stayed up even later testing haha.

 

Well this is good news. Maybe a software fix is possible after all!

This also confirms that the glitch is a function of the difference in vertical freq and we can predict what the recurrence period would be based on the video mode freq.

So does anyone know what vertical frequency the GC uses @ 480p?

Did you (or anyone with a PAL tv) ever try PAL GC/GBP with 50Hz video to check for stuttering? Is it similar rate to 60Hz output (about 5 seconds) or something different? I'm also curious what the glitch period in 288p mode is (another test our PAL friends can try)

@ 50hz they have to be dropping frames several times a sec already so I'm not sure why they'd have a glitch over such a small freq discrepancy (assuming they do).

 

The same as 480i. 27000000 / 858 / 525 = 59.94 Hz

GC 240p is allegedly 263 lines = 27000000 / 2 / 858 / 263 = 59.8261 Hz

The GBA is 16777216 / 4 / 308 / 228 = 59.7275 Hz

 

Are the following any help? (PAL GC + Component cable + framemeister)

240p:




480p:




horrible-scrolling 288p:




edit:
I am not entirely sure that 240p is the best screenmode, it seems smoother BUT - at least on my setup - gfx seem downscaled... most apparent on the GC overlay graphics

 

Thanks Calpis! I was wondering where that number came from. It looks like we would need an extra .43419 lines per field to match GBA in 240p. Not sure if it's possible to coerce GC into doing that though. An extra half line would be a more realistic target at least initially.

The fact that 240p reduced the glitch period transparently makes me think that the GBP is using an interrupt tied to the vertical refresh. Or possibly sampling the beam position.



keropi


The menu overlays should look downscaled since they're rendered at 480 and half the lines are getting thrown away.

The GBA portion of the screen should look fine since the lines are normally being doubled and dropping half of them won't matter. It doesn't look any worse to me in your pics fwiw. Do you have the GBP screen size set to full insetad of normal?

How does your setup handle other 240p sources? If it looks bad in Swiss 240p but handles, say, SNES games properly then it might be an issue with the GC's 240p signal generation that your framemeister doesn't like. Another thing to try would be a GC game that natively does 240p like Mega Man X collection or Zelda Collector's edition.



Thanks for the pics. I don't know if it's related to the graphical quality but it's odd that 240p is reported as 60.05Hz. The 27MHz master clocks might also be a little bit off. Not sure. Everything in the 480p pic looks right.



When you say horrible-scrolling is that in refernce to the periodic glitching or some other artifact? If it's a continuous problem then it might be fixable by switching filters in the GBP although I don't know why 288p would be worse.


If you can find a good test game and manually count the seconds between glitches you can get an approximate measurement for the glitch period after a few trials. It should be roughly 5 seconds for 59.94 and 10 seconds for 240p. I'm not sure about PAL.

 

@Wembley

I don't have problems with other 240p sources, I've made a thread elsewhere for framemeister 240p component settings, I admit I don't know that much about those gazillion settings the unit offers. Also great thinking on the GB size option, I did not check it at all! Will see it later along with the input I get on the framemeister settings.

About the horrible scrolling 288p: the screenmode is 50hz so you can imagine how many frames are dropped... it's just horrible, like an emulator with frameskip.
I am not that good on counting shutters, I can see a micro-shutter every now and then but I usually don't notice it... :\

 

59.94 is from the color NTSC spec, and the 27 MHz pixel clock is SMPTE timing, which the GC follows.

You can't match the GBA frequency in hardware unless you modulate the line timing which would throw off the display. As discussed you could change the GBA's frequency with a PLL, however, it shouldn't be necessary, and won't completely eliminate the problem without reworking the software.

The pixels out of the GBA go into a FIFO for the GC to read. Of course the GC/GBP knows the status of the FIFO.

The display controller is programmable. 60.05 Hz is the correct 240p frequency for a 262 line frame (which is more common than 263). 27000000 / 2 / 858 / 262

 

That seems to conflict with what @shuffle2 said on the 1st page, quoted below

That sounds like it's mapped onto the ARAM bus and read on demand by GC (through DMA naturally).


But who knows. I've never seen any documented research on it. It's all just rumours.

Are you using a NTSC disc? What happens if you just run it normally (no forced mode)?