nullPointer

Hi JCGamer, You might try changing your Advanced Config setting. I'd try [Mapping Off] Exit (Process Close) first to see if that takes care of the issue. [Mapping Off] Exit (Alt+F4) is another possibility, but it will depend on whether MagicEngine has an in-built key combination that allows you to immediately exit the emulator. I'm currently away from my emulation rig so I can't remember all of the default Advanced Config choices, but don't be afraid to experiment . If nothing works, I'll be home later at which point I may be able to provide a bit more feedback.

I'm inclined to agree, but I do think you'd find even a 7inch screen to be a vast improvement over the smaller screen of an iPod. With a 7 inch screen you can view a single full page with good readability and still maintain an acceptable level of artwork detail (to my eye at least). The only time the 7 inch screen is a bit of an issue is when you encounter a full 2 page layout. Even then ComicRack features super smooth scrolling around the full layout (as well as pinch zooming) so it's not a huge deal, but more of a temporary inconvenience. All the same I understand the 'purist mentality' and if you're determined to stick with traditional formats then more power to you! All those local comic shops could certainly use the patronage! I think I'm just at a point in my life in which convenience and portability have taken precedence over being hardcore in terms of my comic reading habits (i.e. I don't have to worry about moving / managing / protecting a huge physical collection ... but I'm also obviously more of a casual reader at this point than a hardcore collector) Now if you bumped up to a 10inch screen ... well at that rate it basically is like reading a full sized comic (albeit at a higher cost and less mobility than a smaller tablet).

@Adultery: Godspeed my good man! So glad to hear you got it working z-man! It can be very hard to spot the difference of one character when you’re troubleshooting issues like these, particularly when you’re already fried. I think that particular issue has come back to bite us all a time or two! The main thing is that it seems to be working well now. I’m also glad to hear that JCGamer has experienced some success with Ootake. I’ve never used Ootake, but I’ve heard good things. I’d have to take a look at his config to see what’s happening with his command, but if he’s passing the ROM name and path directly to Ootake it might be parsing the command differently and thus “allowing” spaces in the directory path. Sorry, now we’re getting our wires crossed. MagicEngine does require the use of a SCSI drive. Adultery and I were talking about native support in GameEx for DaemonTools. GameEx defaults to a virtual DT drive when you run the [VIRTUALDRIVE] command, thus the potential need for a plugin. Clear as mud? Happy gaming guys!

Just a couple of quick thoughts: It's been awhile since I've looked at a runitgame.bat which utilized the [VIRTUALDRIVE] command. It would be worth while to check that out to see whether it uses the mount DT flag. If it does, that flag would need to be overwritten with mount scsi. If [VIRTUALDRIVE] runs some alternate command it may be necessary to overwrite the entire command. (although I'm pretty sure there aren't that many options for mounting DaemonTools Lite from the command line) Probably want to notify the user that they'll need to install a virtual SCSI drive in order for the mount scsi thing to work. Seems like a no-brainer, but you never can tell ... It would be awesome if you could run this verification programmatically. I think you can run sommething to the effect of the following to make this happen DTLite.exe -get_count scsi Future enhancement idea: Roll in support for DaemonTools Pro since the executable is named differently (and maybe some of the commands too?). This is something I don't think even GameEx supports natively ATM.So just a few snowball ideas there. Sorry man, I didn't mean to imply that this is something you should jump on immediately! For that matter I've been know to sling a line of code or two myself. Maybe this is something I could attempt as well. In all actuality both of us may be kidding ourselves as I'm pretty sure we're both currently swamped with IRL stuff. Any hoo, I'd be happy to assist in this endeavor in any way. Thanks Adultery!

