How to disassemble Pac-Man VR #11
Comments
|
Hi there, the instructions provided are for people who really like to do everything from scratch themselves - I guess that comes from being a developer, sorry about that :) Let's try to break it down and simplify:
How about you give this a try and report back. Note that I'm not a Windows user (only tested Wcdatool once on Windows a few years back), so you might need to fiddle around a bit more to get it running. Once you got things set up, check out issue #9 as that contains lots of additional information (especially regarding what to do with the output). |
|
Alright, so I did get it working, here's what I did: Installed open Watcom 2.0 from the precompiled version like you said, PATH didn't seem to work so I copied wdump.exe directly to the wcdatool folder. Since it wasn't working right at first with the exact terminal scripts you gave, I also copied wcdatool.py itself to the root folder, as well as the modules folder. Objdump was still giving me issues, further frustration with that as I eventually realized that the official GNU downloads were also only code that you needed to compile yourself, I spent hours trying to figure out how to do so, but to no avail. Then tried to look up how to compile the tools on Windows (yes I am using Windows,) and that eventually lead to discovering that a handful of compiled versions for Windows actually already exist, MinGW and tdm-gcc seem to be the main ones. I went with tdm-gcc as ==================================================================================== In case you were wondering, the game in question I was trying to take a look at is Virtuality's Pac-Man VR for the SU2000 system. I wanted to take a look at the code and have a comprehensible decompile in the hopes of it possibly aiding a port finally happening, whether that be through emulation, a direct port to modern systems, or if it came down to recreating it from scratch in Unity or something, I thought it could be an aid in figuring out how the actual gameplay worked on a fundamental level. If you were willing, I'd like some assistance in analyzing the actual code output. Either way, thank you for your help up to this point, and for responding so quickly. |
I'm always glad to help if someone asks nicely and is willing to put in some effort of his own (like you did and are) .
Wow, that's a very interesting (and rare/obscure) system. Never heard of it before, but from a quick glance at specs and details of that system it would seem that this will be quite a challenge (especially considering the custom-built, then high-end graphics cards). But then, reverse engineering almost always is... ;) Does the executable contain debug info/symbols? If so, Wcdatool can be a great help for your endeavor. If not, be sure to check if there are other versions/releases/revisions of the game's executable that could contain debug info.
I'll be glad to assist when and if I can (as I did in #9 for deevus). Feel free to post you findings and questions here. Please just don't expect me to answer swiftly as I don't have lots of free time at my disposal atm. |
|
Here's what I got out of wcdatool, you could take a look at it if you'd like: (link removed) A guy who managed to get his hands on the system actually did some documentation on the hardware a while back: http://www.arianchen.de/su2000/su2000.html this is the original forum post: https://www.mameworld.info/ubbthreads/showflat.php?Cat=&Number=309187&page=&view=&sb=5&o=&vc=1 The ROM can be found on Internet Archive which is how I got it in the first place: https://archive.org/details/pacman_202009 You can also find the original Technical Manual in various places online in PDF format. When it comes to debug symbols, I'm not sure if this is what we're looking for but you get some output like this when opening it in a normal text editor, with the legible text mixed in: |
Well my man, you struck gold! The executable does contain debug symbols. Check out these files for a formatted disassembly that makes use of those symbols (modules, function names, reference names etc.): Even better, make sure to check out The next step, if you want to keep going with Wcdatool and further refine the output, would be to map out memory regions within the code object(s) that contain data and memory regions within the data object(s) that contain code. Without this, the disassembly is likely flawed/incomplete (see |
|
Try the latest version of wcdatool attached to this message. Haven't gotten around to upload it yet. This version will reconstruct the folder structure of the original sources, which facilitates separating libraries from game code. Latest version: Resulting sources tree: |
|
Cool! Here's what I got out of it: (link removed) looking at the log file though, it seems the beta version actually has a lot more Misplaced item errors, unless it was me that messed something up. |
That's what it should look like.
That actually is a good thing, not a bad thing. The new version finds more code regions to process/analyze and therefore also produces more misplaced items. You see, those are not errors, they are warnings (hence the yellow lines on the command line). Each misplaced item indicates a region that currently seems flawed and requires your attention. Let's use an example from The misplaced item is Now, the Wcdatool also helps you out here: Now, create a hint file in subfolder Once done, run wcdatool again, now with additional command line option Now, the jump table is decoded as data and the 'misplaced item' comment is gone (because all items are now correctly aligned). So, that's the task ahead of you (and that is what I meant by saying 'mapping out memory regions' in an earlier comment). Note that this task is not always straightforward and the possible hints printed by wcdatool may not always be correct (it just tries its best to help you). So, try to wrap your head around the example and then try solving other 'misplaced items' regions yourself. The ultimate goal is to have NO misplaced items (or at least no important ones). |
|
You were right...this may be a much more daunting task than I thought. The problem is, I'm not actually much of a Programmer. I know how to use terminals, I know how to write/edit basic scripts...but nothing on this level. Regardless, I know it would be completely unfair to ask you to do all the work. I can still try using the log file as a reference, but I'm not sure how far I can get. Overall though, thank you very much for all your help, I never would've gotten to this point without it, and this is huge progress in general for this game's code to be restored to such a legible state. One question I have regarding the game's actual assets: how would you go about opening/converting the ASC model files to a usable state? I did some searching, tried to use MeshLab but to no avail, I know the other files are Lightwave Object and 3DS Max, but the ASC files remain the biggest challenge in extracting the actual assets. |
I noticed early on, when you talked about 'readable' sections and 'garbage' in between in your first comment... BUT: And just to clear that up:
If you were to ask, I'd have to decline anyway - I'm currently involved in several other projects and simply can't afford to spare the time. Also, although I certainly think this particular project is worthwhile, I myself don't have a strong personal connection to PacMan VR, which makes joining the effort less appealing to me.
You're welcome. Think about what I stated above, maybe you can find a way to continue this on your own or with the help of others.
Well, the Since we're talking about simple text files, it would also be possible to code/script a converter with ease. Maybe someone has done that already (highly likely as 3D Studio was THE 3D application back then). Or maybe importer plugins for modern 3D applications exist. Widen your online search accordingly. |
Ah, you're right, it's Studio not Max, the two are different. I actually did try to install 3D Studio in DOSBox recently but the install process doesn't seem to work correctly using DOSBox, I could maybe use PCem, but not sure. The 3DS and LWO files can be looked at and converted using some modern programs, it's just the ASC files that remain a challenge like I said before, and that's a problem since most of the models are in that format. Speaking of DOSBox, you actually can run the original PACMAN.EXE in it, but this is where it stops: |
|
And holy shit, just as I was writing the previous post I searched for the game on YouTube again, and found these: |
That is to be expected. It will take quite some time until this game can be emulated. Graphics card, controllers, VR headset are all custom-built.
I'd bet that this is running on original hardware. There is a white box visible above one of the monitors, that's probably the system that drives the arcade machine. Regarding the version, I also noticed that - versions below 1.0 are not common for production systems. On the other hand, no one beside arcade operators would ever see the version number, so it might actually have less relevance for arcade systems (just a guess). How about you try to get in touch with the author of that video? If you want, you can invite them here to this issue to talk about things, I wouldn't mind. |
I was thinking the controllers and headset output could somehow be handled by OpenXR, would that be possible if it was full emulation? If a Windows compatible executable COULD by some miracle be made, would OpenXR be feasible? As I previously mentioned the idea of, would there even be any feasible means to convert the calls for the PIX 1000 (though it's 2000 in the 0.69 code...was there a later card made?) to a modern GPU, or other means of rendering? Kind of just want to see the game itself load, even if it's not in VR. |
Well, from experience I'd say a realistic goal would be emulation (e.g. within MAME). Emulation runs the unmodified software in an environment that provides (emulates) the required hardware. First steps towards that goal have actually already been made (there are several Reddit posts discussing PAC-MAN VR and emulation within MAME). The thing you are talking about, i.e. creating a native application for newer OSes that either reproduces the original code or wraps it in a way that allows intercepting and translating calls to the custom-build hardware is also possible (the guys that ported Syndicate Wars went down that road). But, you are thinking light-years ahead here - it would already be quite an accomplishment to get the game running with stubs in place, i.e. just getting the text-based debug output (as shown on one of the monitors in that Youtube video) and the game logic to run without any graphics/sound output. |
So, you think I'm on the right track with what we've been attempting here? The wrapper idea I was also considering for the DOS version itself, not just source ports to modern systems, or somehow bypassing the calls for the GPU itself and rendering it another way. I've also considered just rebuilding the game from scratch in Unity, which has built-in VR even for standalone applications (Meta Quest 2 for example) which is why I want to do a complete extract of the Assets too, but as mentioned, those pesky ASC files are the only obstacle there. You can pretty easily look at the textures since they're all just Targa files. |
Certainly. No matter which approach you consider, understanding how the game and its hardware works is always the first step - and a good disassembly helps tremendously with that. Even if you'd choose to reimplement the whole game from scratch, you'd still need to analyze the game logic to get a decent approximation (e.g. enemy behavior). |
|
I did manage to get in contact with the author of those videos, this is what they had to say:
|
I'm curious, how did you manage to do that? There is no contact info given in those videos. Is there a Youtube feature that allows contacting authors that I don't know about? And, by the way, are you user 'Cr4z3d' on Youtube?
That's what I suspected.
They tried to modify MAME's disassembler from what I can tell. Never used it, maybe it's worth checking out. |
|
I created memory mappings for object 1 (save to subfolder Command line to make use of this: This greatly increases disassembly quality and reduces warnings to minimum. But, there's likely still lots of hidden data (hidden meaning not causing warnings) that needs to be mapped. |
|
By the way, just so you are aware: Pac-Man VR is not abandonware, some company acquired the rights and assets a couple of years ago. Thus, you should be careful regarding uploading/distributing any disassembly online. You better remove the Google Drive uploads you provided. |
I emailed them, if you go to the "about" page on a channel, it'll sometimes have a link to the user's email.
Yes, that's me, haha. Also lol @ the issue title change, though I suppose it's more fitting at this point...maybe I should've made a separate thread since the initial issue was solved, and I kind of derailed it into this. |
The situation regarding this is confusing...yes Virtuosity is the last known owner of the rights, but they basically seem to do nothing with the IP, and have essentially vanished into thin air. They even promised official ports of the original Virtuality games to modern systems themselves, but that was the last of that, and those ports essentially became Vaporware. If you do think there's an actual risk to the links, then I suppose I can take them down, but part of the whole idea behind this project was to potentially help anyone else who wants to work on emulation for it have a much better head start than years past. The situation is made more confusing by the fact that the ROM is freely available on the Internet Archive, but no legal complaint has yet been made. Regarding the su2000 branch I linked, these entries might be of particular significance? |
Good to know, thanks.
That's alright. This issue has actually developed quite nicely, I even linked it in the README to present it as an example use case.
I would take them down if I were you, better to be safe than sorry. Also, at this point anyone who is interested only needs wcdatool + hints file to generate the exact same disassembly for themselves. That is actually the reason why I created the tool in this fashion and with this feature.
That alone doesn't say much - the Internet Archive is full of copyrighted stuff, I always wondered why no one seems to bother. |
|
Alright...should I just email you privately about it in the future then? Thanks for the updated hints file. |
No, discussing it is perfectly fine. Quoting from it to. Just posting/uploading the whole thing is probably not a good idea the way I see it. I have generated the disassembly myself (couldn't have worked on the hints otherwise), so whenever you want to point out something, simply quote from it with visible offsets and I can look it up easily myself. |
Just a thought, but probably because, at heart, the IA is dedicated to the preservation of software, not really profiteering off of it. Plus the irony is that by doing so, if the companies themselves lost their own software, they could go to the Archive and retrieve it themselves, as one possible scenario. Preservation is the goal of my own project here, nothing malicious intended... |
That's true, could well be that other rules/laws apply to them because of this. |
You could ask if they would at least consider creating a proper dump of the game (hard disk + CD). From what I read on Reddit, the dumps available on the Internet Archive are incomplete and thus more or less useless. Also, we already know that the versions differ, so it would be great to get that (presumably later) revision. |
|
The only thing that seems to be "incomplete" is the lack of the music. I'm wondering if the way the files are laid out if the music was actually on a separate CD from the main game, or maybe it was Redbook audio which is notoriously difficult to convert properly to my understanding, but as far as I can tell all the files neccessary for running the game itself off the Hard Drive itself are present in the IA release. |
That may sound a bit harsh, but how would you know? You are neither a developer nor do you have any deep understanding of the system we're talking about. A MAME developer stated his view about the usefulness of the dump here: And even if the dump was complete (-music), the author of the Youtube video still has a different revision that doesn't seem to have been dumped thus far. Thus, my suggestion remains: if possible, ask them for a proper dump (and by that I mean REAL images, e.g. obtained by using dd and the like, i.e. sector-based copies of both HDD and CD). |
It is a bit harsh...but logical, you're not wrong.
I have tried to ask them through email, I'm awaiting a response. As for the assumption about the files, I suppose it's due to past experience with installing many DOS games, and being familiar with the usual file structure. To my eyes searching through the folders and all, everything that needs to be there to run the game shouild be there, but as you said, that's yet to be seen. There have been mentions of each game also having its own firmware, so you might be right... |
I was simply trying to make a point. See, the thing with PAC-MAN VR is that we're NOT talking about some DOS game, we're talking about a custom-built $100K-machine that is merely x86/DOS-based. As with arcade machines in general, you should assume that there might be all kinds of trickery involved as developers would utilize whatever means necessary to achieve their goals using the technology of the era. That whole assumption might still turn out wrong in the end, but I'd use it as a basis for the project until you can prove otherwise.
Excellent. A proper dump would already be a significant contribution towards preserving the game! |
|
I knew you were trying to make a point, and this wasn't just "some ol' DOS game." |
|
At least there is likely no copy protection in place - as a copy would've been useless without the specialized hardware back then, I doubt the developers bothered to implement any copy protection. |
|
True. |
|
Excellent news! Ariane got back to me, here's what they had to say:
|
That is good news, but:
A copy of their version of PacMan VR would be the most interesting at the moment of course.
Very interesting. So they have actually already been working on emulation of that system. Are they currently working on that or is this a description of work in the past? |
I checked myself and I think you might be right, but it does contain some other Virtuality games that have been completely lost to time up until this moment, which in itself is pretty exciting. The games in question being Boxing and Zone Hunter. The response when I asked Ariane about an actual disc image rip of their copy of Pac-Man VR was a bit confusing, here's what they had to say:
I think in the past, as they said in one of the previous emails that they're not currently working on SU2000 emulation. The last commit on the GitHub page is August 11, 2022. |
Nice. Too bad those too are not DOS4G(W) executables, wcdatool won't work on them. What about
Well, unless you are seeing different files on that server than me, there are two ZIP files containing ROM dumps and a single image file containing a hard disk image. No CD images and also no SU-3000 image. Maybe they thought they already uploaded those other images, but actually never did? |
Ah, as a matter of fact yes! it is. That one is Dactyl Nightmare 2: Race for the Eggs.
No, you're right, I see the exact same files you do. The CHDs mentioned may be the contents of the formatc and insidetrak ZIPs, the insidetrak files also have definite significance though as that was the card the machine had that handled the motion tracking data, the Polhemus InsideTrak. |
That might be the weirdest game title I've ever heard, right next to Attack of the Mutant Penguins on Atari Jaguar.
As I said, those ZIP files contain ROM dumps, i.e. dumps of the [E][P]ROM chips found on the extension cards (in other words: firmware). No CD images there. |
|
Here's the old promo video for it, lol: https://www.youtube.com/watch?v=jowtEbpVJrc as the 2 suggests, it was actually a sequel to the original Dactyl Nightmare, which could be seen as one of the earliest multiplayer FPS games. Funny thing, on the topic of remakes, there actually was a remake of the original Dactyl for Oculus Rift a while back called Polygon Nightmare, you can still get it from the Oculus store today (free though.) |
Interesting. The first one even predates Catacomb 3-D and already featured real 3D graphics. But, as always, the key to a successful game is the gameplay. One of the Youtube commentators sums it up like this:
That's probably the reason why Virtuality and its games quickly descended into obscurity. No doubt a considerable technical feat at the time, but apparently not an enjoyable experience. |
That and perhaps the ridiculous price some people recount for one round. The better model I think I've heard some places had was you basically paid ahead of time, like an admission fee, and the machines were on freeplay. This was I think exactly the case for the one amusement center that had a dedicated setup for Legend Quest, which is at the start of this video: https://www.youtube.com/watch?v=KKkZEXGaApE |
|
Any luck in obtaining the missing files from Ariane? |
|
No...I think they misunderstood what I was asking. They actually did tell me how to properly boot the su2000 emulation from the command line in their version of mame with the files included in the archive, but every time I try I get this error: |
|
Hey, do you have a Discord? I'm considering making a server for this project, comprised of people either interested or who have already contributed. |
|
No, I don't. Feel free to create one. |
|
Oh...ok. Was going to have you on-board as a consultant, as well as it being a much easier means of direct communication than this forum thread. |
|
Sure, why not. Sounds like a good idea. |
|
Also :) The entire maze is all there in the 3DS files, I learned that Blender 2.74 had an importer for 3DS, so used that. Weird that they took it out of later versions for some reason. |
|
Nice. Have you had any luck with opening the
|
|
Not directly...I did figure how how to basically just recreate the model from scratch by adding the matching number of vertices and then manually typing the coordinates for each in Blender. A friend from Discord had actually begun writing a script for importing them directly into Unity, and it gives a pretty good representation of the shape, but it's represented by multiple cube objects and not an actual mesh, not sure if they're going to continue it or not, need to ask. Also, through that experiment with the vertices in Blender, I confirmed what I had suspected about how the ghosts rendered...the 3D object for them was literally just a flat rectangle, they really were just the 2D sprites that you find in the assets, the body would just face directly at the player camera at all times, sort of like DOOM, and their face was rendered separately and would rotate around the body independently, facing where the ghost was facing in-game. Upon closer inspection of footage and screenshots, the pellets were also just sprites, though I can't seem to find which exact assets were the sprites in question... Did you ever make the Discord account? If you did you can tell me your User ID and I can add you to the group I made. |
|
Well, MilkShape 3D seems to work and is also able to export to various formats, have you tried that?
|
|
Ooh no, I hadn't even heard of MilkShape 3D, awesome! Added to the comment above, sorry late edit. |
Yeah, noticed that too when opening those
Oh, I see, that was misunderstanding. I thought you were asking if I had a Discord server that could be used for the project. A Discord account I already have. Just post the invite link here. |
Ohh ok, haha. One sec. |
So I have a non-MK app that I'm trying to decompile, I managed through IDA to identify that it was in fact compiled through Watcom. I've tried multiple softwares to try to decompile it into comprehensive code, but to no avail. Some lines ARE in fact clearly readable in other softwares, but there's a lot of garbage inbetween those sections, and I don't know how to clean that up. Did some searching and lo and behold, I found your project and was overjoyed that something was created specifically for Watcom applications, but I just can't for the life of me get it running, and the install instructions are incredibly confusing.
For example, you never specified where to put objdump. I tried to run your included BAT files for compiling Open Watcom 2.0 from source, but that didn't seem to work correctly either. I tried transferring the files I already had from a seperate installation of OW 1.9 from the official site, but that didn't seem to do anything either. Just would really like some clarification on how to actually install/use this, thanks.
The text was updated successfully, but these errors were encountered: