October 19th, 2012, 12:39
Care to explain your thoughts a little further on this one?
Originally Posted by squall_leonhart
I thought a recompiler core was out of the question due to the fact that you could have instances where, on one block of code, you have cache misses, whereas in another, have hits. I suppose you add x86 instructions to take that into account as well, but the gains aren't going to be as large as non-CE emulators.
I've actually been thinking about ways to possible multithread or add some compiler support way down at the end of the road.
I was almost thinking something along the lines of ROB entries, but in software. Doing this would enable me to perform speculative execution on each core and not synchronize on every cycle, as this has proven to be prohibitively expensive. If I end up having to toss out a few entries here and there, it's no big deal because there would be so much more processing power at my expense. I've writing the simulator in such a way that I can augment it with statistics to determine exactly how much communication occurs between the cores to see how plausible this idea is.
But I'm getting WAAAY ahead of myself at the moment. For now, I'm just working on getting the core implemented.
October 19th, 2012, 12:43
Again, way down at the end of the road, I might look into buying an Indy with a u64 board if it's not going to cost my heart and soul. There's simply not enough information out there to make a fully CE RSP core right now.
Originally Posted by mrmudlord
October 20th, 2012, 20:30
Carts are booting. Tested two carts -- CIC-NUS-6102 (Super Mario 64) and CIC-NUS-6105 (Zelda: OOT). As long as the correct seed is placed in PIF RAM before the IPL2 gets control, all checks pass and the actual game code starts executing.
On to emulating another handful of instructions and possibly some basic video (within the next few weeks? No idea how long this is going to take...).
Last edited by MarathonMan; October 20th, 2012 at 20:34.
October 21st, 2012, 01:30
You shouldn't have much trouble getting an indy and a U64 board though you'll probably end up spending over 350 bucks easy. If they for some reason don't have the software just ask someone who already owns one to copy it for you ( I think it's on about 8 CD's). They'd probably be more then nice enough to do it. Not sure why you'd need it for developing an emulator though. Wouldn't something like a 64drive flashcart and a used N64 suffice?
Originally Posted by MarathonMan
Last edited by Zuzma; October 21st, 2012 at 01:33.
October 27th, 2012, 23:51
I would imagine that having a "real" developer platform gives you a little more flexibility. Failing that, it's certainly a time-saver (and it would be nice to have, for posterity's sake :p).
Originally Posted by Zuzma
Anyways, weekly update:
Not a whole lot of progress this week. Worked out some bugs, added some new instructions, etc. I've implemented enough of the VR4300 core to the point where the ROMs appear to be sticking themselves in a busy loop and waiting for the RCP and friends to respond (at least, I think that is what's occuring). hopefully I can get around to implementing some of the RSP/RDP and really getting things going sometime soon.
October 29th, 2012, 01:23
It would indeed be more flexible. I was just thinking more of the price point and the fact that you wouldn't be waiting around for a U64 board (waiting for a lower price that is). Thanks for the update too! It's really interesting to see the actual code progress. Good luck with emulating this beast of a console system!
Originally Posted by MarathonMan
Last edited by Zuzma; October 29th, 2012 at 02:52.
October 30th, 2012, 19:59
Lots of information undercovered about the RSP... maybe the community is aware of this, maybe not, but here's what I've been able to confirm (using a developer platform and studying ucode):
The claim that the RSP is a "R4000-based" microprocessor is a little rough on the edges. The RSP, while is does belong to the R4000 series, is much more like the R4300i-based core. It, too, has a 5-stage pipeline and is one of the "less beefy" members of the R4000 series. The primary difference between the VR4300 core and the RSP is that the RSP has a vector co-processor.
The really neat thing, that I'm not sure well known about the RSP, is that it appears to be dual-issue. It'll actually execute two instructions per cycle (if possible): one scalar instruction, and one vector instruction. It also looks like the RSP will stall the pipeline if it detects hazards (which the VR4300 does not!)... but maybe too little sleep is throwing off my brain.
If that seemed like a bunch of jibberish, no worries. I suppose the conclusion of all of this is that a cycle accurate simulator, fully modeling both the VR4300 and RCP, is absolutely possible (with enough time!). Over the last few days, the architecture of the RSP has absolutely overwhelmed me -- I had no idea that it was this impressive. I'll have to rethink my current design and hack away for quite awhile. In terms of getting something running at full speed -- this is going to be quite the challenge. Modeling a dual-issue 32-bit scalar/128-bit vector pipeline is nothing short of a large challenge.
... but it does mean that we'll eventually have an emulator that 'just works'
October 30th, 2012, 23:51
I know it may sound funny, but every time I read you, I feel like I'm participating at a forbidden and crazy experiment. It's like you're playing with powerful and unknown forces.
I still don't understand what you're doing though.
edit : keep up the magic man, it's awesome!
Last edited by DETOMINE; October 30th, 2012 at 23:54.
November 11th, 2012, 18:20
November 11th, 2012, 22:55
I can't wait to see the first screen-shots .
I was wondering, does your project use some of the mame code?