@JCGamer and z-man: Please refer to what I posted here, as I think it will help you to overcome your current set of obsticles It's the virtual SCSI factor at play again. If you have a virtual DT drive installed the [VIRTUALDRIVE] command will default to that one rather then using the SCSI drive. Some emulators (such as ePSXe and MagicEngine to my knowledge) require the use of a SCSI drive which has something to do with the way they read sub-channel data. All of this leads to discussions like this one. Various users have reported successfully mounting images to SCSI drives using the [VIRTUALDRIVE] command if they only have one DaemonTools drive installed and it's a virtual SCSI ... but even then an equal number have reported that this doesn't work for them (FWIW I'm in the group that this has worked for). Not sure what the determining factor for success is there, but it seems to be something of a pattern. I suppose it might also work if you had multiple DaemonTools drives all of which were virtual SCSI but I've not tested out that particular scenario. What complicates matters is that DaemonTools is installed as a virtual DT drive by default. So you need to remove the default DT drive(s) and add a virtual SCSI drive for the [VIRTUALDRIVE] command to even have a shot of working on those emulators requiring a SCSI drive. So this typically leads to an ... interesting ... troubleshooting discussion. I typically just go for the "Launch Before / Launch After discussion" rather than have the users start mucking about with their DaemonTools drives. Hmm ... out of curiosity is there any way a plugin could intercept the [VIRTUALDRIVE] command and inject the "mount scsi" flag as necessary? Just a thought.

Hi z-man and welcome to the GameEx forums! I’m glad to hear that you and JCGamer are working on this together. Nothing like a little team work to get a problem solved! The main thing I was hoping would be accomplished sounds like it was successful. You guys were able to get that image mounted to DaemonTools via the command line alone. That’s good. At this point the devil is in the details. Let’s break this down. This was the command you successfully ran via the command console: dtlite.exe -mount scsi, 0, "C:\zFiles\Games\ROMS\TurboGrafx\Buster Bros. [CD][TGXCD1031][Capcom][1993][PCE][terryn].cue" And this is the ineffectual command configured in GameEx: C:\Program Files\DAEMON Tools Lite\DTLite.exe" -mount scsi, 0, "[ROMPATH]\[ROMFILE]” Do you notice the difference? It’s subtle, but in the first command you navigated to the DaemonTools directory before running the command. In the second one you’re specifying the full DaemonTools directory path in the command. More to the point that directory has spaces in it. So in order for that command to be successful you’ll need to completely enclose the directory path with quotation marks. Try this on for size: LaunchBefore = "C:\Program Files\DAEMON Tools Lite\DTLite.exe" -mount scsi, 0, "[ROMPATH]\[ROMFILE]" If that works, you'll also want to fix this: LaunchAfter = "C:\Program Files\DAEMON Tools Lite\DTLite.exe" -unmount scsi, 0 (you don't really need to unmount_all, and capitalizing SCSI may or may not cause an issue) Now, those may have been a typos in your post, but those commands appear the same way a few times in the information you posted which leads me to believe that they are configured that way in GameEx too. Hard to tell without looking at your GameEx.ini or Emulator config. OK so the “[ROMPATH/ROMFILE]” thing. In GameEx ROMPATH is a place holder for … wait for it … your ROM path . Whatever you entered for your ROM path will be substituted for the place holder value when you run the command. Likewise the ROMFILE setting is a placeholder for the ROM file being launched including the file extension. So “[ROMPATH]\[ROMFILE]” becomes "C:\zFiles\Games\ROMS\TurboGrafx\Buster Bros. [CD][TGXCD1031][Capcom][1993][PCE][terryn].cue" where ROM Path = C:\zFiles\Games\ROMS\TurboGrafx And Selected ROM = Buster Bros. [CD][TGXCD1031][Capcom][1993][PCE][terryn].cue If you ever need to verify the exact commands that GameEx is running to launch a game you can look at your runitgame.bat as seen in the How to Ask For Help thread, or spelled out in its entirety right here: One way to troubleshoot a problem is to add the word "Pause" at the end of the Runitgame.bat file. When Windows asks "Do you want to save the changes..." Click on "Save". Next, double click on the "Run Last Game" Icon in the Start Menu. This will send the commands again, but the command window will remain open. It may show an error that will help you to understand what is wrong. If you get this error: 'Emulator name.exe' is not recognized as an internal or external command, operable program or batch file. It means that either you have the incorrect name specified for your Emulator.exe, or your working path is incorrect. If it gives an error that you don't understand, please let us know that you tried this method, and let us know what the error is. If you’ve got something running outside of GameEx via the command line but it’s not working within GameEx, comparing the runitgame.bat to your known working commands is a great place to start. Keep us posted on how this is going for you. If things still aren't working as anticipated, I'd request that you repost your emulator config (the one that you export from the setup wizard), as well as a copy of your runitgame.bat after experiencing the problem, since it seems like there have been a number of changes to the previously posted settings. Thanks fellas.

