October 8th, 2012, 08:23
Maybe post some code and show us what instructions you have simulated, what you have left to add etc (to maybe lessen the need for self bumps)
October 8th, 2012, 14:54
Originally Posted by Remote
Interfaces and overall structure is absurdly unstable.
Insns: ADDIU, ANDI, BEQ, BEQL, BNE, BENL, ORI, LUI, LW, XORI.
Most of the execution unit itself is (obviously) unimplemented. I only implemented enough instructions to get an idea of 'how fast' the pipeline currently is (where the aforementioned testing essentially dumbed down to a LW/ANDI/BEQL loop).
I spent the last week or two trying to see if it was actually possible to simulate the pipeline at full speed (which I fully believe it is). Most of the focus right now is getting the interfaces up to speed. I hope to get an actual, clean cache/memory interface up within the next week or so (not the shoddy excuse of an inline half-arsed lookup that's currenlty in place). After that, I'll move on to implementing most of the pipeline and actually get something going.
EDIT: There are a couple design issues with the code that I'm currently aware of and intend battling in the future. Most of these are due to my initial hope that everything couple be threaded and not have horrendous performance on 32-bit architectures, but I've had to toss out those interests in order to get decent performance (i.e., 32-bit TLB lookup and write entry interfaces probably need to be nixed and replaced with a sole 64-bit version).
I've only been working on this project for a little over a month now, so if it looks infantile, that would be why :p.
Last edited by MarathonMan; October 8th, 2012 at 15:05.
October 16th, 2012, 05:41
Lots more progress. Made an actual emulator repository (right now, will likely only compile on Linux machines, though).
* Currently wads all the way through IPLROM and loads the first few pages of cartridge ROM into memory and begins executing it.
* Lots of performance improvements. Even a lowly C2Q at 2.0GHz is almost able to handle the grunt for the time being. I shocked myself with the performance of this thing (considering caches are currently disabled and there are no delays currently in place for memory accesses -- both of which will improve performance substantially). I do expect it to get worse... but only because cycle-accurate emulation on a processor of this calibre would be unreal.
October 16th, 2012, 21:13
I have to admit that I totally don't understand what you're doing (i.e. the code), but I'm still impressed
Last edited by DETOMINE; October 16th, 2012 at 21:17.
October 17th, 2012, 00:35
Enjoying this read. Please keep up the good work and keep us involved!
October 17th, 2012, 19:07
You posted a lot of code, I was thinking more that you post maybe a loop where you write some short comments on what you are doing and what registers you are simulating/emulating to get interest brewing. Keep ut the work and maybe post a short todo list where you can show what you want to do in the closest future and when you reach a goal you can check/update your list.
October 18th, 2012, 00:43
Probably a good idea :p
Originally Posted by Remote
What the VR4300 core currently lacks:
* TLB interface, instruction and data caches.
* Several instructions/opcodes.
* Interlock/fault handlers.
* COP0/COP1 (MMU/FPU).
* SysAD synchronization.
* Proper memory access delays.
* Various other doodads.
What the VR4300 core currently has:
* Basic pipeline structure, register file, fault queue.
* 25% of the execution unit implemented.
* Memory load/store interface.
* Virtual address resolver.
Basically, I've implemented enough to get the VR4300 to boot the PIF ROM in it's entirety. In addition, I have _just_ enough of the actual console components (audio, video, PIF, etc.) to get the VR4300 to pass all the initialization phases of the PIF ROM. Correct me if I'm wrong, but MESS is the only other emulator that I'm aware of that currently uses the PIF ROM to boot (not that it's super important or anything).
What's up next?
* More work on the VR4300 core: more instructions!
* Something to show that this project isn't vaporware (perhaps an incredibly anemic video controller or something).
* Move on to VR4300 caches, performance improvements, etc.
* Then focus on the rest of the components (video, audio, etc.)
As always, the first and foremost goal is accuracy, with performance and design closely following. Each component of the system is an entirely separate entity (library) that gets linked together in the final executable.
October 18th, 2012, 20:40
Amazing. I don't understand a lick of it, but it sounds like this is promising!
October 18th, 2012, 20:56
The Great Gunblade Wielder
an lle recompiler is not impossible at the end of all this.
October 19th, 2012, 02:45
I wonder if the undocumented DCT RSP opcodes will be added.