You know you're a hardcore IT guy when the people who wrote the program you're talking about find you and add extra information you missed. Fantastic work as always!

1:47 I appreciate that, where many other channels would break with an apology that Things Are About To Get Even More Complicated, But Just Stick With Me For A Second, instead you just moved on to the topic. You know why we're all here

Love your fantastic deep dives! Thanks so much for all the effort you put into crafting them. They are a treat for my brain.

i am always excited for your videos since they are some of the greatest on the platform and have been eager since your community post!! keep up the good work!!!!

Sounds like hacking patches into old ROM chips in the early arcade era was at the software level just like rewiring any electrical device in hardware with jumper wires. Not a lot of space on storage chip, very primitive coding languages without automated resorting and renumbering algorithms to help quickly recompile a program to incorporate even minor changes, and hard coding limits mean hijacking electrical signals and bank switching very rapidly becomes a necessary but tangled web to make changes to a piece of software on non-volatile hardware.

I like your funny words magic man

It’s funny that they changed the name Clyde to Sue but kept the same behavior

@13:46 Yes, it was just an error! I disassembled the earliest version of code I have (this is actually Crazy Otto). It shows the correct patch for all four monsters: 2745: 2A 0A 4D ld hl,($4D0A) 2748: 3A 2C 4D ld a,($4D2C) 274B: CD 2F 3F call $3F2F 274E: CD 66 29 call $2966 277B: 2A 0C 4D ld hl,($4D0C) 277E: 3A 2D 4D ld a,($4D2D) 2781: CD 2F 3F call $3F2F 2784: CD 66 29 call $2966 27B8: 2A 0E 4D ld hl,($4D0E) 27BB: 3A 2E 4D ld a,($4D2E) 27BE: CD 2F 3F call $3F2F 27C1: CD 66 29 call $2966 2800: 2A 10 4D ld hl,($4D10) 2803: 3A 2F 4D ld a,($4D2F) 2806: CD 2F 3F call $3F2F 2809: CD 66 29 call $2966 Note they all have the same CALL $3F2F. So originally we had it working, all four monsters random, and then we screwed up INKY and SUE when we adjusted the patch code to align with 8-byte boundaries. Ok that is seriously depressing. A bug report for work we did in November 1981, 43 years ago.

I would have though that a rom chip is cheaper then the pal chips. Do you have an idea why they didn't go that way instead?

i am guessing its more likely to be eather the first or 3rd reason with a diffrent reason for the first. maby they at the time didnt know you could patch between 2 patch blocks or maby it wasnt in best pratice at the time. i dont think its a second one because they made an effort to prevent a likely diffrent bug.

How could Sue's "AI" be updated for Ms. PacMan when it was Sue's FIRST game, since Sue was not part of PacMan. Also...stop fucking using AI when you have no idea what it means.

Sue, the original gaming trans icon apparently

Im always excited to see a new video from this channel

Player starts at the bottom of the screen and they probably ran into issues with getting killed to early so they reversed it

"But first we have to talk about-" Parallel Universes??? "...no"

that "hijack" is exactly what you do for API hooking, Microsoft even begins api with dummy instructions to avoid moving away the overwritten code

It's worth noting that the Red and Pink ghosts are the most immediate in their pursuit of Ms. Pac-Man, and since, when the Blue ghost begins to chase, it relies on Red's position, it will already have some chaos injected into its pursuit routine. Since the purpose of the randomness in Ms. Pac-Man was to break Pac-Man's susceptibility to patterns, there just wasn't any need to further randomize Blue's movement. And Orange's function is largely as a spoiler, the other ghosts are plenty efficient in their pursuit of the player themselves, it's mainly around to get in the way and provide a fourth target to chase while Energizers are active.

sheesh, they could even have finished their patches with 18 01 to skip the last byte of the LD DE,target instructions. And if the alignment had been worse (only the opcode byte available to overwrite), they could have written: GET_RAND_QUAD_INKY: LD A, <INKY_DIR> JR GET_RAND_QUAD_FIXUP GET_RAND_QUAD_SUE: LD A,<SUE_DIR> GET_RAND_QUAD_FIXUP: POP DE -- increment return address by 3. INC DE INC DE INC DE PUSH DE GET_RAND_QUADRANT: ....

It would be cool to have a modified rom of ms. pacman that has this code patched so inky and sue are also random

Sue?? It's always been Clyde.

Before I saw the title saying Mrs Pac-Man, I was confused when I saw the name Sue.

Very funny. Seems like the developer felt it was unclean to "waste" two patch slots on a single patch, especially since they wouldn't have known upfront how many they were going to use in total. But then they didn't notice that this made their patch functionally useless for two of the ghosts.