Gamepimp is exactly on the money here. Separate directories will likely be your best option. If you find yourself in a position in which mixed ROM directories are the only option, you would likely need to use map files to keep your various game lists clean in GameEx. There are several resources and quality tools available for creating map files if you decide to have a go. Adultery's Map File Maker (freshly updated!) Tempest's Map File Magician fRequEnCy's Map Files

Fantastic job Adultery! Keep up the great work.

You've been busy there Adultery! Fantastic job. I can't wait to check out the new enhancements particularly that control panel viewer. If I could hit the Like button several times for this I would.

Hi Ptinov Does this happen for all games or just select ones? It's likely that the games behaving in this fashion will need a custom config. We've been fairly decent about creating configs for some of the popular games, but since Steam has such a vast library of games it's nigh impossible to account for every game. This can get a bit technical, but it's not terribly complex. Verify that the problematic games run GameOverlayUI.exe when they're launched (this is the ingame overlay typically accessed with the tab key). Most Steam games do, but there are a handful that don't. I think you also need to enable this in your Steam settings (Steam > Settings > In-Game > Enable Steam Community In Game). If the game doesn't launch the overlay process it will need a custom config. The configs are stored in media\steam\configs in your GameEx directory and are created when you launch the game. You will need to set the overidewaitprocess setting to something else, most likely to the game executable itself.Hopefully that answer is descriptive enough. I can expound on that a bit more if necessary, but that's the nuts and bolts of it. Remember to back up your files before making edits. Hopefully this should put you on the right track.

OK ... the important thing is to stay calm and take it one step at a time. Let's not get ahead of ourselves here. Remember we're taking baby steps. We're not trying to run a game yet. We're not even going to start the emulator. All we're trying to do is mount a disc image via the command line. 1. Verify that you have DaemonTools configured correctly. You'll want to make sure you have a virtual SCSI drive installed. When you open up your dashboard for DaemonTools (from the system tray in the lower right corner of your screen), it should look something like this: Some things to note: you'll notice I have a DT drive and a SCSI drive here. The DT drive was part of the default DaemonTools installation. I had to manually add the SCSI drive. I've highlighted the button used for adding a SCSI drive in the event that you need to do so. 2. OK so far so good? Let's mount a disc from the command line. Not GameEx. Not the emulator. Let's fire up our command window. Here you can see that I've run a series of bad commands and one good one. Let's talk about these in detail. 1. In the first command I've typed in an invalid DaemonTools directory. You can see that Windows didn't like that at all, since it said The System cannot find the path specified. 2. In the second command I botched the ROM directory. You'll notice that Windows didn't care one iota about the invalid disc image directory. That's because DaemonTools is in charge of the command at that point. It would be great if DaemonTools had an error message here, but it doesn't. Deal with it. I can tell that the command was ineffective because when I open up my Daemon Tools dashboard it still looks like the first image above [sCSI-0] (H:) No Media 3. In the third command I tried to mount an invalid disc image (INVALID DISC.txt). This has the same result as the second command. [sCSI-0] (H:) No Media 4. Finally for the last command I ran it correctly. Now when I look at my DaemonTools dashboard I can see that my image has been mounted. Success! For the record here's the 'good' command I ran: "C:\Program Files (x86)\DAEMON Tools Lite\DTLite.exe" -mount scsi, 0, "E:\Emulation\Roms\Sony_PlayStation[RE]\ePSXe\Final Fantasy VII (USA) (Disc 1)\Final Fantasy VII (USA) (Disc 1).cue" So at this point, that's all I want you to do. If we can't even get a disc image mounted from the command line, I can't in good conscience recommend a different emulator since we'll have the exact same problem. So let's see if we can get that far, then we'll go from there. If we get can get that done then we'll move on to Lesson 2: Unmounting the Image. Are you excited? I can tell you're excited. Good luck man.

