Trotterwatch
Active member
Fantastic news 
On the road of accuracy
- Thread starter Hacktarux
- Start date
ExtremeDude2
Member
I have a love-hate relationship with plugins.
What up with all of the spam?
Last edited by a moderator:
OP
- Thread Starter
- #25
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.
- 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.
ExtremeDude2
Member
You can do it! :king:
ihearpixels
New member
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
- Thread Starter
- #28
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.
ihearpixels
New member
Riiiiight.
I will wait until everything is 90-100% cycle perfect before making more points.
I will wait until everything is 90-100% cycle perfect before making more points.
ExtremeDude2
Member
Sticky?:bounce:
ScottJC
At your service, dood!
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:
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.
ExtremeDude2
Member
Update? :bouncy:
weinerschnitzel
Surreal64 Nut
This is great to see! Thanks for the update Hacktarux, good luck with the RDP!
OP
- Thread Starter
- #40
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.
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.