Come Get Some :)


I wonder, Angel... Is it working on your FLU yet? *chuckles* Just kidding.

Seems to be any BLU unit, plus or not.. Anyone know what those units have in common that the FLU and NLU don't have, besides backlighting?
 
Might be worth mentioning at this point the good ole antics of Zardoz Jones' old gameboy emulator GPvGB for those of you who joined after it ceased to be the best GB emu on the block (heh.... ZJ.... name I haven't remembered in a while - anyone know where he got to?). For those of you who were around, you'll recall that on some units the emu ran fine, whilst on others - and there seemed little way to tell them apart - it just wouldn't load.

The problem seemed to go back to the fact that Zardoz had configured the thing to run at 99MHz for GBC emulation, rather than a "standard" clockspeed - although that problem shouldn't be the case here. However, once switched over to 132MHz (someone fiddled it iirc) it ran on most everyone's units. And then Rlyeh released fGB and ZJ vanished, and most people will have forgotten (or at least shelved) the whole issue, I imagine.

Whilst it might be somewhat unrelated - being a definite clockspeed issue in GPvGB - it might be sensible for those who haven't got the program to work to download and try the unhacked version and see if they can get it to run, just in case its similar. It could be simply that all BLU units have this problem - a problem that at one stage seemingly randomly picked on some users and not others.

Just an idea... its probably wrong.
 
iirc ZJ used to use something like 80mhz with the ram also running at 80mhz. This is overclocking as it's not recommended to push the ram over 66mhz. When the cpu is over 66mhz the ram is usually set to be half the cpu speed, so ZJ's 80mhz setting was very similar to todays normal 160mhz cpu overclock. If this, or something similar, was the clock setting he used in GPvGB then it explains why it crashed for a lot of people. When GPvGB was switched to 132mhz the ram would also have been dropped to 66mhz, making it stable for everyone.

Anyway, the problem with duke could be the firmware (I can't see how that would effect it but it's certainly a possibility), or it couldbe the clockspeed (but if it was then surely it would effect just as many non-blu's as it does blu's), or it could be just about anything else. I will solve this problem, but I'll do it in a logical way, not by changing random settings just for the hell of it ;).
 
Angel posted on Sep 29 2005 at 08:03 PM said:
also working for people with NLU. And it would be hard to pin down firmwares, there are too many and a lot of people have flashed their GPs.


NLU and FLU are identical electronics wise. A FLU is an add-on to a NLU so of course it would work on both.
 
Last edited by a moderator:
I have an old NLU around somewhere. I have been tempted to bring it out. If Duke had sound I might have had to do it. I may if it can't be fixed for he BLU.
 
woogal posted on Oct 1 2005 at 02:22 AM said:
Anyway, the problem with duke could be the firmware (I can't see how that would effect it but it's certainly a possibility)

Im no programer but the firmware ide sounds a little fishy.
I have a blu flashed to slubman's firmware when i try duke with the files posted and every thing it will go white then the gp32 bios monitor pops up with all the resistor values and such.
Even if i cant play it on my gp32 You rock!! :p

Bourbon
 
Last edited by a moderator:
bourbon posted on Oct 1 2005 at 07:18 PM said:
I have a blu flashed to slubman's firmware when i try duke with the files posted and every thing it will go white then the gp32 bios monitor pops up with all the resistor values and such.
Thanks for the info. There are a few areas in the code where duke will exit (eg, failed to find files), but in those cases you will get a clean reboot. If you are getting the bios monitor then it means there is a definate crash happening. Now to find out where...
 
Last edited by a moderator:
Well Woogal.
Then if in the BLU machines the port cant load the files, that is the reason about the reset, no ?

Regards .. RST
 
wave posted on Oct 2 2005 at 09:09 AM said:
woogal, shouldn't you release the source code?
Damn, the gpl police have found me ;)
Yeah, the source is being uploaded today. Didn't want to post it into this thread as it would just get lost among the other posts, so I'm just putting a quick page together.

rst: If the files can't be found (or screen can't be setup etc) then it will reset, but if there's a bug then it will crash. For most people you can't tell the difference, but if you've flashed to a firmware containing spiv's bios monitor then a graceful reset will return the gp32 back to the launcher and a crash will show the bios monitor screen. As bourbon is getting the bios monitor then it proves that the blu is crashing and it's a bug.

In other news, I was testing some stuff out last night and it seems that one of the reasons music won't play is because the gp32 didn't have enough memory to load it in. Now I know that most people won't care about music, but the point is that the file was only 14k so it was showing that memory was dangerously low. I've made a tweak to free up memory (at a cost to the loading speed as it means shrinking the image cache) so maybe it will now work on a blu? Or maybe not. I'll release a test later today.
 
Last edited by a moderator:
"woogal" said:
Damn, the gpl police have found me wink.gif
Yeah, the source is being uploaded today. Didn't want to post it into this thread as it would just get lost among the other posts, so I'm just putting a quick page together.
I did the question beacause I want to look at it :p
 
Last edited by a moderator:
I think is more important load the sfx sounds instead of the music....
i mean if not exist enough ram.


Regards ... RST
 
Back
Top