On the road of accuracy

[Bighead]

Please keep us updated on your progress Hacktarux. I love following N64 emulation progress and have been following this thread for some time now. It would be sad to see it not updated anymore.

 

[willrandship]

Indeed. I, for one, am extremely happy to see this emulator.

By the way, MESS's N64 emulator isn't that bad anymore. Sure, it only runs at half framerate, but keeping in mind how insanely low level MESS gets, along with aiming for cross-platform builds, I wouldn't be surprised to see this emulator running 100% on current hardware.

Oh, and you should just ignore mudlord. bsnes got its fame for a reason.

 

[Fanatic 64]

Indeed. I, for one, am extremely happy to see this emulator.

By the way, MESS's N64 emulator isn't that bad anymore. Sure, it only runs at half framerate, but keeping in mind how insanely low level MESS gets, along with aiming for cross-platform builds, I wouldn't be surprised to see this emulator running 100% on current hardware.

Oh, and you should just ignore mudlord. bsnes got its fame for a reason.

Cycle-accurate emulation is even slower than Low Level Emulation. But yeah, maybe with some optimization (and being compatible with multi-core and 64 bits processors) it could run at a decent framerate.

 

[Rodimus Primal]

Has there been any progress Hack? Just curious.

 

[Hacktarux]

I've just dug out this project. It's been a long time and it is a little hard to remember what was the state of the project. Hopefully my v64jr and my old p133 with parallel port and win98 are still working to run hardware tests, i will test them tonight.

The next step is to find out why a demo is not working (the line demo). Probably a timing problem with pif and serial interface but i'm really not sure. Maybe i can use another emulator (mupen64 or nemu64) to check where it is breaking from normal behaviour.

Yesterday i switched the project to use c++11... that's like a totally new language with these new features

 

[ExtremeDude2]

I've got a gameshark set up and I can do mem dumps and in theory run homebrew, but I never got it to work all it does it fail to upload the code.

 

[Hacktarux]

Ok, now i know where the problem is. The y scale factor is set to 0 by the line demo. So i apply the normal formula it's always displaying the same line on the whole screen. But if i launch the demo on a real n64 it works. So i guess 0 is a special value. I don't know if anyone here have n64 technical knowledge but if you do, i'd be glad to hear what you think about this

 

[MarathonMan]

Ok, now i know where the problem is. The y scale factor is set to 0 by the line demo. So i apply the normal formula it's always displaying the same line on the whole screen. But if i launch the demo on a real n64 it works. So i guess 0 is a special value. I don't know if anyone here have n64 technical knowledge but if you do, i'd be glad to hear what you think about this

Yes! I'm so glad that you're dusting off the cobwebs! More cycle-accurate work.

I might be able to get back to you about the y-scale factor later tonight.

EDIT: If the ROM is public domain and you could post/PM it to me, that would be helpful too.

 

[Hacktarux]

You can find the rom in this archive:
http://mupen64.emulation64.com/test_demos.zip

the file is LINE.V64

With this rom i have two problems, y-scale factor and the last byte of the pif ram does not seem to be written... so i wonder how the controller can be read.

 

[Narann]

Ok, now i know where the problem is. The y scale factor is set to 0 by the line demo.

Interesting, how this rom run on real hardware? This would maybe mean N64 has kind of implicit scale values? From what I know, VI_Y_SCALE_REG (Are we talking about this one?) is mainly 0x400 (1x) or 0x800 (2x).

I know MarathonMan has some hack to read N64 registers (am I right?) If so it could be interesting to have the VI_Y_SCALE_REG register value (and others maybe) for this specific rom.

Does all what I said has any sense or am I completely off?

EDIT: Reading this, it seems that some register values are not always setted.

Hope this humbly help...

 

[Hacktarux]

Yes that''s this register. The rom set a normal value for xscale but 0 for yscale,

 

[MarathonMan]

The PIF ROM problem is more interesting. It's unfortunate that the contents of the Sharp controller's ROM in the PIF have not been dumped yet (the PIF was recently? decapped, but had a metal protective layer on top... grr).

I know MarathonMan has some hack to read N64 registers (am I right?) If so it could be interesting to have the VI_Y_SCALE_REG register value (and others maybe) for this specific rom.

I haven't modeled the AI/VI/PI at all. Just emulate, the same way all other HLEs do now.

 

[Narann]

Yes that''s this register. The rom set a normal value for xscale but 0 for yscale,

And about this? :

EDIT: Reading this, it seems that some register values are not always setted.

It seems that the yscale register is not set from the beginning. If it's not set, it could be interesting to see how real N64 behave to such situation (And we could discover an implicit behaviour).

I haven't modeled the AI/VI/PI at all. Just emulate, the same way all other HLEs do now.

I was referring to your N64's image with all the cords over it, I was thinking it was intent to dump the registers, and so, see which state they are, and so, see if N64 set yscale or not.

