Announcement: Cycle-accurate N64 development underway.
- Thread starter MarathonMan
- Start date
OP
MarathonMan
Emulator Developer
- Thread Starter
- #882
It's the sub-module based repository, which just seems like more of a burden than it's worth. I know there are at least a few people over at #n64dev that agree with me. They can speak for themselves, but here's the gist of my reasoning for opposing this structure.
To fork the repository, you have to fork the main project as well as the 9 other projects. If you modify 1 project, you have to submit a pull request for that project. So if /one/ person made a fork and made regular commits to the entire project, that's 9x the amount of pull requests from 1 person. This increases the workload for you, and slowly turns you into a manager instead of a programmer. In the worst case, the 2-3 people who want to help with the whole project are doing this, that equates to 18-27 pull requests to keep track of. This could be 2-3 requests which is entirely manageable. That's on your side of things, on the other side of things it gets even more tedious.
If you only want to work on one module (Which isn't really possible without cloning the entire repository so you can build and test anyway), you have to fork 1 module. But let's say you wanted to work on the entire system as a whole, that's 10 forks you have to make, and 10 projects to create pull requests for. If it were all unified into one repository, you'd only need to fork 1 repository no matter the number of modules you want to work on.
I understand that the original intent of the sub-module system is to make it easier for new developers to commit code, but in practice it is one of the biggest impediments to that goal. Anyway, this project has a very noble goal, and I want to be a part of that no matter what. Just saying the the repository is a pain to work withSee? Constructive criticism!
This is probably one of the biggest complaints I see about CEN64. Warranted? Perhaps, but I don't regret my decision... yet!
Suppose you become the master of the audio system. What business do you have touching the video system? None, really. But perhaps I would rather make you the "master" of the audio system, rather than myself. Fine; no problem. By partitioning off the emulator into multiple subsections, I can control who is allowed to contribute to what part of the emulator. Suppose somebody ends up creating some super-ultra-fast-compliant RDP module that completely deviates from what I have. No problem for me; I just update my .gitmodules to point to their repository, and CEN64 is effectively updated to point to that repository instead of my crummy, outdated one.
Rarely will anyone want to fork the entire emulator for the purpose of working on every subsystem at once (at least, in my opinion).
There's a saying in computer science: "every problem in CS can be solved by another layer of indirection."
OP
MarathonMan
Emulator Developer
- Thread Starter
- #883
I issued pull requests for visual studio project files on each module. Going through and trying to resolve all the errors (Most of which are in the Common.h files trying to define false and true in _MSC_VER 1700). However there are a few unresolvable errors I've come across:
1. cen64-vr4300, CP1.c - The use of the C++11 "cfenv" and "fenv" to manage FPU flags.
2. cen64-vr4300, VR4300DMULT, VR4300DMULTU - Unimplemented since VC doesn't support 128-bit integer types __int128_t and __uint128_t. A back-up solution will need to be implemented.
3. cen64-rsp, CP2.c - Many implicit conversions from int16_t[8] to uint16_t* (Line 205 for example). Was this intended? Casting pointers isn't portable
4. cen64-vr4300, CP1.c - Visual Studio doesn't understand your inline assembly at all (Different syntax, I'm sure), and I don't really either D:
That's all for now, 1 and 3 are the biggest priority for me at the moment, the D-Word multiplies aren't probably used a whole lot, so they can be implemented in my leisure time.
EDIT: It appears MS is adding more C++11 into VS2013, and cfenv.h is one of them, huzzah. That just leaves 3 I suppose
1) M$ how2standards
2) Use the MSVC intrinsics: http://msdn.microsoft.com/en-us/library/82cxdw50(v=vs.90).aspx
3) In C, this is legal... not so much for C++. It was entirely intentional. That file is a mess in general, though... keep meaning to clean it up.
4) Err yeah, that's unfortunate. lol Fortunately the syntax isn't so bad:
__asm__(
"yourassemblycodehere"
: outputs
: inputs
: clobber list
);
Clobber list just specifies what the assembly block may destroy if it touches things other than inputs/outputs. The %# in the assembly code just references the arguments from the output/input list. If there is one output and one input, %0 refers to the output and %1 refers to the input.
Last edited:
OldGnashburg
New member
Hey MarathonMan, I have several questions for you. I am more of a laptop guy and am wondering what kind of computer will I need when this is finished. And will this emulator be 100% accurate once finished, and if not, what won't be. And what are the point-slope ROMs and the PIFROM. What will I need it for, do you need it to accurately emulate the N64, and if so how will I acquire it (if I can't ask sorry I just signed up). How will the input work, should I get an N64 controller to USB port adapter (or whatever it is you need to connect an N64 controller to a computer, Adaptoid or something). And once the emulator is fully complete, will you add the following; savestates, cheat support (like Project 64 does with the ability to change variables in the cheat code for modifiers and whatnot), audio & video recording, higher resolution support, retexturing support, netplay, support for the Gameboy Tower in Pokemon Stadium and features in other games that need require certain N64 accessories, Screenshot support, and all those little goodies that other emulators have? And how far are you in development now? What is your status with implementing multi threading. Where are you in development, once finished with emulator, will you continue on staying in the emulation scene? Maybe create another cycle accurate emulator, for example, a cycle accurate emulator for the GameBoy series? You amaze me MarathonMan, I look at this thread everyday to see what is new. Keep up the work, and good luck emulating this beast of a system.
OP
MarathonMan
Emulator Developer
- Thread Starter
- #885
Really don't mean to sound like a bigot when I write this:
I've probably answered all of these questions a million times now. I understand, however, that there's no FAQ and there's no quick way to find all the answers short of reading the last 100 pages of posts on this topic. I haven't been able to devote a lot of time to CEN64 lately and it's probably best to not spend time answering questions on forums, so I'll let a community member answer your questions if you have any so I can spend more of my (limited) free time on the emulator itself.
you'll probably need a 3-4 GHz modern intel CPU... and that's assuming he can get it properly optimized
in terms of 100% accuracy... that's the whole point of this emulator
for controller... probably gonna work with any gamepad
the pifrom thing is the same file required by MESS. just with a different name. google it
in terms of progress... mostly it's just bugfixes and sound left to do. then more optimization
other questions are still unknowns. don't hold your breath.
ShadowFX
Guardian
This is probably not achievable. It'll be more along the lines of 99%, since there will always be bugs, unknown instructions and the like, or simply the impossibility of emulating certain components and or behavior 100% correctly.
The audio is indeed the next major component left to emulate. Don't forget the RDP (video) will most likely be replaced by MarathonMan's own version eventually.
I know this project is not yet complete but has there been any consideration for implementing this into libretro and RetroArch at some time in the future? Just curious as I have become a bit a of a libretro fanatic (mainly because it unique linux KMS/EGL driver). I know that anyone can just fork it and make it themselves but I am talking like officially pushing libretro into the upstream.
In any case, I am so impressed with the progress after just a little over a year. N64 is my favorite system and I can't wait til this project is finished. I and many others are very grateful for your hard work. Also are you accepting monitary donations for this project at all?
In any case, I am so impressed with the progress after just a little over a year. N64 is my favorite system and I can't wait til this project is finished. I and many others are very grateful for your hard work. Also are you accepting monitary donations for this project at all?
We really need a FAQ and a subforum
.-> Not at the moment, probably never (officially), someone else will need to do the job.
-> Good question, I can't remember if the answer has been posted already. I will let MM answer this one.
OP
MarathonMan
Emulator Developer
- Thread Starter
- #891
I've been talking to a dev who has expressed interest in working on the audio.
^ This, thanks @arbingordon and any who wish to donate.
On a side note, I'll probably be relatively inactive for the next couple weeks. I've been battling a minor illness and have some hefty deadlines coming up. Don't be surprised if there's a gap in progress.
I have some patches that #n64devs have done that need merging, too...
ShadowFX
Guardian
That's good news! It this someone that's active on these forums?I've been talking to a dev who has expressed interest in working on the audio.
And that's not very good news! Hopefully you get well soon, just make sure you put yourself first before your work and hobbies. And take all the time you need, this is also an opportunity to test the latest changes to CEN64 more extensively.I've been battling a minor illness and have some hefty deadlines coming up. Don't be surprised if there's a gap in progress.
Last edited:
XICO2KX
New member
Is there any N64 debugging device that can be used to retrieve the registers/memory/state of the real N64 hardware?
It could be used to compare those values with the ones produced by the emulator and help track down bugs really fast! :gunman:
OP
MarathonMan
Emulator Developer
- Thread Starter
- #894
Is there any N64 debugging device that can be used to retrieve the registers/memory/state of the real N64 hardware?
It could be used to compare those values with the ones produced by the emulator and help track down bugs really fast! :gunman:
Yes, I got a 64drive for the purposes of running code on the actual console. It's still not that easy to track things down, though.
It would be nice to have some accurate audio for once. For some reason, every audio plugin I tried gets scratchy noise, doesn't sync well, or when it is forced to sync, it slows the emulation by 3-4 VIs.
I know the slowdown is a little redundant to say with a cycle-accurate emulator, but hopefully a good audio plugin will come out from CEN64, and then be usable in PJ64 or 1964 ... of course, I can only hope .
For some reason, every audio plugin I tried gets scratchy noise, doesn't sync well, or when it is forced to sync, it slows the emulation by 3-4 VIs.I know the slowdown is a little redundant to say with a cycle-accurate emulator
, but hopefully a good audio plugin will come out from CEN64, and then be usable in PJ64 or 1964 ... of course, I can only hope .
Last edited:
XICO2KX
New member
That seems like only a flashcart to load ROMs but without any debugger features...
I was thinking more like a debugging tool that allowed pausing the execution and had a "step" command and the ability to inspect the memory and register contents.
Something along the lines of the "Memory Editor" feature of the Gameshark Pro / Action Replay Pro.:wolverine
Or a hardware device that could write a full trace/log of execution, with each line saying the executed instruction and the changed memory/register output value.:borg:
Then you could do the same in Cen64 and simply make a diff between the two files to track down the instructions that had different outputs.:sorcerer:
Hasn't anyone built such a device yet? :whistling
At just $1000 + shipping this seems quite nice: http://www.ebay.com/itm/NINTENDO-KY...JAPAN-OFFICIAL-DEVELOPMENT-UNIT-/321071172696
OP
MarathonMan
Emulator Developer
- Thread Starter
- #899
[mikeryan wrote a piece of software that allows it to write back to the FAT32 filesystem from the 64drive, which is what I planned on using.
The "ultimate" debugger system would be an Indy with a u64 board, but they're cost prohibitive... if you can even find them.
The "ultimate" debugger system would be an Indy with a u64 board, but they're cost prohibitive... if you can even find them.
Nintendo Maniac
New member
It would be nice to have some accurate audio for once.
I know the slowdown is a little redundant to say with a cycle-accurate emulator
This would be particularly useful for USF-based playback in Winamp and Foobar2000. I've personally noticed that the USFs for Mario Kart 64 playback a little bit slower than the music actually does on a console.