I think the first question you should ask yourself is whether you would want to go with an e-ink reader (like the standard Nooks and Kindles), or whether you want to go all in for a color screen albeit without the super-crisp resolution of the e-ink models (as in some sort of tablet). Personally I went with a less expensive Android tablet so I could get a color screen, but my wife and my mom both love their e-ink Kindles. I can definitely see the advantages of e-ink as it’s really easy on the eyes and you cannot beat the battery life. But … here’s the thing. I noticed in your recent post that you’re a comic book reader? That’s part of the whole reason I went in for the color screen. My favorite desktop e-comic reader ComicRack has an absolutely kick-ass Android version of the app (I sprung for the paid version). I can’t tell you how sweet it is to carry around a fully indexed library of comic books that remembers everything I’ve read, everything I plan to read, where I left off reading, and can be synchronized wirelessly with the e-comic collection on my desktop machine. Add in all the other Android goodness (like being able to take an emulation capable device with me when I travel on business), and it’s a winning combination. Android tablets can be slightly more expensive when compared with e-ink readers, but in several cases it’s a difference of about $50.00 USD or so. If you’re huge into reading regular ol’ standard books it’s certainly worthwhile to check out the e-ink readers, but if I were to make a humble recommendation I’d go the Android route.

Well played Mr. Solo ... but riddle me this: What is the air-speed velocity of an unladen swallow? Also from one Aaron to another, please let me congratulate you on having a kick ass name my good sir.

Oh snap! I thought he was referring to an error message in the command window! It didn't even occur to me that he was referring to the Verify Setup text. Good call Bigby! @JCGamer: yeah don’t worry too much about that Verify Setup screen. When I run verify setup the output is flooded with red lines. It doesn’t necessarily mean anything is broken. Once you start getting ‘creative’ with your settings the Verify Setup screen just doesn't know how to handle it. I’d recommend verifying your setup by running the emulators themselves. If everything works then it must not be broken!

I think it’s great that you’re fighting the good fight and pitching in to help your community LC. You take care of what’s truly important, and we’ll be here when you stop by for a visit. Don’t forget to keep us posted on your impending nuptials as the date draws near! We want to hear all about the big event!

First thing to try: Change “[RomPath]\[RomFile]” to “[ROMPATH]\[ROMFILE]”. Not sure it will make a difference, but normally those parameters are in all caps. Next thing to try: have you tried mounting an image directly from the command line using the DaemonTools command? (nevermind Gameex for the moment). If you’re testing from the command line you’ll need to replace the [ROMPATH]\[ROMFILE] parameter with the actual path to one of your disc images (i.e. “C:\MyRoms\TG16CD\MyGame.cue”). Does that work? If that command doesn’t work directly from the command line there’s either a problem with your DT executable path, a problem with your ROM path, or a problem with your DaemonTools drive (like maybe it’s not finding a SCSI drive). If you can get the mounting command working directly from the command line, then you’ll also want to verify that the unmount command works directly from the command line. Let’s try and focus on the component pieces here before we get back to talking about GameEx.

