What's new
Maybe we can decompile the imageView.class
I'm able to view the file in my web browser by using 192.168.29.100/imageView.class. I have attached the file. A lot of it seems viewable in ASCII, but there are a lot of characters that don't display properly and I'm not sure if they're just Japanese characters that aren't rendering properly in my text editor or if they're something else.
You can't "read" this with a classic editor since it's compiled Java.
In practice, I was unabled to uncompile your file since it has html header and is not recognized as a valid java class by the decompiler. I will look for some hex/bin editing.
Not sure about the way you used to download this class file but I think the better is to right-clic->download with your browser when viewing the html source of hsview.htm

network: Connecting http://192.168.29.100/img.jpg with proxy=DIRECT

It could be that since the camera is broken, it's not generating a usable jpeg for this stream and maybe this would be working otherwise.

Edit: I can also load 192.168.29.100/img.jpg in my browser, but it's just blank. Perhaps this is the URL for a single still generated at the time the page is loaded?
I agree : this static image should be for web preview only. The fact that it's blank is probably bad news for the cam itself.

Sorry if I'm breaking open door : I don't know how high are you knownledges of html and embeded Java Applet
 
I have a decent understanding of HTML (I mess with it a lot for work), but almost no knowledge of Java applets. I've started out on my other arcade projects with almost no knowledge, though, so we'll see how far I can get.

I'll see if I can find a different way to download the class file.
 
I have a decent understanding of HTML (I mess with it a lot for work), but almost no knowledge of Java applets. I've started out on my other arcade projects with almost no knowledge, though, so we'll see how far I can get.

I'll see if I can find a different way to download the class file.
sure you can ;)
 
Would you be able to capture the http requests the board is sending to the camera to obtain a picture?

192.168.29.100/imgview.htm is something you would expect from the game board as well.
I totally missed your post. I didn't analyze the communications that closely, but I mostly saw a lot of pinging between the camera and the game. Since the communication ultimately fails, it eventually drops out. I also can't be sure that I'm seeing everything. I'm using the hub that came with OR2SP and am not sure if it's doing what you said switches tend to do when they try to be smart and isolate communication between established connections. It's possible I'm only seeing the more generic pings and broadcasts of addresses. I figure since I don't yet have a working setup for getting an image displayed in the game, I'm better off waiting to do the analysis once I have everything working. I don't want to go too far into analyzing what is ultimately resulting in errors.
 
Ok, I think I have the class files downloaded without the html tags. Previously my browsers were just opening them directly and then a save-as ended up parsing html tags onto them.

There's imageView.class and hsView.class. These are the 2 different class files for what I guess are a normal stream and what google translate calls a high speed stream.

Edit: I just tried my hand at the first Java decompiler I came across in google (jd-gui) and it seems to open imageView.class without any issues. :thumbsup:

I don't know if I have much time to get into it today, but I wonder how possible it would be to change this up to "stream" a static image file and get that loaded into Mario Kart... :D

My guess is that Mario Kart is accessing one of these class files to stream the images and/or possibly just image.jpg. I don't believe I've ever seen a working camera on a MK, so not sure if it live streams while capturing or if it's a lot more laggy like it's just pulling still frames at a relatively slow rate.
 

Attachments

  • Mario Kart Camera -applet class files.zip
    6.3 KB · Views: 96
Last edited:
In the Mario Kart GP 1 rom file I do see this...

GET /img.jpg HTTP/1.0

hmm....

If my theory is true that ip/img.jpg is simply an image generated on an ad-hoc basis and served whenever accessed, then things potentially get a lot easier.

What are the chances it's as simple as hosting an image at the expected ip address/img.jpg?

This java business may be a dead end.
 
good job.

here are the 2 java class.

Fast analysis :
HSView just read the img.jpg file and attach it to a thread
ImageView is a little more complexe. I'm not used to these "image stuff" in java but as far as I can understand, it creates an image.

