Welcome!
Final Burn Neo => FBN Development => Topic started by: lantus on January 24, 2012, 10:57:52 AM
-
Hi guys,
ive been updating from the main code base now. Here are some additional big endian patches that can be applied to the repo. They should apply and not affect win32 builds in anyway. If we could get these updated in SVN it would save me a ton of headaches :)
there are more to come but i will get started here
cheers!
-
minor capcom big endian palette update
-
cave big endian
-
cps3run big endian fixes
-
Thanks lantus, as you've probably seen, all these have been merged into the repo.
-
thanks for that. Ill keep them coming. The misc drivers are the painful ones to deal with =)
-
thanks for that. Ill keep them coming. The misc drivers are the painful ones to deal with =)
Yeah, but at least now they'll get integrated into the tree. :)
-
irem driver endian fixes
nec/vez cpu endian fixes
-
Thanks lantus, I applied the patches to the repo.
I moved the LSB_FIRST define from burnint.h to a makefile flag, since burnint.h isn't always used by cpu cores.
-
thanks Treble. That makes life easier for me as i now wont need to comment out the #define in burnint.h each time
some psykio endian updates (d_psykio4.cpp/d_psykiosh.cpp)
-
megadrive bigendian updates
-
Thanks lantus, the repo is up-to-date with the patches again.
-
pgm big endian
-
pgm big endian
Thanks lantus - applied again.
Would this;
- if (gptr[i] == (0xffff - i)) gptr[i] = 0x4e75;
+ if (gptr[i] == (0xffff - i))
+ {
+#ifdef LSB_FIRST
+ gptr[i] = 0x4e75;
+#else
+ gptr[i] = 0x754e;
+#endif
+ }
+
not be better as;
- if (gptr[i] == (0xffff - i)) gptr[i] = 0x4e75;
+ if (gptr[i] == (0xffff - i)) gptr[i] = (BURN_SWAP_ENDIAN_INT16(0x4e75);
?
-
it would be, go ahead and change that if you like. thats what late night coding does :)
-
it would be, go ahead and change that if you like. thats what late night coding does :)
Ok, changed that one and a similar one in the same file.
-
additional nec/vez cpu endian fixes.
i added the following code to bitswap.h also
/* ----- macros for accessing bytes and words within larger chunks ----- */
#ifdef LSB_FIRST
#define BYTE_XOR_BE(a) ((a) ^ 1) /* read/write a byte to a 16-bit space */
#define BYTE_XOR_LE(a) (a)
#define BYTE4_XOR_BE(a) ((a) ^ 3) /* read/write a byte to a 32-bit space */
#define BYTE4_XOR_LE(a) (a)
#define WORD_XOR_BE(a) ((a) ^ 2) /* read/write a word to a 32-bit space */
#define WORD_XOR_LE(a) (a)
#else
#define BYTE_XOR_BE(a) (a)
#define BYTE_XOR_LE(a) ((a) ^ 1) /* read/write a byte to a 16-bit space */
#define BYTE4_XOR_BE(a) (a)
#define BYTE4_XOR_LE(a) ((a) ^ 3) /* read/write a byte to a 32-bit space */
#define WORD_XOR_BE(a) (a)
#define WORD_XOR_LE(a) ((a) ^ 2) /* read/write a word to a 32-bit space */
#endif
and uncommented out the BYTE_XOR_LE() calls in nec/vez which now gives us toaplan sound on big endian :)
-
about 1/2 way through pst90s patches.
here they are
-
more incoming. first up - CPS palette fix for your r350 changes
-
more incoming. first up - CPS palette fix for your r350 changes
Thanks - I knew something would need making endian-safe in it.
-
d_seta.cpp & d_seta2.cpp
-
d_lordgun.cpp & d_mcatadv.cpp
-
d_gauntlet.cpp
d_raiden.cpp
d_vmetal.cpp
nec.cpp reverted (fixed d_raiden.cpp)
-
thanks Treble
we have a few more to go but just about there now :)
-
thanks Treble
we have a few more to go but just about there now :)
nice - thanks for your work lantus.
-
- konami needed quite a bit of work
- be patches for phoenixed cps2
- sega fd1089 protection big endian
- some more misc driver updates
-
more misc 90s
- d_gaelco.cpp
- d_gaiden.cpp
- d_galspnbl.cpp
- d_suna16.cpp
- d_tecmosys.cpp
-
more misc 90s
- d_gaelco.cpp
- d_gaiden.cpp
- d_galspnbl.cpp
- d_suna16.cpp
- d_tecmosys.cpp
Thanks lantus, sorry for the delay in applying these.
-
no problem Treble :)
more....
pre90s ones this time
- d_sf.cpp
- d_snk68.cpp
- d_toki.cpp
-
- data east big endian
- some more PGM Big endian updates
-
arm cpu
more data east
sega16 sprite fix
we are really at the home stretch now..just a few minor fixes here and there i believe :)
-
Hey lantus, could you do me a favor and see if you could possibly track down a crash bug in the PGM code for me please? It seems to pop up at random, sometimes fba crashes on exit, sometimes not. I'm not sure where it's happening, if you could at least point me in a direction, i could fix it. :S
-
i've noticed that too iq..ill take a look
-
we are really at the home stretch now..just a few minor fixes here and there i believe :)
Very cool - nice work lantus. :)
-
I really hope someone might have a few moments to spare to enlighten me about this "big endian" business. I just really would like to know what its all about. Is it a new efficient coding scheme? Is this being done for the sake of consistency with mame updates? Or is there a bigger picture behind all of this? I'm sure everyone has much more important things to do but it would but a cliff-notes summary would be greatly appreciated.
-
It's for cross-platform support (eg, xBox-360). It's implemented in such a way so as to not affect the Win32 code or performance at all.
It's built into the main tree now, to prevent lantus having to redo his work every version. :)
-
It's for cross-platform support (eg, xBox-360). It's implemented in such a way so as to not affect the Win32 code or performance at all.
It's built into the main tree now, to prevent lantus having to redo his work every version. :)
ahh, very nice, thanks for that.
-
Hey lantus, could you do me a favor and see if you could possibly track down a crash bug in the PGM code for me please? It seems to pop up at random, sometimes fba crashes on exit, sometimes not. I'm not sure where it's happening, if you could at least point me in a direction, i could fix it. :S
Hmm, was going to take a look, but I can't produce a crash at all. Any tips on anything that is more likely to make it crash? :)
-
it seems to happen at random..if i can find a test case that i can reproduce ill share it
attached a few more neogeo endian patches
-
I really hope someone might have a few moments to spare to enlighten me about this "big endian" business. I just really would like to know what its all about. Is it a new efficient coding scheme? Is this being done for the sake of consistency with mame updates? Or is there a bigger picture behind all of this? I'm sure everyone has much more important things to do but it would but a cliff-notes summary would be greatly appreciated.
short answer is:
if you want fbalpha to run on the following
- Xbox360
- PS3
- Nintendo Wii
- Nintendo Gamecube
- Power PC Amiga computers
- PPC based Mac's
- PPC Mac Mini's
- any other system that has a 'big endian' cpu either now or in future (PS4, Xbox720, WiiU perhaps)
then these patches are a good thing
it improves portability to as many different systems as possible.
-
Hmm, was going to take a look, but I can't produce a crash at all. Any tips on anything that is more likely to make it crash? :)
yeah it happens randomly but more chance to have this crash with kovs sets (maybe something related to nvram?)
-
Hmm, was going to take a look, but I can't produce a crash at all. Any tips on anything that is more likely to make it crash? :)
I run demon front through the intro/demo loop a few times, then play the first level, then reset, then intro again. lol
Sometimes it crashes fba on exit, sometimes not.
-
I run demon front through the intro/demo loop a few times, then play the first level, then reset, then intro again. lol
Sometimes it crashes fba on exit, sometimes not.
It looks it's writing outside of allocated memory somewhere. If I let demon front run through the demo/intro until the IGS logo appears again gdb reports heap corruption on exiting the driver.
warning: HEAP[fbas.exe]:
warning: Heap block at 11FB1058 modified at 11FE2060 past requested size of 31000
warning: HEAP[fbas.exe]:
warning: Heap block at 05F7C118 modified at 05F94920 past requested size of 18800
-
in my experience the easiest place to end up with such bugs is sprite rendering code, if you're not checking your clipping properly....
of course it can actually be anywhere, sound buffers, ram/shared ram allocations... just those are more likely to crash consistently because they're more likely to be making bad accesses on a frequent basis.
-
Thanks to the big-endian patches by Lantus, FBA mainline now runs on 360, Wii and PS3 through SSNES/libsnes.
Perhaps one small change can be pushed upstream to make my life a bit easier - the header file that needs to be included for a big-endian port is called 'endian.h' right now - if this could be changed to some other name it would be much appreciated. The reason for changing it is that Linux has a system header file by that name and it conflicts when I build FBA libsnes on a Linux system (I compile PS3 builds on a Linux system with the Win32 PS3 toolchain running through WINE) - so right now with every new version of FBA that is released I always have to change the name to something that won't conflict, such as 'big_endian.h'.
-
Ok, pretty sure I've got it fixed. There's a crash when NVRAM is corrupted too, but that's somewhat of a non-issue atm imo.
-
Noticed a bug while testing FBA libsnes on SSNES PS3 - if a savestate was made with any CPS3 game, the screen colors would be distorted heavily. This would only partly go away in the next round, but the colors would still be off.
You can see an image of what would happen here:
https://imgur.com/A5QOy
The following needs to be changed in cps3run.cpp - line 689 - change:
RamPal[(paldma_dest + i) ^ 1] = coldata;
to:
#ifdef LSB_FIRST
RamPal[(paldma_dest + i) ^ 1] = coldata;
#else
RamPal[(paldma_dest + i)] = coldata;
#endif
That fixed the issue for me at least.
-
Noticed a bug while testing FBA libsnes on SSNES PS3 - if a savestate was made with any CPS3 game, the screen colors would be distorted heavily. This would only partly go away in the next round, but the colors would still be off.
You can see an image of what would happen here:
https://imgur.com/A5QOy
The following needs to be changed in cps3run.cpp - line 689 - change:
RamPal[(paldma_dest + i) ^ 1] = coldata;
to:
#ifdef LSB_FIRST
RamPal[(paldma_dest + i) ^ 1] = coldata;
#else
RamPal[(paldma_dest + i)] = coldata;
#endif
That fixed the issue for me at least.
Cool. ^^ Pushed this to the SVN.
-
Small typo in d_psikyo4.cpp for big-endian code path -
change line 452 from:
DrvSprRAM((address) & 0x3fff] = data;
to:
DrvSprRAM[(address) & 0x3fff] = data;
-
Cool. Fixed :)
-
Thanks to the big-endian patches by Lantus, FBA mainline now runs on 360, Wii and PS3 through SSNES/libsnes.
Perhaps one small change can be pushed upstream to make my life a bit easier - the header file that needs to be included for a big-endian port is called 'endian.h' right now - if this could be changed to some other name it would be much appreciated. The reason for changing it is that Linux has a system header file by that name and it conflicts when I build FBA libsnes on a Linux system (I compile PS3 builds on a Linux system with the Win32 PS3 toolchain running through WINE) - so right now with every new version of FBA that is released I always have to change the name to something that won't conflict, such as 'big_endian.h'.
Thanks for pointing it out, I changed the include to burn_endian.h.
-
Ok, pretty sure I've got it fixed. There's a crash when NVRAM is corrupted too, but that's somewhat of a non-issue atm imo.
gdb no longer reports the heap warnings on exit (and I got them 100% of the time before).
-
gdb no longer reports the heap warnings on exit (and I got them 100% of the time before).
Wonderful. :D
-
don't forget Saturn, I'm back :)
-
welcome back =)
-
d_cps1 endian updates for the new stuff and some bootlegs i never bothered with in the past
-
a small endian cps1 fix for SF2MDT
-
- endian fix for System16A tiles (Shinbo set 1 and 6)
- endian fix for d_tecmo.cpp palette (rygar)
-
- endian fix for d_cybertnk
-
These Big Endian patches are from MagicSeb. Verified and tested working.
- d_cbuster.cpp : Colorfix + No crash
- d_simpl156.cpp : Sprites fix
- d_supbtime.cpp : Colorfix + No crash