Open DuggletMcNugglet opened 1 year ago
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:
For OpenWatcom, the simplest way is to download precompiled binaries (no need to build from sources). Download and extract/install to a directory of your choice.
Both objdump
(part of binutils) and wdump
(part of OpenWatcom) need to be accessible via PATH. Run the following commands in Windows Terminal or a Linux console (and then KEEP GOING within that same session for the following steps):
Linux: export PATH=$PATH:<path-to-objdump>:<path-to-OpenWatcom>/binl64
Windows: set PATH=%PATH%;<path-to-objdump>;<path-to-OpenWatcom>/binnt64
Once set, simply running objdump
or wdump
should yield something, otherwise PATH was not specified correctly.
Clone my repository:
git clone https://github.com/fonic/wcdatool.git
Then change directory to the top of the repo, i.e. cd wcdatool
, and stay there for the following steps
Copy your executable to repo's subfolder Executables
On Linux, run one of the convenience scripts provided in subfolder Scripts
or run the following command:
python Wcdatool/wcdatool.py -od Output Executables/<name-of-executable>
On Windows, run the following command:
python Wcdatool\wcdatool.py -od Output Executables\<name-of-executable>
Output generated by Wcdatool will be stored in subfolder Output
.
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 https://github.com/fonic/wcdatool/issues/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 the installation is easy and the version of binutils seems to be the most up to date, binutils 2.36.1.
====================================================================================
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.
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) .
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.
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.
If you were willing, I'd like some assistance in analyzing the actual code output.
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:
Here's what I got out of wcdatool, you could take a look at it if you'd like: https://drive.google.com/file/d/1zh-A6ofnhoXCWK_pCrEEMQ8VNB-rrOGj/view?usp=share_link 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.):
PACMAN.exe_disasm_object_X_disassembly_formatted.txt
Even better, make sure to check out PACMAN.exe_modules
which contains the same disassembly, but nicely split into the original source files that were originally used to build the game.
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 ; misplaced item
comments). As wcdatool performs a static code analysis, there are limits to what it can detect automatically.
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: wcdatool.zip
Resulting sources tree:
PACMAN.EXE_modules
├── C
│ ├── PACMAN
│ │ └── c
│ │ ├── attract.c.asm
│ │ ├── awe.c.asm
│ │ ├── cd.c.asm
│ │ ├── clock.c.asm
│ │ ├── disp.c.asm
│ │ ├── file.c.asm
│ │ ├── game.c.asm
│ │ ├── gauge.c.asm
│ │ ├── gfx.c.asm
│ │ ├── ghost.c.asm
│ │ ├── main.c.asm
│ │ ├── matrix.c.asm
│ │ ├── message.c.asm
│ │ ├── path.c.asm
│ │ ├── player.c.asm
│ │ ├── process.c.asm
│ │ ├── score.c.asm
│ │ └── tga.c.asm
│ └── PROJECTS
│ └── LIBRAR~1
│ ├── CD
│ │ └── c
│ │ ├── cddate.cpp.asm
│ │ └── newcd.cpp.asm
│ ├── CTRL
│ │ └── c
│ │ ├── ctrl.cpp.asm
│ │ ├── ctrldate.cpp.asm
│ │ ├── ctrli.cpp.asm
│ │ ├── fcard.cpp.asm
│ │ ├── fcardsnd.cpp.asm
│ │ ├── fcardtim.cpp.asm
│ │ ├── mmc.cpp.asm
│ │ ├── mmccode.cpp.asm
│ │ ├── mmcsnd.cpp.asm
│ │ └── timer.cpp.asm
│ ├── EXP
│ │ └── c
│ │ ├── credit.cpp.asm
│ │ ├── exp.cpp.asm
│ │ ├── expdate.cpp.asm
│ │ ├── screen.cpp.asm
│ │ └── volume.cpp.asm
│ ├── MISC
│ │ └── c
│ │ ├── file.cpp.asm
│ │ ├── file3.cpp.asm
│ │ └── vel.cpp.asm
│ ├── MOUSE
│ │ └── c
│ │ └── mouse.cpp.asm
│ ├── OS
│ │ └── c
│ │ ├── dososi.cpp.asm
│ │ ├── os.cpp.asm
│ │ ├── osdpmi.cpp.asm
│ │ └── ospci.cpp.asm
│ └── TRACKER
│ └── c
│ ├── inside.cpp.asm
│ ├── notrk.cpp.asm
│ ├── spacepad.cpp.asm
│ ├── trk.cpp.asm
│ ├── trkdate.cpp.asm
│ └── trki.cpp.asm
├── D
│ └── PROJECTS
│ └── PIX2000
│ ├── c
│ │ ├── pix.cpp.asm
│ │ ├── pixbin.cpp.asm
│ │ ├── pixbin1.cpp.asm
│ │ ├── pixbin2.cpp.asm
│ │ ├── pixbin3.cpp.asm
│ │ ├── pixbin4.cpp.asm
│ │ ├── pixbin5.cpp.asm
│ │ ├── pixbuf.cpp.asm
│ │ ├── pixcoff.cpp.asm
│ │ ├── pixconf.cpp.asm
│ │ ├── pixicoff.cpp.asm
│ │ ├── pixlight.cpp.asm
│ │ ├── pixmain.cpp.asm
│ │ ├── pixmater.cpp.asm
│ │ ├── pixmath.cpp.asm
│ │ ├── pixmem.cpp.asm
│ │ ├── pixmodel.cpp.asm
│ │ ├── pixppc.cpp.asm
│ │ ├── pixprim.cpp.asm
│ │ ├── pixrnder.cpp.asm
│ │ ├── pixtex.cpp.asm
│ │ ├── pixvideo.cpp.asm
│ │ ├── pixview.cpp.asm
│ │ └── pixwin.cpp.asm
│ └── libc
│ ├── 3dsread.cpp.asm
│ ├── ascread.cpp.asm
│ ├── dpmi.cpp.asm
│ ├── lworead.cpp.asm
│ ├── memory.cpp.asm
│ ├── pci.cpp.asm
│ └── rtgread.cpp.asm
├── V
│ └── TXT
│ └── c
│ └── txtprint.c.asm
├── embed.c.asm
├── hardware.c.asm
├── library.asm
├── midieng.c.asm
├── midivar.c.asm
├── nrpn.c.asm
├── nrpnvar.c.asm
├── s
│ └── txt.asm
├── sbkload.c.asm
├── sfhelp1.c.asm
├── sfhelp2.c.asm
├── sysex.c.asm
└── wavload.c.asm
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.
Cool! Here's what I got out of it: https://drive.google.com/file/d/129RnevMscDYWiLAWm_ESSmnvoJLsj29i/view?usp=share_link
That's what it should look like.
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 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 PACMAN.EXE_disasm_object_1_disassembly_formatted.asm
:
SendMidi_reference_7: ; access size: DWORDS
19a6c: 10 99 01 00 46 99 adc BYTE PTR [ecx-0x66b9ffff],bl ; fixup: num: 4563, src obj: 1, src ofs: 0x19a6c, dst obj: 1, dst ofs: 0x19910; fixup: num: 4562, src obj: 1, src ofs: 0x19a70, dst obj: 1, dst ofs: 0x19946
19a72: 01 00 add DWORD PTR [eax],eax
19a74: 7c 99 jl 0x19a0f ; fixup: num: 4561, src obj: 1, src ofs: 0x19a74, dst obj: 1, dst ofs: 0x1997c
19a76: 01 00 add DWORD PTR [eax],eax
19a78: b2 99 mov dl,0x99 ; fixup: num: 4560, src obj: 1, src ofs: 0x19a78, dst obj: 1, dst ofs: 0x199b2
19a7a: 01 00 add DWORD PTR [eax],eax
19a7c: e8 99 01 00 11 call 0x11019c1a ; fixup: num: 4559, src obj: 1, src ofs: 0x19a7c, dst obj: 1, dst ofs: 0x199e8; fixup: num: 4558, src obj: 1, src ofs: 0x19a80, dst obj: 1, dst ofs: 0x19a11
19a81: 9a 01 00 8b 45 fc 83 call 0x83fc:0x458b0001
; misplaced item, should be at offset 0x19a84
SendMidi_branch_2:
19a88: e8 08 89 45 f8 call _GRF4DivZero_branch_2
19a8d: 83 7d f8 05 cmp DWORD PTR [ebp-0x8],0x5
19a91: 77 a4 ja SendMidi_branch_1
19a93: 8b 45 f8 mov eax,DWORD PTR [ebp-0x8]
19a96: c1 e0 02 shl eax,0x2
19a99: 2e ff a0 6c 9a 01 00 jmp DWORD PTR cs:[eax+@obj1:SendMidi_reference_7] ; fixup: num: 4557, src obj: 1, src ofs: 0x19a9c, dst obj: 1, dst ofs: 0x19a6c
The misplaced item is SendMidi_branch_2
, and it is misplaced because it should actually start earlier, but the spot is occupied in part by the call 0x83fc:0x458b0001
instruction.
Now, the jmp
instruction at 0x19a99 tells us that the 'stuff' below SendMidi_reference_7
at 0x19a6c is actually not code, but data (list of pointers, also called 'jump table'). Wcdatool has no way of knowing this. This is due to the fact that code objects may contain data and vice versa. A computer (specifically a CPU) does not care about the distinction code vs. data, all it sees is raw data that it processes more or less blindly.
Wcdatool also helps you out here:
Possible object hints for code objects:
Object 1:
...
x) start = 00019A6CH, end = 00019A84H, type = data, mode = dwords, comment = DWORDS
...
Now, create a hint file in subfolder Hints
named exactly PACMAN.EXE.txt
and add the hint above that instructs wcdatool to interpret the specified range as data. For the hint file syntax, see one of the example files for Mortal Kombat. A minimum hint file looks like this:
Object Hints
==============================================================================
Object 1:
100) start = 00019A6CH, end = 00019A84H, type = data, mode = dwords, comment = Jump table
Once done, run wcdatool again, now with additional command line option -wao Hints\PACMAN.EXE.txt
. If everything has been done correctly, the example region in PACMAN.EXE_disasm_object_1_disassembly_formatted.asm
will now have changed:
;-------------------------------------------------
; Hint 100 (data, dwords, 24 bytes): -
; Jump Table -
;-------------------------------------------------
SendMidi_reference_7: ; access size: DWORDS
19a6c: 10 99 01 00 dd @obj1:SendMidi_reference_1 ; fixup: num: 4563, src obj: 1, src ofs: 0x19a6c, dst obj: 1, dst ofs: 0x19910
19a70: 46 99 01 00 dd @obj1:SendMidi_reference_2 ; fixup: num: 4562, src obj: 1, src ofs: 0x19a70, dst obj: 1, dst ofs: 0x19946
19a74: 7c 99 01 00 dd @obj1:SendMidi_reference_3 ; fixup: num: 4561, src obj: 1, src ofs: 0x19a74, dst obj: 1, dst ofs: 0x1997c
19a78: b2 99 01 00 dd @obj1:SendMidi_reference_4 ; fixup: num: 4560, src obj: 1, src ofs: 0x19a78, dst obj: 1, dst ofs: 0x199b2
19a7c: e8 99 01 00 dd @obj1:SendMidi_reference_5 ; fixup: num: 4559, src obj: 1, src ofs: 0x19a7c, dst obj: 1, dst ofs: 0x199e8
19a80: 11 9a 01 00 dd @obj1:SendMidi_reference_6 ; fixup: num: 4558, src obj: 1, src ofs: 0x19a80, dst obj: 1, dst ofs: 0x19a11
;-------------------------------------------------
; End of hint 100 -
;-------------------------------------------------
SendMidi_branch_2:
19a84: 8b 45 fc mov eax,DWORD PTR [ebp-0x4]
19a87: 83 e8 08 sub eax,0x8
19a8a: 89 45 f8 mov DWORD PTR [ebp-0x8],eax
19a8d: 83 7d f8 05 cmp DWORD PTR [ebp-0x8],0x5
19a91: 77 a4 ja SendMidi_branch_1
19a93: 8b 45 f8 mov eax,DWORD PTR [ebp-0x8]
19a96: c1 e0 02 shl eax,0x2
19a99: 2e ff a0 6c 9a 01 00 jmp DWORD PTR cs:[eax+@obj1:SendMidi_reference_7] ; fixup: num: 4557, src obj: 1, src ofs: 0x19a9c, dst obj: 1, dst ofs: 0x19a6c
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.
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.
I noticed early on, when you talked about 'readable' sections and 'garbage' in between in your first comment...
BUT: It is certainly possible to learn the skills necessary to continue this project. Just depends on how much time and effort you are willing to put into this. You could also try to find other people who might be interested in joining you, so that you can split the workload and learn form each other. Reverse engineering sure is a daunting task, but it is NOT an impossible one.
And just to clear that up: The readable sections are most likely strings that appear somewhere within the game (e.g. output lines for the command line, items in the options menu, etc.), the 'garbage' in between is code/data in its natural raw form (this is what wcdatool decodes).
Regardless, I know it would be completely unfair to ask you to do all the work.
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.
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.
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.
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.
Well, the .ASC
files are in ASCII format and everything points to 3D Studio as the application those assets were created with (note that there are also .3DS
files). I even worked with 3D Studio myself in the 90s for some time. If current versions are unable to open those files, try using a version from the same time period as the game (1996). For example, you could use a VM or DOSBOX to run 3D Studio for DOS.
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.
Well, the .ASC files are in ASCII format and everything points to 3D Studio as the application those assets were created with (note that there are also .3DS files). I even worked with 3D Studio myself in the 90s for some time. If current versions are unable to open those files, try using a version from the same time period as the game (1996). For example, you could use a VM or DOSBOX to run 3D Studio for DOS.
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:
the PIX error is referring to the custom graphics card, as you previously mentioned. Part of what I was wondering with this whole thing is if there would be some way to do something like rewrite the relevant sections to make the game just render off the CPU itself, or something like OpenGL, just to be able to boot the game itself in DOSBox.
And holy shit, just as I was writing the previous post I searched for the game on YouTube again, and found these: https://www.youtube.com/watch?v=ShSOvyDC73c https://www.youtube.com/watch?v=ShSOvyDC73c I'm not sure, but this appears to be running on the original hardware. One thing I noticed is that the version number is v01.01.00. The one you can get from the Internet Archive is v00.00.69, which makes me wonder if it's actually a prerelase version.
Speaking of DOSBox, you actually can run the original PACMAN.EXE in it, but this is where it stops: [image]. The PIX error is referring to the custom graphics card, as you previously mentioned. Part of what I was wondering with this whole thing is if there would be some way to do something like rewrite the relevant sections to make the game just render off the CPU itself, or something like OpenGL, just to be able to boot the game itself in DOSBox.
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.
And holy shit, just as I was writing the previous post I searched for the game on YouTube again, and found these: https://www.youtube.com/watch?v=ShSOvyDC73c I'm not sure, but this appears to be running on the original hardware. One thing I noticed is that the version number is v01.01.00. The one you can get from the Internet Archive is v00.00.69, which makes me wonder if it's actually a prerelase version.
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.
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 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.
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.
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).
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.
So, you think I'm on the right track with what we've been attempting here?
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:
It is running on original hardware. However, good luck on emulation the game. You might take a look at [https://github.com/SailorSat/cabmame/tree/su2000] At the moment, I don't actively work on anything SU2000 related.
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?
It is running on original hardware.
That's what I suspected.
However, good luck on emulation the game. You might take a look at [https://github.com/SailorSat/cabmame/tree/su2000]
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 Hints
):
PACMAN.EXE.txt
Command line to make use of this:
python Wcdatool\wcdatool.py -od Output -wao Hints\PACMAN.EXE.txt Executables\PACMAN.EXE
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'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?
I emailed them, if you go to the "about" page on a channel, it'll sometimes have a link to the user's email.
And, by the way, are you user 'Cr4z3d' on Youtube?
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.
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.
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?
I emailed them, if you go to the "about" page on a channel, it'll sometimes have a link to the user's email.
Good to know, thanks.
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.
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.
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.
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.
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.
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.
Alright...should I just email you privately about it in the future then?
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.
That alone doesn't say much - the Internet Archive is full of copyrighted stuff, I always wondered why no one seems to bother.
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 alone doesn't say much - the Internet Archive is full of copyrighted stuff, I always wondered why no one seems to bother.
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.
I did manage to get in contact with the author of those videos, this is what they had to say:
It is running on original hardware. However, good luck on emulation the game. You might take a look at [https://github.com/SailorSat/cabmame/tree/su2000] At the moment, I don't actively work on anything SU2000 related.
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.
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: https://www.reddit.com/r/MAME/comments/nnqspn/comment/gzwwm2o/?utm_source=share&utm_medium=web2x&context=3
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).
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.
It is a bit harsh...but logical, you're not wrong.
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).
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...
It is a bit harsh...but logical, you're not wrong.
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.
I have tried to ask them through email, I'm awaiting a response.
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:
I've dumped both my SU2000 and SU3000 discs, but not uploaded them to the archive yet.
You can get dumps of the discs at http://files.arianchen.de/?x=su2000 (in CHD format)
Any DOS emulator can run the software - however the custom hardware is a pain in the ass...
As for my emulation advances... Most of those components are "there enough" to keep the test software happy.
The network card is working.
The soundscape part of the FORMAT-C is uploading its firmware, but crashes/overwrites it's memory. The control part of the FORMAT-C is lacking a proper CPU core for the i80196/i80198
The polhemus tracker card is working and running it's code, but missing any useful data in/output translation - currently it reads "random" values.
The 3d processing cards (PIX) are missing a propper CPU core for the MC88110 to do any usefull.
Finally the framebuffer/video card is there but does not do anything yet.
Excellent news! Ariane got back to me, here's what they had to say:
I've dumped both my SU2000 and SU3000 discs, but not uploaded them to the archive yet. You can get dumps of the discs at http://files.arianchen.de/?x=su2000 (in CHD format)
That is good news, but: 1) there is only one image available via that URL (su2000.ima) 2) the image does not contain PacMan VR afaict
A copy of their version of PacMan VR would be the most interesting at the moment of course.
Any DOS emulator can run the software - however the custom hardware is a pain in the ass... As for my emulation advances... Most of those components are "there enough" to keep the test software happy. The network card is working. The soundscape part of the FORMAT-C is uploading its firmware, but crashes/overwrites it's memory. The control part of the FORMAT-C is lacking a proper CPU core for the i80196/i80198 The polhemus tracker card is working and running it's code, but missing any useful data in/output translation - currently it reads "random" values. The 3d processing cards (PIX) are missing a proper CPU core for the MC88110 to do any usefull. Finally the framebuffer/video card is there but does not do anything yet.
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?
the image does not contain PacMan VR afaict
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:
These are actual disc images... - you can use 'chdman' to "unpack" the CHDs to IMG (for the HDDs) and BIN/CUE (for the CDs)
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 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.
[...], 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.
Nice. Too bad those too are not DOS4G(W) executables, wcdatool won't work on them. What about DN2
, that also a game? Contains debug symbols, can be disassembled using wcdatool. Then there's ETS
, which looks like a hardware testing program for the system. Also contains debug symbols, also can be disassembled.
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:
These are actual disc images... - you can use 'chdman' to "unpack" the CHDs to IMG (for the HDDs) and BIN/CUE (for the CDs)
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?
What about DN2, that also a game? Contains debug symbols, can be disassembled using wcdatool.
Ah, as a matter of fact yes! it is. That one is Dactyl Nightmare 2: Race for the Eggs.
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?
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.
Ah, as a matter of fact yes! it is. That one is Dactyl Nightmare 2: Race for the Eggs.
That might be the weirdest game title I've ever heard, right next to Attack of the Mutant Penguins on Atari Jaguar.
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.
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.)
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:
I vaguely remember playing this game at Epcot back in the 90s. All I could remember about it was that an egg was involved somewhere, and how completely disorienting and disappointing the experience was. I don't think I even actually ever found any eggs myself in the game, I was too busy just trying to figure out how to move around. I'm so glad that modern consumer VR is nothing at all 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'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: Unknown slot option 'enet16' in slot 'isa2'
I asked for clarification on how to fix this too, but no response.
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.
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.