IQ via discrete cosine transformation unimplemented

[cxd4]

Part of a series of failed hardware tests as cited by #15 of krom's test code at PeterLemon/N64.

DCT IQ is not implemented and unavailable to commercial developers due likely to patent issues. It is virtually impossible to find any pragmatic application of the operation because it was reported to recipients as reserved and nonexistent.

Reference:

• RSPTest/CP2/RESERVED/VMULQ/RSPCP2VMULQ.N64
• RSPTest/CP2/RESERVED/VRNDN/RSPCP2VRNDN.N64

[bryanperris]

So are these opcodes really reserved on the real N64? The RSP official doc provides information on these opcodes. I guess since the RSP/RDP docs were released near the end of the N64 era, it makes sense if games never used it.

`// vrndp vd,vs,vt[e] ; Vector DCT Round Positive: VRNDP VD,VS,VT[ELEMENT] (Reserved: MPEG DCT Rounding)

// vmulq vd,vs,vt[e] ; Vector Multiply Integer: VMULQ VD,VS,VT[ELEMENT] (Reserved: MPEG Inverse Quantization)

// vrndn vd,vs,vt[e] ; Vector DCT Round Negative: VRNDN VD,VS,VT[ELEMENT] (Reserved: MPEG DCT Rounding)

// vmacq vd,vs,vt[e] ; Vector Multiply Accumulate Integer: VMACQ VD,VS,VT[ELEMENT] (Reserved: MPEG Inverse Quantization)`

[cxd4]

I do not believe they are reserved; however I wouldn't place any certainty for such behind any documentation, either on Nintendo's or SGI's part. They wouldn't be the only reserved opcodes as documented to exist in either case.

Having said that, many years ago (maybe like 2010-ish) I remembered seeing one of the files from the plain old Nintendo 64 SDK that listed a list of RSP opcodes for the assembler. It appeared to me they had inadvertently left "vmacq" in the list yet remembered to remove vmulq, vrndp and vrndn. I believe Nintendo knew the opcodes were usable but for some reason did not choose to make their usability known (after all, none of the microcodes and examples by SGI used any of these instructions, either, as far as I can remember).

[bryanperris]

The assembler I am using has the placeholder for those instructions that make sense. If I had the n64drive, I would have attempted to see if the instructions execute or not. For now, I will put them under reserve since nothing is going to use them. Thanks.

[cxd4]

Rest assured that the op-codes do have functions to them, reserved or not.

If the RSP wasn't a slave processor, you would know if they were reserved just from trying to execute them. Since it is a slave processor, though, you cannot really tell if they are reserved, no matter what tests you run. I would say there's more evidence to the contrary; krom's 64drive test ROMs generally wipe or neglect to set any bits in the destination vector $vd whenever a "reserved" operation is attempted, but the only exceptions to this pattern are those well-known vector operations implemented in all N64 emulators in addition to vmulq and vmacq and vrndp and vrndn.

So I think they are not reserved, but possibly for patenting reasons Nintendo received the technology under the premise as if they are. So as far as we need to be concerned, they are. Whether you want to go beyond that depends whether you care more about the games or the hardware I suppose, but in either case, I depend on test software before I'll implement such things.

[bryanperris]

I know the rsp doesn't handle exceptions or interrupts but these instructions could be tested against real MPEG data. I wish I had the drive to attempt such tests and learn more about the rsp itself.