• DCEmu Homebrew Emulation & Theme Park News

    The DCEmu the Homebrew Gaming and Theme Park Network is your best site to find Hacking, Emulation, Homebrew and for the first time Theme Park News and also Beers Wines and Spirit Reviews and Finally Marvel Cinematic Univers News. If you would like us to do reviews or wish to advertise/write/post articles in any way at DCEmu then use our Contact Page for more information. DCEMU Gaming is mainly about video games -
  • b8a

    by Published on March 14th, 2007 11:53

    It's been a few weeks since NJ released his latest update, but since I've been busy trying to nail down a process for creating accurate rips of PC Engine S/CD games on OS X (all with open source software), I haven't had a chance to compile NJ's converters until now.

    Having ripped and tested my S/CD library (all work beautifully in Mednafen), I did a quick compile of NJ's rom converters. The great news is that the source is now extremely multi-platform friendly and compiles very easily, so if you use an OS that doesn't have any working publicly released binaries (such as, perhaps, Mac OS X Intel), you can now easily compile the converters on your own. It only takes a few minutes. The only catch is that there are a few modifications that you'll probably have to make to the source. These are the steps that I had to follow to get the converters to build successfully:
    • Change all instances of "zopen(" to something else (I use "z_open("). This doesn't even take 10 seconds using a text editor that can recursively search-and-replace. TextWrangler (freeware) does this beautifully.
    • Remove all <malloc.h> headers. I only found one in common.h and unzip.c each.
    • cd into the romcnv source directory and compile! (make -f makefile.mvs UNIX=1)
    • I always ran into a problem at this point that required me to run: ranlib ./obj_mvs/zlib.a
    • Run make one more time

    Since there are a few differences between NJ's official release and the backends I've been maintaining for MacX_romcnv (my version requires you to specify a save path, allows you to automatically remove the converted files from the zip, and, of course, is compatible with the GUI), I've updated those backends, and as usual, have posted them over at the MacX_romcnv release thread.

    I think these should run on Intels, but don't have one to test on, so if any Intel users want to give these a shot I'd love to hear the results. ...
    by Published on February 18th, 2007 12:40

    In case you haven't been following the latest release thread, NJ updated all of his emulators on 2/16 to fix various bugs in the 2/14 (and 2/15) releases, and asked that those previous releases be removed from any sites they're hosted at, and that users be urged to download the latest releases from his page. (yes, he did specifically ask that users be directed to his page)

    And Mac users of CPS2PSP and/or MVSPSP might be happy to hear that I've finished porting OS X versions of his new ROM converters for those emulators. You can get them at the MacX_romcnv release thread.

    Give Feedback/ Compatability Reports Via Comments

    Download from NJ site ...
    by Published on February 14th, 2007 12:15

    NJ has once again said farewell to the PSP scene, this time offering a major update to all of his emulators as a final parting gift.

    We have new versions of each emulator for

    Neogeo MVS
    NeoGeo CD


    Last Words
    Although it was my intention to stop updates as of 2007/01/28, I delayed it a bit due to various issues, but am now finished making updates as of today, 2007/02/14. I will not be making any more PSP software, but it is my hope that these will be of some use as reference.

    2007/02/14 NJ
    About The Software Presented Here

    -If you have used any of the previous versions please take note that a portion of the control scheme as changed. The menu is opened with the HOME button.
    -Please read the readme_???.txt included with each software first.
    -The control schemes are all pretty much the same. They are written in the readme_???.txt (files) so please run your eyes over them.
    -For all menus other than the main menu, there is a simple controls help function available. It is displayed by pressing the R TRIGGER, so please run your eyes over these as well.
    -I have also prepared Japanese language versions of the 3 arcade emulators, however the amount of allocatable memory decreases by about 800KB (with these).

    About The resource_jp.zip (file) Included With The English Language Version (Excluding NCDZPSP)
    -The files included in the English language version resource_jp.zip are files that are necessary if Japanese is to be used in the game list and the command list.
    *If you are not going to use Japanese this (file) is unnecessary so please delete it.
    *When displaying Japanese, copy the files included in resource_jp.zip exactly as they are to /PSP/GAME/CPS1PSP/.
    -Even in the English language version, when using the Japanese command list, the Japanese font is loaded, and the amount of allocatable memory decreases by that amount.

    About Emulators That Use Cache
    -All of the CPS2PSP games, as well as almost half of the MVSPSP games, will not run if you do not create cache files for them.
    -Please create the cache files with the romcnv_cps2.exe and/or romcnv.mvs.exe included with the released binaries. Since I included a version check, you can not use older cache files.
    -With CPS2PSP, it is possible to use zip compressed cache files, however, the speed drops considerably compared to uncompressed cache files. Other than a few of the smaller games, I recommend that you use uncompressed cache files.
    -When using cache files, the speed of the game is influenced by the loading speed of the Memory Stick. When using AdHoc, the speed of your opponent's (Memory Stick) will have an effect, so it is better if you don't use pre-PRO Memory Sticks.

    About The AdHoc Version
    -I put various efforts into stabilizing it, but since there are a lot of unknowns about the PSP AdHoc, even though it's gotten somewhat better, it's still unstable.
    -It's possible to play normally even with the AdHoc version. The reason I separated it from the regular version is because the speed of the AdHoc version is somewhat slower. If you do not plan on using AdHoc, I recommend that you use the regular version.
    -When using AdHoc, a portion of the options are fixed. Due to synchronization circumstances with NCDZPSP, the load screen emulation is always set.
    -Since you can't synchronize with different binaries, you will not be able to connect between a Japanese version and an English version.

    About The Command List File Size Reduction Function (I forgot to write this in the documentation)
    -When you select command.dat in the file browser, the file size reduction function starts up. Since the Japanese language version of a MAME! Plus command list is close to 4MB, please execute this first. Game loading times will somewhat decrease.

    *Please refer to each emulator's section to see what's changed.

    Changes for CPS2 Emulator
    -Due to merging the NCDZPSP source, all of the source (code) has been rewritten.
    -Added a Japanese interface version to all of the emulators. Compared with the English language version, the Japanese language version consumes about an extra 800KB of memory.
    -Added compatibility with MAME Plus! style command lists. Please place command.dat in the same directory as the EBOOT.PBP. Also, when using a Japanese language command list, an approximate 800KB of extra memory is consumed.
    -Although the amount of items that can be set in the makefile have increased, it is better not to use UI_BPP32 outside
    by Published on January 17th, 2007 11:45

    I've spent a bit of my spare time over the last few months porting NJ's ROM converters to OS X. Anyway, what with all of the different OS X versions and the different PowerPC and Intel macs, I do not know how many setups this will work under, but I've thoroughly tested it on a PowerPC running 10.3.9. Feedback on how this works on other people's Macs would be very much appreciated (although I don't pretend that I'll be able to do anything about problems arising from setups that I can't duplicate/anticipate).

    It should go without saying, but this is only for use with games that you legally own. Accordingly, I have only tested it with a few games (and even then, I've only checked that they initially work, I haven't had the chance to extensively test-play any yet). If you find that this doesn't work with any of your games, please post which one(s) they are and I will see if there isn't anything I can do to fix it.

    The usage should be self explanatory, but complete instructions are included in the readme file.

    Much thanks to NJ and the original MAME team for making this possible.

    Note About The GUIs
    In a seperate thread, Paladinja pointed out that if you choose the "Generate compressed cache files" under the CPS2 section, and then later try to unzip and use those files, that they WON'T work. When I first read that, I thought "of course", but then I recently launched the GUI and saw that displayed text message does say that it WILL work. I appologize for this, but the cache system has undergone many changes since I started porting this tool, and originally the zipped cache files WERE the same as the unzipped files. I can't remember when the change occured, but the data contained in each file type is now indeed different. So, rather than releasing a GUI update just to fix that one sentance, I'm letting you know here.

    Update: 3/14/2007

    These are the backend command line tools for converting roms for compatibility with the 2.0.6 versions of both emulators. As before, I haven't tested much, and if you like graphical interfaces, then you'll need to add these to one of the appropriate packages from below.

    Due to the fact that NJ made some major changes to the source code, I think that these will run on Intels, but I don't know for sure.

    If these don't work on Intels, cheer up, because NJ's raw source is now super-easy to compile on macs, so just go ahead and grab the sources and compile yourself some converters.

    These steps were all it took to compile the converters from NJ's virgin source on my mac:
    • Change all instances of "zopen(" to something else (I use "z_open("). This doesn't even take 10 seconds using a text editor that can recursively search-and-replace. TextWrangler (freeware) does this beautifully.
    • Remove all <malloc.h> headers. I only found one in common.h and unzip.c each.
    • cd into the romcnv source directory and compile! (make -f makefile.mvs UNIX=1)
    • I always ran into a problem at this point that required me to run: ranlib ./obj_mvs/zlib.a
    • Run make one more time

    Of course, I had to tweak the code to make them compatible with the GUI front end, so raw compiles from NJ's source won't work with my GUI. -- Just in case anyone was interested.

    Update: 2/18/2007

    Finished porting the converters for the 2.0 versions of both emulators. I've tested these even less then the previous versions, but the tests I have done have gone well. Please let me know if you have any problems.

    These are just the command line tools, so if you prefer to use a graphical interface, you'll also need one of the GUI versions from below.

    Update: 1/20/2007

    There have been reports that the GUI below doesn't recognize zip files for some people. The details of the reports have been somewhat vague so I can't say for sure, but I think this is a 10.4+ specific problem. In any case, if this is a problem that you've had, either use the raw CLI backends or try this alternate GUI which has been confirmed to address this specific issue. This package does not contain any of the nessecary CLI backends, so you will have to use use the ones from the 2.0 update above, or the original release below. See this post for instructions on where to put the CLI backends.

    Original GUI+Converters Release: 1/17/2007

    This is the original release package which contains both the GUI and the CLI backends for romcnv_mvs for MVSPSP 1.63 and romcnv_cps2 for CPS2PSP 1.66. Source is included in this package. There are English and Japanese versions of the program and all materials, and I can always package more if anyone out there is willing to do translations for other languages. ...
    by Published on December 17th, 2006 12:33

    NJ has posted the following on his website, with a specific request that the message be translated:

    Please read following thread in "DCEMU.UK forums"

    DCEMU.UK / NJ Arcade Emulators Source Translations - transrated by b8a


    -Although this is compatible with uni-bios and other hack BIOS, basically their use is not recommended. It's possible that a portion of the games won't run.


    Also, MVSPSP constantly runs with Raster Effects = ON when using the UNI-BIOS (because it won't work when set to OFF). Accordingly, situations may occur where the operating speed drops dramatically on the low-on-processing-power PSP.
    If you are hoping for a stable play experience, please use the newest version possible of either the Euro or Japan MVS BIOS. Or, in other words, please don't use any BIOS other than these. Since it's causing me various troubles, I'll be deleting UNI-BIOS and DEBUG BIOS with the next source code update, so I ask for your understanding.

    That having been said, I've never had any problems occur with Metal Slug 4 with my setup. If you have used UNI-BIOS even once, then first change to an MVS BIOS, open the menu and confirm that Raster Effects is set to Off, and if it's set to On, then please change it to Off.
    If it still doesn't work even then, then the cause is a total mystery. Irregardless there will be no further updates of MVSPSP itself, so I ask for your understanding.

    (Mods: I realize that this really isn't front page material, but I've found that a lot of people don't get these messages unless they're posted in a new thread on the front page... So, please move it to whatever location you think is appropriate) ...
    by Published on December 7th, 2006 11:58

    Hot on the heels of achieving full speed CPS2 emulation on the PSP, NJ has posted yet another update to his emulators, this time solely for MVSPSP. The news from his site reads as:
    Since I had only checked that the source was compile-able, it looks like there were a few problems with (the last version). I'm going to take some time to perform some maintenance on this.

    -It looks as though 1.31 didn't compile correctly so I recompiled it and swapped out the file with 1.32 but the version display still says 1.31, so I'll switch it when I get home.
    -Since there were various bugs with 1.30, I hurriedly updated it to 1.31 with a PCM cache test version, but I think that, operationally, this version should be better.

    Known Bugs
    -PCB versions ms5pcb and svcpcba have a SYSTEM ERROR and don't run. The cause is currently under investigation.
    MVS versions mslug5 and svc should work.
    (this hasn't been confirmed with 1.31, but it probably hasn't been fixed.)

    How To Use
    All previous cache files are broken, and you'll need to make new cache files. Please use the romcnv_mvs.exe(Ver.06) included with this file to create them. Also, due to the circumstances, I've stopped zip compressing the cache files.
    When you create the cache, a folder called gamename_cache will be created inside romcnv's cache folder. Same as before, copy this folder to MVSPSP's cache folder.

    State Of Development, Etc...
    -Concerning the topic on 2ch about whether to reconvert all ROM files or to just keep using them as-is, for various reasons it's set up so that current original ROMs and cache can also be used. I have no plans to change this setup in the future.
    -There's nowhere near the necessary amount of memory to decode and decrypt on the PSP. Also, the processing power is so low that it would take quite a while to decrypt, so a methoud to use ROMs as-is is impossible.
    -If all are converted, barring a change in the implementation, all would have to be uncompressed and the space used on the MS would increase.
    -I think that compressing only a portion of files after reconverting all of them would be pointless for the following reason.
    Approximately half of the games don't require cache, and cache files are only constructed for a portion of the remaining half, I probably just don't want to separate all the work (laugh)

    As Mr. 201 has written, and I'm sure that those who know are already doing this but, none of the sprite ROMs (c1.rom, etc...), PCM ROMs (v1.rom, etc...), and program ROMs (p1.rom, etc...) from the original ROM file are used after conversion so it's possible to delete them.
    The files that are ok to delete are the files that are displayed when the cache file is created.
    The reason I didn't write this is because I'd get mail saying things like "It doesn't work after deleting" or "please create a deletion tool". Also, please understand that the reason I don't delete these with the tool is because there are those that hate this.
    (Since the games you'll be playing are probably limited, I think it's not too much of a problem to just do this on your own...)

    Download and Give Feedback Via Comments ...
    by Published on October 15th, 2006 09:02

    True to his word, NJ has released the source code for his three arcade emulators: CPS1PSP, CPS2PSP, and NGEPSP. With the release of these sources, he also released the final version of CPS1PSP which includes a minor bugfix for a single game:
    Fixed state save/load in Pang!3
    Additionally, he has addressed speculations about what project he'll tackle next:
    With this, things have settled down for me. I don't think there will be anymore updates for the forseeable future.
    As for what I'll make next, maybe I'll port something else... However, it's more likely that I'll just end it with this.

    There aren't any (that I'm interested in) from overseas makers, SEGA, or CAPCOM.
    Source could be reused for SEGA, however, sadly, I have absolutely no interest in them, including their home consoles. Additionally, I started working on CPS1PSP without knowing about the impending release of Capcom Collection. It looks like there might not be any need to make anything else.
    Just my two cents, but since there still aren't any solid PCE-S/CD emulators for the PSP, and seeing as how NJ was able to nail NG-CD emulation, that's one project that I'd personally love to see him tackle.

    Download and Give Feedback Via Comments ...
    by Published on September 14th, 2006 12:20

    Have you forgotten about the CPS1 emulator with all of the excitement over the CPS2 emulator? Well, NJ certainly hasn't and he's been hard at work on his CPS1PSP emulator.
    -Change the drawing processes to ones similar to CPS2 to improve the speed by as much as possible.
    -Change the Z80 core.
    -Add state save/load: The state save feature is mainly to make the debugging process easier (I added it because I don't want to keep on playing until the same spot where a bug occurs over and over again), and I have given absolutely no consideration for compatibility with other emulators.
    -Anything else that I may happen to think of.

    Nothings been going the way I had planned. First of all, it's unstable. There's been lots of occasions where I haven't even been able to compile it. By adding the -G0 compile option it won't even run. Without it, there are games that won't run when using the same C68K as CPS2. It also looks like I won't be able to use CZ80. To make it compatible with kabuki encryption, I'd have to make quite a few changes to the source, but by making it compatible, I've got the feeling that it'll be even slower than MAME's Z80.
    This is about what the state of things is right now.

    It certainly is rough emulating YM2151 with the PSP's processing capabilities.
    I'm planning on ending development of this with the next release.
    Additionally, he has finally released the source code for the cache converters for the NEO GEO and CPS2 emulators, and it should now be much easier to port this tool to other platforms. For those interested:
    About the Source
    -I had absolutely no plans to release this, so there isn't even a single comment.
    -Because the it would be tedious to write the explanation, I haven't even written instructions on how to compile it.
    -The source code is so disorganized that I have declined to supply it when I have received requests for the source in order to port it. Frankly, (especially with CPS2) I don't think you'll be able to tell what's going on when looking at it.
    -Visual C++ 6.0 is necessary in order to compile it. If you fix the makefile you can compile it in versions later than 6.0. It would be necessary to rewrite the code under GCC.
    -zip32j.dll is used for the ZIP compression.
    -I won't reply to any questions related to the program, so please understand.
    The readme contains much of the same information, but with apologies for only using GCC for PSP applications, a note that he uses GNU MAKE, an appeal to do something about the zip32j.dll dependancy should it be ported, and finally, a comment that the source for the emulators proper needs to be cleaned up, but is forthcoming. ...
    by Published on September 11th, 2006 16:20

    Here's yet another quick release from everyone's favorite 90's era arcade emulator porter, NJ. He has now updated his CPS2PSP emulator to beta 2 in order to address some palette issues.
    What's Changed beta 2
    -Made a fix for a new problem that occurred in some games due to a change in the palette processing. There are no changes other than the palette. Even the state save data can be used exactly as it is from the beta version.
    Additionally, he added some new information for TIFF loader users:
    I forgot to add this to readme_cps2.txt, but when using this under the TIFF loader, please add the text below to the appropriate file. When added to the GTA loader, memory decreases so please don't add it to that version. If you already added this portion for text 5/beta, then all you need to do is change [CPS2PSP_3ccaece6] and the ebootname in the first line.
    The value in the first line can be determined through the EBOOT_signature.exe program that is included with eLoader 0.98.

    #************************************************* ************************#
    #* CAPCOM CPS2 Emulator for PSP beta 2 *#
    #* LOADER: 0.98 *#
    #* TIFF: 2.0 - YES : Only the small size games can be played. *#
    #* GTA: 2.0 - YES *#
    #* GTA: 2.01 - YES *#
    #* GTA: 2.5 - YES *#
    #* GTA: 2.6 - YES *#
    #************************************************* ************************#
    ebootname=CPS2PSP beta 2

    Download and Give Feedback and Compatability Reports Via Comments ...
    by Published on August 15th, 2006 09:02

    NJ has once again updated his CPS2 emulator, this time to test version 5. Quite a bit has changed in this version, so see the translated release notes from his site for the details:
    CAPCOM CPS2 Emulator for PSP (test ver.5)

    CAPCOM CPS2 Emulator test ver.5 binary Download

    Since I've pretty much finalized the cache file specification, I plan to make the next release an alpha version.

    What's Changed (test ver.5)

    There's quite a few things that have changed.
    Since I've made a few large changes, some new problems will probably crop up.
    If you're having problems, please use test 3 or test 4.

    -Changed the cache file specification. Since there isn't any compatibility with the cache files up until now, it'll be necessary to remake all of your cache files.
    Thanks to this change, Memory Stick reading for the games below only occurs when loading the game.
    ecofghtr / avsp / sfa / 19xx / megaman2 / qndream / spf2t / csclub / mpangj / pzloop2j

    -Due to development circumstances, I've implemented save state. Since I'm thinking that there will be frequent changes to the specification before this becomes the official version, basically you should assume that save state compatibility will be lost each time this is updated.

    -Fixed it so that it won't freeze on sleep.

    -Fixed it so that ssf2t is read as the parent cache file for ssf2t and it's clone sets.

    -Changed the palette processing. I'm now going to determine whether or not this works correctly.

    -Change the initial sound sample rate value to 22050Hz.

    -Rewrote the sprite management processing.
    Although only slightly, I think the speed of shooting and side-scrolling action games has either improved or stabilized.
    Conversely, for later, larger fighting games that frequently access the file , the speed has probably dropped. (The priority level for these types of games is very low, so I don't envision there will be any improvements from here on. Simply put, it's physically impossible to make them faster.)

    -Made huge changes to the sprite drawing process.
    Problems with the sprite mask drawing processing and priority in the following games has been fixed. (Even though I'm performing the drawing so as to not make the speed drop as much as possible, since the drawing is more complicated than usual, there are instances where the speed drops somewhat on such screens.)

    csclub: Spot process of CAPCOM's logo directly after loading

    ssf2t: Some of the character's continue screens

    dimahoo: The ninja Tatumaki's shadow as well as all of the ending

    gigawing: The Betting font, as well as all of the tanks and the BG's priority

    progear: The second form of the third stage boss

    ddsom: Stage 3-A on the heavy war cart where just the elf's sword and shield's priority is funny

    If drawing problems occur other than those mentioned above, I'd appreciate it if you could report them using the bug report uploader (As far as it's usage, please refer to the information at the link. This is being tested)
    Checking sprite data one by one'll make your shoulders stiff and your eyes hurt, it's just too tough.
    I'm not young anymore so this kind of work is hard on me.
    From here on, I'll just work on those that are reported, or so I say, but if I find any I'm just going to want to fix them.

    And, the portions of the readme that have changed:
    State of progress
    CPU: Finished
    Video: The sprite drawing process are still unfinished(?)
    Sound: Finished
    Input: The analog input in puzzloop2 is not supported yet

    Firstly, please regard the speed as something that's not going to get any better.
    The PSP simply doesn't have the ability (VRAM, memory, CPU processing power: all of them).
    Vampire Hunter and the likes is one thing, but in games like MVC where the screen changes that frequently, no matter how you think about it, speeding it up would be impossible.
    There is still a chance, however, that the sense of speed will slightly go up with VRAM partitioning and memory cache optimization.

    Download and Give Feedback Via Comments ...
    Page 1 of 2 12 LastLast