Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Arjin wrote:
Found my old disk, and ripped it. Got as far as an Object in invalid state for operation error.
That's emulator core itself crashing for some reason. It may be easy or it may be hard to fix. If you can reproduce it, save a stack trace (there's button for it in error message box) and post it as it actually shows what and where did go wrong (so I have even remote chance of fixing the problem).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Quietust wrote:
The fact that JPC-RR movies require a byte-for-byte match on the hard disk image (and have no option to say "I don't care if it doesn't match, play the movie anyways") would seem to be a bit of an annoyance...
If its movie and not a savestate, you can edit the image ID in initialization section to match what you have (no need to edit that imageinfo stuff, emulator won't read it anyway). I have done this few times, usually with bad results (desync due to wrong "ROM")...
This trick doesn't work with savestates (unless you force emulator to load it as movie file) and you really want to have byte-to-byte identical image when loading one as otherwise all bets are off when emulator blindly patches it with copy-on-write sectors from savestate.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Aqfaq wrote:
henke37 wrote:
Did you load the FPU module as instructed above?
Oh, thanks, forgot to test that, but after testing, still not working. I also tested it with your altdos floppy image, but the error message is always the same.
Runtime error 200 is divide by zero. Errors due to missing FPU usually show up as endless loop of trying to use FPU messages with rapidly incrementing numbers or as exception 7 (DEVICE_UNAVAILABLE or some such) error.
This error is almost definitely CPU emulation error. Unfortunately that sort of emulation errors are usually real nasty to debug. Very probably secondary damage.
There's the infamous Turbo Pascal delay bug, but I don't think default clock rate of 20MHz is enough to trigger it...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
Phallosvogel wrote:
What about frame advance?
The default keys have the following bindings:
3 -> Enable pause on vretrace starting ("enable frame advance")
4 -> Disable pause on vretrace starting (disable frame advance")
5 -> Start/resume execution
6 -> pause execution
The first two can also be set from breakpoints menu. Note that these bindings are only valid when correct window (JPC-RR) is focused.
Phallosvogel wrote:
Savestats?
In addition to the functions bound by default to (shift+)Fx keys, one can save/load named snapshot (Snapshot -> save -> snapshot)/(Snapshot -> load -> snapshot). I usually do that at beginning and at end of stage and after any difficult section. It is also useful for gaining access to backups of savestate slots.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1142)
Joined: 5/1/2010
Posts: 1217
BadPotato wrote:
I just tried to run some linux live-CD and it crash, because there were no FPU module according to the log console.
That would likely be just one of the problems. I have tried to get Linux to boot and failed. I guess the CPU emulator just isn't good enough for that.
BadPotato wrote:
Could you tell us where we can find the list of "string" for all avaible module that can be loaded? If there some missing, where can I download them?
I'm aware of following modules (all come with JPC-RR r10.x):
If you want multiple use comma (,) between module names.
BadPotato wrote:
I can see the raw output with frameshow, but I can't figure out how I can capture this into a video format.
I usually use something like:
rawtorgb capture.dump capture.rgb lanczos2 640 400 16666667
This reads capture.dump, outputting raw RGBx data to capture.rgb using lanczos with alpha=2 to resize frames if needed (to 640x400) with frame rate of (as close as possible) 60fps.
At least mencoder and ffmpeg can take raw RGBx as input and convert those to other formats (such as raw yuv420p, which in turn can be fed to x264).
The usual resolution indeed is 640x400 because of pixel doubling and doublescanning the usual 320x200 resolution. Note that some games (e.g. God of Thunder) might use other resolutions and then one has to figure out what it is and what is the proper resolution.
For sounds there is rawtoaudio2 (try 'rawtoaudio2 --help', it shows the options).
