What's new

Announcement: Cycle-accurate N64 development underway.

OP
MarathonMan

MarathonMan

Emulator Developer
Wow, I'm on a roll with these "derp moments", aren't I? Maybe I should just stop talking...

The "official" documentation is still neither complete, nor without errors. Aside from a few opcodes that appear to only be function on dev kits, I believe I have everything. Time will tell!
 
OP
MarathonMan

MarathonMan

Emulator Developer
Been a couple days, so bumping for an update.

- The assembler I wrote has paid itself off a hundred times over. Found quite a few bugs in the scalar unit and hammered them all out.

- All instructions other than LWC2/STWC2/CTC*/MTC*/MFC*/VECTOR are done and all infrastructure is in place, so the next week or so will likely be spent implementing instructions.

- Before instructions enter the pipeline, my simulator must classify them to determine if it needs to create stall cycles due to load, store, or use dependencies. Runtimes for my micro-benchmarks were getting quite poor, so I profiled the simulator and realized I spent a large fraction of time classifying the instructions (as it was resorting to a jump table twice per cycle). I implemented a much more clever solution that involves only one conditional branch and two array fetches and was pleased to see that it went from being one of the largest time hogs to one of the smallest time hogs. Not only that, but depending on the complexity of the instructions targeted by the microbenchmark (i.e., a 'add' is much simpler to execute than a 'lwv'), the runtime changes drastically. This is, in my opinion, good as it suggests that my code is spending a good chunk of time doing 'actual work' and less time interpreting instructions. Implementing that solution also made me realize that there's another large potential optimization vector related to the interpreter that will save me a good chunk of time, but I'll leave that for later.

- I started implementing some of the LWC2/SWC2 instructions (and finished 'lbv', 'lsv', and 'lwv' last night). To my surprise, no other "LLE" emulators pay attention to endian-ness -- all IMEM/DMEM is stored in little-endian byte order! My simulator has is that it always maintains a big-endian byte order representation of IMEM/DMEM. This will 'fix' any ROMs that have ucodes that depend on big-endian byte-ordering (should they exist), and eliminate the need for "byteswapping" ROMs at the cost of a small performance hit.

'sall for now, folks.
 

straightflushin

New member
Been a couple days, so bumping for an update.

- The assembler I wrote has paid itself off a hundred times over. Found quite a few bugs in the scalar unit and hammered them all out.

- All instructions other than LWC2/STWC2/CTC*/MTC*/MFC*/VECTOR are done and all infrastructure is in place, so the next week or so will likely be spent implementing instructions.

- Before instructions enter the pipeline, my simulator must classify them to determine if it needs to create stall cycles due to load, store, or use dependencies. Runtimes for my micro-benchmarks were getting quite poor, so I profiled the simulator and realized I spent a large fraction of time classifying the instructions (as it was resorting to a jump table twice per cycle). I implemented a much more clever solution that involves only one conditional branch and two array fetches and was pleased to see that it went from being one of the largest time hogs to one of the smallest time hogs. Not only that, but depending on the complexity of the instructions targeted by the microbenchmark (i.e., a 'add' is much simpler to execute than a 'lwv'), the runtime changes drastically. This is, in my opinion, good as it suggests that my code is spending a good chunk of time doing 'actual work' and less time interpreting instructions. Implementing that solution also made me realize that there's another large potential optimization vector related to the interpreter that will save me a good chunk of time, but I'll leave that for later.

- I started implementing some of the LWC2/SWC2 instructions (and finished 'lbv', 'lsv', and 'lwv' last night). To my surprise, no other "LLE" emulators pay attention to endian-ness -- all IMEM/DMEM is stored in little-endian byte order! My simulator has is that it always maintains a big-endian byte order representation of IMEM/DMEM. This will 'fix' any ROMs that have ucodes that depend on big-endian byte-ordering (should they exist), and eliminate the need for "byteswapping" ROMs at the cost of a small performance hit.

