fba - omap, cyclone and more

[crow_riot]

i've been porting fba to the pandora recently and while doing so, some problems/questions


1)


i'm been using parts of notaz gpsp port to get direct access to the omap hardware scaling capabilities.


i wanted to add "real" fullscreen with all thos ugly stretch issues, but that does not work for me - though i set up the outgoing layer to be 800x480.


it "only" does aspect correct scaling (which is cool for me, but tastes are different!) - is this a limitation of the scaler or just my failure to setup it correctly?


2)


the cyclone core crashes on games that are marked as working in the capex frontend - so i guess it worked on the gp2x (never owned one); this also crashes on the caanoo;


i've debugged it to be the line 52 in the cyclone.s - i know it's very little information, very likely too little, but i'll just throw it out

ldrh r8,[r4],#2 ;@ Fetch first opcode

what i've tried to do is to create a new cyclone assembler file and see if the fixes incorporated by notaz would help.


but well, i just dont know what config's i need to enable/disable in the config.h. any hints?


3) i've added keymapping capabilities and wanted to be as universal as possible


so i wanted to use "XStringToKeysym" to convert the key string to the key code.


but that specific function is not defined in the place where it's meant to be. is there an alternative/built-in way to convert key-strings (any format, dont care) to keycodes


thx in advance

 

[mcobit]

about 1)


Could it be, that sdl already scales the output to aspect in software, so that it would have black bars on 640x480, too? if you scale that to 800x480 these will still be there.

 

[notaz]

about 2)


one thing is it's using rather old cyclone, but that's probably not the reason it crashes. It more looks like some glue code is missing for some arcade board drivers and PC is not passed as emulator pointer, it's probably the emulated 68k PC instead.


As for config.h, config_mamegp2x.h sample might be good (included in cyclone sources), but that depends how emulator does things really.

 

[crow_riot]

about 1)


Could it be, that sdl already scales the output to aspect in software, so that it would have black bars on 640x480, too? if you scale that to 800x480 these will still be there.

i'm not using sdl at all - but the framebuffer directly, so that couldnt be the issue

about 2)


one thing is it's using rather old cyclone, but that's probably not the reason it crashes. It more looks like some glue code is missing for some arcade board drivers and PC is not passed as emulator pointer, it's probably the emulated 68k PC instead.


As for config.h, config_mamegp2x.h sample might be good (included in cyclone sources), but that depends how emulator does things really.

i think i've tried that config, it still crashed and other games previously working stopped to do so. should give it a try again

 

[notaz]

about 1)


Could it be, that sdl already scales the output to aspect in software, so that it would have black bars on 640x480, too? if you scale that to 800x480 these will still be there.

i'm not using sdl at all - but the framebuffer directly, so that couldnt be the issue

It could still be using incomplete framebuffer (i.e. with black bars), and that's scaled accordingly.

 

[mcobit]

about 1)


Could it be, that sdl already scales the output to aspect in software, so that it would have black bars on 640x480, too? if you scale that to 800x480 these will still be there.

i'm not using sdl at all - but the framebuffer directly, so that couldnt be the issue

It could still be using incomplete framebuffer (i.e. with black bars), and that's scaled accordingly.

Thats what I meant, sorry, sometimes I can't explain such things in english.

 

[crow_riot]

about 1)


Could it be, that sdl already scales the output to aspect in software, so that it would have black bars on 640x480, too? if you scale that to 800x480 these will still be there.

i'm not using sdl at all - but the framebuffer directly, so that couldnt be the issue

It could still be using incomplete framebuffer (i.e. with black bars), and that's scaled accordingly.

Thats what I meant, sorry, sometimes I can't explain such things in english.

yeah now i got it ... no, no black bars - it does aspect-correct scaling, but what i want is stretchy scaling for the ones who don't care about wrong aspects but rather like to have really full screen

 

[mcobit]

You know, that the resolution of the cps2 games x2 is already fullscreen? If the emulator sqeezes that into the 4:3 aspect, there are black bars, but if you scale that up, those might still be there?


This is really hard to explain, maybe notaz can help a bit.

 

[crow_riot]

You know, that the resolution of the cps2 games x2 is already fullscreen? If the emulator sqeezes that into the 4:3 aspect, there are black bars, but if you scale that up, those might still be there?


This is really hard to explain, maybe notaz can help a bit.

ah now ... gotcha ... stupid me i think thanks

 

[crow_riot]

ad 2)


i've retried to add the cyclone with mame's config, but without luck. the outcoming core source differs by >300kb - so i guess there needs to be set something else, dunno.


but anyway, i don't think it's cyclones problem but more fba's one as i've replaced the core with a musashi 68000 and the game doesnt crash but doesnt start either ...

 

[notaz]

Well at least hopefully you'll not drop asm cores like everyone else seems to be doing these days.

 

[crow_riot]

Well at least hopefully you'll not drop asm cores like everyone else seems to be doing these days.

no i've no intention to do so, the speed is really awesome with the cyclone core, and well it's often speed versus compatibility, isn't it?

 

[notaz]

It shouldn't be, there is no reason Cyclone can't be as accurate as Musashi.