Posts for SeanSullivan86

Experienced Forum User
Joined: 5/26/2014
Posts: 7
Ah, the docs ( http://tasvideos.org/Bizhawk/LuaFunctions.html ) say onmemoryexecute is supported for N64 but then later says onmemory* events are unsupported for N64. edit: well I found the memory address I was looking for. :) edit2 : I eventually found the assembly code. The address I was interested in was written to many times per frame, but I was interested in only the case where it was set to 0x40. I ended up attaching Cheat Engine to Project 64 (in Interpreter mode, not recompiler) and using the conditional breakpoints functionality to break when the address got the value I was interested in. Then you have to step forward in the CheatEngine debugger (through the x86 instructions that Project 64 is executing) until the MIPS $PC value shows up in one of the x86 registers (was just looking for a value like 0x800*****). I don't think it works if you run the emulator in Recompiler mode since the original MIPS $PC is irrelevant if the code is recompiled to x86.
Experienced Forum User
Joined: 5/26/2014
Posts: 7
Thanks Kuwaga. I appreciate the reply. I had already been using those techniques for following function calls backwards, but the part about editing out function calls might be helpful. I hadn't tried that before. I guess I'll try looking harder for a relevant memory address. Haven't tried too hard yet. I just realized I can't even produce this behavior in Nemu. I use bizhawk for finding memory addresses usually... and it's easy to produce the behavior there. I guess Nemu's input plugin is converting my left/right key presses into analog movements differently than bizhawk does. I still think dumping all the addresses of the instructions executed over a period of time would be a helpful thing. Seems that bizhawk has a lua hook event.onmemoryexecute , but it requires you the specify the address. I suppose calling it for every address probably wouldn't perform very well...
Experienced Forum User
Joined: 5/26/2014
Posts: 7
Thanks for the reply. Here's what I'm trying to do (not really TAS related, sorry about that, if there's other active communities out there please redirect me). I come from the Mario Kart 64 community (www.mariokart64.com). I want to investigate some of the game mechanics to see under what conditions they occur. For example, in 150cc mode, if you correct your steering too much, you spin out. For some other things, I've found RAM addresses whose values relate to the game mechanism in question, then put read and/or write breakpoints on those addresses to find the code which is using them. In this case, I haven't found any relevant RAM values (I could probably try harder), so I thought it would helpful to find instructions that are only executed when doing this behavior in the game. To help with replies... I'm a software developer. For my job I write mostly backend java code. I did some projects related to MIPS assembly in college so I'm moderately familiar with assembly, but I'm not particularly fast at looking at a bunch of instructions and knowing immediately what the purpose of the code is.
Post subject: N64 Debugging : Find code related to specific game mechanism
Experienced Forum User
Joined: 5/26/2014
Posts: 7
First off, I'm pretty new to this. I've been using Nemu64 for stepping through asm. If anyone knows other emulators/tools which might have a friendlier or more full-featured interface... please let me know. I had an idea for a type of code search... 1) Play the game for awhile (call this period A) 2) Do something special in the game you didn't do during period A (call this period B) 3) Have the emulator find all addresses/instructions which were executed during period B but not in period A Is that sort of thing possible? I guess the B minus A thing is a bit specialized, but more generally is there a way to collect the set of instructions which get executed during some period? I could do the set subtraction myself.
Experienced Forum User
Joined: 5/26/2014
Posts: 7
Hey Drew, I got it to work. (Dex Save / Memory Pack file) -> Controller inputs with lag frames missing Then I run a lua script similar to the m64->bkm script that comes with BizHawk. This corrects the lag frames issue. It starts at Power On, navigates through the menus, starts a race, and then starts the ghost data on the correct frame. So I tried it with a LR 1:38.97 ghost and it synced perfectly, so it appears as if the race is being raced live.
Experienced Forum User
Joined: 5/26/2014
Posts: 7
I found that using the null controller worked. Use keys like "P1 Start" and set them using joypad.set(buttons). The BKM format page has a typo for N64: http://tasvideos.org/Bizhawk/BKMFormat.html It lists the format as: Flag UDRLBAZSLRudlr xxx, yyy other controllers I think it should be UDLR at the start.
Post subject: Trouble with lua joypad.set
Experienced Forum User
Joined: 5/26/2014
Posts: 7
I have a main loop like this:
while true do
  -- Only read the next frame of data if the last one was used
  if input_was_used and not finished then
    read_next_frame() -- sets buttons, X, and Y variables
    input_was_used = false
  end
  
  if not finished then
    joypad.set(buttons, 1)
    console.log(string.format('Buttons : %s', table.tostring(buttons)))
    local analogs = { ["X Axis"] = X, ["Y Axis"] = Y }
    joypad.setanalog(analogs, 1)
  end
  
  if finished then
    console.log("Movie finished")
    client.pause()
    return
  end
  
  emu.frameadvance()
end
The log statements indicate that the 'buttons' table is being populated correctly, for example key "Start" gets value true (boolean). However, the button data never gets passed to the emulator. The analog data DOES get passed to the emulator, just not the button data. This is for N64 ... Mario Kart 64 ROM Am I using joypad.set wrong?