I need more time to conclude anything.
 

Attachments

  • 20180425 cam.zip
    3.6 KB · Views: 52
If my theory is true that ip/img.jpg is simply an image generated on an ad-hoc basis and served whenever accessed, then things potentially get a lot easier.

What are the chances it's as simple as hosting an image at the expected ip address/img.jpg?
Easy test to make. You may give a try.

Just wondering about the JVS connection.
 
IT WORKS!!!!! IT WORKS!!!!!!!!!!!!!!!!!!!!!!!!!!

I set up an apache server on my RPi and posted a test image that's apparently in the rom file per this page: https://tcrf.net/Mario_Kart_Arcade_GP

I used the color test one, and set the server's IP to 192.168.29.105 and set the game to board ID 2 (so it gets set to .151 and expects a camera at .105).

In camera test, I see this!

mkagp camera test.jpg

I think this means that the simple solution is to be to get a webcam going on the RPi, set up some kind of program that posts a jpg from the camera to img.jpg at some regular interval. Then the apache server just serves it up when called. GPIO could theoretically be used to set IP of the RPi the same way it's done on the stock board, but that can come later.

I think I have a path forward!
 
Last edited:
So the simple test I just ran is plugging in a super old and terrible web cam into the RPi and using a program called fswebcam, I can enter a command to save a capture to img.jpg that is hosted by the apache server.

This is a webcam I had originally tried to get working with OctoPi for my 3d printer, but couldn't get a live a stream from it. It would generate stills, so it works for this test.

Here are details on fswebcam: https://www.raspberrypi.org/documentation/usage/webcams/

The Mario Kart camera test seems to be updating the image as soon as it's posted, so it appears that it is probably refreshing the image at some regular interval.

This will be pretty easy to take to the next step and ultimately a working solution!
 
I don't currently have controls wired up to get Mario Kart to actually start a game from my test bench and I don't have time to test it in the cab today, but on the bench I can pass the camera test at boot and get the game booted into attract mode.

I assume it's going work in-game and simply display whatever is hosted at: ip/img.jpg

Whatever method is used to update img.jpg is basically inconsequential. Any number of solutions could be put in place to make that happen.

The RPi3 seems to handle both of the usb webcams I have natively, so I'm going to probably go that route. I'm not sure what the most cost-effective solution would be. Arduino would probably be another potential route, but I'm not at all familiar with setting up web servers on Arduino (there are probably plenty of tutorials and examples) and it will probably require some kind of additional ethernet shield.

RPi method needs:
-camera
-power suppy (or adapter for in-cab power)
-RPi (probably 3 since it has hard-wired ethernet port and regular USB ports - Pi-zero needs all kinds of adapters and has always been off-putting to me because of that)

I figure buying parts new for this sole purpose can be done for under $100 (and I already have everything on hand). The RPi could probably be made dual purpose for those who use one for netbooting.

We'll see. I'll get something worked up over the coming days, but I've spent too much time on it today! :D
 
I went ahead and ordered the parts needed for a single camera alternative unit for MKAGP1/2 and got the total in at $75.30.

This includes a dedicated 2.5A 5V PSU, Rasberry Pi Model 3B, pack of 5-foot ethernet cables, an RPi camera (I want to experiment with the dedicated camera), and a 32GB micro SD card. Those who use a single motherboard and netboot source with just a cross-over cable may have to invest in a switch/hub/router to use with this if adding it as a 3rd networked component.

I would imagine there may be a need for a few extra supplies to get this finalized and installed in a cab. Perhaps a connector adapter if trying to make use of wiring that is in a stock Mario Kart cab.

I'm not working from a stock cab, and may ultimately not consider stock wiring in my solution, but one factor to keep in mind is that the stock camera board is only getting 3.3v. There is no 5v or 12v going to it. I'm not sure if there are options for running a RPi with 3.3v, but I'm planning to run mine with 5v (not sure whether I'll use a dedicated PSU or wire into the JVS PSU). Maybe if you're trying to adapt stock wiring, switch the 3.3v wire to 5v wherever it starts.

