Nintendo Maniac
New member
Wow, I'm on a roll with these "derp moments", aren't I? Maybe I should just stop talking...
Announcement: Cycle-accurate N64 development underway.
- Thread starter MarathonMan
- Start date
Wow, I'm on a roll with these "derp moments", aren't I? Maybe I should just stop talking...
OP
MarathonMan
Emulator Developer
- Thread Starter
- #62
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
Emulator Developer
- Thread Starter
- #63
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.
- 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.
Nintendo Maniac
New member
I gotta ask, what CPU are you running your micro-benchmarks on?
OP
MarathonMan
Emulator Developer
- Thread Starter
- #65
#1) 2600k @ 4.5GHz.
#2) Q8400 @ 2.0GHz.
I use the latter to try and get a sense of what the "average" user is going to experience.
straightflushin
New member
Very impressive, well done! I can't help much, but I'm really enjoying following your progress here.
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!
I can't wait to see your program in action!
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.
Therefore it would seem like this emulator is going to be particularly of interest to me in the future.
OP
MarathonMan
Emulator Developer
- Thread Starter
- #69
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?
ExtremeDude2
Member
n64 has no BIOS
Nintendo Maniac
New member
So it's like the SNES in that regard? That's convenient.
...I just realized, the systems with BIOSes have boot-up screens, such as the Game Boy Advance. I presume that such a boot-up screen is what requires the need for a BIOS in the first place?
F
Fanatic 64
Guest
As far as I know, the N64 does not have a BIOS (which means no).Thanks for the explanations
OP
MarathonMan
Emulator Developer
- Thread Starter
- #74
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
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
Emulator Developer
- Thread Starter
- #76
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.
Nintendo Maniac
New member
Oh, so you're following the Project64 methodology with plugins rather than the Dolphin method of total integration. Gotcha.
OP
MarathonMan
Emulator Developer
- Thread Starter
- #78
Sort of. Right now, all the libraries are statically linked, so developers control the plugins selected; not the users.
Nintendo Maniac
New member
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
http://forums.dolphin-emu.org/Thread-new-ax-hle-what-is-it-and-how-does-it-work
OP
MarathonMan
Emulator Developer
- Thread Starter
- #80
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.