MooglyGuy's Shoddily-Put-Together N64 WIP Page - March 2007 Entries
03/31/2007 - Newwwwwww Math
A few new test items this afternoon:
| Opcode | Description | Status |
|---|
| VADD | Vector Add | Pass (tentative) |
| VSUB | Vector Subtract | Pass (tentative) |
| VABS | Vector Absolute Value | Pass (tentative) |
| VADDC | Vector Add w/ Carry | Pass (tentative) |
| VSUBC | Vector Subtract w/ Carry | Pass (tentative) |
| VRCP | Vector Reciprocal | Fixed |
I'm tentatively marking VADD*/VABS/VSUB* as passing - it's run through
about 4% of the test suite values right now, but typically if it hasn't
failed by now it's not going to.
Addendum: It just occurred to me that I should probably mark VSAW
(Vector Store Accumulator Word) as passing as well. I use it to
transfer the accumulators into a vector, which I then write to DMEM, in
the register-transfer function of the RSP probe. Since the transfer
function works on both the N64 and MESS, it's an incidental test, so
it's obviously fine.
03/31/2007 - My Favorite Things
For those of you who want to see a page on the status of each individual
vector-specific opcode, I've thrown this page
together. Check it out
03/31/2007 - Shave and a Haircut
The clipping operations seem to check out:
| Opcode | Description | Status |
|---|
| VCL | Vector Clip Low | Pass |
| VCH | Vector Clip High | Pass |
| VCR | Vector Clip Reverse | Pass |
Also, it would appear that there's some confusion with regards to what
I'm currently doing, due to an update that I failed to post: I found out
what was preventing the patched core from working, so I am now back to
testing individual opcodes against the Nintendo 64 itself.
03/30/2007 - Discordianism
A hodge-podge of opcode updates:
| Opcode | Description | Status |
|---|
| VAND | Vector AND | Pass |
| VNAND | Vector Not AND | Pass |
| VOR | Vector OR | Pass |
| VNOR | Vector Not OR | Pass |
| VXOR | Vector Exclusive OR | Pass |
| VNXOR | Vector Not Exclusive OR | Pass |
| VCL | Vector Clip Low | Pass |
| VCH | Vector Clip High | Pass |
| VCR | Vector Clip Reverse | Pass |
More updates as they happen.
03/30/2007 - The Programmer's Stone
Latest opcodes to undergo testing:
VRSQL / VRSQH: Vector Reciprocal Square-root Low/High. First verified
inaccuracy. Shouldn't subtract the destination element off of 7 when looking
up the destination element, just use the value encoded in the
opcode.
VRCPL / VRCPH: Vector Reciprocal Low/High. Same issue.
Stay tuned for more updates.
03/24/2007 - Wonder Twins
I probably should have done this after first applying it, but I have
discovered that the patch that made the RSP core endian-independent also
managed to prevent any games from working now. With that in mind, I am
currently bolting the original, endian-dependent RSP core onto the new,
endian-independent RSP core, without actually making it a separate CPU
core. Before each opcode is executed, it will synchronize the bolted-on
RSP's data memory (hacked into a separate array) with the main RSP data
memory, and after each opcode, it will compare the separate fake DMEM
and register state with the endian-independent RSP's DMEM and register
state. If there's a desync, it will fatalerror, and inform me of the
current Program Counter so that I can see what opcode I need to fix in
the endian-independent core.
Simple, right?
03/24/2007 - Irrational Exuberance
VMULF: Pass
03/24/2007 - Electric Avenue
At the moment, VMULF is undergoing unit testing. It consists of loading
s0 with a value, then loading it into each of the elements
in v1 and v2, then executing VMULF v0, v1, v2. This will load v0 with
v1 * v2 * 2.
The current test harness loads s0 with 0 and subsequently adds 0x0011 to
s0 with each iteration. This strikes me as a fair enough balance
between comprehensiveness, given that running 65536 iterations would be
prohibitive, whereas 3855 iterations (0xFFFF / 0x0011 = 0x0F0F) is
comprehensive enough, ensures that the elusive 0xFFFF edge case will be
tested, and is still quick enough to be able to run to completion
through the night.
As I type up this entry, it's up to 0x2222. Hopefully, by tomorrow
morning, it will still be running, and will have rolled over!
03/18/2007 - 1 In 10 Will Enjoy It
Well, the RSP probe seems to be working. Hooray!
I've highlighted the registers and their corresponding positions in
vector register 0. It'd reflect the lower 16 bits of r16 through r23,
but as you can see, the registers were in the middle of updating when I
snapped the picture.
I ended up having to implement a couple of workarounds. First, you'll
notice that there appears to be a lot of strange contents in the
registers. That's because the RSP's registers are in a randomized state
on powerup. For what it's worth, though, they appear to be in the same
random state every powerup, so theoretically it would be a trivial
matter to emulate them with such values. For now, though, I put in a
workaround such that it first copies the real registers into the
emulated registers so as to not throw a spurious mismatch. Secondly,
single-stepping mode does not handle jumps gracefully, and so I've made
it so that the prober does not attempt to run the register-copy function
if the RSP is in the middle of a jump.
Anyway, now it's pretty much on the eminent Ville Linde to write the
proper probe code rather than the rudimentary test data that I'm using.
Still, good stuff all around.
03/16/2007 - Irrational (Amounts Of) Numbers
This is more like what I want to see:
Note: This is the result of the emulated RSP running on a real
N64. I have not yet gotten the N64's RSP to run code, but that's just
because I haven't uncommented that stuff yet. It turns out that the
black screen issue was due to the N64 getting angry over my lack of
double-buffering.
03/16/2007 - Alas, Poor Yorick
Well, the Doctor V64 arrived, and it works perfectly. The RSP probe, on
the other hand, does not. I've commented out everything that tries to
touch the RSP directly, leaving it just emulating the RSP and updating
the display on-screen, but even then it just gives me a black screen.
I'll be damned if anything is occurring to me immediately offhand as to
what the problem could be, given that the demonstration program that hcs
includes with alt-libn64 works fine, and I've made only minimal
modifications to its functionality. Ah well, I'll take a look at it
after a touch of WoW. Yeah, I know.
03/09/2007 - Highway To Hell
This is what failure looks like:
Actually, it's faux-failure - I intentionally induced an error in the
CPU core to make it fail. It will automatically dump out any
mismatching GPRs, vector registers and accumulators that do not match,
as well as their previous states (which is admittedly redundant to
display twice) and the twin program counters (emulated and real) onto
the screen for easy debugging. The next step, as I wait for the Doctor
V64 to arrive from the UK, is to add other functionality such as being
able to page through a display of the entire register set after a
mismatch.
In addition, yesterday I found the first - arguably most important for
the trojaning effort - thing to figure out about the N64's hardware: how
the RSP handles setting the program counter while handling a branch in
single-step mode. Think about it: The RSP single-steps through a
branch, but there is still another instruction to be executed
immediately after. While the RSP is halted, you set the PC to be
elsewhere. What happens? We shall see.
03/06/2007 - That's A Biiiiiiig Twinkie
Success! Well, in a manner of speaking. Observe:
What is shown in that picture is an emulated N64 displaying the register
contents of an emulated RSP being emulated on that emulated N64,
the RSP having just run a short bit of code. For
all intents and purposes, I now have a program which can conceivably run
test code on a real Nintendo 64. I expect once the Doctor V64 is in my
possession that it won't run on a real Nintendo 64, because that's how
my luck has been. However, for now, take comfort in the thought that
perfect RSP emulation may soon be a reality.
03/03/2007 - The Late Night Double-Feature Picture Show
Just a quick update; I managed to optimize the register usage of the RSP
register-transfer function. My original plan was to limit unit testing
to vector operations only, but in the event that a full test is ever
desired, it should now be possible to test all instructions' effects on
all general-purpose registers except one (t0) now. I've hard-coded the
register-display function to show "0xdeadbeef" for registers that can't
be tested. I suppose marking r0 as untestable is a bit unfair, but
there's just not a whole hell of a lot to test.
03/03/2007 - Baby Steps
A couple new developments. First of all, thanks to an anonymous
donator, I will soon be in the possession of a Doctor V64 unit with
which I can run test code on a real N64 - this is when the magic starts
to happen.
The current plan of attack for probing the behavior of the RSP is to directly
port MAME's current RSP core to the N64 itself, and to run the emulated RSP
in lockstep with the real RSP, verifying the vector register contents after
each instruction (it can be safely assumed that non-special opcodes are in
good condition already). According to documentation, the RSP has facilities
for running in single-stepping mode such that it will automatically halt
after executing one instruction, though I have not heard any verification as
to whether or not this works as expected.
Second of all, the prober is slowly starting to take shape. The first
step, getting a C compiler running that can cross-compile for the N64,
has taken place. Currently all the test code does is pull values from
the area of RSP DMEM that I have reserved for the RSP-side code to copy
the vector registers, but the hard part (getting a viable C compiling
environment and the ability to display text on-screen) is done. The
next step, over the next day or two, will be for me to graft MAME's RSP
core into this new codebase, but that should be reasonably
simple.
With that, I leave you with a screenshot of what it does so
far:
Current News
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007