reg_log question (working on raw 7c/7d-data from VGM-files)

Por Bengalack

Champion (405)

imagem de Bengalack

24-05-2021, 15:12

When is reg_log writing it's data? Comment in _reg_log.tcl says:

Quote:

The state of the debuggable is saved to a log file every VDP frame. Note that it does not take into account
different VDP interrupt rates.

Does that mean that it might work on 60Hz when I run things in 50Hz? Like the "snapshot" of its data is 60 times a second when I might assume 50?

(Using openmsx 16)

(Background story: I made a YM-2413/MSX-Music replayer which eats raw data that I extracted from vgm-files. This worked nice... I assumed. Turns out that there are a few timing issues here and there, in some clips. So, far, finding the culprit has proven really hard, and I try to use the raw-reg_log.tcl-output from the program to compare with the same output from vgmplay by Grauw)

Entrar ou registrar-se para comentar

Por Manuel

Ascended (18151)

imagem de Manuel

24-05-2021, 15:17

reg_log just follows the VDP framerate. So after each frame, the data is logged. You can specify the output filename yourself, as the help text tells you. You can just add the path as well before the filename.

Por Bengalack

Champion (405)

imagem de Bengalack

24-05-2021, 16:19

Thanks for answering, but unfortunately, I'm no wiser. It's just that the output seems strange at times.

All I do is this (the program is not heavy, only a few writes):

loop:
halt
write to regs
repeat loop

What I experience (sometimes here and there) is that only half of the writes are included in the current frame in reg_log, the rest is "corrected" in the next frame. I also do wait way more than the requires 84 cycles between the writes, just to be on the safe side.

So, as if the "snapshot" of the debuggable is done mid-frame. But only sometimes. If this hypothesis is correct... I have a problem Smile

Here is the output of frame 0 and 1 (notice those last registers (0x33-0x38)):

 61 e1 cd 1f f4 f8 64 55  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
 61 e1 cd 1f f4 f8 64 55  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 e3 c6 54 63 89 89  0  0  0  0  0  0  0

And what I write in frame 0 ("51 x y" means "write register: x, value: y"):

 
 51  0 61
 51  1 e1
 51  2 cd
 51  3 1f
 51  4 f4
 51  5 f8
 51  6 64
 51  7 55
 51 30  0
 51  0 61
 51  1 e1
 51  2 cd
 51  3 1f
 51  4 f4
 51  5 f8
 51  6 64
 51  7 55
 51 31  0
 51  0 61
 51  1 e1
 51  2 cd
 51  3 1f
 51  4 f4
 51  5 f8
 51  6 64
 51  7 55
 51 32  0
 51 33 e3
 51 34 c6
 51 35 54
 51 36 63
 51 37 89
 51 38 89
 51  e  0

Looks strange that registers 0-7 gets overwritten with the exact same values 3 times in the same frame, but this is data recorded from moonblaster. Anyways: We can see that I write those nonzero-values in 0x33-0x38, but only values in 0-7 are dumped in the first frame. I have debugged this, and all those data are actually written, and is visible in the debuggable-gui. I think this confirms that the data written to file is not when I expect it to be.

Por Grauw

Ascended (10065)

imagem de Grauw

24-05-2021, 16:55

The openMSX reg_log command relies on the after frame command which triggers when “VDP scanning reaches vsync”, so at the moment the vblank interrupt is triggered. If the music player code is running on the interrupt and never takes longer than one frame it should work, but I don’t know the details of your implementation. An alternate more flexible approach is to write a TCL script to do the logging with breakpoints like here.

Por Bengalack

Champion (405)

imagem de Bengalack

24-05-2021, 21:16

Grauw wrote:

If the music player code is running on the interrupt and never takes longer than one frame it should work

Thanks. Yes, it should work. I don't use interrupt in this sample code, but there is "nothing" running, so a plain loop with halt would normally do the same thing, AFAIK.

I still struggle with tcl. I might either try to come around that, or possibly see if I can isolate the current logging issue to see where the problem lies.