[Request] List SNES scanline position registers in lua

[OmnigamerSDA]

Many system architectures have hardware registers that provide the current Horizontal and Vertical scanline positions. Bizhawk and some of the cores must keep track of these registers somewhere, and some make the information available in trace logs. However, these registers aren't currently exposed to users via emu.getregister or other methods. Please make these registers accessible to users where possible.

This request is specifically for SNES with bsnes core.

[vadosnaprimer]

Test this commit:
51b2843

It's for 1.x branch, because I can't build 2.x waterbox. If it works, we'll get it to 2.x too.

[brunovalads]

I'm really interested on this too. I tried compiling this commit but something is not working. I tested the following script:

local registers

local function print_HV()
  registers = emu.getregisters()
  console.clear()
  print(string.format("H: %d, V: %d", registers.H, registers.V))
end

while true do
  print_HV()
  emu.frameadvance()
end

But the output is always 0 for both H and V. Not sure if this is related with some mistake I did while compiling (for sure there's something wrong, I'm testing with Super Mario World and BG2 and BG3 are not showing at all).
Since the dev build site doesn't seem to work with 1.x commits, can you give a link to a compiled version of this commit?

[vadosnaprimer]

https://yadi.sk/d/hi4sSTKh3VBqq6

luainterface core will likely not work, so just try with nlua.

[OmnigamerSDA]

I briefly tested the above build, and I am able to grab the H and V values mid-update. Vertical values seem to be correct, as best I can tell, but H occasionally reports values beyond the range it should be able to support. Original value as far as the core knows should only go to 9 bits. Values in the screenshot below show the V (first value) and H (second value) of the moment game or vblank routines end.

[vadosnaprimer]

But the trace log has the correct value?

[OmnigamerSDA]

I just looked through trace logs for the current and past versions - they all have values as shown, so I guess it's correct in that it's passing what it's tracking internally. It looks like the value shown for H is about 4 times what it should be (capped at 340 per vertical line). Maybe the core uses this value for some other purpose internally, and expects the 4x value?

[brunovalads]

I tested and it's working nicely. I noticed too H being 4x larger than it should be (via both trace logs or emu.getregister).
Now I can finally make a lagmeter for the bizhawk version of the SMW Utils script, once it's on 2.x of course.

[OmnigamerSDA]

That was my purpose in looking into this as well! It needs some fixing yet to account for proper shape sizing and some argument differences, but here's the start of my ported code for that script: https://pastebin.com/jDDsYbq7

[vadosnaprimer]

I feel we need to find the reason of incorrect value in the core. I have no idea about it. How does this particular thing show up in lsnes?

[brunovalads]

In Lsnes the range is the same: V is "ok" but H is 4x

[vadosnaprimer]

I guess it's how bsnes originally outputs it then. We can ask Ilari and natt what they think, and maybe fix this entirely. Or forget about it and simply forward the thing we already have here to 2.x.

[brunovalads]

For now adding to 2.x seems ok. But indeed this need to be discussed with them, I'm not sure how this affects emulation, maybe it was an old workaround that was carried over.

[vadosnaprimer]

What is the lsnes setup that I can use to quickly show this to Ilari?

[brunovalads]

I adapted the Lagmeter tool from the SMW Utils, so it will work only with this game. It should print this.

local master_cycles = 0
local v, h = 0, 0

local function get_master_cycles()
  v, h = memory.getregister("vcounter"), memory.getregister("hcounter")
  master_cycles = v + 262 - 225

  master_cycles = 1364*master_cycles + h
  if v >= 226 or (v == 225 and h >= 12) then
    master_cycles = master_cycles - 2620
  end
  if v >= 248 then
    master_cycles = master_cycles - 262*1364
  end
end


local function draw_lag()
  local meter, colour = master_cycles/3573.68
  if meter < 70 then colour = 0x0000FF00
  elseif meter < 90 then colour = 0x00FFFF00
  elseif meter <= 100 then colour = 0x00FF0000
  else colour = 0x00FF00FF end

  gui.rectangle(-2*22, 0, 2*339, 2*(v-1), 1, 0x8000FF00, 0x8000FF00) -- 339 should be the highest H value
  
  gui.text(0, 2*228, string.format(" V: %d, H: %d ", v, h), "white", 0)
  gui.text(0, 2*240, string.format(" Lagmeter: %.1f%% ", meter), colour, 0)
end

memory.registerexec("BUS", 0x8075, get_master_cycles) -- $008075: wait for IRQ/NMI in SMW 

function on_paint()
  gui.left_gap(2*22)
  gui.top_gap(2*1)
  gui.right_gap(62*2)
  gui.bottom_gap(2*37)
  
  draw_lag()
end

[vadosnaprimer]

And what the correct value should be limited to?

[brunovalads]

According to https://wiki.superfamicom.org/#toc-opvct-vertical-scanline-location

H Counter values range from 0 to 339, with 22-277 being visible on the screen. V Counter values range from 0 to 261 in NTSC mode (262 is possible every other frame when interlace is active) and 0 to 311 in PAL mode (312 in interlace?), with 1-224 (or 1-239(?) if overscan is enabled) visible on the screen.

[vadosnaprimer]

Test https://yadi.sk/d/hi4sSTKh3VBqq6

[OmnigamerSDA]

In that latest build the Horizontal values reported from both emu.getregister and in the trace log resemble what they should be. Well done!

[vadosnaprimer]

@nattthebear here are the commits that fix this ticket for the 1.x branch:
71cb2f9
51b2843

Can you reproduce them on 2.x so it's properly closed?

[brunovalads]

I tested too and works perfectly with trace log and emu.getregister, thanks feos! (and Natt in advance)

Just a note: the hcounter value in bizhawk and lsnes seems to be the master cycles taken each scanline, according to https://wiki.superfamicom.org/timing
The SNES runs 1 scanline every 1364 master cycles, except in non-interlace mode scanline $f0 of every other frame (those with $213f.7=1) is only 1360 cycles.
So that explains why the value shown was 4x the value it should be.

[vadosnaprimer]

This has been implemented in master ebd6408
Please test the latest dev build!

[brunovalads]

Works perfectly, both the lua functions and the tracelog. Just one note: in the tracelog, for example V:261 H: 334, now there's an extra space after "H:", which is not necessary now since H now goes up to 339.
Thanks @vadosnaprimer and @nattthebear

[vadosnaprimer]

FUUUUUUCK

[vadosnaprimer]

e5516b4

And with that, this issue is fixed.