F
Fanatic 64
Guest
I'm the 3rd user in the database (1st one to register) 
I guess that makes me a senior member?
I guess that makes me a senior member? Announcement: Cycle-accurate N64 development underway.
- Thread starter MarathonMan
- Start date
I'm the 3rd user in the database (1st one to register)
Jealous i got 12th
ExtremeDude2
Member
Net_Bastard
New member
I just want to say, I'm glad that this is happening. The last few days I was thinking about how messed up the N64 emulation scene is. But it seems like it still has a pulse. I hope that this project works out in the end.
I made a really basic frontend for CEN64 that was overhauled by Beannaich . If there's any problems with it I can try to fix them, as well any features you want let me know I can see what I can do.
For latest version go here
http://cen64.com/viewtopic.php?f=5&t=8
For latest version go here
http://cen64.com/viewtopic.php?f=5&t=8
Last edited:
Last edited:
OP
MarathonMan
Emulator Developer
- Thread Starter
- #930
Real life/work, illness, marathon training, ... take your pick. These two weeks will prove to be especially busy at work. :doh:
I definitely haven't gotten much time to work on CEN64 lately. Anyways:
* I am internally working on a rewrite of the VR4300 core that will permit me to multi-thread CEN64 (I also found a few bugs, but I'm not certain that they were ever encountered since most of them were edge cases). There are lots of extra steps that need to be done when multi-threading a cycle accurate simulator (the VR4300 core basically needs to be able to "rewind" itself back in time), so I am not sure that it will be faster, or how much faster it will be if it proves to be faster.
Programming perspective: I checkpoint the state of certain pieces of the core and basically treat time as a transactional event. Basically, I commit several cycles of simulation at a time, while keeping checkpoints of the core at previous places in time around until I am certain that every core in the system has elapsed past that time. If there was an interrupt or some event that another core raises that occured in the past, I rewind to the closest checkpoint that proceeds that event and replay the simulation, only this time I service the interrupt that occurred in the past. The hope is that communication with the bus is sparse enough that large checkpoint intervals can be used and the VR4300 can execute mostly undisturbed on it's own host core and only potentially have coherency issues when accessing common components like RDRAM.
* I'm also working on internally experimenting with implementing the VR4300 on an FPGA. Maybe something like FPGABoy, but FPGAN64 (!), will be a reality. I don't know anything about FPGAs, though, so it's been a learning experience. But I could say the same for the C programming language 4 years ago, and N64 emulation about a year and a half ago... so who knows what the future will bring.
OP
MarathonMan
Emulator Developer
- Thread Starter
- #932
Things have been pretty quiet, unfortunately. Haven't had a lot of time to hack lately. What time I have is still going into a newer VR4300 core that should hopefully bring CEN64 a lot closer to real time performance.
I've also been using the new core to start implementing a soft-CEN64 in hardware (verilog) on a Terasic DE0-Nano FPGA (~$55 academic, ~$75 non-academic), which has proved to be a challenging, yet interesting approach to the "limited speed" problem. The DE0-Nano probably won't be sufficient once the RSP/RDP are implemented -- something like a Cyclone V GX is probably closer to being realistic. I also have to look into legality issues... even with a clean-room approach, I'm not sure the legality of releasing this.
Currently regrading soft-CEN64, I'm focusing on implementing a R4300i core -- it looks as though this part of the console, caches and all, should fit on the DE0-Nano without any issues. My SDRAM controller is able to deliver >100MB/s for 16-byte line accesses at much lower latency than the N64's RDRAM, so should be enough oomph to supply the R4300i for now (?)
Switching back to CEN64, kromy has gotten some audio demos to work. He's also been working on some experimental OpenGL stuff. Though, as far as I know, he, too, has been fairly tied up in other things.
F
Fanatic 64
Guest
Well, as long as it's progressing, even if slowly, and you don't dissapear from the internet, everything is great.
I'm also interested about that hardware N64 emulator. That would truly be a "cycle-accurate N64 development underway"
I'm also interested about that hardware N64 emulator. That would truly be a "cycle-accurate N64 development underway"
Nintendo Maniac
New member
As a Trinitron CRT user, I do not understand. Cen64 already outputs at 640x480, and all monitors that are at least like 25 years old should be able to display 640x480.
The only thing holding Cen64 back is that, AFAIK, it does not include a fullscreen option; IIRC there are front-ends that do support this however.
Nintendo Maniac
New member
As of right now Cen64 always outputs to a 640x480 window. I don't know about other resolutions, but 640x480 is rendered natively while 320x240 is upscaled 200% via nearest neighbor (aka "pixel doubling").
Are you aware that Cen64 has an official forum now? (http://cen64.com) You may be able to get a more in-depth discussion and response on the subject if you ask on there.
I don't really care about optimizations or whatever the hell they do in MAME/MESS, I mostly care about accuracy, but by fixing a few bugs this fine gentleman apparently means going from MESS 0.128's renderer of November 2008, that I started to work with, and haven't looked back at MAME/MESS code thereupon, to my current SVN:
https://code.google.com/p/angrylions-stuff/source/browse/trunk/#trunk/mylittle-nocomment
Everybody possessing an eye or two should be able to make their own conclusions, whether it's a few bugfixes or a rewrite of all RDP's subsystems pretty much beyond recognition, by running their favorite diff tool on these two files, video/n64.cpp from MESS 0.128 and my n64video.cpp and by tracing MAME's and my changelogs. Everybody should be able to find out, how much of the code has been downright rewritten by myself, like 5% or, to the contrary, let's say close to 60%. Likewise, everybody is free to make their own judgment on the importance of passing dozens of RDP hardware tests that I have here on my hard disk (sure enough, the current MESS can't pass them all, because not all of my accuracy improvements have been backported), on the importance of resolving many incidents of conflicting information between the so-called "C simulator" and the so-called ".V files", on the importance of turning bits of information that are only present in more cryptic parts of ".V files" into legible C, and on the importance of jumping from ehm... let's be somewhat generous... let's say, infant state of MESS 0.128 renderer (and let's omit the fact that said renderer also had a habit of crashing like a hooker coming off her drugs) to zero known RDP-caused bugs in commercial games (yes, I've personally tested them all, E and U versions, to some extent), not to mention that display lists of a few games that still exhibited visual glitches with my plugin in the currently available plugin-based emulators were dumped and turned into hardware tests to make sure that these glitches were not caused by the RDP.
I also want to point out that this gentleman has been famous among oldbies of the emulation community since at least 2004 for his refined ethics. For instance, if you somehow happen to casually mention to him that some of his code changes run slower on a certain processor or mention that you sent a neutral RSP related email to someone else without mentioning this sir's "pioneering" (but unrelated to the particular matter in question) work or something equally innocent, he wouldn't hesitate to call you a f*cktard or sh*tf*ck, depending on the position of constellations in Sweden's night sky, and apply all the other designations that regular readers of MESS shoutbox and various MAME related forums are all too familiar with for they're honored to be exposed to reading his unprovoked swearing there at least once a couple days. Perhaps only mudlord could compare to him in the strictness of his moral principles, let alone basic civility. Taking this into account, no one should be left wondering why the hell this good sir is all too ready to staple a label of "his own" on the code that's also been in a great part written by Ville Linde, which is totally obvious even from a cursory glance at any N64 related progettoemma page, let alone obvious to those who followed the events of 2006-2008.
If a certain emulator developer prefers to repeatedly refer to the code on my SVN as a "MooglyGuy's and MAME team's renderer" and thus save himself the trouble of mentioning my humble contributions, then he'll probably be better off reverting to MESS 0.128 renderer as far as accuracy is concerned, purging all the nonsensical and pointless code I've written over the years and maybe after that re-adding C++-ifications and optimizations committed by MooglyGuy since November 2008 until these days, along with his contributions of another kind made around 2008-2009, like, for example, conceptually wrong attempts to implement coverage, VIF filters, alpha blending control bits and other stuff, some parts of which may be alright (I didn't pay much attention to it after Nov 2008), so pompously blogged about on the defunct blog of this PR princess (btw I'm still chuckling at the method that he tried to use to "test" his coverage generator against hardware). It's also possible and worthwhile, for example, to duplicate the bug that this gentleman managed to introduce into my very simple video_max() function while backporting it to MESS back then, thus ruining one of my VIF filters, but hey what's the point using my contributions if they're so lackluster that I'm not worth mentioning?
There's absolutely no proof, by the way, that I've ever claimed the code in question to be solely my own. I called the plugin mine because I'm the goddamn maintainer of the plugin but I've always made sure to specify it's not all my code, by saying it directly on PJ64 forum, in private communications and iirc elsewhere, by uploading a file called CREDITS.txt to my repository and by putting this information into the plugin interface itself.
That said, I'm totally sick of hearing this particular MAME actress's nonstop bullsh*t performances in the same genre of "they're trying to steal my fame" again and again over the years, and it's just nauseating to take part in this cheesy political power game that he apparently so enjoys, yet I'm kinda forced to say something courtesy of the above mentioned smear monger.
