vr4300 Opcodes

Discuss topics related to development here.
Post Reply
krom
Posts: 72
Joined: Sat Oct 05, 2013 2:19 am

vr4300 Opcodes

Post by krom » Mon Nov 11, 2013 6:23 pm

Hi MarathonMan =D
I thought it might be useful to make a list of the final missing opcodes from the cen64 vr4300 core emulation:

CP0 (vr4300/CP0.c & vr4300/EXStage.c & vr4300/TLB.c):
LL
LLD
SC
SCD
SYNC

BGEZALL
BLTZALL
BREAK
SYSCALL

TEQ
TEQI
TGE
TGEI
TGEIU
TGEU
TLT
TLTI
TLTIU
TLTU
TNE
TNEI

TLBP
TLBR
TLBWR

CP1 (vr4300/CP1.c):
CEIL.L.S * Now Implemented (cen64 v0.1)
CEIL.L.D * Now Implemented (cen64 v0.1)

CEIL.W.S * Now Implemented (cen64 v0.1)
CEIL.W.D * Now Implemented (cen64 v0.1)

FLOOR.L.S * Now Implemented (cen64 v0.1)
FLOOR.L.D * Now Implemented (cen64 v0.1)

FLOOR.W.S * Now Implemented (cen64 v0.1)
FLOOR.W.D * Now Implemented (cen64 v0.1)

ROUND.L.S * Now Implemented (cen64 v0.1)
ROUND.L.D * Now Implemented (cen64 v0.1)

ROUND.W.S * Now Implemented (cen64 v0.1)
ROUND.W.D * Now Implemented (cen64 v0.1)

TRUNC.L.S * Now Implemented (cen64 v0.1)
TRUNC.L.D * Now Implemented (cen64 v0.1)

It is great to see only a small amount of opcodes are now missing, and how far cen64 has come =D
I will try to help out by working on the remaining CP1 opcodes, it will be great to cross them all off the list for 100% CP1 emulation =D ** EDIT ** Done!
Last edited by krom on Fri Nov 15, 2013 2:11 pm, edited 2 times in total.

User avatar
Iconoclast
Posts: 47
Joined: Fri Oct 04, 2013 8:00 pm

Re: vr4300 Opcodes

Post by Iconoclast » Mon Nov 11, 2013 6:47 pm

Implementing missing instructions is one thing.
Stabilizing the emulator to prevent hazardous futures has been another.

They usually are implemented on the basis of finding games that use them, so that they can be checked immediately while testing their usage in a game to make sure it's both stable and conformant to the widely available documentation about them.

In my experience, the information I look for the most in this sort of development is not which op-codes are missing, but what is a ROM that tests it.

krom
Posts: 72
Joined: Sat Oct 05, 2013 2:19 am

Re: vr4300 Opcodes

Post by krom » Mon Nov 11, 2013 7:54 pm

Hi Iconoclast,
I do agree with your statement above...
I've already implemented a huge amount of CP1 opcodes into the cen64 core already to help out MarathonMan with cen64.
I use a combination of commercial roms/PD roms, and my own bespoke N64 mips assembly roms that run on real hardware to check the output of each opcode that I add.

I also added the N64's 32bpp screen mode into cen64, using a Mandelbrot fractal program I wrote as a test, when only a few PD Roms, & only 1 commercial rom was running on cen64 =D
I also optimized the opengl portion of cen64 to use a much faster vertex array for the screen quad.

The reason I have been able todo all of this is that I started making my own unreleased N64 emu about 5 years ago, and when I saw how far cen64 was,
I decided to add everything my emu had that was missing at the time into cen64 e.g ultra fast opengl quad blit, 32bpp screen mode, & loads of CP1 opcodes =D

After we get 100% CP1 opcodes in, I want to make a big CP1 test rom that will check every opcode with known values on real hardware, and any strange edge cases to make sure the outputs & flags are all bit perfect. Then I will try todo a similar test for CP0 opcodes...

Timing is already an issue, for instance my Mandelbrot Julia animation test performs much slower on a real N64, compared to cen64 running on a p.c because each double precision number is getting calculated as fast as possible on the p.c side.
If MarathonMan decides todo perfect cycle timing, I will be happy to make bespoke tests for him to test all the opcodes timings etc...

User avatar
Iconoclast
Posts: 47
Joined: Fri Oct 04, 2013 8:00 pm

Re: vr4300 Opcodes

Post by Iconoclast » Mon Nov 11, 2013 9:13 pm

That's pretty cool. Yeah, the more accurate, stable implementation side of things is currently in Hacktarux's perspective. It seems the adverse factor of speed has its share of contributions from your OpenGL knowledge.

I thought one of the things that needed the most optimization in the current zilmar-spec pixel-accurate graphics plugin by angrylion was not using DirectDraw, and finding an accelerated way to project it with OpenGL blitting. However I have no direct OpenGL experience. (I was playing with rewriting to SDL instead.)

I might pick up from any techniques you illustrate when doing the plugin version implementation, or I might analogize what I've learned about OpenAL and work out a customary attitude of how to do blitting in OpenGL. (Though the latter does balance against me being a somewhat slow learner.)

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest