Let's Go Jungle Special

There is a video on YouTube titled 'Lets Go Jungle Special at home' where a man seems to be running LGJS in his home Lindbergh cabinet. He says he has modified it slightly to run on one screen so I know it can be done.

If I remeber well, playing it long time ago in Japan, Special version use uzis guns instead of pivot guns and 2 opposite screens with a charriot that turn back 180° one to the other. The 2 screens are just alive one at the time.

@nem Thank you for the lead, I've managed to get hold of the installation disk for this, and are waiting on the key chip.

Interested to see how the game controls the moving platform. It could either be done through the main JVS line, or through the COM ports like it does for games such as OR2 I've been told. I believe I'm right in thinking that it mainly runs JVS through the com ports for this, and so shouldn't be too hard.

I'll keep everyone updated as I make progress, as I think it would be nice if ALL the Lindbergh games where available.

Just if anyone is interested, I've managed to get Let's Go Jungle Special to run and will do a write up on interesting parts of the game later. Its got the biggest service menu I've ever seen, and about 15 different safety sensor inputs in JVS.

Let's Go Jungle Special : Post 1 ( Dummy files )
Disclaimer: I thought as I found interesting things out about this game I would post them here in different sections. I won't be posting how to get around the games security checks, or download links to the game as this is against the forums rules. I will also be referring to Let's Go Jungle Special by LGJS from now on to keep thing shorter.

After a lot of messing around in a HEX editor, I found some interesting things that might be useful in other games and these are 'dummy' files. The game software looks for various files placed in the games current directory, which are blank in content and start with '.dummy_'. These change the way the game functions according to what comes after the underscore. This is probably for development purposes, as each person working on LGJS likely didn't have an entire theater cabinet on their desk! I haven't done much more research on these dummy files, but I know they exist in Outrun 2 SP as well, however they are not as interesting.

The list below is of the dummy files the game checks for, and what I think they might do:

./dummy_spcabi - This may force the game to stop checking that the parts of the special cabinet (control board, dual screens) is available. However I'm not sure about this and the following paragraph explains why. LGJS reguarly checks if there are any errors, or issues that might cause danger to the person inside the cabinet. Things such as it not being able to talk to the seat control board, will stop the game functioning and display a message asking for the people inside the cabinet to stay seated and wait for an attendant to come and get them. As I don't have the seat control board (usually connected via a serial port) I always get this error when starting the game. To counter act this, I originally took out all the checks for the safety of the cabinet and allowed the game to continue running anyway. Bearing this is mind, there may be a dummy file that stops this error happening, but I haven't been able to check yet as my game is already modified to stop this error regardless.

./dummy_relimg - I have no idea what this does

./dummy_seri - The control board is connected via serial as explained above, and this probably emulates what the control board would be sending. I'm assuming this would go together with the ./dummy_spcabi file to make the game run stand alone without the checks for the control board.

./dummy_jvs - This probably emulates a JVS I/O board being plugged in, and so allows the game to start without an I/O.

./dummy_autoplay - This makes the game auto play itself. Once you press start, the game goes through the starting procedure itself and shoots at the spiders automatically.

./dummy_dispmatching - Not sure what this does. It might be the score you get to do with the couple in the games love for each other.

./dummy_disptime - Not sure what this does. Probably displays the time or something.

./dummy_debug_sound - Not sure what this does. Maybe it mixes the surround sound into just left and right?

./dummy_spiderjumpdebug - No idea what this does, but looks like it could be fun.

./dummy_dispseatcommand - Again not sure, but probably displays whats being sent to the seat.

Its worth noting that with the files containing the words 'disp' could be set to toggle information written out to the console, which has been turned off before the game is compiled compiled and so anything 'debug()' writes simply return from the function without writing anything out.

Haven’t been able to video much of LGJS for a while because I’ve been working on OpenJVS but have recently got a 7800GS so that the game runs at a better speed. The card was literally sent to me in an envolope and I’m very impressed it still works!

Only last problem I’ve got is that some of the audio when the people speak is out from the captions - not sure if anyone else has experienced this with any other games?

Thought I would put an interesting update on some findings that are probably known, but thought I'd write them anyway:1. Graphics Card Issues
Although its generally said online that for games such as Let's Go Jungle Standard you need the 7800GS card, I've found that it works fine on the 6800 card with only a minor bit of slowdown at some point.
For Let's Go Jungle Special however the game is unplayable due to slowdown without the 7800GS card, strangely though I can only access the test menu with the 6800 card, and just get a blank screen on the 7800GS.
I also cannot get the 2 monitors to output properly, as they would in the Let's Go Jungle Special game. The second monitor gets turned off before the game even starts, and the game never tries to switch monitors. On normal Lindbergh games the game is output to both monitors at the same time. Unsure quite how I would make the machine swap to the other monitor in the game, as it just sticks on the one monitor for now, maybe it had some sort of card that swapped the input rather than using 2 monitors? It could also be that the monitor swapping is based off a reading from the spinning chairs position, and seeing as I give no reading it doesn't swap!