The first cab I'll be trying to fit this to is a WMMT cab, so I'll have to figure out a decent, non-destructive, and good-looking way to mount the camera to this cab. My end solution may involve a 3D-printed shroud.

We'll see what happens. I still need to prove that my theory holds up in-game, but at this point I'm pretty sure it will.
 
I actually was able to get a game to start on the bench. Touching analog input pins with my hand apparently fluctuates them enough sometimes to register. I'm happy to report that the game boots and the camera works in game!

At the moment, I've got an apache server running on an RPi and the root directory is set to a ramdisk. This means images that are being written and served at ip/img.jpg are in RAM instead of ruining an SD card with tons of writes. I put together a super simple shell script that stores an image read from the camera and then a python script that runs this shell script repeatedly. It's most likely slower than the refresh rate that the game is using, but it seems like it will work well enough. There may be more efficient and faster ways to post the jpegs, but I'm not sure how much I will mess with that. The camera for this game is not for video, it's for taking a still photo and it gives you plenty of time to position yourself correctly when taking the photo, so the laggy input shouldn't be too big of a deal.

Sorry if anyone wants more pictures, but I'm not going to post photos of myself! :P

I'll continue to document my progress I as I work towards a final built-in solution for my cabs, but I think the proof of concept is complete! :thumbsup:

I'll also eventually document how to set up the RPi from scratch, but I wanted to experiment with an RPi camera in addition to the USB webcams I have, so stay tuned.
 
Nice and neat job ;)
Big thanks to you! The java route didn't end up being the answer, but it did lead to the discovery of img.jpg, so I think it was a necessary step in this quest, and I thank you for the suggestions and help. This is one reason I like to publicly document my progress in projects like this, because there are always others out there who know more than I do and offer to help.
 
I briefly experimented with the Pi Camera and think I actually like it and the method for using it better. There are some commands for this camera natively in the RPI os, and it's possible to set it up for time-lapse and it ends up posting images quicker than I was getting with the USB Webcam route, though I didn't test any time-lapse functionality of the program I was using for those.

One reason I like the Pi Camera better is that it's smaller and will be easier to do what I want with a 3d printed shroud.

This camera was only $15 and is plenty good enough for this task. The DIY instructions that I end up sharing are going to be for these cameras.

Also, I received a stock camera from @jlazaris today and he was nice enough to include the shroud, so I can use this for reference when making a 3d printed shroud. I can also use this camera to get an idea of how the stock camera performs, just because I'm curious.
 
Nice to read you figured it out. Now you might try to figure out how fast the original camera was refreshing it's jpg pictures.
You probably already know the size of those jpg's.
Their file size could be interesting as well to know the approx. compression level and quality setting it uses.

If you ever intend to create a read only root fs for your raspberry pi, I might be able to help with that.
Basically, a read only root fs doesn't write to the sd card.
It's biggest advantage is that the sd card doesn't become corrupt if you simply cut the power.

My setup uses a ramdisk overlay on the file system so that you actually are still allowed to write stuff.
It just will be gone upon the next reboot.
 
The DIY instructions that I end up sharing are going to be for these cameras

Great !
WIth python save (card) script, just lacking forcefeedback and I'll can use totally MK2 in my OR2 twin!

If the same RPi can handle save and camera, it would be amazing.
 
I briefly tried the stock camera board and I notice that the game during test mode refreshes pretty quickly and the camera does pretty well in low light.

I can get similar speed from the picamera by running it from python, but I haven't figured out a good balance between good low light performance and speed to match the stock hardware. At worst the speed will have to be sacrificed for a better image. This wouldn't be too bad, though, since you're really only using the live feed to position yourself for a static photo (from what I can tell).
 
Back
Top