@14:00 I think your speculation here is correct: we patched INKY and SUE properly at first, and then changed our code! I suspect the fix was originally the same for all the monsters. Once I started designing the patch hardware, we went back and rewrote some of the code such that the patches were on 8-byte boundaries. And it looks like we messed up these two. I have earlier versions of the code, and I may be able to see how these patches were implemented initially. Maybe…

congrats to sue on her transition 💚🏳️‍⚧️

@13:00 Actually the PAL hardware only allowed 42 eight-byte patches. This is because each PAL output is driven by a 7-input OR gate. Each input decodes a single patch address. Six of the PAL outputs are then OR-ed together, making a giant 42-input OR function to detect if this is a patch address. So we ended up with only two spare patches.

@12:50 Yes, your good guess is exactly right. Patches were aligned on eight byte boundaries.

For all of you wondering why he sounds tired/depressed, he put out a post addressing it on his Bluesky: > For all of my "followup" videos (the ones I put the quicker intro in), I tend to use my footnote voice, which is just my normal speaking voice instead of super enthusiastic voice I use for the main videos. > > Of course that means I get a lot of comments asking if I'm depressed, ha and in another post: > Which I mean... yeah.. but it's not that bad! In fact things have been pretty good lately

@10:07 Yes, your speculation is exactly right. We wanted the patches to align with 8-byte boundaries. So that's why the INKY and SUE patches are different. The reason for the 8-byte boundaries, was a limitation of the PAL chips. The PALs had a limited number of input pins. Eight bytes seemed to be a good compromise. That required decoding eleven Z80 address signals A3-A13.

Is it possible it’s a timing issue? You mentioned the only consecutive patches replace two different functions, so presumably there’s a fair amount of time between them being executed. The PAL must introduce some level of delay to address reads, and maybe crossing an 8-byte boundary causes enough delay that the CPU timing contract is violated?

Nice video. I like the creativity they had in the early days. Saving lots of resources with a little bit of engineering effort. Most people these days don't do this anymore, be it software or hardware. Example.. Need some boolean status flags? Majority of people: Make an array of N and wonder why memory gets low. People who think about it: Use bit maps and store 32 bool states in 4 Bytes instead. There is a little bit code overhead involved, but thanks to shift operations and logical operations that is quickly optimized on many architectures by default.

maybe the hardware could not handle two patch blocks in a row without unpatched code between them? there could be some kind of hardware thingus, such as a a latch that saves the patch number when the patch block is entered, and then gets reset when it jumps to an address at 8000-ffff (where the patches live). this would mean the same patch would've gotten executed over and over again. the two separate patches with adjacent blocks wouldn't trigger this kind of event since it is called from different places and not run contiguously.

Thank you for the assembly breakdown

I always thought Ms. Pac-Man was its own code. I had no idea it was this convoluted.

did sue transition between games

you sound sick

Looked like a mistake to me on first video, or a revert because it made the game too difficult (too unpredictable, too unfair). A good video game AI is a fun one, not a smart one that annihilates the player...

asdasdasd

Maybe they tried playing it, and it was just too easy or too hard the new way. I'm speculating, but there's no real reason someone couldn't make the changes and see how it plays.

It was enough randomness to get the job done of making it so players just can’t memorize the play patterns. And yeah if Bandai-Namco had just added that feature to Pac-Man, players woulda been mad

I thought they can't change course mid-corridor, only at intersections? So why call their AI every frame?

Interesting

TIL sue is a trans icon

There's seems very little chance this was intentional. If they had intended to put the patch for inky and sue where it is located in the final hijack, then there wouldn't be a purpose in performing the hijack at all. 1) If they had decided to make it ineffective at a later point, it would have required them to change both the call site patch location and the injected patch code itself. i.e. from some other set of instructions to the 'LD JR LD' combo at the beginning of the patch code. 2) If for some reason, late in the development, they couldn't *not* perform a patch and had to keep *some* patch in place. They could have just patched the code to be the same code that got replaced instead of the CALL instruction. For example, patch 'LD, A, <SUE_DIR>' over 'LD, A, <SUE_DIR>'. Of course, there is the possibility that it was a late-stage change, and that whoever was doing the changes didn't realize they could just do something simpler than this by either removing the patch altogether or patching the instructions to the same instructions.

Big reminder: That's not sue Just recolor them purple in post or something As a big pacman nerd I hate the Clyde remaining bullshit that Ms pacman did

I'm surprised they didn't just reassemble the source code.

OK ok ok, but I really need to know why there's no chip co-ordinates for 6G and 6I.

12:38 why not patch only 27b8 $27b8: jmp temp $temp: two original instructions, CALL GET_RAND_QUADRAND and then JMP 27C1

Well, with that bluesky account announcement, I won't be there. I doubt I'll watch any further videos you make. Have a good day.

Take a slug of vodka every time he says FFF

I wish you had a fediverse account to follow you on...