OP
MarathonMan
Emulator Developer
- Thread Starter
- #421
I would still advise actually emulating cycles on a cycle accurate emulator ;-)
It should be done as early as possible otherwise you will end up with something very similar to existing emulators except you have splitted cpu emulation to several stages. BTW, the real benefit (accuracy seen from the games code) to emulate each stage is to have correct cycle counts and cache. It is also important to take into considerations all possible case where the pipeline stalls. I remember having a hard time figuring out how to emulate data bypass between stages especially with the 2 cop1 registers formats: this is one of the cases that involve pipeline stalls if i remember right. Anyway, i can tell you to be very careful with cache and timing, it really has an effect on the machine seen from the software and some roms do really weird things (i'd say they were very lucky that all n64 were behaving exactly the same, it hides a lot bugs).
I am still not convinced i can really run it fullspeed. Things like cache and write buffers add many things that should be checked for nearly each instruction and timing between all components takes a lot of time. The problem is not really to add delay. It is to let each components do its jobs at the same time and synchronize everything at the right number of cycles. I have also tried to emulate as correctly as i could the behaviour of the VI interface, it is also taking a good amount of cpu time (i am not talking about crt emulation that is virtually free as it is done with GPU). Taking all of that into consideration, i still think it will be extremely slow with RDP. Then again, i am not doing this project with speed as a requirement at this stage.
I won't share source code right now as a lot of values are really experimental and i feel that if i spread it, it would prevent other people from doing their own tests on the real n64. I think it is quite important now, that different people do their own experimentation and later we can share and compare to hopefully fully understant how the hardware is behaving exactly. That said, if you have any question that you feel i can answer, feel free to ask. I will do my best to answer.
Barring cache accesses and coprocessor interlocks and such, I am cycle accurate in the sense that I'm modeling the pipelines, and the ratios of the device clocks are correct (the vr4300 runs at precisely 1.5x the speed of the RCP, etc.). I'm sure the timings with the cache will make a difference (look at the iQue -- things like Ganon's castle falling in the final scene is MUCH smoother when the system is backed with DDR RAMs), but I've already planned out how it will fit in and I don't see it being much of a problem to come back to at a later time. To be fair, if you want to be really cycle accurate, you also need a cycle-accurate RDRAM model to simulate the latency of the RAMs... which involves keeping track of the refreshes and accesses... I'm okay with saving this for a later time in the interest of better overall support at the moment
.I haven't bothered with the VI interface at all yet, either. I just do a naive copy to video texture memory and raster it on a quad. Again... planning to do this at a later date but pushing it off in interest of getting to the RSP/RDP/etc. My philosophy is to build a structure that stands as a proof of concept, then paint the walls and fill in the holes.
. Something like the VI interface will hopefully be amenable to buffering and vectorization to help eliminate such performance issues.I understand your decision to not release the source. I'll let you know if I run into any issues -- thanks for the offer to help!
- M
