Jump to content

CoinOPS 2 (old dev site)


BritneysPAIRS

Recommended Posts

  • Replies 4.1k
  • Created
  • Last Reply

Top Posters In This Topic

OK im happy with the Console stuff now its tidy and bug free....

 

ill be moving on usless people ask for stuff and good sound reasons.....

onto N64 or maybe FBA one of the two....but both are going to get the same treatment and run under CoinOPS settings

 

 

This is moving fast now..... The latest encarnation ROCKS HARD loving Double Dragon but I still get a lock up at the end when fighting my pal !

 

The MK series is totally killer, you done some awesome work there !

 

BP you got some serious skills bro !

 

Are you going to do a new GUI for EPIC, or are you saving it for the XBMC project ?

 

PS I hope you can optimize Goldeneye to run better :D

Link to comment
Share on other sites

in the old slow down versions did this happen? as I adjust the driver a little....or is there some driver updates required?

 

the GUI is undecided...ill finish FBA and look at N64....then ill patch in the New GUI HD skin....and get back to arcade games....

 

might actually look at midway core next and add the missing games if I can....looks not to hard

Link to comment
Share on other sites

Sounds awesome, can't wait to try it! :)

 

OK im happy with the Console stuff now its tidy and bug free....

 

ill be moving on usless people ask for stuff and good sound reasons.....

onto N64 or maybe FBA one of the two....but both are going to get the same treatment and run under CoinOPS settings

Link to comment
Share on other sites

Hey BP,

 

Regarding DOUBLE DRAGON, this has happened for a while. I remember I asked IQ about it and he pointed this post out from MAWS:

 

8th January 2006: Bryan McPhail - Double Dragon has a crash which sometimes occurs at the very end of the game (right before the final animation sequence). It occurs because of a jump look up table: BAD3: LDY #$BADD; BAD7: JSR [A,Y]. At the point of the crash A is 0x3e which causes a jump to 0x3401 (background tile ram) which obviously doesn't contain proper code and causes a crash. The jump table has 32 entries, and only the last contains an invalid jump vector. A is set to 0x3e as a result of code at 0x625f - it reads from the shared spriteram (0x2049 in main cpu memory space), copies the value to 0x523 (main ram) where it is later fetched and shifted to make 0x3e. So.. it's not clear where the error is - the 0x1f value is actually written to shared RAM by the main CPU - perhaps the MCU should modify it before the main CPU reads it back? Perhaps 0x1f should never be written at all? If you want to trace this further please submit a proper fix! In the meantime I have patched the error by making sure the invalid jump is never taken - this fixes the crash (see ddragon_spriteram_r).

 

in the old slow down versions did this happen? as I adjust the driver a little....or is there some driver updates required?
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...