so..... this is still on track to interpret Rogue squadron at 60fps right ;D
The slowdowns right now are due to the fact that I'm not simulating the caches and have to use the bus to communicate with the RDRAM on a per-cycle basis. I also don't stall on RDRAM. That being said, I can still sift through ~50 million instructions on a powerful machine, so I'm hoping that the IPC of the actual console is somewhere around that range.
EDIT: On the plus side, there won't be any "oh, does it run X game or Y game well?". Really, for a simulator, all games are equally challenging. If it runs one game well, it should run them all well (within reason).
I think it's pretty cool with a cycle accurate N64 emulator in progress and my suggestions was mainly that you could use a preexisting plugin to get the visual part while working on the core and then just remove support for it and swap it with a software renderer.
I was just saying: don't try to compare the game with the lowest known requirements and compare it to Conkers.like how RARE games completely abused the actual console
Whoo hoo. Interrupts being handled well enough for Super Mario 64 to start running its way around libultra. I can even see the OS scheduling different threads (due to the large streams of LWC1/SWC1 during context switches).
Couple more unimplemented instructions that are likely causing things to break shortly after that though...
Random thought regarding being "polygon accurate" - wouldn't this also allow external textures? I know some fan translations like Sin and Punishment (pre-virtual console) use external textures for english text.
Pretty sure it's the only translation that relies entirely on texture packs. That's mostly because they were too lazy to encode and reinsert them (although you can use upsclaed images easier this way). It's not like the compression isn't known either.