'sall for now, folks.

Very impressive, well done! I can't help much, but I'm really enjoying following your progress here.
 

Nintendo Maniac

New member
Welp, with the newest Nintendo Direct, it's very obvious to me that Nintendo is not interested in the same things I'm interested in. It is safe to say that, unless it gets homebrew'd and hacked up the wazoo like the Wii, the Wii U is not for me.

Therefore it would seem like this emulator is going to be particularly of interest to me in the future.
 
OP
MarathonMan

MarathonMan

Emulator Developer
https://github.com/tstache1/cen64 give me an error 404, did you change the link?

I can't wait to see your program in action!

Apologies. CEN64 is intended to be the "final application", which is composed of several plugins -- "librsp", "librdp", and "libv4300". I have taken down CEN64 for two reasons:

1) It was too much of a hassle to keep the framework's interfaces in lockstep with the libraries.
2) I've been considering changing the license from GPLv3 to Apache (or something else).
 

DETOMINE

New member
Apologies. CEN64 is intended to be the "final application", which is composed of several plugins -- "librsp", "librdp", and "libv4300". I have taken down CEN64 for two reasons:
1) It was too much of a hassle to keep the framework's interfaces in lockstep with the libraries.
2) I've been considering changing the license from GPLv3 to Apache (or something else).
Thanks for the explanations :)

I was wondering something, will cen64 need a N64's bios?
 
OP
MarathonMan

MarathonMan

Emulator Developer
As far as I know, the N64 does not have a BIOS (which means no).

The N64 does not have a BIOS in the traditional sense, but yes, there is a "bootrom" located in the peripheral input device that copies the next stage of boot code off the cartridge (PIFROM; mapped to physical address 0x1FC00000 to 0x1FC007BF). In addition to that ROM, there's also some proprietary ROM necessary for pixel-accurate rendering.

As for the PIFROM, I eventually emulate it so that it's not a requirement for simulation. This is what any other N64 emulator does as all the PIFROM really does is copy a tiny bit of data and set some registers before passing off control to the next stage.

As for the point/slope ROM, it will be a requirement for pixel-accurate rendering. If/when I get around to writing a "traditional" RDP plugin, the point/slope ROM will not be required as the "traditional" plugin will just translate the RDP command lists into OpenGL calls.
 

Nintendo Maniac

New member
As for the point/slope ROM, it will be a requirement for pixel-accurate rendering. If/when I get around to writing a "traditional" RDP plugin, the point/slope ROM will not be required as the "traditional" plugin will just translate the RDP command lists into OpenGL calls.
Wait, so this WILL be using OpenGL rasterization and not software rendering? Then why was mudlord so adamant that this would use software and therefore polygonal enhancement (such as AA & AF) would be out of question?
 
OP
MarathonMan

MarathonMan

Emulator Developer
Wait, so this WILL be using OpenGL rasterization and not software rendering? Then why was mudlord so adamant that this would use software and therefore polygonal enhancement (such as AA & AF) would be out of question?

No, it will use software rendering by default. However, all the libraries (librdp, for example) are pluggable and thus if/when I create a second render library, it won't need point/slope ROM.
 
OP
MarathonMan

MarathonMan

Emulator Developer
Oh, so you're following the Project64 methodology with plugins rather than the Dolphin method of total integration. Gotcha.

Sort of. Right now, all the libraries are statically linked, so developers control the plugins selected; not the users.
 
OP
MarathonMan

MarathonMan

Emulator Developer
Then isn't it more like Dolphin actually? Originally it used plugins but they got integrated in. I believe they are still somewhat modular on the development side however since, for example, they're developing a new HLE audio engine and it just replaces the "module" that has the old HLE audio:
http://forums.dolphin-emu.org/Thread-new-ax-hle-what-is-it-and-how-does-it-work

Never used Dolphin. But yes, the idea is that only developers control the plugins. I dislike the idea of plugins flying all over space as they do in PJ64 and others.
 

Top