The good news is that is you’ve got it running outside of GameEx with DaemonTools, that’s already one huge step out of the way. So um … those Launch Before and Launch After parameters are empty right now? We gotta whip those suckers into shape! So try this: Command: Verify that the -cd: parameter points at the letter of your DaemonTools drive LaunchBefore: Verify that the DaemonTools executable path matches the executable path for your DaemonTools installation. Verify that you’re running a virtual SCSI drive in DaemonTools (when you install DaemonTools, the default drive type is a virtual DT drive. That’s not what you want here. If you don't have a virtual SCSI, you'll want to add a SCSI drive through DaemonTools) LaunchAfter: Same verifications as the LaunchBefore Good luck man

The only thing I worry about with Mednafen is that it might just compound you’re issue. Mednafen isn’t exactly known for being very user friendly. It’s a command line only emulator. It has no GUI. (Apparently it does have some third party GUI tools, but I’ve never used them). So I’m extremely hesitant to recommend Mednafen since it’s very dependent upon how comfortable you feel running emulators from the command line. If your controller is recognized by Windows then you can use it within Mednafen, although there again it’s not exactly the most user friendly process. You hit a function key, and onscreen prompts walk you through each configurable button. If you screw up one button you can't go back; you have to reconfigure every button all over again. TBH my recommendation would be to just stick with MagicEngine. In this case I think it’s better to deal with the problem you know about than the one you don’t. Just my 2p. Have you got it running outside of GameEx yet? What’s your GameEx config looking like at this point? (or if you want to be a super cool guy you can post your emulator config for only this emulator using the setup wizard. Follow Step 1 right here, )

So just a couple of things then. First you’ll want to verify that that MagicEngine is working outside of GameEx from a disc image mounted on your virtual drive. If you can test this via the command line (rather than the GUI), that would be ideal. After you’ve got everything working outside of GameEx you’ll want to fix your GameEx settings. Currently your GameEx settings are wrong and will not work for mounting disc images in DaemonTools. Please refer to this post in order to correct your GameEx settings.Bing bang boom. Done. I’m afraid I can’t speak too much to much about the internal configuration of MagicEngine, as I use Mednaen. And even then it’s been a while since I configured Mednafen.

No, what I’m saying is that I pulled that line directly from the config you posted, and it won’t work under any circumstances: If that doesn’t match what you’re settings actually are, please export your emulator config, and I’ll take another look. In the mean time, please refer to the linked post and attempt to duplicate those settings as closely as possible. So just to verify - you've installed DaemonTools Lite correct?

I’d like to take this opportunity to let it be known that in my opinion the logo for the Famicom Disc System is the absolute pinnacle of game console logo design. Simple, whimsical, and it never fails to catch the eye. If I could take one console logo with me on a desert island, that would be the one. Great job doing it justice KRC!

Hi JCGamer, I'm still taking a look at your settings, but the first thing you should know is that this is not a valid internal command in GameEx for mounting the virtual drive: [-VIRTUALDRIVE-] and [VIRTUALDRIVE]:\ are the only valid virtual drive commands in GameEx that I’m aware of. You’ll notice that you can’t specify a SCSI drive with either of those. If you need to use a virtual SCSI drive you’ll want to go old school and revert to Launch Before parameters used in conjunction with Launch After. I’d take a closer look at this post and duplicate the contents there to the closest possible extent. Good luck man.

Bang up job on these KRC. I was always a fan of the original set, so I’m glad you’re revisiting the concept. Well done!

Hi rabidpuppy! I can honestly say that I've never had any problems running any emulators under Windows t 64 bit. I suspect that if there are any emulators that don't cooperate well under Win7 that they are either so terribly out of date as to be not relevant, or have been surpassed by more modern emulators. It's hard to say without knowing what you plan on running, but I'm relatively certain you'd be safe with this upgrade. Hardware might be the bigger determining factor here. You said this was for your cabinet? You might want to verify that you're not running any hardware that relies on XP drivers (in the event that they've not been updated for Win7) Let us know what you decide!

Just remember to enjoy the journey and you'll do just fine.