Hey,

I attached a zip with new a RB build I did where I fixed a few audio related things (mostly noise channel related). There’s no huge changes, so you’re not likely to notice much of a difference, but I figured I’d post it anyway.

The other thing is… there’s also a build called reality_boy_rommap.exe . This build creates a file (or files) mapping out the ROM, determining which parts are code and data, and also code alignment. It does this by tagging all ROM accesses as either code (which means it was fetched by the processor to execute), or as data (meaning it was read with the load operation). While there may be some cases where this method doesn’t work, I don’t have any reason to believe any of the existing VB games do any of them, and this should at least be a good reference.

What I’m requesting is if you plan on playing a game in the emulator for a while, if you could use the _rommap version, and then zip/post to this thread the .map file that gets output, it’d give us a lot of information regarding the ROMs and save a lot of time for those of us looking to hack/modify/reverse engineer ROMs.

Since different parts of the ROMs get used depending on where you’re at in the game, that’s why I said if you plan on playing for a while, since just starting level one will only touch parts of the ROM related to the startup and first level. You can incrementally post them though, if you can start later in the game, like Wario Land or Teleroboxer… I can merge multiple files to get a master map (which is what I plan on doing anyway).

Also, for those looking to hack ROMs, you can use this by pressing T in the game to dump the current map to file and clear the map… then do whatever you want, like start a level, then hit T again to dump any accesses since the last T press. If you look at the file, it’ll be a file the same size as the ROM, full of 0’s, except the character D for data, I for instruction (first byte of the instruction), and C for code (rest of the instruction, tells whether it was 16 or 32 bits).

The location of the characters corresponds to the location in the ROM. So, if you want to know where the speech data in Red Alarm is, press T just before “T&E Soft Presents”, then press it again right after, and look at the .map that gets output and look for the cluster of D’s… it’s likely there. The .map file names get incremented each time you output a map (and it outputs a final one when you exit RB), though they’ll get overwritten if you run the same ROM in Reality Boy again.

You’ll also need the normal libraries that RB needs… if you have an existing version, you should be able to just drop it in the same directory… otherwise download RB, then drop these in the directory. Let me know if you have any problems w/ it.

BTW, I’ll post several utilities to use w/ the ROM maps in the next day or two (merge and mask).

DogP

Attachments:

1. rb.zip

DanB wrote:
I second e5frog. The anaglyph red/cyan mode doesn’t work anymore (“-dspmode affine -pallet rc”) It’s greenish/yellow/red inverted sort of. Did you change the command line parameters?

On mine, with the same parameters, I just get a monochrome, monoscopic image. 😕

I looked in the executable and it’s still using the same command-line options. Also, my front-end version is not using the same ones (I changed them in the front-end and in my copy of the RB source). I’m having compiler trouble in relation to a registry corruption, but I’ll build a new binary soon, if I can.

AFAIK I didn’t change any of that stuff. I’ll take a look though.

DogP

Oops… sorry, my fault 😉 . I forgot that I started to play around with the color patch idea a while ago, but never disabled it when I started messing around with the rest of the code. These builds should be fixed.

DogP

Attachments:

1. rb_pal_fix.zip

All of these crash on my Windows 7 system, for some reason.

DogP wrote:
Oops… sorry, my fault 😉 . I forgot that I started to play around with the color patch idea a while ago, but never disabled it when I started messing around with the rest of the code. These builds should be fixed.

DogP

Still grey palette when red palette is chosen.

… and when running affine mode they’re all red/blue no matter what palette is chosen.

Still grey palette when red palette is chosen.

… and when running affine mode they’re all red/blue no matter what palette is chosen.

It works as it should for me now… are you sure you’re using the right parameters?

I’m clicking the usual parameters in the front end, it works with the old version (that doesn’t need the Allegro dll).

Ah, I’m not using the frontend. I’ve made separate shortcut icons for every game that I use regularly, and manually put different parameters in them, like:

Target: “D:\…\reality_boy.exe C:\cygwin\home\Dan\yeti3d\bin\yeti3d.vb -dspmode affine -pallet rc -brite 1.5 -sclscr 2 -volume 64”

Then I just click on one on the desktop to run it.

RunnerPack wrote:
I looked in the executable and it’s still using the same command-line options. Also, my front-end version is not using the same ones (I changed them in the front-end and in my copy of the RB source). I’m having compiler trouble in relation to a registry corruption, but I’ll build a new binary soon, if I can.

I’ve built a new binary, but I had to install VC6 to do it, so it probably won’t work for most people. Here it is anyway, just in case.

