nukeykt / nuked-md Goto Github PK

So, as i ponder of more improvements of changes and ways to contribute in terms of optimizing the code base to be faster, there really needs to be unit testing to ensure changes don't break the code base.

I am willing to write the entire test suite, the issue is, i will need a lot of test vectors, which i don't have the time to fully obtain them, if somebody wishes to help with this effort and obtain test vectors for each of the chips (the cartridge and input portions i can do easily) we could have a method of ensuring nothing breaks and possibly finding bugs within the chips themselves.

This is apart of #17 as fixing this up for BSD's would be simple, but that would come at a later time. currently optimization should be the goal on top of furthering progress of the compatibility with games.

Saving for these games is unsupported.

Barkley: Shut Up and Jam! 2 (EEPROM)
Blockbuster World Videogame Championship II (NBA Jam T.E. portion) (EEPROM)
Brian Lara/Shane Warne Cricket (Europe/Australia exclusive title) (EEPROM)
College Slam (EEPROM)
Evander "Real Deal" Holyfield Boxing (EEPROM)
Frank Thomas Big Hurt Baseball (EEPROM)
Greatest Heavyweights of the Ring (EEPROM)
Mega Man: The Wily Wars (Europe uses EEPROM, Japanese release uses SRAM)
Micro Machines '96 (Europe exclusive title) (EEPROM)
Micro Machines 2 (Europe exclusive title) (EEPROM)
Micro Machines Military (Europe exclusive title) (EEPROM)
NBA Jam (EEPROM)
NBA Jam Tournament Edition (EEPROM)
NFL Quarterback Club (EEPROM)
NFL Quarterback Club '96 (EEPROM)
NHLPA Hockey '93 (EEPROM)
Rings of Power (EEPROM)
Sports Talk Baseball (EEPROM)
Unnecessary Roughness '95 (EEPROM)
Wonder Boy in Monster World (EEPROM)

Both of these games fail to boot up. Same thing happens with the other Genesis Core.

When using the core over analog video the blacks are elevated and there is a green tint. This is not present on hdmi output.

chip->w266 = chip->w289 && chip->w356 && chip->w356;

w356 two times :wtf:

I know that it's probably way too early to ask for such a feature, considering that the emulator is still heavily WIP, but I'm wondering if having VGM logging is considered once more progress is made. While BlastEm does a pretty good job at VGM logging right now, IMO it never hurts to implement the feature in a more accurate emulator.

This obviously compiles on Windows and Linux, has anyone attempted to get it to compile on BSD variants?

If not, i could take the challenge of getting it to compile on OpenBSD so it could be submitted to their ports, however i have no experience with any other BSD variant.

May slightly differ on FreeBSD and NetBSD. (Though technically OpenBSD is derived from NetBSD so porting to OpenBSD may solve NetBSD) (Don't quote me).

As for OSX i have no machine or care to bother with it.