You can use any file you want so long as it is large enough. The trick simply uses a large dummy file to ensure that the nuon.cd file gets pushed away from the inner tracks. You can use any size you want, but anything over 40 megs is probably overkill. Obviously smaller files take less time to burn, so its advantageous to determine the minimum size file that can be used and still obtain working discs.
I didn't discover this trick, and there are several people that swear by it, so it should work in almost all cases. From my own experimentation, a 15 meg file should be sufficient.
Does it matter what type of file I use as my dummy file (ie: a Word Document or Excel file)?
Riff wrote:You can use any file you want so long as it is large enough. The trick simply uses a large dummy file to ensure that the nuon.cd file gets pushed away from the inner tracks. You can use any size you want, but anything over 40 megs is probably overkill. Obviously smaller files take less time to burn, so its advantageous to determine the minimum size file that can be used and still obtain working discs.
I didn't discover this trick, and there are several people that swear by it, so it should work in almost all cases. From my own experimentation, a 15 meg file should be sufficient.
Does it matter what type of file I use as my dummy file (ie: a Word Document or Excel file)?
Well, I tried the dummy file trick last night per your advice and it does appear to be successful on the 3 programs I burned. I tried 3 different CD-R (IBM, Imation and some cheap PNY brand) and all worked successfully on first try!
Nuance is based on NuonEm, so the compatibility is about equal. I tested all of the SDK examples in Nuance and the only ones that don't work also did not work in NuonEm. The emulator was also ported to use the Qt GUI library and also switched from BCB5 to VC7. Remarkably, many programs, especially those based on libsprite, run twice as fast or more as they did in NuonEm. So even though Nuance doesn't have dynamic recompiling support at this time, its already a good upgrade from NuonEm.
None of the commercial games are playable yet, mostly because I haven't implemented the BIOS media calls that will allow them to read in a nuon.dat data file. I don't know if IS3 will ever be playable due to the heavy use of MPEG2 video. It depends on libmovie and/or the "presentation engine" code. If it uses the special purpose VLD registers to stream the video, there is absolutely no chance of it being playable, although it might be possible to rig something up to skip the video playback. If the video files are simply MPEG macroblocks with no compression, the emulator would be able to handle that.
Riff wrote:
None of the commercial games are playable yet, mostly because I haven't implemented the BIOS media calls that will allow them to read in a nuon.dat data file. I don't know if IS3 will ever be playable due to the heavy use of MPEG2 video. It depends on libmovie and/or the "presentation engine" code. If it uses the special purpose VLD registers to stream the video, there is absolutely no chance of it being playable, although it might be possible to rig something up to skip the video playback. If the video files are simply MPEG macroblocks with no compression, the emulator would be able to handle that.
Interesting! So I guess Freefall 2050AD would need such workarounds as well since it has some MPEG2 video segments.
I'll download and give the new emulator a try. Keep up the great work!
I have all the games, but I haven't played Freefall yet. Ballistic may never be playable either, if only for the fact that the DVD doesn't show any files on it! This may be a simple dual-directory file protection scheme which is easily circumvented. If not, it will be the only game not able to be emulated simply due to the fact that I cant load the files
I do, suspect, however, that none of the commercial games do anything funky with the undocumented control registers. As long as they all use the same versions of the presentation engine and other libraries, it will be possible to detect jumps, branches and calls to library routines by checking for specific addresses at packet decode time. The emulator can use a native call interface handler to implement the routines to bypass emulation altogether. This is already done for the BIOS routines. The difference there is that linkable libraries are going to require header or auxillary files defining base addresses and lengths for determining if a given instruction address references a native library call implementation. Additionally, the use of different versions of a library might require finer grain address checks. The benefits would be enormous in some situations such as having a native libsprite implementation or floating point library implementation. Even having a native integer division implementation would speed up many programs.
