What's new

On the road of accuracy

OP
Hacktarux

Hacktarux

Emulator Developer
Moderator
Not much progress last month as i had a lot of real life things to deal with but still some new things implemented:
- pi timed as precise as i could
- checksum check during boot process pass now that i have fixed a bug in bypass path of the r4300 pipeline

To get the first demos working i think i need to implement a cycle accurate fpu and video output. The main problem is that emulation is quite slow, i need a few seconds to execute the checksum code during boot process.
 
Not much progress last month as i had a lot of real life things to deal with but still some new things implemented:
- pi timed as precise as i could
- checksum check during boot process pass now that i have fixed a bug in bypass path of the r4300 pipeline

To get the first demos working i think i need to implement a cycle accurate fpu and video output. The main problem is that emulation is quite slow, i need a few seconds to execute the checksum code during boot process.

You can do it! :king:
 

ihearpixels

New member
cycle accurate fpu and video output.

No cycle accurate r4300i/RSP?

>_> If you want to go cycle accurate, do it properly and do the whole fucking thing. We can wait 10-30 years for faster PCs that will run said things with cycle accuracy. One MAMEdev suggested their LLE N64 emulation will require a 12Ghz multicore CPU for peak performance. I am sure people are willing to wait that long.
 
OP
Hacktarux

Hacktarux

Emulator Developer
Moderator
Calm down, i never said other parts are not cycle accurate. They will be either cycle accurate or as accurate as i could measure on the real machine. The fpu is a part of the r4300. I have not even started RSP emulation. I am only posting a few words to say what i am currently working on, it is not a detail of everything that has been done and everything that is planned.
 

ScottJC

At your service, dood!
Riiiiight.

I will wait until everything is 90-100% cycle perfect before making more points.
Progress is progress whether you are able to use it or not.

Worst case scenario, Hacktarux creates an emulator that is completely unusable for x number of years

Even then if the source code is released that could be useful for a number of reasons, someone might come along and use it as a reference - It saves having to do the research on the n64 again.

You seem to give off the impression that Hacktarux is wasting his time by doing this, I don't see how doing nothing is productive.

Well I prefer progress to nothing, whether I can use it now or not.

Btw, go back 7 years and apply that narrow minded look to pcsx2 - imagine if they just sat on their arse and did nothing, now pcsx2 is playable for a fair number of games and getting better all the time. the wait and see approach DOES work.
 
Last edited:

Clements

Active member
Moderator
Big progress has been made in recent years by using LLE graphics plugins to get games working that have never worked before. N64 graphics plugin development is a much smaller deal nowadays, as making improvements is becoming exponentially difficult using HLE. An accurate full LLE N64 emulator with good debugging tools and such would document the system and help progress the HLE emulators as well with the findings. I wish Hacktarux luck with his project. :)
 
OP
Hacktarux

Hacktarux

Emulator Developer
Moderator
I think now, most of the system is emulated except RDP. It runs really slow, the fire demo by LaC is running at approximately 10 VI/S. Below is a video of the fire demo running with an interlaced crt emulator.

 

Azimer

Emulator Developer
Moderator
Good to see progress Hack. Care to give us anymore information on what you are doing now compared to how you emulated the N64 with Mupen?
 
OP
Hacktarux

Hacktarux

Emulator Developer
Moderator
Hi azi,

it is focused on accuracy and clean design, here is the list of the main differences i see:
- clean object programming model that really documents all i know about the n64
- the main loop is event based and not opcode based (for example, an event can be word written by the pi dma, or a new line processed by the vi or a r4300 cycle
- r4300's 5 stage pipeline emulation
- r4300's data and instruction cache emulation
- cop0 hazards emulation
- write cache emulation
- rdram bank switch timing
- every rcp register read/write timed as measured on real hardware
- vi emulation more accurate with the same antialias and dither filter as the real hardware
- crt emulation that supports interlaced output (based on cgwg glsl filter).

There are probably some other things i can't remember.
 

Top