My Gp32 Flu Screen Has A Smear Underneath, Should I Open It Up?

[ralp99]

i have a GP32 FLU, it's given me years of dedicated service - I still love the thing and use it quite often. Unfortunately somehow there's a smear just under the screen (the top outer one) and I really wanna just open the thing up ad try to wipe it away - it's really ruining a lot of the visuals!

As it is a Frontlit unit, I am extra-sketchy about opening the thing up - I remember back in the day, some words of caution being thrown around about such things. I am tired of having a half-assed system though (however, smeary is better than a broken one!). Can anybody kindly offer some words of advice, other than "buy a new system?"

Thanks for the help!

 

[reeced]

I would recommend removing it and replacing with a glass screen. If you search back there's lots of info on removing/replacing the outer screen.
I've had a glass screen in mine for years. Best thing I ever did - no scratches, wipes clean, and much clearer than the plastic.

 

[DaveC]

i have a GP32 FLU, it's given me years of dedicated service - I still love the thing and use it quite often. Unfortunately somehow there's a smear just under the screen (the top outer one) and I really wanna just open the thing up ad try to wipe it away - it's really ruining a lot of the visuals!

As it is a Frontlit unit, I am extra-sketchy about opening the thing up - I remember back in the day, some words of caution being thrown around about such things. I am tired of having a half-assed system though (however, smeary is better than a broken one!). Can anybody kindly offer some words of advice, other than "buy a new system?"

Thanks for the help!

If it is not too bad, leave it.

Any microscopic spec of dust that gets on (almost impossible not to) will light up like a Christmas tree. You will get what looks like a sea of bad pixels. The light diffuser thing is next to impossible to clean. If you manage to get most of the dust off you will be left with scratches.

I tried this once and ended up with a NLU after I ripped out the dust ridden light diffuser and pitched it

 

[bourbon]

Like Davec said if it isnt too bad leave it cuz of the light diffuser. But if you feal the need you should open it up and take it apart in a bathroom after you or some one has taken a shower. That way you will have minimum problems with dust getting in.

 

[ralp99]

hmm.. sounds like i should just quit while i am ahead and bear with it. Thanks everybody!

 

[slaanesh]

I dunno - I'd clean it.

I recently did the glass screen mod on a GP32 FLU. That's basically the same process as removing the top layer of screen and putting it all back. I managed to do it with no dust under the screen and by-crikey it looks a lot better now.

The trick is to not undo the GP32 from behind, but do it from the front. The grey frame surrounding the screen is simply stuck in there - you can lever it off with a single-edged razor blade bent slightly to the curve of the frame. Slide the ouchy side into the gap and lever it off. Easy.

Whilst you're doing it you may as well do the glass screen mod. Glass doesn't scratch and is easy to clean.

Do avoid dust, do the mod in your bathroom. First, get the shower hot so that it steams up. It helps if your bathroom is relatively dust free in the first place but the hot steam helps subdue the floating dust particles and is generally the most dust free environment due relatively little carpet, etc.

 

[ralp99]

oh jeez i dunno if i would wanna do it in my bathroom though. i mean... you know all those little hairs that collect by the bowl, in the shower drain. you know what i am talking about! bad enough getting just DUST under the screen if you get my drift!!!

ok in all seriousness, this one sounds like it might be worth a shot. thanks again!

 

[slaanesh]

As a dedicated GP32 user, you may be interested to know that I'm going to release the GP32 port of MAME4ALL soon.

 

[trooper]

As a dedicated GP32 user, you may be interested to know that I'm going to release the GP32 port of MAME4ALL soon.

Cool, Sounds good. Any info you care to share about it ?.

Trooper

 

[slaanesh]

Cool, Sounds good. Any info you care to share about it ?.

Trooper

It will have all the features of the GP2X version with the limitations of the GP32.

Cons:
Big games won't work and won't be supported.
Speed is limited to GP32 speed. ie. 133Mhz standard plus whatever your GP32 can overclock to.
It will have to be split into modules (again) like the previous port of MAME for the GP32.
Games with FM sound are generally slow-ish.

Pros:
Same nice frontend as MAME4ALL on GP2X. Individual configs, etc.
Same functionality as MAME4ALL on GP2X including menus and redefinable keys, etc.
Precise timing so all games play at the correct speed (unlike the previous version).
Robust sound driver using 16-bit stereo sound.
Support for 8-bit and 16-bit video modes.
Support for sound samples and artwork.
Support for hi-scores and cheats.
Future support for double-buffer v-sync, for tear-free display.

I've got the Capcom / Sega System 1 module done. This was my test module.

I'm currently working on the Vector graphics module.

I've also got some optimizations in mind including:
* ARM ASM line drawing routine which I hope will provide a nice speed up for the Vector module.
* Possible speed improvements for DrZ80.
* Possible ARM ASM sound engines. BitBank has an ARM ASM SN76496 sound engine (which can be adapted) and said something about an AY-3-8910 engine - which would be most excellent.
* Other optimizations to help speed things up here and there.

There's still a few things to clean up but there will be a 1.0 release coming soon.

 

[trooper]

WOW, That does sound cool, Awesome work slaanesh.

EDIT: Not very often i go weak at the knees, But i think i just did.

Trooper

 

[slaanesh]

I'll use this thread as a secret blog for GP32 MAME4ALL.

Played vector Star Wars last night on the GP32. Initially had some scaling issues but fixed that.
It's also a bit slow but that's what I'm going to try and fix. Throwing more Mhz at it helps (of course). If your GP32 does 166Mhz then it's fun already. Anyway, the main bottlenecks are the CPUs (2x 6809) and the video (vector) drawing. Sure, could turn sound off but the speech is a must, and I'm not a fan of games without sound.

