To paraphrase a legendary line from Indiana Jones and The Temple of Doom:
The developers at EmuTalk will be banned. Then we will overrun the kiddies and force their “HLE” to bow to Moogly. And then the Rice God will fall and finally the PJ64 God will be cast down and forgotten. HA HA HA HA HA HA HA HA HA HA HA HA HA [etc]
I’ll let the pictures speak for themselves:
Tonight I present the first in what will hopefully be a regular series: Dramatic Message Board Readings.
Tonight’s installment can be found here.
I picked up something fun today! Technically I could’ve picked it up sometime last week if I weren’t really lazy. It was waiting at the post office for me.
Anyway.
For all of the following screenshots, you can copy their URLs and remove the “T” to get a full-sized 8-megapixel photo.
When you first boot the Nintendo 64 Test Cartridge, nothing happens for a second or two. You’re then met with the following screen, presumably while the most low-level of tests occur:
Note that the “VIDEO 3″ overlay is from the TV, not the N64. At first I feared that my Nintendo 64 was broken, or was one of the newer-revision models that are incompatible with the Nintendo 64 Test Cartridge. I picked up my controller after five seconds or so and began to push various buttons to see if I could progress past the above screen. Sure enough, after some frantic pushing, the screen changed to… another RAM test:
As it turns out, I needn’t have worried about my controller, as it progresses to this screen regardless of whether you press anything on your controller or not. A few seconds later I was summarily dumped at the following screen:
The N logo shown on the weird screen thing rotates about its Y axis. How droll.
After pressing the A button on my controller, it kicked over to the main menu:
I myself am not quite certain what the difference is between Auto Test and Burn-In; they both immediately start up an RSP test and keep going. Let’s choose “Individual Tests”:
RSP test? RDP test? Hot damn!
Being an orderly sort of gent, I tried the Controller Test:
…And, after ten seconds of screwing around with the analog stick and watching the crosshair move around, I was met with:
Hmm. Well, that sucked. As it turns out, that “5″ that you see on the right-hand side of the screen in the previous snapshot is a counter that counts from 10 to 0, and if you don’t press the button on the controller to which the arrow is pointing, it defaults to a failure. Whoops.
I tried it again.
Much better.
Moving on, I skipped the Rumble Pak Test as I do not have a Rumble Pak unpacked from my last move, and vowed to return to it after all of the other tests were performed. After around a second or so after selecting “RSP Test”, I received good news:
Oh joyous day! The Nintendo 64 that I use to play games without any issues apart from dirty contacts has a fully-working RSP! I never would have discovered this otherwise!
Ahem.
Moving on, the RDP Test gave me a whole bunch of large text and a counter!
It, too, passed.
I moved on to the Audio Tests, since I just can’t get enough blips, bloops, voice clips, and square-wave chords:
Left Channel and Right Channel play a vocal clip through the right and left speakers on your TV, respectively. WAIT! No. They play a vocal clip through the left and right speakers on your TV, respectively. The voice is female and sounds somewhat bored, as all vocal test clips are wont to do. In fact, it sounded a bit like Leslie Swan (voice of Princess Peach in Super Mario 64, other female voices in other Nintendo games, and Nintendo employee in general), which I don’t doubt given the time frame.
The Music Playback Test plays a brief clip of hardcore gangsta rap through the left, right and center channels, at rates of 32kHz, 41.1kHz, and 22.05kHz.
Sadly, that’s a lie; in fact, the “music” that it plays is a Major note progression followed by three chords, played by a square wave.
Up next are the video tests.
The color tests are as you would expect.
Actually, that is red-orange. Thanks, NTSC!
Yes. Yes, it is.
Ceci n’est pas un bleu.
It’s like my very own TV station that’s experiencing technical difficulties!
Trudging onward, the “Video Patterns” option performs five interactive tests. The text is perfectly readable, so I’ll omit my customary pithy sayings.
Last - also least - is the Rumble Pak Test. You can turn it on and off. Welp.
Now the real question is whether I’ll be able to get a dump of the cartridge and get it running - even partially - in MESS. There are certainly enough tests here that it should shake something loose really quickly.
Whose idea was it to deregulate the United States Postal Service, anyway? What kind of business stops taking phone calls at 4PM? I’ve been playing phone-tag with these bastards for the past week to try and find a mutually agreeable time for me to pick up the N64 Test Cartridge that I ordered on eBay, to no avail so far. Damn, man.
For no reason other than the fact that I felt like it, I decided to see if it would be possible to perform LLE RDP emulation while satisfying the desires of the “free games” crowd for high-resolution graphics. Sure enough, I was able to temporarily repurpose my coverage-related code into a simple 4x resolution scale.
For all of the following pictures, click on them to see a high-res version.
Mario 64:
Mario Kart 64:
Tetrisphere:
Diddy Kong Racing:
Star Fox 64:
Of course, this all comes at a cost: The already-slow coverage-related code is now running on the order of a second or so per frame. Still, it works, and with modern shaders and high-bandwidth buses there’s no reason why it shouldn’t be possible to get pixel-accuracy without sacrificing speed.
I’ve been rather busy at work lately, and will be for a while yet, so don’t expect too terribly many N64 updates in the coming months.
That said, I’ve converted the Controller Pak handling into actual pluggable devices using MESS’s device framework. The upshot is that games no longer need to attempt to format a brand new Controller Pak each time a game is started.
It seems that there are some lingering bugs, however - games report that there are 123 pages free on the Controller Pak, as they should, but attempting to create a new save file causes the game to claim that the Controller Pak is full. Ah well.
Apologies for the long delay since my last blog post, I’m quite swamped with work at, well, work. I guess that’s why they call it work.
As some of you may have heard and some of you may’ve not, the “Next Big Thing” as far as MAME is concerned is “decapping”.
What is “decapping”? “Decapping” is short for “decapsulation”, which involves removing the plastic packaging surrounding the silicon chip that comprises a microchip. Decapping is important, because depending on the skill of the decapper and the type of chip, it is possible to optically read out the contents of ROM on otherwise read-protected microcontrollers, zap security bits and electronically read out the contents of ROM on otherwise read-protected microcontrollers, determine the type of microcontroller used in a chip that has otherwise had its serial numbers filed off vis-a-vis custom fabrication by a third party (such as the CIC present in N64 cartridges), and more.
The Guru, of MAME dumping fame, is currently preparing a very large shipment of chips to be sent off for decapping. He’s agreed to send off any N64-related chips that need decapping, as long as I can get them to him in a timely manner.
I don’t want to sacrifice my single N64, nor do I want to sacrifice the single copies of some of my N64 games. I don’t have an eBay account, and I have no idea where I could locally find a large stash of used N64 games in the Albany, NY area. This is where you guys come in.
If anyone reading this blog post can spare one or all of the following to ship to me to in turn ship to Guru, I can offer my eternal gratitude:
Thanks in advance.
Tonight I fixed up the Controller Pak code to contain a valid initial image and fixed EEPROM support.
With the former, I can now browse a blank Controller Pak in various games’ Pak browsers. I could probably do more if I made MESS actually save the Controller Pak image:
With the latter, a number of games boot up for the first time, including Chameleon Twist:
Donald Duck: Goin’ Quackers:
Pilotwings 64:
Mario Party 2:
Tomorrow I’ll try to abstract Controller Paks as devices so that it’s possible to specify a Controller Pak from an external file.
I’ve got a grab bag of assorted updates tonight!
First is a feature that I implemented several weeks ago but never got around to posting - proper frame sizing based on VI registers. As the driver was written, it relied entirely on the FB_WIDTH and VI_CONTROL registers to determine the frame size, which was incorrect. Games only use those two registers to determine the gross sizing of the framebuffer, but the actual video timing signals are generated based on an entirely different set of VI registers. The end result was that in the previous implementation, a lot of games displayed garbage in the surrounding frame that was supposed to be resized out of the frame based on the VI register settings.
A quick fix later and the driver goes from this (click for big):
To this (click for big):
Incidentally, this also fixes a number of issues wherein garbage would be displayed during transitions, when the games would set up the VI registers to display an effective height or width of 0, which would obviously display nothing on a real TV.
Next up, apparently Ville forgot to plug in the appropriate CIC response code for 6102-chipped games, resulting in Star Fox (among others) not booting. A quick fix there, as well, nets us this:
It boots, but man is it slow.
Last but not least, some fixes to PIF comms handling have caused a few things to spring to life. Hooray!
First, tweaking the controller status parameters that were being sent back by the Read Pad command now satisfies Command & Conquer:
For some reason or other, Armorines was displeased with PIF comms as well, and my fixes seem to have placated it, though it has rather severe texture issues in the UI (throw another game onto the growing list of RDP issues):
Lastly, I have Controller Paks almost working. Games will at least detect that a Controller Pak is inserted, but it detects the Pak as being irreparably damaged - all repair attempts fail. I think this is because the Controller Pak needs to have a few pages pre-initialized with some data that games are unable to re-write in the event of corruption, but I’ll have to verify this on real hardware if I can find someone selling Controller Paks that are New Old Stock (yeah, good luck).
With those tweaks in place, games start to light up, but as I said, are displeased with the corruption (click for big):
That’s about it for tonight, stay tuned for work on the PIN64 Viewer sometime in the next week!
Rumor has it that sometime next week some good folks from NOA are going to be reading this blog in order to give a final yay / nay on whether or not I’ll be able to submit all of my improvements to MESS.
With that in mind, I looked over my blog myself, and I realized that at no point have I really laid out any kind of mission statement as to just what I’m doing and what I plan to do. With that in mind:
The Story
In the mid to late 90’s, emulator authors in pursuit of kudos from people looking for wholesale piracy while the N64 was still alive and kicking were attempting to write N64 emulators using the traditional method at the time: Have a C or C++ implementation of each opcode of each CPU in the relevant system, and simulate the display processor through software rasterization. By late 1998, the best emulators of their ilk were able to display the opening 2D legal screens of a handful of games, including Waverace 64 and Mortal Kombat Trilogy.
Depending on one’s perspective, January 28th, 1999 marked the point at which everything came up roses (if you’re in it for free games, you pirate) or went straight to hell (if you’re a company that cares about your IP), which was when a brand new emulator hit the scene: UltraHLE.
UltraHLE introduced two concepts of emulation that were relatively unknown at the time: Dynamic Recompilation (DRC) and library black-boxing, dubbed “High-Level Emulation” or “HLE”.
The former is a straightforward method of speeding up the emulation of high-speed processors in order to achieve more efficiency on commodity hardware. Unlike a standard “interpreter” core that requires the overhead with a function call for every emulated opcode, a DRC core will convert blocks of opcodes into sequences of assembly code that can be executed in one go, often caching off heavily-used translated blocks in order to mitigate the overhead of block conversion.
The latter is also straightforward in principle, but is a bit of a square peg trying to be forced into a round hole when applied to the N64. When applied to systems that have a coprocessor with a fixed program, the principle involves figuring out what the program is doing, and then simply simulating the effects of the commands that are sent to it rather than attempting to simulate the coprocessor itself. This is applicable to the N64 as well, with one rather humongous caveat: There are a number (around 10) of different microcode programs that games uploaded to the RSP (the N64’s vector coprocessor), and not all of them are fully understood. The end result is emulators with many per-game hacks in order to make them work properly.
HLE, in fact, is most likely what Nintendo is using for Virtual Console - this is mostly obvious by the fact that all games appear to be running at a full 640×480 resolution, there is no visible dithering in alpha blending, the Invisible Cap Mario in Super Mario 64 is drawn as completely translucent rather than using a noise dither pattern, and the same issue occurs when Mario’s model fades in and out during teleportation. The latter two issues are kind of sad, actually, as I can think of at least one method that could accomplish the effect on the GX.
Unfortunately, the nature of people wanting free games without supporting their publisher being what it is, the end result of HLE was that popular games were made to run fine, whereas lesser-known games or games that push the RSP in unusual ways run in either a glitchy manner or not at all. I actually suspect that this is the primary reason why certain popular games may be delayed or be completely absent from Virtual Console entirely - Blast Corps relies on the processing speed of the RSP and the drawing speed of the RDP to slow things down rather than run out of control, Goldeneye (licensing notwithstanding) uses a bizarre method for drawing the skybox, and Animal Crossing has many graphical issues on most all HLE-based emulators.
The Plan
I’ve always been an accuracy-minded fellow, and it always pained me that low-level emulation of the N64 went by the wayside in favor of haphazard grabs at popularity and kudos from people interested in little other than piracy. Redemption came in the form of MAME, around two and a half years ago. MAME emulates arcade machines, but there were a number of arcade machines made for the Seta Aleck64 hardware, which is little other than a Nintendo 64 on a custom arcade board and custom per-game inputs. Emulator author Ville Linde wrote a first-pass implementation of the Nintendo 64’s hardware, which ran well enough that Magical Tetris Challenge ran, as it used almost entirely 2D commands.
Over the coming six months during the first half of 2006, Ville put together a Nintendo 64 driver for MESS, the sister project to MAME; whereas MAME concentrates on arcade machines, MESS concentrates on computers and game consoles. A number of games booted, but the majority of them had issues ranging from crashing MESS to major graphical glitches.
In early 2007 I came to the decision that I would start contributing to MESS’s implementation of the Nintendo 64, as Ville went Missing In Action to the siren song of World of Warcraft. Someone was kind enough to donate a Nintendo 64 cartridge copier, and another friend of mine helped me get a cross-compiling version of GCC running that could compile code for the Nintendo 64. The project is located here, uses no official Nintendo development tools or libraries, and as such is completely legal.
Once the groundwork was put down I began to write a test suite for the Nintendo 64 that could run RSP code in parallel with MESS’s implementation, verifying register contents after each opcode was executed. For good measure I threw in a memory viewer, an input tester, and a couple other bits and bobs. Thus was born NUTS: Nintendo Ultra64 Test Suite.
Until late 2007, all of my work was done to produce an initial version of NUTS. However, once NUTS was mostly done, I became interested in tackling the RDP as well, since Ville was well and truly engrossed in World of Warcraft and nobody else was stepping up to the plate. In the past six months I’ve begun working on a new tool, PIN64: Polygon Inspector for Nintendo 64. The end goal is to be able to capture a frame’s worth of RDP commands from MESS, then play back that frame in a separate program, being able to view the individual commands and the RDP’s state while the frame is being built. In addition, a user should be able to then play back that frame on a real Nintendo 64 as well, in order to compare how the RDP commands would behave on real hardware versus the current emulation state. You can see the current state of PIN64 in previous blog posts.
The Rules
The rules are simple: Do everything legally, accurately, and non-competetively.
From a legal standpoint, my intention is for everything to be on the up-and-up. This means that I will not use any confidential Nintendo documents, tools or hardware.
From an accuracy standpoint, I want to make MESS good enough that anything that will run on real hardware will run on MESS with no modifications and no degradation in graphical or aural quality. This means fully emulating every aspect of the RDP including coverage.
From a competition standpoint, unlike the folks who wrote HLE-based emulators, I am not in this for kudos, and I am not in it for free games. My goal is expressly for MESS not to draw attention away from Nintendo’s Virtual Console service. My accuracy goal will probably do this for me, as accuracy will in turn affect the overall emulation speed; the current inaccurate RDP implementation and interpreter RSP implementation causes games to run at an average of 10% of full speed on my average-spec laptop. Things will likely only grow slower as I make the RDP implementation more accurate.
This is not to say that I will reject any patches from other developers that increase the speed of MESS’s Nintendo 64 implementation without affecting accuracy, but I myself will not go out of my way to seek out kludgey optimizations.
In short, my entire goal can be summarized as follows: Do not upset and do no harm to Nintendo.
So far everything is on the up-and-up; now we can only hope that NoA agrees.