Welcome!
Final Burn Neo => FBN Development => Topic started by: destronger on February 02, 2014, 06:21:52 PM
-
i noticed in an old topic by kenshiro that he created a mame to fba driver converter. it's a rather old topic though. i was wondering if an updated tool has been made and if it could be shared.
mahalo. :biggrin:
-
Now thats a good idea to think of a programme that makes converting Mame drivers into FBA format easier even better is to actually
go ahead and create such a programme
How id love something like this for Mame a tool that easily allows you to roll source code either forwards or backwards between versions
say make Mame84 the base source and take some driver/video/sound/cpu source files etc from the latest mame sources
run em past a programme that converts them into files that can be simply implanted into a previous source :cool:
-
All it did was take a rom structure (rom size, crc) from a pasted driver and put it into the format that fba needs. I still use my tool I wrote for this. It also does input conversions too. Really the easiest part of making a driver, but imo the easiest to mess up and most tedious.
-
so the one on the old post is the latest then?
-
Yes this is the last one.
Despite the fact it's quite old and badly written (IIRC that was my second C program, it is not very academic lol ), he should do the job just fine ;p
-
Dip Switches Generator 1.1 ?
-
moo!!
-
Dip Switches Generator 1.1 ?
Nope, i was talking about the driver converter ;p
-
oh, ok, i've finally found it ! for sure i'll try it too !
-
it does that, or it should do more ?
// Astro Fighter (set 1)
static struct BurnRomInfo AstrofRomDesc[] = {
};
STD_ROM_PICK(Astrof)
STD_ROM_FN(Astrof)
struct BurnDriver BurnDrvAstrof = {
"astrof", NULL, NULL, "1980",
"Astro Fighter (set 1)\0", NULL, "Data East", "",
NULL, NULL, NULL, NULL,
BDF_GAME_WORKING, 0, HARDWARE_MISC_PRE90S, 0, 0,
NULL, AstrofRomInfo, AstrofRomName, astrofInputInfo, AstrofDIPInfo,
DrvInit, DrvExit, DrvFrame, DrvDraw, DrvScan,
0, NULL, NULL, NULL, &DrvRecalc, 256, 256, 4, 3
};
// Astro Fighter (set 2)
static struct BurnRomInfo Astrof2RomDesc[] = {
};
STD_ROM_PICK(Astrof2)
STD_ROM_FN(Astrof2)
struct BurnDriver BurnDrvAstrof2 = {
"astrof2", "astrof", NULL, "1980",
"Astro Fighter (set 2)\0", NULL, "Data East", "",
NULL, NULL, NULL, NULL,
BDF_GAME_WORKING | BDF_CLONE, 0, HARDWARE_MISC_PRE90S, 0, 0,
NULL, Astrof2RomInfo, Astrof2RomName, astrofInputInfo, Astrof2DIPInfo,
DrvInit, DrvExit, DrvFrame, DrvDraw, DrvScan,
0, NULL, NULL, NULL, &DrvRecalc, 256, 256, 4, 3
};
// Astro Fighter (set 3)
static struct BurnRomInfo Astrof3RomDesc[] = {
};
STD_ROM_PICK(Astrof3)
STD_ROM_FN(Astrof3)
struct BurnDriver BurnDrvAstrof3 = {
"astrof3", "astrof", NULL, "1980",
"Astro Fighter (set 3)\0", NULL, "Data East", "",
NULL, NULL, NULL, NULL,
BDF_GAME_WORKING | BDF_CLONE, 0, HARDWARE_MISC_PRE90S, 0, 0,
NULL, Astrof3RomInfo, Astrof3RomName, astrofInputInfo, Astrof3DIPInfo,
DrvInit, DrvExit, DrvFrame, DrvDraw, DrvScan,
0, NULL, NULL, NULL, &DrvRecalc, 256, 256, 4, 3
};
// Tomahawk 777 (Revision 1)
static struct BurnRomInfo TomahawkRomDesc[] = {
};
STD_ROM_PICK(Tomahawk)
STD_ROM_FN(Tomahawk)
struct BurnDriver BurnDrvTomahawk = {
"tomahawk", NULL, NULL, "1980",
"Tomahawk 777 (Revision 1)\0", NULL, "Data East", "",
NULL, NULL, NULL, NULL,
BDF_GAME_WORKING, 0, HARDWARE_MISC_PRE90S, 0, 0,
NULL, TomahawkRomInfo, TomahawkRomName, tomahawkInputInfo, TomahawkDIPInfo,
DrvInit, DrvExit, DrvFrame, DrvDraw, DrvScan,
0, NULL, NULL, NULL, &DrvRecalc, 256, 256, 4, 3
};
// Tomahawk 777 (Revision 5)
static struct BurnRomInfo Tomahaw5RomDesc[] = {
};
STD_ROM_PICK(Tomahaw5)
STD_ROM_FN(Tomahaw5)
struct BurnDriver BurnDrvTomahaw5 = {
"tomahaw5", "tomahawk", NULL, "1980",
"Tomahawk 777 (Revision 5)\0", NULL, "Data East", "",
NULL, NULL, NULL, NULL,
BDF_GAME_WORKING | BDF_CLONE, 0, HARDWARE_MISC_PRE90S, 0, 0,
NULL, Tomahaw5RomInfo, Tomahaw5RomName, tomahawkInputInfo, Tomahaw5DIPInfo,
DrvInit, DrvExit, DrvFrame, DrvDraw, DrvScan,
0, NULL, NULL, NULL, &DrvRecalc, 256, 256, 4, 3
};
-
Nope, i was talking about the driver converter ;p
@kenshiro: i noticed that you mentioned a neogeo specific version but i couldn't locate it. could you supply download here?
mahalo
-
it does that, or it should do more ?
It should do more. All BurnRomInfo structs are empty, this is not normal.
-
@kenshiro: i noticed that you mentioned a neogeo specific version but i couldn't locate it. could you supply download here?
mahalo
Sorry, it simply does not exists. I started (few years ago) to work on it but never finish it ;)
-
ok, thanks for the reply.
-
Kenshiro i was wanting to ask you a quick question about VMM code in FBA/L i know you have lots of experiance in this area
there's 3 games that wont boot on stock xboxes DD Crew Laser Ghost and Desert Breaker of those 3 desert breaker is the one
i'd like play so the question is does VMM have to be coded on a game to game basis or is it added to cover all games in a driver
and can this code simply be reused in the segas18.c driver to get the above games to boot???
-
IIRC, Nes6502 had a try with DD Crew and coded a VM. The game was very slow so he decided to not integrate it into FBL (it was too CPU consumer).
You could probably just have a try and see :)
-
IIRC, Nes6502 had a try with DD Crew and coded a VM. The game was very slow so he decided to not integrate it into FBL (it was too CPU consumer).
You could probably just have a try and see :)
Oh im not a developer with regards to Final Burn Legends im just interested in how VMM works in FBL if it was a simple case
of just reusing VMM code that was done for other games i was hoping to rope destronger into implementing it into the
system18 driver as some point but now that you've mentioned nes6502 actually got the game to boot and it
played too slow then it would be unfair to ask a developer to work on adding VMM code with no guarantee the games
would actually work and play properly afterwards
desert breaker is nice wee game i wanted to get it playable in MameoXtras but the amount of work required was huge
i thought the easier quicker way would be adding VMM for it in FBL but if the game's going to be too slow as is likely
then there would be no point
Thanks for your reply though kenshiro it's much appreciated
-
All it did was take a rom structure (rom size, crc) from a pasted driver and put it into the format that fba needs. I still use my tool I wrote for this. It also does input conversions too. Really the easiest part of making a driver, but imo the easiest to mess up and most tedious.
is this tool that you created somewhere in this forum?
-
Oh im not a developer with regards to Final Burn Legends im just interested in how VMM works in FBL if it was a simple case
of just reusing VMM code that was done for other games i was hoping to rope destronger into implementing it into the
system18 driver as some point but now that you've mentioned nes6502 actually got the game to boot and it
played too slow then it would be unfair to ask a developer to work on adding VMM code with no guarantee the games
would actually work and play properly afterwards
FBAL has two VMMs. The old one that was in FBAx and the one I wrote specifically for PGM (I've got a switch in the source so that you can test it on PC).
desert breaker is nice wee game i wanted to get it playable in MameoXtras but the amount of work required was huge
i thought the easier quicker way would be adding VMM for it in FBL but if the game's going to be too slow as is likely
then there would be no point
Iirc that game is extremely slow too. I would highly suggest taking a look at the games running in FBA on pc, check the % of cpu it uses (ensuring that you are disabling any gfx enhancements, etc). So if the game takes 10% cpu on a quad-core at 4ghz, you're look at 4,000 (mhz) x 4 (cores) * 0.10 (10%) -> 1600 mhz (1.6ghz) is probably required to run the game properly. That puts it well outside the realm of feasible in xbox. There are often ways around this (take a look at my work on pgm and the psikyosh games), but it takes a ton of work and no guaranteed results.
-
is this tool that you created somewhere in this forum?
I don't remember ever posting it, no. I will post it tonight when I get home, but it's nothing that's in a polished state whatsoever.
-
Iirc that game is extremely slow too. I would highly suggest taking a look at the games running in FBA on pc, check the % of cpu it uses (ensuring that you are disabling any gfx enhancements, etc). So if the game takes 10% cpu on a quad-core at 4ghz, you're look at 4,000 (mhz) x 4 (cores) * 0.10 (10%) -> 1600 mhz (1.6ghz) is probably required to run the game properly. That puts it well outside the realm of feasible in xbox. There are often ways around this (take a look at my work on pgm and the psikyosh games), but it takes a ton of work and no guaranteed results.
Funny enough ive looked over your PGM and psikyo VMM some top class work there :cool: it seems there's no easy way here
a ton of VMM work would be required for destronger in FBL while in MameoXtras i'd be looking at multiple driver and linked source file updates to get those few games playable with no guarantee that they would function well at all
i have an idea though i'd like to leave the sega drivers in MameoXtras in their currant state eg Mame84 im thinking about if i
can simply dump all the source code required for desert breakers be it protection video etc into the segas18.c driver and
add it into my compile it would certainly be the quickest way to do this something to try on a rainy day i guess
-
Funny enough ive looked over your PGM and psikyo VMM some top class work there :cool: it seems there's no easy way here
a ton of VMM work would be required for destronger in FBL while in MameoXtras i'd be looking at multiple driver and linked source file updates to get those few games playable with no guarantee that they would function well at all
I don't mean to discourage you!
i have an idea though i'd like to leave the sega drivers in MameoXtras in their currant state eg Mame84 im thinking about if i
can simply dump all the source code required for desert breakers be it protection video etc into the segas18.c driver and
add it into my compile it would certainly be the quickest way to do this something to try on a rainy day i guess
Give it a shot!
-
I don't mean to discourage you!
No you haven't discouraged me it's 2 things really destronger is the currant FBL developer it's something he would have to want to
work on plus i think now that those games wont play fast enough with Xbox FBL so it could end up being a ton of work with no
happy ending ;) plus to be honest the FBL sources are kinda a puzzle to me i find the Mame sources easier just now
Give it a shot!
i already have!! i put all the sega drivers from Mame91 into my source after some code tweaks i managed to get all the linked files
sound video decryption etc to compile fine it's the drivers where the problems started maybe i missed something sound related
as there seems to be an unsupported sound core for some games plus im not sure how to rollback the some of the control defines
for certain games back to what my Mame84 source requires so i thought to avoid a ton of work and these issues i'll try and dump
what i think desert breaker needs into the one driver and keep it seperate from the rest
im just mulling over a conflict just now as system18 video start is already defined in system18.c i cant also have it in segas18.c
or i get a compile error something to try again on a rainy day i guess
-
FBAL has two VMMs. The old one that was in FBAx and the one I wrote specifically for PGM (I've got a switch in the source so that you can test it on PC).
Iirc that game is extremely slow too. I would highly suggest taking a look at the games running in FBA on pc, check the % of cpu it uses (ensuring that you are disabling any gfx enhancements, etc). So if the game takes 10% cpu on a quad-core at 4ghz, you're look at 4,000 (mhz) x 4 (cores) * 0.10 (10%) -> 1600 mhz (1.6ghz) is probably required to run the game properly. That puts it well outside the realm of feasible in xbox. There are often ways around this (take a look at my work on pgm and the psikyosh games), but it takes a ton of work and no guaranteed results.
The Sega tilemap handling is pretty slow, due to their size (1024x512), two priorities, column scroll, row scroll and ability to select to show from a different "alt" page (meaning that we have to render two for each layer, and then check which one we need to show on a tile-by-tile basis after we've calculated the column and row scroll). Also add on the fact that we need to have an Opaque and a transparent version for the background tilemaps - it's a nightmare. :)
That said, though the tilemaps are cached in memory and the scroll, row scroll, column scroll and page select are applied each frame as necessary. The tilemaps are only calculated when the game writes something different.
The page select isn't used that often (although more in System 18 than in others), so the tilemap handling could be simplified for speed (at the sake of some bugs in games). Older FBA releases would have relevant source for comparison.
See http://barryharris.me.uk/article_view.php?id=94 for a bit more info.
-
those games sure look better with those tilemaps added some nice work there!!
-
any chance of quick how to on the prog you uploaded iq_132?
-
any chance of quick how to on the prog you uploaded iq_132?
copy a mame driver file, paste it into the same directory as the program, run the program, type the filename of the mame driver (eg. midas.c). it should spit out a file named output.cpp
-
thanks
-
It should do more. All BurnRomInfo structs are empty, this is not normal.
i used an old mame driver maybe around 0.36, too old version ?
-
i used an old mame driver maybe around 0.36, too old version ?
Definitely! The mame structs have changed a lot since then!