This new version of MAME has some nice features that I'm not sure the previous version had. Or maybe I didn't notice. There's antialias and translucency options. Unfortunately with the need for speed, antialias is our of the question for complex vector games. ie. Star Wars but may be an option for other games (perhaps games with only one emulated CPU).

Started optimizing some of the vector line drawing code. It's doing some interesting things: Not only does it use DIRTY updates to draw the screen; it does something similar to clear the screen! The code keeps track of pixels written and writes them back as the background color. According to the comments in the code this is supposedly faster.

I thought about integrating the ARM ASM line drawing routine. The MAME line drawer is okay, but there's a bit of overhead to handle the DIRTY video and keeping track of which pixels have been written. Each pixel within the line has this overhead.
I'm hoping the ASM line drawer in conjunction with simply blitting the entire screen (ASM memcpy) and then erasing the screen (ASM memset) is faster than all this overhead. For "busy" (high detail) screens I think it would but for "empty" screens maybe not. There's only one way to find out.

 

[slaanesh]

Added all the vector games to the Vector module last night. Initially wasn't working but I had forgotten something simple and was soon testing our various games.
Tempest is nice! Working very nicely at 133Mhz which is great news. Major Havoc is not and is really slow. :-/
In fact this is by far and away the slowest of all vector graphic games I've tested so far. It's a pity as it's one of my favorites.
There are 3x 68000 vector games (not including clones) which surprised me. I knew that there was as least one - Quantum.
The frontend has an option to select standard 'C' cores (for M68000 and Z80) or select the assembler equivalents (DRZ80 and Cyclone). For DrZ80 this is a necessity as it's not highly compatible. But Cyclone boasts 100% compatibility now so I might remove the option for the 'C' 68K core. Anyway, it's slower and HUGE, taking up 700KB!
I may hold off adding the ARM ASM line drawing code for now and just concentrate on getting the next few modules ready. Looks like there is going to be quite a few of them.
There are so many games to split into modules - it obviously makes sense to split them into similar hardware to make maximum use of the sound and cpu engines.
It's something that the author of PalmMAME had to deal with as well. I could cunningly look at his code to see how the modules were split... h34r:

 

[trooper]

Sounds like a lot of work. :blink:

I still have 3 GP32`s, 2 x Blu`s and 1 x dead Nlu.

One of the Blu`s clocks to 166mhz, The other clocks to ~200mhz (pencil modded a few years ago and still going strong ).

Thanks for the updates slaanesh, They are much appreciated.

Trooper

 

[slaanesh]

A bit more achieved over the weekend.

Despite what I said in the previous post I couldn't help try some Vector optimizations. I tried removing dirty pixel handling but it's slower. So this is now a compile time option - but one I won't use. Still need to try the ASM line drawer but that will be later.
Tried some games that require samples. Zektor is a good one as it's also a vector game so loaded it up and everything seems to be in order. The sample pack for the GP2X which contains the standard MAME samples seem to be fairly high quality samples - much higher than required by the GP32. The samples I looked at were all 16bit 44100hz - which is double as much as what is required. This makes for really big samples and as a result eats loads of memory. Star Trek samples are probably not going to fit at this size. So I'm going go through them and reduce them all to 22050hz (and possibly less for Star Trek).
Tried the artwork - there are 5 images that can be used as backdrops. I used Asteroid Deluxe as my test bed. Again the original artwork is huge - mega resolution which just isn't required. These large images will take up several megabytes of GP32 RAM which just isn't there. Needless to say the standard size images don't work so again I'm going to prepare special GP32 sized images (320x240).
I also made some fixes to configuration file saving, so MAME now saves configs and other files that need to be written out.

 

[slaanesh]

Okay, I've been playing around with getting artwork going. Finally success! I had a long standing bug where the entire zlib wasn't actually compiled using the GPSDK libs - instead using the ARM EABI libs - which means that it's using the wrong malloc() and free().
What does this mean? Inevitable crashes. Which is exactly what was happening. Anyway, that's fixed now.
So we have artwork! Sort of!
Another little problem creeped in - the GP32's screen memory is non-standard - it's rotated 270 degrees - which is a right pain in the ass for most porting projects
MAME has some nice modes whereby you can PREROTATE graphics - which is exactly what I do. However, the artwork isn't prerotated. And unfortunately prerotating the PNGs doesn't help either as other things get out of whack. Anyway it's a bug to chase down.
Optimized some of the palletized blitter routines. It was reading one 16-bit pixel and then writing one 16-bit pixel. Changed this to read and write two pixels at once.

Still quite a bit to do!

 

[Blah]

If anybody's still reading this for the original topic, I say DON'T open up the FLU. The lightguide is way to easy to damage. And you can't replace the screen cover because the lightguide is epoxied to it and the screen.

 

[ralp99]

ha!! so weird to see this, i looked into this thread for the first time in ages and what a surprise!! Hope to see Mame4all (in whatever form it ends up as) when it comes out!! So funny (and very cool)

 

[slaanesh]

It will come out.

I've done the artwork now for games that use it. There are actually only three (currently) working games with artwork: Asteroids Deluxe, Battlezone and Warriors. The other two, Solar Quest and Armor Attack aren't working in MAME 0.37b5 but I'll fix that in a subsequent release of GP32 MAME4ALL.

The release will include GP32 sized artwork as the original stuff is too big and get's scaled down to 320x240 anyway.

I'm now looking at the sound samples. Again many of these are sampled at rates that are over the top. I'm going to down sample them to samplerates that are more in line with the GP32's capabilities.

I'm probably going to need some testers at some stage so hopefully I can get some GP32 users to do so.

 

[ralp99]

volunteering to test! (probably little surprise there, i know)