I suggest doing what Dan did, or associating VB files in the registry, like I mentioned before.

DaVince wrote:
All of these crash on my Windows 7 system, for some reason.

Has anyone else tried this on Windows 7 (or Vista)? Did it work/not work? I’ll try to test it on my friend’s Windows 7 box, but I’m not sure when I’ll be able to.

DaVince: Was there any error message, or did it just crash. I assume you’ve got the allegro dll referenced earlier in the thread?

DogP

It doesn’t play nice with Windows 7 Desktop Composition. I don’t know if that’s an easy fix or not, but many emulators have these problems it seems…
Runs fine, maps working as well.

cYa,

Tauwasser

I’m using Windows 7 RC 64-bit, no problems.

The balance and brightness settings in both front ends (tried old front with old version and new front end with new version) seems to do nothing… How come? The real VB is a little more purple in my opinion compared to the bright red I get in emulation, would be nice if the balance settings worked.

Did you try setting the command-line parameters manually? Make sure to look at the actual “usage” output of the emulator, to see what it’s actually expecting (although this text can get out of sync with the parameter parser, depending on what DogP has been experimenting with).

It could be either the front-end or the emulator (or both?) causing the problem, so it’s important to figure out which needs to be fixed.

EDIT: Actually, I just tried this and there is no usage information anymore… But, I did look at the strings in the exe, and it’s at least looking for the “brite” and “balance” switches (which are what all versions of the front-end are using) so I guess the problem is in the emu.

I noticed the balance settings only seem to affect the affine mode (or anaglyph as it’s called in the new front end). I guess the “redscale” is fixed and can’t be adjusted with those settings.

[DaVince]

DogP wrote:

DaVince wrote:
All of these crash on my Windows 7 system, for some reason.

Has anyone else tried this on Windows 7 (or Vista)? Did it work/not work? I’ll try to test it on my friend’s Windows 7 box, but I’m not sure when I’ll be able to.

DaVince: Was there any error message, or did it just crash. I assume you’ve got the allegro dll referenced earlier in the thread?

DogP

Yup, and it just crashed. Standard Windows “send error report” window popped up.

It doesn’t play nice with Windows 7 Desktop Composition. I don’t know if that’s an easy fix or not, but many emulators have these problems it seems…

Well, with the original version Windows just tells me that display compositing was disabled automatically while the app is running. But this version flat-out crashes.

I can run in a terminal if it gives me any extra output… Or perhaps there’s a parameter or special version you could compile that logs everything that happens into a file?

@RunnerPack: you’re right, I should test it through the commandline too… But the frontend is just so damn convenient! :rolleyes

EDIT: Well! Seems like the emulator would run just fine when run from the commandline. The frontend’s just a frontend, what could be so wrong in the way it calls the emulator? Perhaps some arguments the emu can’t handle properly, like (as suggested) the color correction flags?

• This reply was modified 14 years, 10 months ago by DaVince.

[RunnerPack]

DaVince wrote:
Well! Seems like the emulator would run just fine when run from the commandline. The frontend’s just a frontend, what could be so wrong in the way it calls the emulator? Perhaps some arguments the emu can’t handle properly, like (as suggested) the color correction flags?

Maybe there are some side-effects of ShellExecute()? The only thing I found with a quick search was related to multi-threading, which the FE doesn’t use.

Looks like the FE needs a new maintainer with access to a Vista/7 machine… (and removing the MFC dependency wouldn’t hurt, but I hope it doesn’t succumb to “.NET’s disease” :-P)

Another option would be to change the front-end into a “command-line maker” that just generates a command-line that can be used in a file association or Shortcut.

• This reply was modified 14 years, 10 months ago by RunnerPack.
• This reply was modified 14 years, 10 months ago by RunnerPack.

I wouldn’t mind creating a little Python-powered front-end (including a proper, standalone EXE version of course), but I’d need to know the commandline flags, and the emulator binaries seem to lack a –help (or similar) option to list those.

(I can’t edit my posts anymore, strange…)

I might have found the problem… Dragging the test1.vb ROM onto the executable works just fine, but when I drag-and-drop the Virtual Boy Wario Land ROM from a different folder onto it, it crashes… This might be an absolute path/relative path problem, I guess? Because running the same ROM using a relative path on the commandline DOES work…

There could be a file name length issue… IIRC, the files are referenced by a 255 byte string, so if you’ve got a really long path, it may hit the limit. And I’m not sure why it doesn’t output command arguments (I haven’t looked at the code yet), but the debug version does output it (reality_boyD.exe). I can’t say that all the arguments are verified to be correct, but I don’t know that any are wrong.

DogP