How to disassemble Pac-Man VR

[DuggletMcNugglet]

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.

[fonic]

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:

1. 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.

2. 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.

3. 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

4. Copy your executable to repo's subfolder Executables

5. 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 #9 as that contains lots of additional information (especially regarding what to do with the output).

[DuggletMcNugglet]

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.

[fonic]

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.

[DuggletMcNugglet]

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:

[fonic]

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.

[fonic]

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

[DuggletMcNugglet]

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.

[fonic]

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).

[DuggletMcNugglet]

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.

[fonic]

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.

[DuggletMcNugglet]

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.

[DuggletMcNugglet]

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.

[fonic]

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.

[DuggletMcNugglet]

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.

[fonic]

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.