What happen on real hardware when you push a matrix in the N64 projection stack?

[Narann]

As you maybe know, N64 has a stack of 10 modelview matrices and one single projection matrix.

Gathering informations here and there, it's not clear how the N64 react when you try to push a matrix in the projection matrix. Most informations say about the perspective matrix that you can load and multiply but you "can't" push or pop.

Reading some emulator code comments, it seems some games try to do that (Extreme-G). So we have two situations possible:
1) The plugin author is wrong and Extrem-G don't try to push anything in the perspective stack.
2) You can push persp matrix on the N64 hardware and it will react like a load. You can pop matrix and it will empty (or leave?) the perspective matrix from the single-element-stack.

So now we have kind of cycle accurate emulator and guys with high N64 hardware knowledge here I want to know your opinion about this.

What is the truth about this?

Thanks in advance!

 

[zoinkity]

I was under the impression this was an RSP abstraction and therefore different between microcodes, but I could be mistaken. For example, you can't push matricies at all under Fast3D simply because it only uses a single projection matrix (which is what makes it "fast").

 

[Hacktarux]

The n64 does not have any dedicated matrix calculation hardware. So the answer is that it depends on the software that runs on the RSP.

 

[Narann]

I was under the impression this was an RSP abstraction and therefore different between microcodes

It surely is. So you mean this would crash at the compilation step ("MTX_PUSH is not define!" or something similar) depending on the chosen ucode. Maybe maybe.

For example, you can't push matrices at all under Fast3D simply because it only uses a single projection matrix (which is what makes it "fast").

By: "You can't", you mean it will fail at compilation time?

The n64 does not have any dedicated matrix calculation hardware. So the answer is that it depends on the software that runs on the RSP.

Interesting. Thinking about it, it seems obvious.

So there is no way to anticipate what the Projection matrix stack will look like in the video plugin to mimic the N64 behaviour (I mean, what to do when a game ask for a push on the projection matrix stack).

 

[Hacktarux]

Well... the game upload the code it needs to the RSP (this is known as a ucode). So if you are writting a HLE plugin you either have to guess what the ucode is capable of or disassemble the rsp code and understanding what it does.

 

[Narann]

Thanks Hacktarux. My intent was to know what to do when I get a ucode with args that the doc said I shouldn't even had. Like:

insert_matrix(PROJECTION, PUSH, mtx)

Or :

pop_matrix(PROJECTION, mtx)

As there is no information about this case (except: "You can't do that!"), I don't know what to do when I encounter it.

Hope I'm clear.

 

[zoinkity]

As there is no information about this case (except: "You can't do that!"), I don't know what to do when I encounter it.

You'd have to check the microcode. Any error handling would have to be programmed there, as there isn't any error handling at a processor level. RSP stands for "Reality Signal Processor". Signal processors are ultra-simplified processors that do no error catching, and that makes them remarkably fast. Division by zero is fine, for instance.

If they were really lazy they might not have any checks. Too many matrices would overwrite whatever data follows. The horror!

 

[Narann]

The microcode doesn't check anything, if you ask it to pop projection matrix, it will execute. What I try to know is: What the hardware will do... I guess only cycle accurate or real test hardware would give me the result of this.