1. Ram Size Matters
Probably the strangest thing I've found, is that when I run Let's Go Jungle Special with 1GB of ram it starts up and plays fine. If I put in 2GB of ram, the game goes into a 'Checking serial comunications...' screen and never completes from there. This suggests that maybe the full theater machine ran with 2GB of ram, and they used 1GB for dev and that's how it decides how to start up? I cannot actually get any output from the serial ports on the machine, but can see there are references to '/dev/tty0' in the code, and so it looks like there would have been some custom version of the Lindbergh CF that has /dev/tty0 populated. Outrun2SP which uses the serial protocol seems to manage to write to the Serial without the existence of the /dev/tty0 file, so it must do it in a different way.

Another thing I found is that when loading The House Of The Dead 4 with 2GB of ram, it loaded at least 3x as fast as normal, so a ram upgrade on the Lindbergh seems to be a really useful idea!

Below you can see a video of it running on my Lindbergh - currently the game runs, and is playable with the 7800GS graphics card. I've currently got a CF image and the game merged onto one hard disk, so the game plays without the need for a CF card.

The drawbacks are that the sound is slightly out of sync and it sometimes lags on the 7800GS. Note that you can only hear some of the sounds, as I've only got 1 of the surround channels plugged in. Funnily enough its the center channel, but whomever made the game decided that wasn't the channel they wanted the voice to come out of!

My goal for this game, is to make an emulator for the ride that the game fits into. This will allow me to run the game vanilla without any modifications. The game as it stands is heavily modified to get running, and I'm thinking this may be the cause of the slow downs and sound issues.

My main blocker at the moment, is that I cannot get any serial output to start debugging the communications with the ride. Unfortunately there aren't any manuals for this machine, and so I'm basing most of my knowledge off of the OR2SP manuals. I can see serial output from the OR2SP game, however there is no serial output from LGJS. Looking at the code I can see some references to a /dev/tty type device, however that isn't actually populated in the /dev folder before the game starts, and although it may create it during the game and delete it on finishing the game I'm highly doubtful. This leads me to think that possibly LGJSP has a special CF card, which has a version of linux with some extra /dev/tty modules - or that this is setup in the frontend file which I unfortunately don't have access to.

Edit:

I've just finished for tonight, but been searching through the code and think I've found what I've been looking for. There is a function that has an error message in that says "port must be 1 or 2", and then near that in memory are the 2 strings "/dev/ttyS1" and "/dev/ttyS0". I know they are not there when looking in /dev - so it looks like I'll have to create them myself and that might lead me closer to getting to the bottom of this.

Also as another interesting note the game references "/dev/input/js%d" which is the linux path for a joystick device. I'm wondering if this game actually supports joysticks for when they where developing it, or if the JVS software actually translates JVS to EVDEV to the game?

So, we've managed to get serial to work. Thanks very much to @doozer for helping, all I needed to do was symlink /dev/ttyS0 to /dev/tts/0 to make it work. It's strange that Let's Go Jungle Special doesn't do this itself, which leads me to believe that I might be using the wrong CF image, and finding the one it originally ran on may help fix my sound + lag issues.

I have a copy here of the code from the receive function in the class that deals with the ride board or LGJCbord as it likes to call it.

I'm trying to work out what I need to send back to get this to accept, but I'm having a bit of trouble making sense of it all!

Edit:

I think I've worked out the protocol from the code.

It must start with 0xC0 based on this line `if (*(int8_t *)(edx + ebx + 0x44) != 0xc0) goto loc_821f444;`

Although the code in the receive() function looks slightly different, the board is definitely sending the checksum strait after the 0xC0 character with the checksum being the exclusive bitwise or operation over all the next characters. I'm unsure if on the way back I should be sending the checksum at the end, as this is what the code here looks like?

I still haven't quite got it to work - I'm wondering if my baud rate etc. is wrong and I should be getting different numbers as the checksum that it seems to want doesn't seem to look like what I'm getting from the output.

This makes more sense as it has the 0xC0 that we can see in the receive function above. The checksum is the first digit after the 0xC0 and is the exclusive bitwise or operation over all the of rest of the 5 digits. I believe it's always fixed in length with 5 payload digits. I'm thinking the payload is maybe an 8bit command, and then 2 16 bit numbers?