MooglyGuy's Shoddily-Put-Together N64 WIP Page - September 2007 Entries
09/29/2007 - Source 2
As I no longer have upload access to the old host for my Animal
Crossing code generator, this is now the home for it as will. I've
fixed a long-standing bug in the player and town name parsing, you
can download the new version's source code
here.
09/27/2007 - Source
Grab the NUTS source code here.
09/26/2007 - Pining for the Fjords
Just a small update - NUTS is currently in a Schrodinger-esque state
of possibly being dead, but possibly not. In the past month I've
changed jobs (I start in a week!), and it's up in the air right now
whether or not I'll be able to continue my work on NUTS. Personally,
I don't think I could be reasonably disallowed from working on it
given the severe unlikelihood that the company has any documentation
at all on the N64's hardware, let alone the RSP (which Nintendo
forced developers to keep under literal lock and key).
That said, as soon as I have access to both the internet and my
home dev machine at the same time, I intend to release the source
code as-is. I feel I owe the community at least that much.
On a totally different subject, here's a bit of fun that I
discovered for all five of you who bought Superman Returns: The
Videogame, for the Xbox 360. Go into the pause menu, and enter the
following code sequence:
D-Pad Right
D-Pad Up
Y
Y
D-Pad Up
D-Pad Right
D-Pad Down
D-Pad Up
X
Watch the cars. Then damage a car and watch the carnage. Fun!
09/02/2007 (2) - Release Candidate
NUTS RC1 is now available to download. Click
here to download it. Please be sure to read all included
documentation. Note that it will likely NOT run on any emulators
other than ones providing explicit LLE RSP emulation. If you have any
questions, comments, bug reports, or suggestions regarding NUTS, feel
free to contact me at my above-listed contact points.
09/02/2007 - Tetris
Everything seems to be fitting together nicely. It's now possible to
run tests on the RSP. It's actually markedly faster than the standalone
versions of the RSP tests due to some brutal optimization. Whereas the
standalone versions updated the screen after each opcode for a pretty
blinkenlights effect, the test suite stops updating the screen
altogether unless the user presses a button to force a frame update.
It's not all that pretty, but we're talking a speedup on the order of
tens of times, which is more than worth it.
For the curious, here's what you'll see if there are no issues detected:
Also, here's what it looks like when there's an error in the testing (in
this case, I forced an error to make the screen come up):
The last two things on the agenda are to make the Input Test screen,
which should be really easy, and document it. All in all, we're on the
verge of a release here, people.
08/26/2007 - Glass Tiger
Sorry for the long delay - yet again - in making progress on the
RSP probe. Over the past few days I've been putting the polishing
touches on the user interface for the RSP Probe section of the test
suite; the only remaining task is to write the actual probe code itself.
This isn't as absurd as it sounds; in fact, the probe code will be
rather elementary, as I've already written standalone versions to test
individual opcodes, and by and large it'll be a copy/paste job. The
most difficult issue so far has been how to present the appropriate
amount of data to the user for tweakage.
The main issue with regards to the interface was how to deal with series
of flag-affecting opcodes. I hadn't thought of this until I looked at
opcodes on an individual basis, but there are some ops where the
behavior is dependent on the compare, carry, or zero flags when entering
the instruction, and can subsequently modify those flags for further
use. As it turns out, the maximum number of chained instructions is
around three, so it was a simple matter of having three opcode selectors
that are enabled and disabled when the appropriate opcode is selected in
the selector before it.
The current UI looks like this:
The main RSP test window. Lets the user change the starting
parameters and the opcode(s) to be tested.
When a flag-affecting opcode is selected, the secondary opcode selector
becomes active.
When another flag-affecting opcode is selected, the tertiary opcode
selector becomes active. Incidentally, the only available tertiary
opcode is VMRG, which is dependent on compare flags.
A separate screen was devised for setting the base address for any
load/store opcodes and the data to be loaded. This is useful for
testing the behavior of unaligned reads and writes. As a single vector
is 16 bytes wide, it makes the most sense to make 32 bytes available,
which will enable the testing of all possible non-aligned reads and
writes.
I'll be moving into a new place in a week or two, but hopefully I'll be
able to get more work done before then and complete the probe in short
order after the move has taken place.
Also, I should point out that once I have moved, I will no longer have a
static IP address available to me, and I will no longer be able to host
my WIP page on my own machine. If anyone would like to offer me web
space where I could continue this page after I move, I would be
appreciative. I can be contacted at my usual info listed
above.
Current News
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007