I'm maybe off about all of this, I just read the various docs to understand such problem but it seems weird a rom could run the VI without set any yscale.

 

[MarathonMan]

EDIT: Nevermind, byteswapping issue.

Hackturax, are you sure that the VI_Y_SCALE_REG write even occurs? I only see these writes in both CEN64 and MAME:

[VIF]: "VIRegWrite: Writing to register [VI_INTR_REG]."
[VIF]: "VIRegWrite: Writing to register [VI_H_START_REG]."
[VIF]: "VIRegWrite: Writing to register [VI_CURRENT_REG]."
[VIF]: "VIRegWrite: Writing to register [VI_STATUS_REG]."
[VIF]: "VIRegWrite: Writing to register [VI_ORIGIN_REG]."
[VIF]: "VIRegWrite: Writing to register [VI_WIDTH_REG]."
[VIF]: "VIRegWrite: Writing to register [VI_INTR_REG]."
[VIF]: "VIRegWrite: Writing to register [VI_CURRENT_REG]."
[VIF]: "VIRegWrite: Writing to register [VI_BURST_REG]."
[VIF]: "VIRegWrite: Writing to register [VI_V_SYNC_REG]."
[VIF]: "VIRegWrite: Writing to register [VI_H_SYNC_REG]."
[VIF]: "VIRegWrite: Writing to register [VI_LEAP_REG]."
[VIF]: "VIRegWrite: Writing to register [VI_H_START_REG]."
[VIF]: "VIRegWrite: Writing to register [VI_V_START_REG]."
[VIF]: "VIRegWrite: Writing to register [VI_V_BURST_REG]."
[VIF]: "VIRegWrite: Writing to register [VI_X_SCALE_REG]."

 

[Hacktarux]

hmm
interesting....
i will have to check but the rom but i should switch on the n64 with the game already loaded on the v64jr to be sure that vi registers have some garbage initilially in them. But again without any write i fail to see how the rom can work on real hardware.

 

[MarathonMan]

My internal testing shows that VI_Y_SCALE_REG is initialized to zero when the console boots (or at least, I have not seen it get set to any other value -- PIFROM certainly doesn't write or read from it, anyways).

Unless there's a bug in both emulators, this would suggest that the VI algorithm is flawed for some corner case on all emulators that I've seen so far.

EDIT: And what do you know? After adding:

if (vi->regs[VI_Y_SCALE_REG] == 0)
  y_scale = 1;

I get the following:

EDIT 2: Still can't move the cursor though -- the PIF issue remains.

 

[Hacktarux]

I fianlly got my v64jr working.... that was quite a hard time. Finding aaa beteries for crt's remote control, plugging everything together, finding out that my old p133 running win98 was only booting when its case was open and so on... Yea, if anybody has a solution to get the v64jr working with modern hardware, i'd be glad to hear how you did it

Anyway... the important thing is, i think my emulator was perfectly working as it should.

I did 2 experiences:

1, If i boot another rom and upload line.v64 without turning of the n64, when i reset i see the game title screen. The cursor is slightly moving to the bottom left corner exactly as on my emulator and i can't move it with the controller.

2. If i switch off the n64 and switch it on afterwards, i can't see the title screen.

From that, i guess it's reasonable to say that:
- On experience 1, it booted because the vi_y_scale register was set by previous rom.
- On experience 2, it couldn't because the register only contained garbage after n64 power up.

It is quite possible that the game was developped on an emulator

Some people may call it regression but i find it quite cool that this does not work on this emulator

 

[MarathonMan]

It is quite possible that the game was developped on an emulator

Some people may call it regression but i find it quite cool that this does not work on this emulator

I agree that it is not a regression. If anything, ROM developers should be aware of these flukes...!

It's also reassuring to know that the cursor fades slowly to the bottom-leftish of the screen, too... thanks for that info. Too lazy to pull out my 64drive.

 

[Narann]

It is quite possible that the game was developped on an emulator

Hahaha If a such rom would have pass a Nintendo validation process, I guess they would have send a hard message: "This guy don't even set the y scale, RTFM noob!"

Some people may call it regression but i find it quite cool that this does not work on this emulator

I agree, this is what accuracy is supposed to be no?
Keep in mind: The aim of all of this is to be able to reproduce the DK64 bug without Expansion Pack and send a fix to Rare!

 

[ace64video]

1, If i boot another rom and upload line.v64 without turning of the n64, when i reset i see the game title screen. The cursor is slightly moving to the bottom left corner exactly as on my emulator and i can't move it with the controller.

2. If i switch off the n64 and switch it on afterwards, i can't see the title screen.

Some people may call it regression but i find it quite cool that this does not work on this emulator

Hacktarux,

It does work on Mupen64 v0.5.1.
Check out this video using Glide64 on Mupen64 v0.5.1