Those tools at least all run under 64-bit Windows 10 so it's not an OS issue.
If you're very lucky running the main exe like 'ggguy.exe > bla.txt' will redirect the output of the command-line (not dos!) programs to said text file, but chances are slim as they are external processes launched by the main exe.

Underclock your machine to a glacial speed, it might take all day to boot but when you run the program everything should run in slow motion

What you will likely find is that nothing comprehensible will be displayed

Oetker wrote on 2021-05-06, 15:02:

Those tools at least all run under 64-bit Windows 10 so it's not an OS issue.
If you're very lucky running the main exe like 'ggguy.exe > bla.txt' will redirect the output of the command-line (not dos!) programs to said text file, but chances are slim as they are external processes launched by the main exe.

That's a good idea, but sadly it just results in an empty text file. It was worth a try, though, thanks.

rmay635703 wrote on 2021-05-06, 15:18:

Underclock your machine to a glacial speed, it might take all day to boot but when you run the program everything should run in slow motion

What you will likely find is that nothing comprehensible will be displayed

Or I could really stress this Windows system. You know, by opening four Google Chrome pages, a music player, and two text files. This PC only has eight gigabytes of RAM, so that would normally result in the screen going white and nothing responding except the mouse cursor, thanks to Microsoft's wonderful memory (mis-)management. Except this would be the one time where Windows would cope with the 'strain'of minimal multitasking.

Hmm. What if you run GGGuy.exe from a command prompt window by using the "Start" command, as in "start ggguy.exe" ?

I'm guessing it's trying to run one of the other .exe files in the zip when it does the patching. You could conceivably try to figure out how those .exe files were written or compiled, and then hex-edit them somehow so they pause when they finish execution, but I doubt that's going to be simple.

Jorpho wrote on 2021-05-06, 15:51:

Hmm. What if you run GGGuy.exe from a command prompt window by using the "Start" command, as in "start ggguy.exe" ?

I've just tried, but it doesn't give any more output. Thanks anyway.

I'm guessing it's trying to run one of the other .exe files in the zip when it does the patching. You could conceivably try to figure out how those .exe files were written or compiled, and then hex-edit them somehow so they pause when they finish execution, but I doubt that's going to be simple.

It wouldn't be for me, no!

BTW, I should have said, I've tried all three N64 rom formats (Big Endian, Little Endian, and Byte-Swapped), but with no success.

You could just try to figure out the syntax of the command that GGGuy.exe is trying to run, and then run it yourself from a command prompt window, but it's not entirely clear from https://github.com/jfktrey/n64hijack what that syntax would be. You could try replacing the .exe files with something that simply outputs the arguments with which it was called, and then pauses. If something like that doesn't exist somewhere, it should be easy to knock it together in Python. (I could not find something appropriate in a moment of Googling.)

ETA: Here we go.
https://krikzz.com/forum/index.php?topic=2920.0

Seems the program might not work properly if you're using a path with spaces in the name. Try unzipping gggn64.zip to something like c:\temp and put your ROM in there as well.

Use video/screen capture (either external or internal) and get the info you want from recorded footage .

darry wrote on 2021-05-06, 17:42:

Use video/screen capture (either external or internal) and get the info you want from recorded footage .

I thought of that too, but as it says in the OP:

I've tried capturing the screen as a video, but even then the video is too slow to show the open window with it's text.

Jorpho wrote on 2021-05-06, 18:14:

darry wrote on 2021-05-06, 17:42:

Use video/screen capture (either external or internal) and get the info you want from recorded footage .

I thought of that too, but as it says in the OP:

I've tried capturing the screen as a video, but even then the video is too slow to show the open window with it's text.

Sorry, I somehow missed that. Maybe trying to capture with an external device would work better .

Alternatively, how about running the program through a debugger and tracing execution step by step. I am not an expert at that, but that should let the OP run through program execution at desired pace , AFAIK .

EDIT: Or in a VM with a cap set on allowed CPU cycles

I believe the GGGN64 program logs its errors into assembly.log

I think that I may have found the root cause of the fundamental issue and the solution . I believe the codes should be entered as such (you apparently need the offset and value to be separated by a space) :

D109A040 0020
8009A977 0001
D109A040 0020
8109A96E 01F4

darry wrote on 2021-05-07, 02:51:

I believe the GGGN64 program logs its errors into assembly.log

But the .log file only appears sometimes, and doesn't seem to help me get to the problem. However, your 'insert a space' solution DOES seem to help (and does make sense, since you're then separating the instruction or memory address from it's proposed value), but sadly even though the rom is now being altered (thanks to the introduction of the space character, presumably before this the program couldn't tell that the values should always be eight characters then another four characters) the now altered rom doesn't run on an N64 emulator, it just seems to lock up with a black screen. Whereas, of course, the unaltered rom boots up fine in the emulator.

Also, when running GGGuy.exe with the spaces added in the codes, the quickly disappearing text in the DOS windows is now much longer, and clearly contains the word "Error" in red letters. So we're closer to a solution thanks to your suggestion,

Kerr Avon wrote on 2021-05-07, 18:43:

the quickly disappearing text in the DOS windows is now much longer, and clearly contains the word "Error" in red letters.

Does that mean your screen recorder can capture it?

What screen recorder are you using, anyway? It is kind of weird that it would deliberately drop significant frames. I used to like Flashback Express.

I would think there would be a more practical way of doing all this, though the ideal way would be to talk to the program's author.

ETA: https://superuser.com/questions/306167/how-to … after-execution suggests you can edit the shell registry entry for .exe files, but that's hella dangerous and you might want to consider using a virtual machine if you're going to go that far.