PDA

View Full Version : Announcement: Cycle-accurate N64 development underway.



Pages : [1] 2 3 4

MarathonMan
September 13th, 2012, 04:20
Hi,

I'd like to inform the community that I have been developing a cycle-accurate emulator for the N64 (not to steal from Hackturax's fire)! The project is currently in infant stages, and nameless, but has several goals:

1) Accuracy.
The community has yet to see a cycle-accurate emulator for the N64, nevermind one that runs at acceptable speed. Because accuracy is my first and foremost concern with this project, I am opening it up to the community for all eyes to see, effective immediately. Technical (read: technical) bug reports or inaccuracies in hardware emulation are welcome and extremely appreciated.

Another reason that I wish to open this project to the community is to improve emulation quality and knowledge base of the N64 in general. Much of the documentation that I have found this far would cease to exist if it were not for the community's efforts in gathering resources solely for this truly one-of-a-kind console. My hope is that I'll be able to give back to the community in the same way that I have benefited from it since the earliest HLEs.

2) Design.
In lockstep with accuracy, design is another major tenet of this project. I absolutely refuse to include hacky workarounds in something as complex as a cycle-accurate simulator for a minor performance gain. The goal is to write an emulator with a clear-cut, well thought-out design that in and of itself serves as documentation for the platform and developers of future projects.

Moreover, I plan to avoid any GNU-specific extensions or third-party libraries as much as possible. My hope is that the emulator will be completely cross-platform and cross-architecture (yes, I'm looking at you, ARM). I also hope to write the code in a manner so that it is amenable to multi-threading (but delay it until after the simulator is in a more developed state and requires a performance boost to run at full speed).

3) Performance.
I am, in the true sense, a systems programmer. I will fight for every little last bit of performance, even if it means increased development time. See below for an idea of how much time I invested into writing the TLB module.

--------------------------------------------------------------------------------

"Yeah, this is great and all, but what have you done thus far?"

I've actually been working on this project for a few weeks now. About a month or so ago, I began collecting documentation and information on the N64. For a few weeks, my only goal was to absorb as much information about the N64 as I possibly could.

A few weeks ago, I began focusing on the VR4300's MMU/TLB (and, to a lesser extent, the ICache/DCache). At this point in time, I have more or less finalized most of the TLB and have been working to document the sources and perform and final tweaks to the code before making an initial release to the public.

I am currently able to simulate, under worst case, the TLB at full speed on "old" commodity hardware (Intel Core 2 Duo P8600, 2.4GHz, 4GB RAM). To be exact, the TLB code is capable of executing ~93,750,000 lookups (1 lookup/pcycle) across a TLB full of global entries in less than a second on the aforementioned hardware configuration. Best case (few global entries, well-distributed number of ASID-specific entries) drops that to about half of that time. This is possible as the code was written such that L1 cache misses are practically non-existent, branch mispredictions are low, and IPC very high (currently running in the range of 2.5IPC). My hopes are that when it comes time to develop the pipeline, I'll be able to do play some clever tricks that will result in only having do a TLB lookup every handful of pcycles (while still maintaining 100% accuracy!).

I'm not sure if the idea has rubbed off or not yet, but my goal is more or less to write a simulator that is not only entirely accurate and well-thought out, but is able to run at full-speed on C2D (or maybe i5/i7 at a maximum). At this point in time, I'm not sure if it's an attainable or realistic goal, but it is my hope nonetheless.

Comments, suggestions, and flame-war type message are welcome. :n64:
(Also, if possible, a subforum would also be greatly appreciated! :saint:)

--------------------------------------------------------------------------------

EDIT: [4/2/13]: Open-sourced the project.

Decided to license as BSD 3-clause. Do whatever you want with the source.

For updates, follow me on github and star the sources.

There are several (err, seven?) plugins; I'll be working on pushing them up to github and update both this post and the first post accordingly. None of them will be of much use until I upload the framework that ties all the plugins together (which will likely be done last to make sure everything checks out).

** Primary Module **
Framework: http://github.com/tj90241/cen64

** Submodules **
AUDIO: http://github.com/tj90241/cen64-audio
BUS: http://github.com/tj90241/cen64-bus
PIF: http://github.com/tj90241/cen64-pif
PI: http://github.com/tj90241/cen64-rom
RDP: http://github.com/tj90241/cen64-rdp
RDRAM: http://github.com/tj90241/cen64-rdram
RSP: http://github.com/tj90241/cen64-rsp
VI: http://github.com/tj90241/cen64-video
VR4300: http://github.com/tj90241/cen64-vr4300

To acquire:
Clone the framework: (git clone git://github.com/tj90241/cen64.git)
Pull in the modules: (git submodule init && git submodule update)

Enjoy!

DETOMINE
September 13th, 2012, 18:57
Can you provide a link to your work (binary? source?)?

Maybe you should join your effort with Hacktarux, or at last share documentations/demos.

It seems promising, I just hope it will go further :p

Darkzack235
September 14th, 2012, 02:48
Will you add real time support for games like doubutsu no mori? And a fix for the black box framebuffer glitch?

MarathonMan
September 14th, 2012, 04:17
Can you provide a link to your work (binary? source?)?

Maybe you should join your effort with Hacktarux, or at last share documentations/demos.

It seems promising, I just hope it will go further :p

Here are the repositories:
VR4300 Simulator: https://github.com/tstache1/vr4300
CEN64 Emulator: https://github.com/tstache1/cen64

I haven't pushed the tlb branch yet, which is where most of the work is right now... getting it photo ready, should have it up in the next day or so hopefully.

I'm not sure I would work fully with Hackturax, as I have always wanted to work on a large project by myself, but I would be more than willing to assist with code and/or share findings with him.

Demos probably won't come for awhile. I plan on finishing most of the CPU before I begin working on the RDP/RSP (and even the RDP will take some time, as I plan to do software rasterizing).

MarathonMan
September 14th, 2012, 04:18
Will you add real time support for games like doubutsu no mori? And a fix for the black box framebuffer glitch?

The idea is that, with cycle-accurate simulators, you don't need to "add" support for anything... everything just works out of the box.

However, I'm light years away from finishing for the time being. :happy:

mrmudlord
September 14th, 2012, 04:48
Not a troll, but angrylion already did a dot accurate RDP software rasterizer...

MarathonMan
September 14th, 2012, 04:54
Not a troll, but angrylion already did a dot accurate RDP software rasterizer...

I'm well aware; I have a clone of every open-source N64 emulator out there stored locally on my machine!

I'm not doing it to compete with anyone, nor do I necessarily think that mine will be better. I simply do what I do for the sake of enjoyment... to me, this is fun.

mrmudlord
September 14th, 2012, 05:13
Question: Do you have a N64 devkit or suitable flash hardware for research?
Doubt you will just make a emulator just based on illegal and leaked SGI documentation for missing RSP/R4300i instructions, as well as proper RDP behaviour.

MarathonMan
September 14th, 2012, 05:36
Question: Do you have a N64 devkit or suitable flash hardware for research?
Doubt you will just make a emulator just based on illegal and leaked SGI documentation for missing RSP/R4300i instructions, as well as proper RDP behaviour.

Not yet. Don't see the need for one until the project is more developed.

MarathonMan
October 8th, 2012, 00:00
<shameful self bump>

Big checkpoint: Able to simulate a handful of instructions (from adds to loads and branches) at a full 93.75MHz on my 4.5GHz i7.

Implementation is single-threaded. The cost of atomic operations on x86 made locking every cycle a lost cause, even on the machine mentioned above.

So far, it's written in ANSI C and should be completely portable across all platforms and architectures. (Technically, it's C99 as it needs stdint.h to guarantee sign-extended 32 and 64-bit types, but other than that... ANSI C).

</bump>

Future goal is to bring the requirements down to more-sane levels so people other than enthusiasts are able to run it!

Remote
October 8th, 2012, 08:23
Maybe post some code and show us what instructions you have simulated, what you have left to add etc (to maybe lessen the need for self bumps) ;)

MarathonMan
October 8th, 2012, 14:54
Maybe post some code and show us what instructions you have simulated, what you have left to add etc (to maybe lessen the need for self bumps) ;)

https://github.com/tstache1/vr4300

Interfaces and overall structure is absurdly unstable.

Insns: ADDIU, ANDI, BEQ, BEQL, BNE, BENL, ORI, LUI, LW, XORI.

Most of the execution unit itself is (obviously) unimplemented. I only implemented enough instructions to get an idea of 'how fast' the pipeline currently is (where the aforementioned testing essentially dumbed down to a LW/ANDI/BEQL loop).

I spent the last week or two trying to see if it was actually possible to simulate the pipeline at full speed (which I fully believe it is). Most of the focus right now is getting the interfaces up to speed. I hope to get an actual, clean cache/memory interface up within the next week or so (not the shoddy excuse of an inline half-arsed lookup that's currenlty in place). After that, I'll move on to implementing most of the pipeline and actually get something going.

EDIT: There are a couple design issues with the code that I'm currently aware of and intend battling in the future. Most of these are due to my initial hope that everything couple be threaded and not have horrendous performance on 32-bit architectures, but I've had to toss out those interests in order to get decent performance (i.e., 32-bit TLB lookup and write entry interfaces probably need to be nixed and replaced with a sole 64-bit version).

I've only been working on this project for a little over a month now, so if it looks infantile, that would be why :p.

MarathonMan
October 16th, 2012, 05:41
Bump.

https://github.com/tstache1/cen64
https://github.com/tstache1/vr4300

Lots more progress. Made an actual emulator repository (right now, will likely only compile on Linux machines, though).

* Currently wads all the way through IPLROM and loads the first few pages of cartridge ROM into memory and begins executing it.

* Lots of performance improvements. Even a lowly C2Q at 2.0GHz is almost able to handle the grunt for the time being. I shocked myself with the performance of this thing (considering caches are currently disabled and there are no delays currently in place for memory accesses -- both of which will improve performance substantially). I do expect it to get worse... but only because cycle-accurate emulation on a processor of this calibre would be unreal.

DETOMINE
October 16th, 2012, 21:13
I have to admit that I totally don't understand what you're doing (i.e. the code), but I'm still impressed :teehee:

weinerschnitzel
October 17th, 2012, 00:35
Enjoying this read. Please keep up the good work and keep us involved!

Remote
October 17th, 2012, 19:07
You posted a lot of code, I was thinking more that you post maybe a loop where you write some short comments on what you are doing and what registers you are simulating/emulating to get interest brewing. Keep ut the work and maybe post a short todo list where you can show what you want to do in the closest future and when you reach a goal you can check/update your list.

MarathonMan
October 18th, 2012, 00:43
You posted a lot of code, I was thinking more that you post maybe a loop where you write some short comments on what you are doing and what registers you are simulating/emulating to get interest brewing. Keep ut the work and maybe post a short todo list where you can show what you want to do in the closest future and when you reach a goal you can check/update your list.

Probably a good idea :p

What the VR4300 core currently lacks:
* TLB interface, instruction and data caches.
* Several instructions/opcodes.
* Interlock/fault handlers.
* COP0/COP1 (MMU/FPU).
* SysAD synchronization.
* Proper memory access delays.
* Various other doodads.

What the VR4300 core currently has:
* Basic pipeline structure, register file, fault queue.
* 25% of the execution unit implemented.
* Memory load/store interface.
* Virtual address resolver.

Basically, I've implemented enough to get the VR4300 to boot the PIF ROM in it's entirety. In addition, I have _just_ enough of the actual console components (audio, video, PIF, etc.) to get the VR4300 to pass all the initialization phases of the PIF ROM. Correct me if I'm wrong, but MESS is the only other emulator that I'm aware of that currently uses the PIF ROM to boot (not that it's super important or anything).

What's up next?
* More work on the VR4300 core: more instructions!
* Something to show that this project isn't vaporware (perhaps an incredibly anemic video controller or something).
* Move on to VR4300 caches, performance improvements, etc.
* Then focus on the rest of the components (video, audio, etc.)

As always, the first and foremost goal is accuracy, with performance and design closely following. Each component of the system is an entirely separate entity (library) that gets linked together in the final executable.

Rodimus Primal
October 18th, 2012, 20:40
Amazing. I don't understand a lick of it, but it sounds like this is promising!

squall_leonhart
October 18th, 2012, 20:56
an lle recompiler is not impossible at the end of all this.

mrmudlord
October 19th, 2012, 02:45
I wonder if the undocumented DCT RSP opcodes will be added.

MarathonMan
October 19th, 2012, 12:39
an lle recompiler is not impossible at the end of all this.

Care to explain your thoughts a little further on this one?

I thought a recompiler core was out of the question due to the fact that you could have instances where, on one block of code, you have cache misses, whereas in another, have hits. I suppose you add x86 instructions to take that into account as well, but the gains aren't going to be as large as non-CE emulators.

I've actually been thinking about ways to possible multithread or add some compiler support way down at the end of the road.

I was almost thinking something along the lines of ROB entries, but in software. Doing this would enable me to perform speculative execution on each core and not synchronize on every cycle, as this has proven to be prohibitively expensive. If I end up having to toss out a few entries here and there, it's no big deal because there would be so much more processing power at my expense. I've writing the simulator in such a way that I can augment it with statistics to determine exactly how much communication occurs between the cores to see how plausible this idea is.

But I'm getting WAAAY ahead of myself at the moment. For now, I'm just working on getting the core implemented. :D

MarathonMan
October 19th, 2012, 12:43
I wonder if the undocumented DCT RSP opcodes will be added.

Again, way down at the end of the road, I might look into buying an Indy with a u64 board if it's not going to cost my heart and soul. There's simply not enough information out there to make a fully CE RSP core right now.

MarathonMan
October 20th, 2012, 20:30
Another bump:
Carts are booting. Tested two carts -- CIC-NUS-6102 (Super Mario 64) and CIC-NUS-6105 (Zelda: OOT). As long as the correct seed is placed in PIF RAM before the IPL2 gets control, all checks pass and the actual game code starts executing. :cool:

On to emulating another handful of instructions and possibly some basic video (within the next few weeks? No idea how long this is going to take...).

Zuzma
October 21st, 2012, 01:30
Again, way down at the end of the road, I might look into buying an Indy with a u64 board if it's not going to cost my heart and soul. There's simply not enough information out there to make a fully CE RSP core right now.

You shouldn't have much trouble getting an indy and a U64 board though you'll probably end up spending over 350 bucks easy. If they for some reason don't have the software just ask someone who already owns one to copy it for you ( I think it's on about 8 CD's). They'd probably be more then nice enough to do it. Not sure why you'd need it for developing an emulator though. Wouldn't something like a 64drive flashcart and a used N64 suffice?

MarathonMan
October 27th, 2012, 23:51
You shouldn't have much trouble getting an indy and a U64 board though you'll probably end up spending over 350 bucks easy. If they for some reason don't have the software just ask someone who already owns one to copy it for you ( I think it's on about 8 CD's). They'd probably be more then nice enough to do it. Not sure why you'd need it for developing an emulator though. Wouldn't something like a 64drive flashcart and a used N64 suffice?

I would imagine that having a "real" developer platform gives you a little more flexibility. Failing that, it's certainly a time-saver (and it would be nice to have, for posterity's sake :p).

Anyways, weekly update:
Not a whole lot of progress this week. Worked out some bugs, added some new instructions, etc. I've implemented enough of the VR4300 core to the point where the ROMs appear to be sticking themselves in a busy loop and waiting for the RCP and friends to respond (at least, I think that is what's occuring). hopefully I can get around to implementing some of the RSP/RDP and really getting things going sometime soon.

Zuzma
October 29th, 2012, 01:23
I would imagine that having a "real" developer platform gives you a little more flexibility. Failing that, it's certainly a time-saver (and it would be nice to have, for posterity's sake :p)

It would indeed be more flexible. I was just thinking more of the price point and the fact that you wouldn't be waiting around for a U64 board (waiting for a lower price that is). Thanks for the update too! It's really interesting to see the actual code progress. Good luck with emulating this beast of a console system!

MarathonMan
October 30th, 2012, 19:59
Lots of information undercovered about the RSP... maybe the community is aware of this, maybe not, but here's what I've been able to confirm (using a developer platform and studying ucode):

The claim that the RSP is a "R4000-based" microprocessor is a little rough on the edges. The RSP, while is does belong to the R4000 series, is much more like the R4300i-based core. It, too, has a 5-stage pipeline and is one of the "less beefy" members of the R4000 series. The primary difference between the VR4300 core and the RSP is that the RSP has a vector co-processor.

The really neat thing, that I'm not sure well known about the RSP, is that it appears to be dual-issue. It'll actually execute two instructions per cycle (if possible): one scalar instruction, and one vector instruction. It also looks like the RSP will stall the pipeline if it detects hazards (which the VR4300 does not!)... but maybe too little sleep is throwing off my brain.

If that seemed like a bunch of jibberish, no worries. I suppose the conclusion of all of this is that a cycle accurate simulator, fully modeling both the VR4300 and RCP, is absolutely possible (with enough time!). Over the last few days, the architecture of the RSP has absolutely overwhelmed me -- I had no idea that it was this impressive. I'll have to rethink my current design and hack away for quite awhile. In terms of getting something running at full speed -- this is going to be quite the challenge. Modeling a dual-issue 32-bit scalar/128-bit vector pipeline is nothing short of a large challenge.

... but it does mean that we'll eventually have an emulator that 'just works' :)

DETOMINE
October 30th, 2012, 23:51
I know it may sound funny, but every time I read you, I feel like I'm participating at a forbidden and crazy experiment. It's like you're playing with powerful and unknown forces.
I still don't understand what you're doing though.

edit : keep up the magic man, it's awesome!

MarathonMan
November 11th, 2012, 18:20
Project isn't dead! :spam: Had a busy last couple weeks...

I have managed to implement a large portion of the RSP's cycle-accurate model. I finished the basic pipeline flow, execution unit, etc. I'm currently working on adding in delays for register hazards, pipeline bubbles, etc. and should hopefully have that finished by today. :) That'll leave me with the vector unit, and the RSP should be 90% complete.

The RSP hasn't difficult to implement at all compared to the VR4300, but it might be because I've been able to reuse so many components and there are a significantly reduced number of instructions in the RSP core. After I finish the RSP, I'll start running code through it to get an idea of how much of the RDP I need to implement based on the command lists and will hopefully get a few screenies out in a few months.

-M

DETOMINE
November 11th, 2012, 22:55
I can't wait to see the first screen-shots :) .

I was wondering, does your project use some of the mame code?

didado
November 11th, 2012, 23:13
Hoi!!

I <3 this project.. :D

I've been "spectating" "Emulation64" for more then 5 years now and its time for positive feedback on this project.

Because someone with this much coding knowledge must make something beautiful ;)

Like DETOMINE its the same magic for me.
Not everyone is "coding" smart alike.. (dunno if this english i type is correct lol) , although those terms like RSP's, VR4300 i always see come back.

I just hope someday (i know it takes time) "Conker bad fur day" and others will be smooth as butter with this new emu on Windows 8 and further.
Because "Project64" with the plugin "Glide64" is the only combination that works almost flawless right now..
And we need an alternative before this dies, but again these are my future thoughts :borg:.

Keep it up \:D/

Greetings

MarathonMan
November 12th, 2012, 01:45
I can't wait to see the first screen-shots :) .

I was wondering, does your project use some of the mame code?

Nope, since MAME wasn't designed to be cycle-accurate. I reference the code and use the built-in debugger as a resource, but I haven't actually used any substantial portion of the code (yet, anyways).

Bighead
November 13th, 2012, 21:55
This project sounds very promising. Good luck with it and keep us updated!

talker
November 15th, 2012, 15:10
This is interesting to read! With all the info you deliver each time it sound like you've hit a milestone every time. I neither have any experience with building and coding an emulator, but by reading what you have done and what your thoughts are makes it somehow understandable for me.
I've seen things like R4300, rsp, and such metion before, but with no meaning behind it. I really like to follow this into the future and see what a 'cycle-accurate emulator' would be like!

MarathonMan
November 15th, 2012, 17:03
Thank you all for the kind words! It is very reassuring to know that the N64 scene isn't a total graveyard!

Nintendo Maniac
November 27th, 2012, 05:19
Just an FYI, you may or may not want to consider a blog for development notes and/or any actual project releases to keep everything in one organized location. Currently this isn't an issue with only 4 pages, but it's just something you might want to keep in mind for the future.

BTW, I too am very glad to see the N64 isn't a total graveyard - it certainly seemed like it for the last 5 or so years. I mean, when Wii emulation is more accurate than N64 emulation, then you know something new needs to be done. Heck, for some N64 games it's more accurate to run the virtual console version in Dolphin than it is to play via an N64 emulator!

MarathonMan
November 28th, 2012, 04:24
Just an FYI, you may or may not want to consider a blog for development notes and/or any actual project releases to keep everything in one organized location. Currently this isn't an issue with only 4 pages, but it's just something you might want to keep in mind for the future.

BTW, I too am very glad to see the N64 isn't a total graveyard - it certainly seemed like it for the last 5 or so years. I mean, when Wii emulation is more accurate than N64 emulation, then you know something new needs to be done. Heck, for some N64 games it's more accurate to run the virtual console version in Dolphin than it is to play via an N64 emulator!

The only issue with a blog is that it's not community-centric, not as searchable, etc. Once I get something bigger, I'll hopefully get the mods to make thread group for me so I can better organize things that way.

AFAIK, the reason why N64 emulation isn't as high-calibre is because large parts of the RCP are not fully understood (due to the fact that it was kept such a secret).

Minor status update -- did a little overhauling of the RSP core. I probably won't get a whole lot done in the coming weeks due to a lot of work-related deadlines approaching. Just wish I had more time to work on the project!

Nintendo Maniac
November 29th, 2012, 01:53
I need to ask though, with such an accurate emulator, would this cause enhancements like rendering in high-res or N64 overclocking (for smooth framerates in various games) to not be possible? Because honestly, I think most of us don't want to view polygons and textures that look like a low-res jagged mess on any display newer than a CRT SDTV... Heck, even on my SDTV the 480i virtual console version of Majora's Mask looked much cleaner than the 240p N64 version.

MarathonMan
November 29th, 2012, 05:16
I need to ask though, with such an accurate emulator, would this cause enhancements like rendering in high-res or N64 overclocking (for smooth framerates in various games) to not be possible? Because honestly, I think most of us don't want to view polygons and textures that look like a low-res jagged mess on any display newer than a CRT SDTV... Heck, even on my SDTV the 480i virtual console version of Majora's Mask looked much cleaner than the 240p N64 version.

Overclocking is extremely, extremely easy to implement (I just call a cycle() function periodically; if call it more often and the system is effectively overclocked). However, running at full speed is already taxing as it is on modern computers -- try bsnes. I doubt you'll be able to push the emulator much further unless you're highly overclocked, if at all, for awhile.

Everything will be standard resolution at first (focusing on accuracy). I'll consider visual optimizations and the like at a much later time and provide options to switch them on for those that desire to do so.

Nintendo Maniac
November 29th, 2012, 05:21
Ok, on a related note then, what about the N64's integrated "hi-res" 640x480 mode? Games like World Driver Championship and Perfect Dark have such a mode as an in-game option, so proper emulation would require this function to emulated anyway. Would it not be a stretch to suggest that such a thing could be forced to run at all times as stop-gap to polygonal resolution independence?

ExtremeDude2
November 29th, 2012, 13:55
There is also the GC versions of OoT/MM that run at 480p I believe :3, and they can be run in an n64 emu :D

DETOMINE
November 29th, 2012, 14:45
I think it is a little too early to speak of 480p or so. We will probably have some technical demos, then maybe (I certainly hope so :) ) some games, then depending of the code, it will maybe be possible to hack around a little to have a brighter result. Let's not rush things too much. :teehee:

Fanatic 64
November 29th, 2012, 19:05
There is also the GC versions of OoT/MM that run at 480p I believe :3, and they can be run in an n64 emu :D

The Nintendo GameCube emulator is what makes the game run at 640x480 @ 30 FPS. If you run the ROM on Project64 with the internal resolution forced at 640x480 and default framerate, or on a real Nintendo 64, you'll see it internally runs at 320x240 @ 20 FPS.

ExtremeDude2
November 29th, 2012, 23:32
Aww :p

MarathonMan
November 30th, 2012, 01:30
Ok, on a related note then, what about the N64's integrated "hi-res" 640x480 mode? Games like World Driver Championship and Perfect Dark have such a mode as an in-game option, so proper emulation would require this function to emulated anyway. Would it not be a stretch to suggest that such a thing could be forced to run at all times as stop-gap to polygonal resolution independence?

It's certainly possible. To be completely honest, most of my reverse engineer and research efforts have been devoted to writing the VR4300 and RSP cores. I still have to delve into the RDP before I make any 'real' claims :)

Nintendo Maniac
November 30th, 2012, 01:42
OK, one last question relating to polygonal rendering

Things like anti-aliasing and anisotropic filtering in emulators are done on the Direct3D/OpenGL side of things, no? Therefore they should be able to be easily enabled in a manner similar to any other Direct3D/OpenGL program, correct?

mrmudlord
November 30th, 2012, 03:22
How frigging hilarious.

You want LLE/cycle accuracy but want your HLE related **** like antialiasing/anisotropic filtering/hires textures, too?

Oh God....People just don't get it. Software rendering wil make AA impossible, unless you want to murder framerates and such with extra filtering on rendered spans like bumping up internal rendering resolution.

I don't get you cycle accuracy people. You want cycle accuracy but want inaccurate **** like bumped resolutions too? Thank god now someone else has to deal with putting up with the crap....

DETOMINE
November 30th, 2012, 16:49
How frigging hilarious.
You want LLE/cycle accuracy but want your HLE related **** like antialiasing/anisotropic filtering/hires textures, too?
Oh God....People just don't get it. Software rendering wil make AA impossible, unless you want to murder framerates and such with extra filtering on rendered spans like bumping up internal rendering resolution.
I don't get you cycle accuracy people. You want cycle accuracy but want inaccurate **** like bumped resolutions too? Thank god now someone else has to deal with putting up with the crap....

And there you go again...
People want to play good old games, if possible in high quality. They are just asking, MarathonMan can do whatever he wants...

Azimer
November 30th, 2012, 23:05
Although I don't agree with the delivery method, mudlord has some accurate points. I do believe a hybrid approach can potentially be feasible but not with software. I also don't believe RCP HLE is the demon everyone makes it out to be for compatibility.

Now that I finished reading the thread in its entirety I wish the author good fortune. I'd love to see something new with N64 emulation.

MarathonMan
December 1st, 2012, 02:54
Although I don't agree with the delivery method, mudlord has some accurate points. I do believe a hybrid approach can potentially be feasible but not with software. I also don't believe RCP HLE is the demon everyone makes it out to be for compatibility.

Now that I finished reading the thread in its entirety I wish the author good fortune. I'd love to see something new with N64 emulation.

Thanks, that means a lot coming from someone who's been around the community for a bit, to say the least.

As mudlord said (though maybe a bit harshly), AA/AF/etc. don't make any sense right now. My initial focus is a cycle-accurate, pixel-accurate, etc. emulator and that is hard enough as it is! My initial goal is to emulate the N64 as closely as humanly possible, at whatever cost. At a later time, if there's enough interest, I can add all kinds of goodies (though I, myself, would rather reminiscent and play OOT in 240p!).

Nintendo Maniac
December 1st, 2012, 03:09
The thing was, I completely forgot about the existence of software rendering. I'm so used to things like Dolphin where software rendering pretty much requires a Sandy/Ivy Bridge i7, so it never crossed my mind that such a thing would be playable at all. Of course I completely forgot that the DeSmuME uses software rendering by default and requires much less CPU, and I would imagine that DS-level polygonal 3D would be much closer to the N64 than the GameCube/Wii (though the DS lacked texture filtering and was a lower resolution...)

So yeah, with software rendering usually AA+AF is automatically out of the question. Hey, we all have our derp moments. :P

mrmudlord
December 1st, 2012, 04:35
Although I don't agree with the delivery method, mudlord has some accurate points. I do believe a hybrid approach can potentially be feasible but not with software. I also don't believe RCP HLE is the demon everyone makes it out to be for compatibility.

Now that I finished reading the thread in its entirety I wish the author good fortune. I'd love to see something new with N64 emulation.

Glide64 actually used a hybrid approach to do RDP emulation: some usage of low level command parsing along with the rest being HLE.

DaFox
January 6th, 2013, 10:42
It's been over a month, any updates? :)

Nintendo Maniac
January 6th, 2013, 10:46
It's been over a month

That's what happens when someone *COUGHmeCOUGH* has a derp-moment and makes a comment that makes themself look like a noob; it has the tendency to cause awkward silences.

MarathonMan
January 10th, 2013, 01:17
It's been over a month, any updates? :)

Lost a pair of drives simultaneously in my RAID-5*, death in the family, proposal deadlines, the holidays, etc. etc., so unfortunately I've made virtually no progress in the last month.

Project isn't dead, though. :)

* had semi-recent offsite backups, so I only lost a commit or two.

DETOMINE
January 10th, 2013, 14:34
Lost a pair of drives simultaneously in my RAID-5
May I suggest using RAID-10 instead?
HDD are cheap, your data aren't... (This sentence would make a great ads, don't you think :p ?)

MarathonMan
January 10th, 2013, 14:43
Actually, I'm using RAID-Z1 now. RAID-10 is too much overhead for me... I have almost 5TB of data.

MarathonMan
January 12th, 2013, 22:15
So, as I was saying... project isn't dead! :spam:

I made a good deal of progress on the RSP simulator. However, I've found that I'm spending too much time for my liking on tracking down hard-to-find bugs. So, I wrote an assembler for the RSP to assist in test generation and regression testing. Yay.

https://github.com/tstache1/rspasm

Requires yacc/lex/C99. There might be a few bugs, and only assembles a handful of instructions (see writer.h), but the lexer is fully-functional. It'll be done within the week, I hope.

Cheers!

EDIT: jk, finished all the "official" instructions. Short of directives, I now have a full-blown assembler. :)

Nintendo Maniac
January 18th, 2013, 15:31
finished all the "official" instructions.
Would this be the microcode that was included in the official N64 SDK? That is, not the custom stuff like was used in games like Rouge Squadron and World Driver Championship.

EDIT: for some crazy reason I'm not getting notified of replies even though I've selected that option...

Fanatic 64
January 18th, 2013, 18:31
Would this be the microcode that was included in the official N64 SDK? That is, not the custom stuff like was used in games like Rouge Squadron and World Driver Championship.

EDIT: for some crazy reason I'm not getting notified of replies even though I've selected that option...

Correct me if I'm wrong, but isn't reversing microcodes a HLE thing? As far as I know LLE and Cycle-Accurate emulators can emulate those game's GFX without having to reverse the microcodes individually, that's the reason why Jabo, Rice, Glide, etc can't emulate those games but z64 and MESS can.

Nintendo Maniac
January 18th, 2013, 18:39
Correct me if I'm wrong, but isn't reversing microcodes a HLE thing?

Wow, I'm on a roll with these "derp moments", aren't I? Maybe I should just stop talking...

MarathonMan
January 19th, 2013, 05:31
Wow, I'm on a roll with these "derp moments", aren't I? Maybe I should just stop talking...

The "official" documentation is still neither complete, nor without errors. Aside from a few opcodes that appear to only be function on dev kits, I believe I have everything. Time will tell!

MarathonMan
January 23rd, 2013, 15:36
Been a couple days, so bumping for an update.

- The assembler I wrote has paid itself off a hundred times over. Found quite a few bugs in the scalar unit and hammered them all out.

- All instructions other than LWC2/STWC2/CTC*/MTC*/MFC*/VECTOR are done and all infrastructure is in place, so the next week or so will likely be spent implementing instructions.

- Before instructions enter the pipeline, my simulator must classify them to determine if it needs to create stall cycles due to load, store, or use dependencies. Runtimes for my micro-benchmarks were getting quite poor, so I profiled the simulator and realized I spent a large fraction of time classifying the instructions (as it was resorting to a jump table twice per cycle). I implemented a much more clever solution that involves only one conditional branch and two array fetches and was pleased to see that it went from being one of the largest time hogs to one of the smallest time hogs. Not only that, but depending on the complexity of the instructions targeted by the microbenchmark (i.e., a 'add' is much simpler to execute than a 'lwv'), the runtime changes drastically. This is, in my opinion, good as it suggests that my code is spending a good chunk of time doing 'actual work' and less time interpreting instructions. Implementing that solution also made me realize that there's another large potential optimization vector related to the interpreter that will save me a good chunk of time, but I'll leave that for later.

- I started implementing some of the LWC2/SWC2 instructions (and finished 'lbv', 'lsv', and 'lwv' last night). To my surprise, no other "LLE" emulators pay attention to endian-ness -- all IMEM/DMEM is stored in little-endian byte order! My simulator has is that it always maintains a big-endian byte order representation of IMEM/DMEM. This will 'fix' any ROMs that have ucodes that depend on big-endian byte-ordering (should they exist), and eliminate the need for "byteswapping" ROMs at the cost of a small performance hit.

'sall for now, folks.

Nintendo Maniac
January 23rd, 2013, 15:56
I gotta ask, what CPU are you running your micro-benchmarks on?

MarathonMan
January 23rd, 2013, 19:43
I gotta ask, what CPU are you running your micro-benchmarks on?

#1) 2600k @ 4.5GHz.
#2) Q8400 @ 2.0GHz.

I use the latter to try and get a sense of what the "average" user is going to experience.

straightflushin
January 23rd, 2013, 20:30
Been a couple days, so bumping for an update.

- The assembler I wrote has paid itself off a hundred times over. Found quite a few bugs in the scalar unit and hammered them all out.

- All instructions other than LWC2/STWC2/CTC*/MTC*/MFC*/VECTOR are done and all infrastructure is in place, so the next week or so will likely be spent implementing instructions.

- Before instructions enter the pipeline, my simulator must classify them to determine if it needs to create stall cycles due to load, store, or use dependencies. Runtimes for my micro-benchmarks were getting quite poor, so I profiled the simulator and realized I spent a large fraction of time classifying the instructions (as it was resorting to a jump table twice per cycle). I implemented a much more clever solution that involves only one conditional branch and two array fetches and was pleased to see that it went from being one of the largest time hogs to one of the smallest time hogs. Not only that, but depending on the complexity of the instructions targeted by the microbenchmark (i.e., a 'add' is much simpler to execute than a 'lwv'), the runtime changes drastically. This is, in my opinion, good as it suggests that my code is spending a good chunk of time doing 'actual work' and less time interpreting instructions. Implementing that solution also made me realize that there's another large potential optimization vector related to the interpreter that will save me a good chunk of time, but I'll leave that for later.

- I started implementing some of the LWC2/SWC2 instructions (and finished 'lbv', 'lsv', and 'lwv' last night). To my surprise, no other "LLE" emulators pay attention to endian-ness -- all IMEM/DMEM is stored in little-endian byte order! My simulator has is that it always maintains a big-endian byte order representation of IMEM/DMEM. This will 'fix' any ROMs that have ucodes that depend on big-endian byte-ordering (should they exist), and eliminate the need for "byteswapping" ROMs at the cost of a small performance hit.

'sall for now, folks.

Very impressive, well done! I can't help much, but I'm really enjoying following your progress here.

DETOMINE
January 24th, 2013, 14:07
https://github.com/tstache1/cen64 give me an error 404, did you change the link?

I can't wait to see your program in action!

Nintendo Maniac
January 24th, 2013, 15:20
Welp, with the newest Nintendo Direct, it's very obvious to me that Nintendo is not interested in the same things I'm interested in. It is safe to say that, unless it gets homebrew'd and hacked up the wazoo like the Wii, the Wii U is not for me.

Therefore it would seem like this emulator is going to be particularly of interest to me in the future.

MarathonMan
January 25th, 2013, 05:14
https://github.com/tstache1/cen64 give me an error 404, did you change the link?

I can't wait to see your program in action!

Apologies. CEN64 is intended to be the "final application", which is composed of several plugins -- "librsp", "librdp", and "libv4300". I have taken down CEN64 for two reasons:

1) It was too much of a hassle to keep the framework's interfaces in lockstep with the libraries.
2) I've been considering changing the license from GPLv3 to Apache (or something else).

DETOMINE
January 25th, 2013, 09:59
Apologies. CEN64 is intended to be the "final application", which is composed of several plugins -- "librsp", "librdp", and "libv4300". I have taken down CEN64 for two reasons:
1) It was too much of a hassle to keep the framework's interfaces in lockstep with the libraries.
2) I've been considering changing the license from GPLv3 to Apache (or something else).
Thanks for the explanations :)

I was wondering something, will cen64 need a N64's bios?

ExtremeDude2
January 25th, 2013, 16:30
n64 has no BIOS

Nintendo Maniac
January 25th, 2013, 16:37
n64 has no BIOS

So it's like the SNES in that regard? That's convenient. :D

...I just realized, the systems with BIOSes have boot-up screens, such as the Game Boy Advance. I presume that such a boot-up screen is what requires the need for a BIOS in the first place?

Fanatic 64
January 25th, 2013, 16:48
Thanks for the explanations :)I was wondering something, will cen64 need a N64's bios?As far as I know, the N64 does not have a BIOS (which means no).

MarathonMan
January 25th, 2013, 17:21
As far as I know, the N64 does not have a BIOS (which means no).

The N64 does not have a BIOS in the traditional sense, but yes, there is a "bootrom" located in the peripheral input device that copies the next stage of boot code off the cartridge (PIFROM; mapped to physical address 0x1FC00000 to 0x1FC007BF). In addition to that ROM, there's also some proprietary ROM necessary for pixel-accurate rendering.

As for the PIFROM, I eventually emulate it so that it's not a requirement for simulation. This is what any other N64 emulator does as all the PIFROM really does is copy a tiny bit of data and set some registers before passing off control to the next stage.

As for the point/slope ROM, it will be a requirement for pixel-accurate rendering. If/when I get around to writing a "traditional" RDP plugin, the point/slope ROM will not be required as the "traditional" plugin will just translate the RDP command lists into OpenGL calls.

Nintendo Maniac
January 25th, 2013, 19:12
As for the point/slope ROM, it will be a requirement for pixel-accurate rendering. If/when I get around to writing a "traditional" RDP plugin, the point/slope ROM will not be required as the "traditional" plugin will just translate the RDP command lists into OpenGL calls.
Wait, so this WILL be using OpenGL rasterization and not software rendering? Then why was mudlord so adamant that this would use software and therefore polygonal enhancement (such as AA & AF) would be out of question?

MarathonMan
January 25th, 2013, 19:38
Wait, so this WILL be using OpenGL rasterization and not software rendering? Then why was mudlord so adamant that this would use software and therefore polygonal enhancement (such as AA & AF) would be out of question?

No, it will use software rendering by default. However, all the libraries (librdp, for example) are pluggable and thus if/when I create a second render library, it won't need point/slope ROM.

Nintendo Maniac
January 25th, 2013, 19:40
Oh, so you're following the Project64 methodology with plugins rather than the Dolphin method of total integration. Gotcha.

MarathonMan
January 25th, 2013, 20:04
Oh, so you're following the Project64 methodology with plugins rather than the Dolphin method of total integration. Gotcha.

Sort of. Right now, all the libraries are statically linked, so developers control the plugins selected; not the users.

Nintendo Maniac
January 25th, 2013, 20:09
Then isn't it more like Dolphin actually? Originally it used plugins but they got integrated in. I believe they are still somewhat modular on the development side however since, for example, they're developing a new HLE audio engine and it just replaces the "module" that has the old HLE audio:
http://forums.dolphin-emu.org/Thread-new-ax-hle-what-is-it-and-how-does-it-work

MarathonMan
January 25th, 2013, 20:46
Then isn't it more like Dolphin actually? Originally it used plugins but they got integrated in. I believe they are still somewhat modular on the development side however since, for example, they're developing a new HLE audio engine and it just replaces the "module" that has the old HLE audio:
http://forums.dolphin-emu.org/Thread-new-ax-hle-what-is-it-and-how-does-it-work

Never used Dolphin. But yes, the idea is that only developers control the plugins. I dislike the idea of plugins flying all over space as they do in PJ64 and others.

Fanatic 64
January 25th, 2013, 22:16
I assume your software rendering won't look like this:

MarathonMan
January 25th, 2013, 22:39
I assume your software rendering won't look like this:

That looks a little grainy from memory. If you're talking about the lower-resolution graphics, then, yes, that is what the software renderer will produce -- same thing that a console would.

Nintendo Maniac
January 25th, 2013, 23:02
If you're talking about the lower-resolution graphics, then, yes, that is what the software renderer will produce -- same thing that a console would.
Unless, you know, it's running in high-res mode (640x480 that is). Maybe such a thing could even be "forced" for games (like Mario 64) that didn't support it...?

MarathonMan
January 26th, 2013, 00:07
Unless, you know, it's running in high-res mode (640x480 that is). Maybe such a thing could even be "forced" for games (like Mario 64) that didn't support it...?

No idea, haven't looked into the RDP enough. I'll keep it in mind, though!

Nintendo Maniac
January 26th, 2013, 00:11
I'll keep it in mind, though! Really?! That'd be great! To be honest, I really don't think a 320x240 polygonal-3D image will look very pretty at all on anything other than an SDTV, and even then it can look like a jaggie-fest at times (Majora's Mask comes to mind).

Fanatic 64
January 26th, 2013, 00:48
That looks a little grainy from memory. If you're talking about the lower-resolution graphics, then, yes, that is what the software renderer will produce -- same thing that a console would.

I'm not talking about the 320x240 resolution, I'm talking about those blurry and distorted graphics. My real Nintendo 64 produces a clean image, while that is what Jabo Direct3D 8's software renderer produces.

Another example:

MarathonMan
January 26th, 2013, 01:23
I'm not talking about the 320x240 resolution, I'm talking about those blurry and distorted graphics. My real Nintendo 64 produces a clean image, while that is what Jabo Direct3D 8's software renderer produces.

Another example:

That's the whole point of software rasterization! My proposed render will produce pixel for pixel, luma for luma, the same image that a console would produce. If you have one hell of a computer, you should give MAME a go; angrylion already finished an implementation of one.

Fanatic 64
January 26th, 2013, 02:05
That's the whole point of software rasterization! My proposed render will produce pixel for pixel, luma for luma, the same image that a console would produce. If you have one hell of a computer, you should give MAME a go; angrylion already finished an implementation of one.

Thanks, just wanted to clear that doubt. I may give MAME a shoot, my computer (well, my processor, I doubt my integrated graphics chip will matter at all, so...) is decent so I guess I will at least be able to see it run .

DaFox
January 26th, 2013, 02:12
Good to see that you are still active MarathonMan! And nice progress.

I also enjoy the Dolphin way of doing modules.

Zuzma
January 26th, 2013, 07:20
Mame / mess is really cool except the thing is pretty unstable. Even mario 64 will lock up randomly in paintings or inside the castle. Hence the need for more research on the system itself. Actually I hope your findings can help their emulator out too MarathonMan.

MarathonMan
January 27th, 2013, 03:20
Realized (by accident) that I was doing something unbelievably clever and got a flat out ENORMOUS speed boost for some instructions (lqv, lrv, sqv, srv). I should be able to use the technique to wiggle out some performance of the other vector instructions, too. Completed all but a handful of the LWC2/SWC2 opcodes, and optimized them with SSE2/3.

I broke big-endian support pretty bad in the process, though... whoops.

EDIT: Got another (!) two major speedups. I was dual-issuing when I shouldn't have, and caught something else silly. Whoops. Today has been an outstanding today... decreased runtime by somewhere around 40% on the average case. Even my lowly, old Core 2 Duo @ 2GHz is able to run some of the benchmarks at 62.5MHz+ (worst case ones being somewhere around 44MHz). My "new" i7 is able to simulate the RSP at over 90MHz realtime for ALL microbenchmarks. I'm very pleased with this thing. :)

didado
January 27th, 2013, 12:01
Hey nice work :)

I wanted to ask you a question about the input lag on emulators. I always see input lag related problems on nes, snes, sega megadrive and master system consoles but not with a n64 emulator.
Because timing in these games are essential, does it have a impact on your emulator?

There are getting more and more n64 usb controllers and converters (Tomee http://stoneagegamer.com/pcmacusbmoonlightn64controller.aspx , Retrolink etc) and it would be great if these can get the proper support. Xbox360 and Logitech pc controllers are the most common these days so native support would be great to.

Thank you for keeping us up to date. :happy:

MarathonMan
January 27th, 2013, 16:09
I'll look into it later on down the road and see what I can do.

Do you have that controller/do you recommend it? I'm in the market for a USB controller... (N64-style)

Nintendo Maniac
January 27th, 2013, 17:01
I wanted to ask you a question about the input lag on emulators. I always see input lag related problems on nes, snes, sega megadrive and master system consoles
Even in bsnes, the dictionary example of an accurate LLE emulator?

--------------------------------------------------

Anyway, I have two concerns regarding this project, one about the "modules" and the other about saves and/or memory cards.

There is one big thing that I am leery of with dev-controlled plugins - regressions of any sort. In particular, the more accurate Dolphin HLE audio backend will completely replace the current HLE audio in version 4.0. The catch though is that the current HLE audio will play sound at 100% speed whether the game is at 75% or at 150%. The new HLE audio instead plays audio at the same speed as your gamespeed, and due to the dev-controlled modular approach of Dolphin, the user cannot choose to use the old HLE audio module. The old version, in particular, is useful if the user cannot run a game at 100% or they want to, say, play F-Zero GX at 90fps/150% (http://forums.dolphin-emu.org/Thread-f-zero-gx-90fps-150-holy?pid=252750).

My other concern is considerably less minor, but still a concern non-the-less. Even though this is all pretty much being written from scratch, are you considering being compatible with N64 save data from other emulators, such as the SRM and MPK formats? Also, what about the DexDrive .N64 memory card format?

didado
January 27th, 2013, 17:52
Hello all :)


Even in bsnes, the dictionary example of an accurate LLE emulator?

I know Bsnes is accurate and i cant compare with a real SNES because i don't have one. ;)
Nestopia i noticed the lag there and i find it unplayable with vsync off because of the tearing.
But even with tearing it can not be the same as the original.
And for me its logical that there is lag because a emulator needs to translate it from: windows -> emulator -> screen. :teehee:

I hope i am wrong lol :chinese:


I'll look into it later on down the road and see what I can do.

Do you have that controller/do you recommend it? I'm in the market for a USB controller... (N64-style)

I saw this you-tube review of that controller and i'm positive about that analog stick. ;)
"Featuring an unbreakable metal analog stick".


http://www.youtube.com/watch?v=doZEQ0NmNWA

I want to buy 4 of those controllers but i cant say if they are the best USB N64 controllers.

Nintendo Maniac
January 27th, 2013, 17:59
Speaking of controllers, since not all of us use N64 controllers and many of us use gamepads with a SNES-style button-layout, being able to have per-game control settings will pretty much be a requirement...

Oh, and I would love you forever if we could map an N64 controller button to multiple PC keys/buttons.

EDIT: I'll stop there and not turn this into a request topic - I mean we don't even have any retail games running.

Fanatic 64
January 27th, 2013, 18:49
Even in bsnes, the dictionary example of an accurate LLE emulator?
bsnes is a Cycle-Accurate Emulator (like this one), not a Low Level Emulator. They are 2 different things, Low Level Emulation is basically the in-between accuracy of High Level Emulation (Like PJ64) and Cycle-Accurate Emulation (like this emulator).


My other concern is considerably less minor, but still a concern non-the-less. Even though this is all pretty much being written from scratch, are you considering being compatible with N64 save data from other emulators, such as the SRM and MPK formats? Also, what about the DexDrive .N64 memory card format?
As far as I know, Native Saves (like EEPROM, FlashRAM, MemPak, etc) are the same between emulators and the real N64, so they should work with this emulator too.

And is great to hear such optimizations are being made! It seems like even the current High-End processors will be able to run this at a good speed (that thing of MESS requiring a year 2020 computer to run at near-fullspeed can kiss my ***).

P.S. I noticed this thread title currently says "Announcement: Cycle-accurate N64 development underway.", which could lead to believe that you are building a Cycle-Accurate physical replica of a Nintendo 64 or something like that (trough know that you have to ask a moderator if you want to change the thread's title, moderators here are kind enough so you could ask them if you want).

Nintendo Maniac
January 27th, 2013, 18:53
As far as I know, Native Saves (like EEPROM, FlashRAM, MemPak, etc) are the same between emulators and the real N64, so they should work with this emulator too.
Well I had to convert my .N64 DexDrive memory card save dumps to .MPK, and then had to re-save that .MPK via Project64 before I could use said .MPK in Wii64 (http://wiibrew.org/wiki/Wii64) (which itself is based off of Mupen64).

MarathonMan
January 27th, 2013, 19:19
Even in bsnes, the dictionary example of an accurate LLE emulator?

--------------------------------------------------

Anyway, I have two concerns regarding this project, one about the "modules" and the other about saves and/or memory cards.

There is one big thing that I am leery of with dev-controlled plugins - regressions of any sort. In particular, the more accurate Dolphin HLE audio backend will completely replace the current HLE audio in version 4.0. The catch though is that the current HLE audio will play sound at 100% speed whether the game is at 75% or at 150%. The new HLE audio instead plays audio at the same speed as your gamespeed, and due to the dev-controlled modular approach of Dolphin, the user cannot choose to use the old HLE audio module. The old version, in particular, is useful if the user cannot run a game at 100% or they want to, say, play F-Zero GX at 90fps/150% (http://forums.dolphin-emu.org/Thread-f-zero-gx-90fps-150-holy?pid=252750).

My other concern is considerably less minor, but still a concern non-the-less. Even though this is all pretty much being written from scratch, are you considering being compatible with N64 save data from other emulators, such as the SRM and MPK formats? Also, what about the DexDrive .N64 memory card format?

I won't budge on dev-controlled plugins, sorry. One of the thing that I dislike about modular plugins is that they encourage the community to fork off each other's work. This is good for projects with large developer bases, but not something like N64 emulation given how rare it is to find N64 emulator developers anymore. All my plugins will focus entirely on accuracy first and foremost. That being said, I'm also a performance nut and have been playing some tricks that I haven't seen anyone else in the community hasn't done yet, so hopefully performance isn't a concern. If it is, well, sorry...! Maybe I'll be able to do something about it down the road, but I'm striving for accuracy at the forefront because that's what I set out to do.

Probably won't be too hard; don't see why I couldn't have compatibility with other save states. If you or anyone else knows a little C, all it would involve in a few calls to fread() and fwrite() after looking up how both save states are structured.

MarathonMan
January 27th, 2013, 19:21
bsnes is a Cycle-Accurate Emulator (like this one), not a Low Level Emulator. They are 2 different things, Low Level Emulation is basically the in-between accuracy of High Level Emulation (Like PJ64) and Cycle-Accurate Emulation (like this emulator).


As far as I know, Native Saves (like EEPROM, FlashRAM, MemPak, etc) are the same between emulators and the real N64, so they should work with this emulator too.

And is great to hear such optimizations are being made! It seems like even the current High-End processors will be able to run this at a good speed (that thing of MESS requiring a year 2020 computer to run at near-fullspeed can kiss my ***).

P.S. I noticed this thread title currently says "Announcement: Cycle-accurate N64 development underway.", which could lead to believe that you are building a Cycle-Accurate physical replica of a Nintendo 64 or something like that (trough know that you have to ask a moderator if you want to change the thread's title, moderators here are kind enough so you could ask them if you want).

Heh. I looked at the MESS source and I'm crushing them in performance as far as executing the actual functional units goes. OTOH, my simulator is currently MUCH more accurate than MESS, and I haven't found a way to do dynarec (they do it, IIRC). So it'll be interesting to see how things turn out.

Forum title doesn't really bother me, but anyone can change it if they so please :p

Nintendo Maniac
January 27th, 2013, 19:27
I won't budge on dev-controlled plugins, sorry. One of the thing that I dislike about modular plugins is that they encourage the community to fork off each other's work. This is good for projects with large developer bases, but not something like N64 emulation given how rare it is to find N64 emulator developers anymore. All my plugins will focus entirely on accuracy first and foremost. That being said, I'm also a performance nut and have been playing some tricks that I haven't seen anyone else in the community hasn't done yet, so hopefully performance isn't a concern. If it is, well, sorry...! Maybe I'll be able to do something about it down the road, but I'm striving for accuracy at the forefront because that's what I set out to do.
Well I wasn't so much worried about performance as I was about feature-set, such as in Dolphin where the audio plays at 100% speed even if the game is at 150% speed. Performance can be made-up in time with newer hardware, but features are gone forever.


Probably won't be too hard; don't see why I couldn't have compatibility with other save states.Err, I was referring to actual game save data, not save states. As I stated with my Wii64 example, just because the file extensions are the same doesn't mean they're compatible.

Zuzma
January 27th, 2013, 19:55
bsnes is a Cycle-Accurate Emulator (like this one), not a Low Level Emulator. They are 2 different things, Low Level Emulation is basically the in-between accuracy of High Level Emulation (Like PJ64) and Cycle-Accurate Emulation (like this emulator).

I thought low level just meant the software tries to replicate more how the real system does it and cycle accurate has to do with the CPU emulator timing. If that's the case then bsnes would be both of those.

Fanatic 64
January 27th, 2013, 20:18
I thought low level just meant the software tries to replicate more how the real system does it and cycle accurate has to do with the CPU emulator timing. If that's the case then bsnes would be both of those.
Yeah pretty much that. That's why I say it's the in-between accuracy, because Cycle-Accuracy replicates the hardware timing while Low Level Emulation doesn't, but it is still more accurate than High Level Emulation.


Well I wasn't so much worried about performance as I was about feature-set, such as in Dolphin where the audio plays at 100% speed even if the game is at 150% speed. Performance can be made-up in time with newer hardware, but features are gone forever.
Well, I suppose if you know how to code, and the emulator's source code is released, you could readd the plugin/feature you want, right?

Nintendo Maniac
January 27th, 2013, 20:22
Well, I suppose if you know how to code
yeah, about that... coding has always been my weak point. I can remove a CPU IHS and make XP run on 256MB of RAM with no pagefile without having a program crash, but give me a line of code and I'll be lost.

(I can however read some HTML along with do some basic command line stuff, and can make simple .BAT files :P)

Zuzma
January 27th, 2013, 20:29
Yeah pretty much that. That's why I say it's the in-between accuracy, because Cycle-Accuracy replicates the hardware timing while Low Level Emulation doesn't, but it is still more accurate than High Level Emulation.

I agree with that. Pure HLE is an interesting way to get games working, but in the long run it can't run all the software on the system in an emulated enviroment. A combination of HLE and LLE or pure LLE is nice too though you'd still be stuck with some odd bugs in games. Cycle accuracy is really the final step as I see it and can be better, but isn't always feasible either.

Edit: This is how I see it as a user not a programmer or an engineer. I honestly wish I knew more about it, but I'm an expert at wasting my own time. :P

Rich_T
January 30th, 2013, 22:16
I too want to add my voice in approval of this thread, I very much hope we see a working build.

This would no doubt bring much need life back into the scene.

Keep up the great work!

squall_leonhart
January 31st, 2013, 04:16
Cycle accurate is low level, but not all low level is cycle accurate.

Please stop attempting to create a new tier of emulation.

didado
January 31st, 2013, 17:16
squall.. so no one must try it because your brains says its useless.. Or you say he's saying things that aren't possible?

Nintendo Maniac
January 31st, 2013, 17:19
I think he is saying that "cycle accurate" is a tier WITHIN "low level emulation" and therefore cannot be viewed as separate tier unto itself.

zoinkity
January 31st, 2013, 18:24
Okay, if we really want to get nitpicky about this, it's a kind of low-level emulation.
Typically when we think low-level we think of something like Mame's amazing hardware emulation. They emulate the behaviour of each of the chips used in a given arcade game. This is low-level hardware emulation.
Technically, you don't have to be cycle accurate when doing this kind of emulation, but chances are you will be. The reason has to do with how your software must interpret the number of cycles each emulated opcode/process should take and count it itself. If you're off, don't account for something, or just don't bother to keep track then it isn't cycle-accurate, since you aren't accurately tracking cycles.

Then there's the flip side. It is possible to be cycle-accurate without being hardware accurate. For a working case of this look at old Speccy emulators, from back in the snapshot days. They weren't running original media, weren't emulating quirks in the CPU or external hardware, half of the tech stuff wasn't even worked out, but they did keep accurate track of cycles (in most cases ;*)). Why? Mainly because the things actually needed to know the current cycle count.

So, what would be the point of a theoretical HLE cycle-accurate N64 emu? Well, how many cycles does each of these eat:
1) ADDIU R0,R0,0000; ADDIU R0,R0,0000; ADDIU R0,R0,0000
2) SLL R0,R0,0x0; SLL R0,R0,0x0; SLL R0,R0,0x0
3) OR R0,R0,R0; OR R0,R0,R0; OR R0,R0,R0
Might not seem pertinent to most users, but it was very pertinent to the developers of the Quagmire engine. Different types of opcode combinations can be executed simultaneously (here meaning within the same cycle), leading to final optimization. They were very careful what kinds of NOPs they put where. To be fair, there's more at work here than mere cycle counts, but anything leading in that direction would greatly assist new developers.

Zuzma
February 1st, 2013, 08:16
Cycle accurate is low level, but not all low level is cycle accurate.

Please stop attempting to create a new tier of emulation.

I know that squall. I was trying to be nice. But yeah I guess I should have just corrected it rather then do that. It was a dumb thing to do.

Rich_T
February 1st, 2013, 17:02
Can I ask, what tools and software are you using to go about this task,
I'm genuinely interested to understand more and want to know how an ideal, i.e. 'make a N64 cycle-accurate emu' actually turns into something usable.

MarathonMan
February 3rd, 2013, 03:05
Can I ask, what tools and software are you using to go about this task,
I'm genuinely interested to understand more and want to know how an ideal, i.e. 'make a N64 cycle-accurate emu' actually turns into something usable.

Sure, a C compiler (gcc, to be exact). That's it.

Oh, and a LOT of documentation that I've gathered.

Sorry I couldn't be more specific/have details. Shoot any other questions you may have, though.

Fanatic 64
February 3rd, 2013, 04:07
You know, I don't want to sound impatient at all but I just wonder, how likely is that this thing reaches mature development stages before 2020?

Again, just wondering :saint:

Nintendo Maniac
February 3rd, 2013, 04:14
TBH, assuming you have the necessary documentation, I would think a LLE emulator could actually reach usable status earlier than an HLE emulator for the same system. The idea here is that LLE code, in theory, can have things "just work".

...of course, I could be way off on that assessment since I can't actually code myself. >_>

DETOMINE
February 3rd, 2013, 14:42
You know, I don't want to sound impatient
You totally sound impatient :teehee: .

MarathonMan
February 3rd, 2013, 21:57
You know, I don't want to sound impatient at all but I just wonder, how likely is that this thing reaches mature development stages before 2020?

Again, just wondering :saint:

Heh, no offense taken. I honestly don't get a lot of time to work on it, but I'm guessing it'll take _at least_ a year at the rate things are progressing now. My job and degree always come first, and don't seem to leave me with a lot of time as of late.

Fanatic 64
February 4th, 2013, 00:06
You totally sound impatient :teehee: .
I was just curious. The attack wasn't necessary.

Nintendo Maniac
February 5th, 2013, 01:11
I just had a thought. Since this doesn't have a GUI let alone an actual true full-on emulation core yet, would it not be optimal to leverage RetroArch so that development can focus mainly on actual cycle accuracy emulation?

Fanatic 64
February 5th, 2013, 02:29
I just had a thought. Since this doesn't have a GUI let alone an actual true full-on emulation core yet, would it not be optimal to leverage RetroArch so that development can focus mainly on actual cycle accuracy emulation?
http://themaister.net/retroarch.html

I suppose it depends on wherever MarathonMan wants to give his work to the RetroArch guys, or if he wants to make his own emulator (based on his comments I think he wants the 2nd option, but you never know).

MarathonMan
February 6th, 2013, 06:02
I just had a thought. Since this doesn't have a GUI let alone an actual true full-on emulation core yet, would it not be optimal to leverage RetroArch so that development can focus mainly on actual cycle accuracy emulation?

Not interested in flumbing around with third-party libraries, sorry.

That being said, everything I write is in ANSI C (+standard integer types; you can either use C99/C11 or typedef them in the common header -- already did the latter for MSVC). It literally compiles on _anything_ and is written very cleanly, so anyone with familiarity with the framework shouldn't have any difficulty porting it.

weinerschnitzel
February 7th, 2013, 18:29
Not interested in flumbing around with third-party libraries, sorry.

That being said, everything I write is in ANSI C (+standard integer types; you can either use C99/C11 or typedef them in the common header -- already did the latter for MSVC). It literally compiles on _anything_ and is written very cleanly, so anyone with familiarity with the framework shouldn't have any difficulty porting it.

<3 I patiently await your finished project.

I'm not so sure if the current platforms RetroArch boasts will be able to handle cycle accurate low level N64 emulation. But it could eliminate the dependency for a "3DArch" that would heavily utilize DirectX or OpenGL for hardware accelerated graphics... if we're talking libretro n64 emu.

Nintendo Maniac
February 7th, 2013, 19:55
RetroArch currently can run the bsnes accuracy profile, and this N64 emulator project will use software rasterization, so surely it'd be possible, no?

Fanatic 64
February 7th, 2013, 20:01
I see you really want this emulator to became a RetroArch module...

Nintendo Maniac
February 7th, 2013, 20:36
I just don't want it locked to PCs and/or the x86 architecture is all, and RetroArch provides an easy way to get it on other platforms. And since this is to be cycle-accurate, I wouldn't expect another emulator to do a better job at accuracy any time soon, so planning for "future proofing" may be wise.

Fanatic 64
February 7th, 2013, 20:41
I just don't want it locked to PCs and/or the x86 architecture is all, and RetroArch provides an easy way to get it on other platforms. And since this is to be cycle-accurate, I wouldn't expect another emulator to do a better job at accuracy any time soon, so planning for "future proofing" may be wise.

MarathonMan already said: "everything I write is in ANSI C (+standard integer types; you can either use C99/C11 or typedef them in the common header -- already did the latter for MSVC). It literally compiles on _anything_ and is written very cleanly, so anyone with familiarity with the framework shouldn't have any difficulty porting it", which means it isn't locked to pretty much anything.

Nintendo Maniac
February 7th, 2013, 20:47
But I'm afraid that people won't port it to things like future consoles because they'll be too concerned with performance, regardless of whether an older emulator can even RUN the game. Heck, even WITH RetroArch nobody seems concerned with porting bsnes to anything other than PC, most likely because Snes9x is seen as good enough.

Fanatic 64
February 7th, 2013, 20:54
But I'm afraid that people won't port it to things like future consoles because they'll be too concerned with performance, regardless of whether an older emulator can even RUN the game. Heck, even WITH RetroArch nobody seems concerned with porting bsnes to anything other than PC, most likely because Snes9x is seen as good enough.
Personally I've always seen emulators on other videogame consoles as something rather trivial. And RetroArch is pretty much just a collection of emulators under the same program, isn't like it does anything outstanding for portability or much less performance.

Nintendo Maniac
February 7th, 2013, 20:59
It was my impression that RetroArch lib files, if designed correctly, can automatically work on any platform that RetroArch is ported to.

Fanatic 64
February 7th, 2013, 21:10
It was my impression that RetroArch lib files, if designed correctly, can automatically work on any platform that RetroArch is ported to.

This emulator will be able to work on any platform, even ones not supported by RetroArch, with minimal to no effort, just by compiling and running it.

Nintendo Maniac
February 7th, 2013, 21:17
This emulator will be able to work on any platform, even ones not supported by RetroArch, with minimal to no effort, just by compiling and running it.
It's not minimal to no effort if you have to code a UI...hence RetroArch.

Fanatic 64
February 7th, 2013, 21:26
It's not minimal to no effort if you have to code a UI...hence RetroArch.
RetroArch has no UI, just a frontend that has to be ported separately.

And if you want SO badly this emulator to became a RetroArch module, then you'll have to port it yourself, since MarathonMan already stated his not making it such.

Nintendo Maniac
February 7th, 2013, 21:33
RetroArch has no UI, just a frontend that has to be ported separately.

There however, is pre-existing interest in creating a UI for ports of the RetroArch frontend specifically because it brings multiple quality emulators with it.


And if you want SO badly this emulator to became a RetroArch module, then you'll have to port it yourself, since MarathonMan already stated his not making it such.

...you seem to be misinterpreting my posts as wishing/begging/pleading/etc. for this to become a RetroArch module.

After MarathonMan stated he wasn't going to, all subsequent posts were purely about the benefits of such an approach, not why I feel this project should actually actively pursue such a thing. If this is not how I came off in my posts, then I apologize - text is poor at conveying the correct feeling and emotion behind one's ideas.

Fanatic 64
February 7th, 2013, 21:39
...you seem to be misinterpreting my posts as wishing/begging/pleading/etc. for this to become a RetroArch module.

After MarathonMan stated he wasn't going to, all subsequent posts were purely about the benefits of such an approach, not why I feel this project should actually actively pursue such a thing.
...then we are going off-topic. We should keep this discussion somewhere else (trough personally I think I'm done with it, all I want to discuss is about this project, not something unrelated to it).

Nintendo Maniac
February 7th, 2013, 21:41
...then we are going off-topic. We should keep this discussion somewhere else (trough personally I think I'm done with it, all I want to discuss is about this project, not something unrelated to it).
Same here, I didn't really want to keep discussing this and I was concerned about off-topic-ness as well, but the conversation kept going so...

MarathonMan
February 8th, 2013, 01:19
It was my impression that RetroArch lib files, if designed correctly, can automatically work on any platform that RetroArch is ported to.

They'd have to be recompiled for the target architecture, but assuming the interface is the same, then yes, they're portable.

MarathonMan
February 9th, 2013, 00:58
Found out that I wasn't stalling in a couple of conditions when I should have, did a full analysis of the RSP, and ... rewrote librsp. :yucky:

I didn't want to, but I dug myself into a hole. On the upside, I've more or less finished the rewrite and got a major performance boost. I pushed the instruction decoding out of the IF stage (and into RD), which assisted the compiler in register allocation significantly. Don't ask why I didn't do that in the first place. I also missed a really easy optimization that reduced the execution time of many of the functional units. Lastly, I rewrote the decoder and other mechanisms in a manner that is amenable to dynamic recompilation for down the road. I'd say it was time well spent. :)

Now for a battery of regression testing, and hopefully implementing most, if not all, of the vector computational instructions this weekend.

Thinking about open-sourcing under the MAME license, too.

Wow, that was a lot of random thoughts.

MarathonMan
February 9th, 2013, 21:23
More good news...

None of the current emulators make effective use of SSE. I figured out how to map most (if not all) of the RSP's vector functions directly to x86 SSE.

I have a feeling that my cycle-accurate core is faster than PJ64's intepreted core, and continually nearing the recompiler core. Whenever/if I implement dynarec, the performance should be comparable. :)

Nintendo Maniac
February 9th, 2013, 22:00
Now, is said SSE optional? Cause you obviously don't want it on ARM and/or PowerPC since SSE is x86-exclusive (though ARM does have NEON).

Zuzma
February 9th, 2013, 22:14
More good news...

None of the current emulators make effective use of SSE. I figured out how to map most (if not all) of the RSP's vector functions directly to x86 SSE.

I have a feeling that my cycle-accurate core is faster than PJ64's intepreted core, and continually nearing the recompiler core. Whenever/if I implement dynarec, the performance should be comparable. :)

That sounds like ps2 emulator level stuff. Pretty sure they have some kind of dynamic recompiler for the systems vector unit. Also sure it's fast now but would hooking it up to the main CPU and RCP slow it down somewhat or are you not worried about that?

Rodimus Primal
February 9th, 2013, 22:48
I have to admit MarathonMan, every time you post an update I get a little excited that a really great running N64 emulator will be out and playable soon enough. I wish I knew enough about coding to help out.

MarathonMan
February 10th, 2013, 01:37
Now, is said SSE optional? Cause you obviously don't want it on ARM and/or PowerPC since SSE is x86-exclusive (though ARM does have NEON).

Optional, but I haven't implemented the "non-SSE" variant in interest of time. Code is basically:

void func_t() {

#ifdef _USE_SSE_
_mm_adds_epi16(...)
...
#else
...

}

You just need to compile with flags that tell the compiler which variant to compiler for:
gcc -D_USE_SSE_ ... -o librsp_sse.a
or
gcc ... -o librsp_generic.a

MarathonMan
February 10th, 2013, 01:38
That sounds like ps2 emulator level stuff. Pretty sure they have some kind of dynamic recompiler for the systems vector unit. Also sure it's fast now but would hooking it up to the main CPU and RCP slow it down somewhat or are you not worried about that?

Running dynarec cores isn't at all an issue, so no. I could even have some interpreted cores and dynarec cores working in unison if I wanted.

Zuzma
February 10th, 2013, 02:19
That's so awesome. Thanks a ton for working on this. :)

MarathonMan
February 10th, 2013, 08:09
Yep, turns out the entire RSP vector opcode set maps perfectly to SSE. Not a single one of my vector instructions have a loop when SSE is enabled.

Hope you have SSE4.1 though!



0000000000000180 <RSPVMADH>:
180: 89 f2 mov %esi,%edx
182: 89 f0 mov %esi,%eax
184: c5 f9 6f 15 00 00 00 vmovdqa 0x0(%rip),%xmm2 # 18c <RSPVMADH+0xc>
18b: 00
18c: c1 ea 10 shr $0x10,%edx
18f: c1 e8 06 shr $0x6,%eax
192: 83 e2 1f and $0x1f,%edx
195: 83 e0 1f and $0x1f,%eax
198: 48 c1 e2 04 shl $0x4,%rdx
19c: c5 fa 6f 24 17 vmovdqu (%rdi,%rdx,1),%xmm4
1a1: 89 f2 mov %esi,%edx
1a3: c1 ee 0b shr $0xb,%esi
1a6: 83 e6 1f and $0x1f,%esi
1a9: c1 ea 15 shr $0x15,%edx
1ac: 48 c1 e6 04 shl $0x4,%rsi
1b0: 83 e2 0f and $0xf,%edx
1b3: c5 fa 6f 1c 37 vmovdqu (%rdi,%rsi,1),%xmm3
1b8: 48 c1 e2 04 shl $0x4,%rdx
1bc: c4 e2 59 00 a2 00 00 vpshufb 0x0(%rdx),%xmm4,%xmm4
1c3: 00 00
1c5: c5 f9 73 dc 08 vpsrldq $0x8,%xmm4,%xmm0
1ca: c4 e2 79 23 fc vpmovsxwd %xmm4,%xmm7
1cf: c4 e2 61 00 da vpshufb %xmm2,%xmm3,%xmm3
1d4: c4 e2 79 23 cb vpmovsxwd %xmm3,%xmm1
1d9: c5 e1 73 db 08 vpsrldq $0x8,%xmm3,%xmm3
1de: c4 e2 79 23 f3 vpmovsxwd %xmm3,%xmm6
1e3: c4 e2 79 23 c0 vpmovsxwd %xmm0,%xmm0
1e8: 89 c2 mov %eax,%edx
1ea: c4 e2 41 40 c9 vpmulld %xmm1,%xmm7,%xmm1
1ef: c5 fa 6f 9f 00 02 00 vmovdqu 0x200(%rdi),%xmm3
1f6: 00
1f7: 48 c1 e2 04 shl $0x4,%rdx
1fb: c4 e2 79 40 c6 vpmulld %xmm6,%xmm0,%xmm0
200: c5 fa 6f a7 10 02 00 vmovdqu 0x210(%rdi),%xmm4
207: 00
208: c5 d9 61 eb vpunpcklwd %xmm3,%xmm4,%xmm5
20c: c5 d9 69 db vpunpckhwd %xmm3,%xmm4,%xmm3
210: c5 f1 fe cd vpaddd %xmm5,%xmm1,%xmm1
214: c5 f9 fe c3 vpaddd %xmm3,%xmm0,%xmm0
218: c5 f1 6b d8 vpackssdw %xmm0,%xmm1,%xmm3
21c: c4 e2 61 00 d2 vpshufb %xmm2,%xmm3,%xmm2
221: c5 f9 7f 14 17 vmovdqa %xmm2,(%rdi,%rdx,1)
226: c5 f9 7f 8f 10 02 00 vmovdqa %xmm1,0x210(%rdi)
22d: 00
22e: c5 f9 7f 87 00 02 00 vmovdqa %xmm0,0x200(%rdi)
235: 00
236: 89 87 80 02 00 00 mov %eax,0x280(%rdi)
23c: c3 retq
23d: 0f 1f 00 nopl (%rax)

Nintendo Maniac
February 10th, 2013, 17:57
...yeah, you're going to want to make that dynamically available or something, because even Thuban doesn't have anything above SSE3.

MarathonMan
February 10th, 2013, 18:11
...yeah, you're going to want to make that dynamically available or something, because even Thuban doesn't have anything above SSE3.

Not a concern for now. SSE4.1 has been around since Core 2/Penryn on the Intel side of things.

Nintendo Maniac
February 10th, 2013, 18:14
Not a concern for now. SSE4.1 has been around since Core 2/Penryn on the Intel side of things.
...well dang, I won't be able to use this emulator until then. :/ (I'm on an AM3 mobo, NOT AM3+)

MarathonMan
February 10th, 2013, 18:44
...yeah, you're going to want to make that dynamically available or something, because even Thuban doesn't have anything above SSE3.

Heh, it'll be on my todo list, no worries. It's just not a foremost concern. I want to get a picture before I start working on features and older hardware.

EDIT: Yeah, just looked... I'm putting it off til later. On the plus side, only two intrinsics are from 4.1 (_mm_cvtepi16_epi32 and _mm_mullo_epi32). Maybe somebody else interested in the project will patch them for me during betas. :p

OTOH, anyone who wants to take advantage of SSE acceleration and doesn't have SSSE3 is basically out of luck ATM.

Nintendo Maniac
February 11th, 2013, 01:17
Umm... on an unrelated note, would it be too ridiculous to suggest an overclocking function like that in 1964 Ultra Fast?

MarathonMan
February 11th, 2013, 05:36
Umm... on an unrelated note, would it be too ridiculous to suggest an overclocking function like that in 1964 Ultra Fast?

That's be so easy to implement. I'd just call cycle() on all the cores more frequently.

Though I don't you'll be able to handle it unless you have a _really_ beefy system. This is a cycle accurate simulator that already has ~100 million cycles on multiple cores to process every second.

Nintendo Maniac
February 11th, 2013, 05:38
Just thinking that World Driver Championship seemed to have a variable framerate, so I'd like to take advantage of that in the future. Also Smash Bros. 64 tourney players would probably appreciate it since we can't expect the cartridges and consoles to last forever. (4-player apparently doesn't run at full speed on an N64 and requires an overclocked system for full speed)

But I gotta ask, if it's so easy to implement then why has no other emulator implemented it? Is it a limitation of HLE or something?

MarathonMan
February 11th, 2013, 06:00
Just thinking that World Driver Championship seemed to have a variable framerate, so I'd like to take advantage of that in the future. Also Smash Bros. 64 tourney players would probably appreciate it since we can't expect the cartridges and consoles to last forever. (4-player apparently doesn't run at full speed on an N64 and requires an overclocked system for full speed)

But I gotta ask, if it's so easy to implement then why has no other emulator implemented it? Is it a limitation of HLE or something?

Cycle accuracy just makes it easier because I directly control the clockrate.

I imagine that it wouldn't be _that_ much harder; maybe there's not enough of a push for it? I don't know.

XICO2KX
February 11th, 2013, 20:30
I have a feeling that my cycle-accurate core is faster than PJ64's intepreted core, and continually nearing the recompiler core. Whenever/if I implement dynarec, the performance should be comparable. :)That's great news, MarathonMan! :drool:
I hope we'll soon see N64 games running flawlessly using your project! :happy:
Keep up the really awesome work, man! ;)

XICO2KX
February 11th, 2013, 20:30
Now, is said SSE optional? Cause you obviously don't want it on ARM and/or PowerPC since SSE is x86-exclusive (though ARM does have NEON).
After the SSE implementation is done, if someone wants to port it to Altivec (used in PowerPC), these technical docs from Apple might make it easier! :shifty:

h**p://developer.apple.com/legacy/mac/library/documentation/Performance/Conceptual/Accelerate_sse_migration/Accelerate_sse_migration.pdf#page=25
It explains Altivec->SSE migration, but you can also make it the other way around! :teehee:
I'm curious to see if this will ever run (at decent speeds) on the Wii!:rolleyes:

Nintendo Maniac
February 11th, 2013, 20:34
Wow, you joined all the way back in 2006 yet made only one post and then make your second and third 7 years later one after another? O_o

Did someone happen to link you here from another site by any chance?


As for Altivec, won't that only be useful once next-gen consoles get homebrew'd? (Wii U is only running homebrew in Wii Mode currently) I don't think the PS360 have enough CPU grunt considering Marcan of Wii homebrew fame claims they have Pentium4-esque IPC.

DaFox
February 12th, 2013, 08:17
I signed up in 2005 and my second post was in this thread, I don't see why it's a big deal. This is really one of the few interesting thing to happen in N64 Emulation since around then anyway.

There's a whole lot of technical info going on at forum.pj64-emu.com/showthread.php?t=3445 Some great back and forth later on in the thread once the trolls die out.

Nintendo Maniac
February 12th, 2013, 08:20
It's not a big deal as in being a problem, I've just never seen it happen before.

winter_mute
February 12th, 2013, 12:58
It's not a big deal as in being a problem... [...]Then... please... stay on topic.

BTW; Keep up great work, MarathonMan.

XICO2KX
February 12th, 2013, 19:03
Wow, you joined all the way back in 2006 yet made only one post and then make your second and third 7 years later one after another? O_o

Did someone happen to link you here from another site by any chance?Yes, but better late than never! :P
This thread seemed worthy for my 1st post! ;)
Actually, I did all my 3 first post the same day! :happy:

As for Altivec, won't that only be useful once next-gen consoles get homebrew'd? (Wii U is only running homebrew in Wii Mode currently) I don't think the PS360 have enough CPU grunt considering Marcan of Wii homebrew fame claims they have Pentium4-esque IPC.
Yes, you are right!:unsure:
At least for the Wii's Broadway CPU (en.wikipedia.org/wiki/Broadway_%28microprocessor%29) (an IBM PowerPC 750CL (en.wikipedia.org/wiki/PowerPC_G3#Broadway) variation) does not include Altivec!:ermm:
Sorry, my mistake!:whistling
But it does support some SIMD instructions named Paired Single instructions (wiibrew.org/wiki/Paired_single), which you can find more about in this technical doc (raidenii.net/files/datasheets/cpu/ppc_broadway.pdf#G21.65213)!:satisfied
On the other hand, both Xbox360 (en.wikipedia.org/wiki/Xenon_%28processor%29#Specifications) and PS3 (en.wikipedia.org/wiki/Cell_%28microprocessor%29#Power_Processo r_Element_.28PPE.29) CPUs support those Altivec SIMD instructions (en.wikipedia.org/wiki/AltiVec#Development_history)! :shifty:
But like you said, not sure if they have enough speed to run this kind of accurate N64 emulation!:geek:

Nintendo Maniac
February 13th, 2013, 19:49
It just hit me. Being an emulator focused on accuracy, widescreen hacks will be out of the question wouldn't it... or would such a thing be part of the theoretical "OpenGL accelerated render plugin" that you mentioned before?

Fanatic 64
February 13th, 2013, 20:51
I have actually been thinking on something. If this emulator supposedly outputs in the resolution and aspect ratio the game runs at, then what would happen with games that run at resolutions such as 640x240 (Mid-res) and let the TV stretch it to 4:3 (640x480)? Would this emulator allow for an option to stretch non-4:3 resolutions (like 640x240 (Top Gear Overdrive), 640x220 (Perfect Dark), etc) to their closest 4:3 resolution (640x480)? Maybe by stretching the final frame with bilinear filter or something like that.

You know, like the higan/bsnes option "Aspect ratio correction".

(Maybe we could also include a hack to force games to run at 640x480, trough I don't know how feasible would be that whiting an emulator that works so closely like the real N64.)

(And we maybe also could include an option to stretch the final frame to the closest 16:9 resolution (like 854x480), for games that include a widescreen option.)

Nintendo Maniac
February 13th, 2013, 21:18
He is already considering a "force high-res mode" (aka 640x480) after I suggested it earlier.

And speaking about aspect ratios, World Driver Championship's hi-res mode runs at something like 640x240 but actually runs in that aspect ratio as well, that is 8:3 (or something close to that). However the in-game menus still run at 4:3, maybe even at 320x240p. This means that the emulator would have to dynamically change the window/fullscreen aspect ratio on the fly if you want "hi-res" mode to horizontally fill a widescreen monitor without the top & bottom of the main menu getting cut off.

Emutalkguy
February 14th, 2013, 00:13
So what is the current progress on this emulator? When is an expected release? And the most important (and god I hope you answer yes) question... Will there be NETPLAY/MULTIPLAYER ONLINE?


Please. Just.... Please.

Nintendo Maniac
February 14th, 2013, 00:16
The answer to all of those is most likely unknown at this point because it's not even running any actual games yet, not even homebrew.

Nevertheless, regarding online, even if this emulator does not implement it, someone could enable it via porting this to a RetroArch module since RetroArch supports online. However, we previously already discussed RetroArch to death, so it'd be better to not go into that subject again.

MarathonMan
February 14th, 2013, 01:58
So what is the current progress on this emulator? When is an expected release? And the most important (and god I hope you answer yes) question... Will there be NETPLAY/MULTIPLAYER ONLINE?


Please. Just.... Please.

1) Read the last few pages.
2) I've seen it before in regards to other things...

**No "features" that are not absolutely required for gameplay of any kind are immediate goal/promise. I'm a one man team working on an emulator that's being written from scratch, and most of my time is spent after work/early in the morning.**

Please ask me if I'm going to support X technology or Y feature. I don't know. Maybe I will down the road, maybe I won't. I don't want to make promises I can't keep, and I'm already spending a lot of time on this thing as it is.

I won't even have a GUI until I get sound/video/basic input working.

Nintendo Maniac
February 14th, 2013, 02:01
Crazy idea: if someone DOES port this to RetroArch before you've even made a GUI, would you still make an "official" GUI yourself?

MarathonMan
February 14th, 2013, 02:13
Crazy idea: if someone DOES port this to RetroArch before you've even made a GUI, would you still make an "official" GUI yourself?

Probably. Not a fan of big applications sitting on top of me.

Nintendo Maniac
February 14th, 2013, 02:14
I told you it was a crazy idea. :P

And from a bit of research I can confirm that yes, World Driver Championship does get a performance benefit from overclocking the N64. Note that 1964 Ultra Fast can NOT run WDC at all since, AFAIK, the only playable emulator configuration uses PJ64 v1.5, and PJ64 obviously lacks overclocking.

MarathonMan
February 14th, 2013, 02:24
I told you it was a crazy idea. :P

And from a bit of research I can confirm that yes, World Driver Championship does get a performance benefit from overclocking the N64. Note that 1964 Ultra Fast can NOT run WDC at all since, AFAIK, the only playable emulator configuration uses PJ64 v1.5, and PJ64 obviously lacks overclocking.

zilmar seems to be active again. Perhaps you should ask him to?

Nintendo Maniac
February 14th, 2013, 02:29
Getting both WDC AND overclocking to be natively supported in PJ64 would be quite the long shot. The only way WDC even works is via a hacked RSP for the Z64 LLE plugin, and even that isn't perfect. (The American version of WDC has some minor texture issues and the European version has very annoying texture issues)

EDIT: maybe not as much of a long shot as I thought:
http://forum.pj64-emu.com/showpost.php?p=43385&postcount=5

...oh wait, you yourself have posted in that thread. :P So that's where your actual dev and coding discussions happen at...

dsx
February 14th, 2013, 04:05
zilmar has set up the latest pj64 alpha version to boot WDC without changing any settings (automatically uses LLE and such)

Nintendo Maniac
February 14th, 2013, 04:07
Really? Well then, now we just need to drum up more interest in N64 overclocking:
http://forum.pj64-emu.com/showthread.php?t=337

That thread hasn't had a new post in 18 months.

dsx
February 14th, 2013, 04:15
when i play WDC on my N64 it seems to be a constant 30fps but 60fps would be nice

Nintendo Maniac
February 14th, 2013, 04:17
Race on Sydney A and go through the first hairpin that's about 1/3 through the track. I particularly noticed the framerate drop in hi-res mode (it's moderately minor, but there)

Also I haven't played the game in quite a while, but considering I noticed the framerate drop even back then, I wouldn't be surprised if less-noticable drops occurred more frequently.

dsx
February 14th, 2013, 04:22
Ah yeah, maybe i did notice and just forgot

Still runs surprisingly well considering how great the game looks

Nintendo Maniac
February 14th, 2013, 04:25
zilmar has set up the latest pj64 alpha version to boot WDC without changing any settings (automatically uses LLE and such)
Oh, I gotta ask, how does PJ64 handle the "cinema-widescreen" aspect ratio of 'hi-res mode' in combination with the 4:3 ratio of the main menu?

zilmar
February 14th, 2013, 04:30
Oh, I gotta ask, how does PJ64 handle the "cinema-widescreen" aspect ratio of 'hi-res mode' in combination with the 4:3 ratio of the main menu?

Sent you a PM

Nintendo Maniac
February 14th, 2013, 04:38
Acknowledged and replied.

EDIT: I'm not getting email notification of PMs? The crap...

EDIT 2: Email notification has been fixed.

MarathonMan
February 16th, 2013, 04:44
Implemented a skew of RSP functions; everything is written in SSSE3/SSE4.1, and there are no loops anywhere. For an interpreter, this thing is screaming.

Still have to implement all the vector compares (except VEQ), VMAC*, VMOV, VMRG, VMUL*, VRCP*, VRND*, VRS*, and VSAR... other than that, the RSP is nearing completion!

Nintendo Maniac
February 16th, 2013, 04:57
For an interpreter, this thing is screaming.

Define "screaming". Is it like running F-Zero GX at 90fps/150% on a 4.5GHz Sandy/Ivy Bridge? :P

MarathonMan
February 16th, 2013, 05:00
Define "screaming". Is it like running F-Zero GX at 90fps/150% on a 4.5GHz Sandy/Ivy Bridge? :P

Simulating a RSP with no stalls at 100MHz on a 4.5GHz Sandy. I don't have the VR4300 or devices emulated anywhere near enough to run ROMs.

Guru64
February 16th, 2013, 09:49
I don't have the VR4300 or devices emulated anywhere near enough to run ROMs.

Let alone Gamecube games.

Fanatic 64
February 16th, 2013, 20:03
Let alone Gamecube games.
What?

If this is a reference to Dolphin, I think you should know Dolphin cannot emulate the N64 at all, what it can emulate is an emulator made by Nintendo to run N64 games on the Wii (aka. Virtual Console).

And this emulator is not meant to compete at all with something like Dolphin, it is meant to be specifically a cycle-accurate N64 emulator.

MarathonMan
February 16th, 2013, 23:42
Getting bored with implementing RSP instructions (aka writing SSE). Going to fill in the rest of the RSP with stubs that just alert me when unimplemented functions get called and jump back over to the VR4300/PIF for awhile. I think there's enough functionality in the RSP to get basic (read: very, very basic) homebrew to boot... would be nice to get something out on the screen, even if it's a static picture with rotating sprites.

Guru64
February 17th, 2013, 00:38
What?

If this is a reference to Dolphin, I think you should know Dolphin cannot emulate the N64 at all, what it can emulate is an emulator made by Nintendo to run N64 games on the Wii (aka. Virtual Console).

And this emulator is not meant to compete at all with something like Dolphin, it is meant to be specifically a cycle-accurate N64 emulator.

It was a reference to Nintendo Maniac's post. F-Zero GX is not a Nintendo 64 game. :P

Fanatic 64
February 17th, 2013, 03:03
Getting bored with implementing RSP instructions (aka writing SSE). Going to fill in the rest of the RSP with stubs that just alert me when unimplemented functions get called and jump back over to the VR4300/PIF for awhile. I think there's enough functionality in the RSP to get basic (read: very, very basic) homebrew to boot... would be nice to get something out on the screen, even if it's a static picture with rotating sprites.
Well, you can always go work on something else and then go back to the RSP. I suppose it would be a significant achievement if you could actually run something and get output to the screen (trough I imagine you would need a Reality Drawing Processor emulator and either a software rasterizer, DirectDraw/Direct3D or OpenGL output method).

MarathonMan
February 17th, 2013, 16:24
Well, you can always go work on something else and then go back to the RSP. I suppose it would be a significant achievement if you could actually run something and get output to the screen (trough I imagine you would need a Reality Drawing Processor emulator and either a software rasterizer, DirectDraw/Direct3D or OpenGL output method).

Right... of course. I'm just saying that if I run homebrew pong, I doubt it'll use the clipping instructions of the RSP or really complex features of the VR4300. I'm really anxious to get to the RDP.

Nintendo Maniac
February 17th, 2013, 19:00
It was a reference to Nintendo Maniac's post. F-Zero GX is not a Nintendo 64 game. :P

Of course it isn't, but running it at 90fps/150% on a 4.5GHz Sandy/Ivy surely counts as "screaming", no?

olivieryuyu
February 17th, 2013, 20:45
Right... of course. I'm just saying that if I run homebrew pong, I doubt it'll use the clipping instructions of the RSP or really complex features of the VR4300. I'm really anxious to get to the RDP.

why not using Angrylion work? he works on the RDP on a LLE level for years now ...

MarathonMan
February 17th, 2013, 21:47
why not using Angrylion work? he works on the RDP on a LLE level for years now ...

1) Not cycle accurate; just pixel-accurate.
2) I genuinely enjoy reserve engineering; for me, this is how I relax in my spare time. I'm really interested in graphics, so I'd like to write my own anywho.

XICO2KX
February 18th, 2013, 01:39
I genuinely enjoy reserve engineering; for me, this is how I relax in my spare time. I'm really interested in graphics, so I'd like to write my own anywho.The honest words revealing the inner motivation behind a great mind! :arabia:
I bet this is going to be the best N64 emulator of all times! :satisfied

MarathonMan
February 18th, 2013, 02:00
Started melding everything into a master binary. Made a couple "plugin" folders, and all is well...


[email protected]:~/Projects/cen64$ ./cen64 data/pifrom.bin data/zelda.rom 10
[PIF]: "Initializing PIF."
[RDRAM]: "Initializing RDRAM."
[XBUS]: "Initializing XBUS."
[RSP]: "Initializing CPU."
[RSP]: "Initializing COP2."
[VR4300]: "Initializing CPU."
[VR4300]: "Initializing COP0."
[VR4300]: "Handling fault: RST"
[VR4300]: "Unimplemented function: LUI."
[VR4300]: "Unimplemented function: MTC0."
[VR4300]: "Unimplemented function: LUI."
[VR4300]: "Unimplemented function: ORI."
[VR4300]: "Unimplemented function: MTC0."
[VR4300]: "Unimplemented function: LUI."
[VR4300]: "Unimplemented function: LW."

I ended up scrapping a large part of the "old" VR4300 core that I had written after all I learned with the RSP core. The VR4300 core should be much faster now (>25%), and is much more elegant to look at as well. As soon as I merge the execution functions from the old VR4300 core into the new one, and rewrite the old VR4300 MemoryFunctions to communicate with the new XBus plugin, things should start fitting together (hopefully).

DETOMINE
February 18th, 2013, 10:56
The VR4300 core should be much faster now (>25%)
Each time I read you, you have made a core 25% faster than the previous one :) . At this rate, I even have the hope that it will run on my computer :D.

Seriously I can't wait to see the first demo.

It's so good to see the N64 emulation scene alive (with your project, the new PJ64 2.0, mupen64plus, and new video plugins...).

MarathonMan
February 18th, 2013, 14:52
Okay, so, I'm not sure who's a developer here, but here's my overall "design approach" after kicking my feet around last night:

It basically boils down to: modularizing everything. And I mean everything. Every possible aspect that is "pluggable" shall be provided by a plugin. Therefore, my initial prototype actually has... 9 plugins (AIF, PIF, SIF, RDRAM, RDP, RSP, VIF, VR4300/MIF, XBUS). The reasoning behind this scheme gets a little technical, but...

(1) Let's suppose the VR4300 wants to tell the RSP that he should start executing. With multithreading, this is fundamentally difficult because if you write the command directly into the RSP's buffers from another thread (in this case, the VR4300's), you could suffer from a race condition and, well, things begin breaking. Thus, instead, everyone writes and reads from a common arbitration layer (XBUS) in the same manner that a real console would. Later on down the road, XBUS will basically be the holy grail to multi-threading support; every single component can run in it's own thread and the commands will get serialized in XBUS. Granted, I'm making this seem much, much, much less complex than the problem actually it, but at least it looks purrty from the outside.

(2) It hides complexity from each plugin, and thus encourages new developers to jump on board. If you're writing a VR4300 plugin, you have enough to worry about. If you need to read from address 0x1FC00000, you don't want to have to place the burden on yourself to look at which device that maps to (PIF ROM). Instead of forcing the burden of redirection on the VR4300 component, the VR4300 simply says "hey, XBUS, read from address 0x1FC00000, will ya?". The XBUS is responsible for talking to the appropriate device, and determining both the data returned/sent via the access, AND the amount of time that the access took (since, say, RDRAM writes/reads are far slower than I/O mapped register writes/reads). Later on, it'll also delay sending the results until they're "really" available in a multi-threaded environment.

There's a slight overhead associated with this flexibility (nothing comes for free), but the complexity (from a developer standpoint) is literally halved. Also, generally, when an external access has to be made, the component that makes the command is going to have to stall regardless... so even with code that generates a lot of off-chip accesses shouldn't suffer from poor performance.

This, of course, will all be hidden from the user as I prefer static library plugins over dynamic ones. :)

EDIT: I also figured out a method to finally fix the overhead of synchronization of multiple cores. I don't want to detail too much yet until I get a working implementation, but basically, cores run in a "detached", unsynchronized mode as long as possible. They only sync under a specific condition that must be met in order to guarantee correctness.

Nintendo Maniac
February 18th, 2013, 18:41
Since each plugin is in it's own module, and there are 9 modules, wouldn't this mean that AMD's "MOAR CORES!" would actually be useful in emulation for once?

squall_leonhart
February 18th, 2013, 19:05
Since each plugin is in it's own module, and there are 9 modules, wouldn't this mean that AMD's "MOAR CORES!" would actually be useful in emulation for once?

no.

Nintendo Maniac
February 18th, 2013, 19:07
no.
Ehh... I'd prefer to hear from MarathonMan before making any concrete conclusion.

And as a reference, I'm only running a 2.5GHz Brisbane.

MarathonMan
February 18th, 2013, 19:09
Since each plugin is in it's own module, and there are 9 modules, wouldn't this mean that AMD's "MOAR CORES!" would actually be useful in emulation for once?

^^ squall's answer ^^

No need to run the things like the controller interface in their own core; you'll just increase contention and deteriorate performance. Some plugins will share a core, while others won't. It'll scale fairly well up for 2-4 cores, though.

Nintendo Maniac
February 18th, 2013, 19:12
4 cores could technically still be viewed as following AMD's "MOAR CORES!" strategy since they're planning on having quad-core parts in Kabini, and not to mention starting with Richland that all non-jaguar-based APUs will be quad-core parts.

MarathonMan
February 18th, 2013, 19:34
4 cores could technically still be viewed as following AMD's "MOAR CORES!" strategy since they're planning on having quad-core parts in Kabini, and not to mention starting with Richland that all non-jaguar-based APUs will be quad-core parts.

Quad cores have been around on both sides for well over half a decade...

Nintendo Maniac
February 18th, 2013, 19:36
And yet Intel seems to only use them in their highest-end parts. Heck they've even made non-low voltage Sandy Bridge i7s that are only dual core (with hyper-threading of course) in the laptop space.

angrylion
February 18th, 2013, 22:16
1) Not cycle accurate; just pixel-accurate.

Right. I have a few RDP test roms on my hard drive that my thingie cannot pass, because they need cycle accuracy. Cycle accuracy of the emulated RDP involves, among other things: correct emulation of RDP cycle counter registers; setting different RDP status bits at the correct cycle; synchronizing the RDP and various RDRAM accesses it makes with the RSP, CPU and VI; emulating the effects of absent Sync commands; emulating some interesting anomalies of the LOD unit, particularly in one-cycle mode; calculating the exact cycle when Load commands with certain parameters start DMAing junk into the TMEM and why do they do it; what the hell do RDP span registers do; correct rendering of primitives with certain, unusual properties (spans look completely different to normal primitives, and then the RDP may or may not crash); calculating the exact cycle when the RDP deadlocks, depending on a particular method to achieve that employed by the display list (there are several such methods I'm aware of). If we talk about real cycle accuracy with respect to the RDP, it is also indispensable that we emulate its internal span buffers and all the IO operations that happen with them. The RDP has several DMA engines, so imo for perfect accuracy it's also important to emulate the arbitration mechanisms that resolve conflicts among them.

MarathonMan
February 19th, 2013, 01:35
Right. I have a few RDP test roms on my hard drive that my thingie cannot pass, because they need cycle accuracy. Cycle accuracy of the emulated RDP involves, among other things: correct emulation of RDP cycle counter registers; setting different RDP status bits at the correct cycle; synchronizing the RDP and various RDRAM accesses it makes with the RSP, CPU and VI; emulating the effects of absent Sync commands; emulating some interesting anomalies of the LOD unit, particularly in one-cycle mode; calculating the exact cycle when Load commands with certain parameters start DMAing junk into the TMEM and why do they do it; what the hell do RDP span registers do; correct rendering of primitives with certain, unusual properties (spans look completely different to normal primitives, and then the RDP may or may not crash); calculating the exact cycle when the RDP deadlocks, depending on a particular method to achieve that employed by the display list (there are several such methods I'm aware of). If we talk about real cycle accuracy with respect to the RDP, it is also indispensable that we emulate its internal span buffers and all the IO operations that happen with them. The RDP has several DMA engines, so imo for perfect accuracy it's also important to emulate the arbitration mechanisms that resolve conflicts among them.

Care to name a couple -- for when I cross that path?

Nintendo Maniac
February 20th, 2013, 23:22
Just thought of something. If we have a cycle-accurate N64 emulator, wouldn't that allow 64DD emulation to be possible?

MarathonMan
February 21st, 2013, 00:44
Just thought of something. If we have a cycle-accurate N64 emulator, wouldn't that allow 64DD emulation to be possible?

Yes and no. 64DD emulation is possible in HLE too, it's just a lack of information that makes it unheard of.

MarathonMan
February 24th, 2013, 04:02
New cores and framework is stable enough to begin loading instructions and data off 6105 carts!


[email protected]:~/Projects/cen64$ ./cen64 data/pifrom.bin data/zelda.rom 8175
[PIF]: "Initializing PIF."
[RDRAM]: "Initializing RDRAM."
[RSP]: "Initializing CPU."
[RSP]: "Initializing COP0."
[RSP]: "Initializing COP2."
[VR4300]: "Initializing CPU."
[VR4300]: "Initializing COP0."
[XBUS]: "Initializing XBUS."
[CEN64]: "Connecting devices to XBus."
[PIF]: "Initializing the cartridge."
[VR4300]: "Handling fault: RST"
[RSP]: "RSPWrite: Unimplemented function."
[XBUS]: "Write WORD to unmapped address [0x04600010]."
[XBUS]: "Write WORD to unmapped address [0x0440000c]."
[XBUS]: "Write WORD to unmapped address [0x04400024]."
[XBUS]: "Write WORD to unmapped address [0x04400010]."
[XBUS]: "Write WORD to unmapped address [0x04500000]."
[XBUS]: "Write WORD to unmapped address [0x04500004]."
[XBUS]: "Read WORD from unmapped address [0x04800018]."
[PIF]: "PIF ROM: Detected write [0x1fc0003c]"
[XBUS]: "Write WORD to unmapped address [0x04600014]."
[XBUS]: "Write WORD to unmapped address [0x04600018]."
[XBUS]: "Write WORD to unmapped address [0x0460001c]."
[XBUS]: "Write WORD to unmapped address [0x04600020]."
[XBUS]: "Write WORD to unmapped address [0x04600014]."
[XBUS]: "Write WORD to unmapped address [0x04600018]."
[XBUS]: "Write WORD to unmapped address [0x0460001c]."
[XBUS]: "Write WORD to unmapped address [0x04600020]."
[XBUS]: "Read WORD from unmapped address [0x0410000c]."
[VR4300]: "Unimplemented function: MULTU."

didado
February 24th, 2013, 22:12
You are going serious fast with this project. Cant wait for the first (demo) screens or video's. :bouncy:

Having coding as a hobby is always better when making a emulator.
Keep it up! :)

MarathonMan
February 25th, 2013, 06:27
Another landmark...


[email protected]:~/Projects/cen64$ ./cen64 data/pifrom.bin data/zelda.rom 8000000
[PIF]: "Initializing PIF."
[ROM]: "Initializing Interface."
[RDRAM]: "Initializing RDRAM."
[RSP]: "Initializing CPU."
[RSP]: "Initializing COP0."
[RSP]: "Initializing COP2."
[VR4300]: "Initializing CPU."
[VR4300]: "Initializing COP0."
[BUS]: "Initializing Bus."
[BUS]: "Connecting devices."
[ROM]: "Preparing the image."
[CEN64]: "Booting the console."
[VR4300]: "Handling fault: RST"
[RSP]: "SPRegRead: Reading from register [SP_STATUS_REG]."
[RSP]: "SPRegWrite: Writing to register [SP_STATUS_REG]."
[RSP]: "SPRegRead: Reading from register [SP_DMA_BUSY_REG]."
[ROM]: "PIRegWrite: Writing to register [PI_STATUS_REG]."
[BUS]: "Write WORD to unmapped address [0x0440000c]."
[BUS]: "Write WORD to unmapped address [0x04400024]."
[BUS]: "Write WORD to unmapped address [0x04400010]."
[BUS]: "Write WORD to unmapped address [0x04500000]."
[BUS]: "Write WORD to unmapped address [0x04500004]."
[RSP]: "SPRegRead: Reading from register [SP_STATUS_REG]."
[PIF]: "SIRegRead: Reading from register [SI_STATUS_REG]."
[ROM]: "PIRegWrite: Writing to register [PI_BSD_DOM1_LAT_REG]."
[ROM]: "PIRegWrite: Writing to register [PI_BSD_DOM1_PWD_REG]."
[ROM]: "PIRegWrite: Writing to register [PI_BSD_DOM1_PGS_REG]."
[ROM]: "PIRegWrite: Writing to register [PI_BSD_DOM1_RLS_REG]."
[ROM]: "PIRegWrite: Writing to register [PI_BSD_DOM1_LAT_REG]."
[ROM]: "PIRegWrite: Writing to register [PI_BSD_DOM1_PWD_REG]."
[ROM]: "PIRegWrite: Writing to register [PI_BSD_DOM1_PGS_REG]."
[ROM]: "PIRegWrite: Writing to register [PI_BSD_DOM1_RLS_REG]."
[BUS]: "Read WORD from unmapped address [0x0410000c]."
[PIF]: "SIRegRead: Reading from register [SI_STATUS_REG]."
[PIF]: "SIRegRead: Reading from register [SI_STATUS_REG]."
[PIF]: "SIRegRead: Reading from register [SI_STATUS_REG]."
[PIF]: "SIRegRead: Reading from register [SI_STATUS_REG]."
[VR4300]: "Unimplemented function: MTC0 [rd = 13]."
[VR4300]: "Unimplemented function: MTC0 [rd = 9]."
[VR4300]: "Unimplemented function: MTC0 [rd = 11]."
[RDRAM]: "RIRegRead: Reading from register [RI_SELECT_REG]."
[RDRAM]: "RIRegWrite: Writing to register [RI_CONFIG_REG]."
[RDRAM]: "RIRegWrite: Writing to register [RI_CURRENT_LOAD_REG]."
[RDRAM]: "RIRegWrite: Writing to register [RI_SELECT_REG]."
[RDRAM]: "RIRegWrite: Writing to register [RI_MODE_REG]."
[RDRAM]: "RIRegWrite: Writing to register [RI_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[BUS]: "Write WORD to unmapped address [0x03f80008]."
[BUS]: "Write WORD to unmapped address [0x03f80014]."
[BUS]: "Write WORD to unmapped address [0x03f80004]."
[VR4300]: "MIRegRead: Reading from register [MI_VERSION_REG]."
[BUS]: "Write WORD to unmapped address [0x03f04004]."
[RDRAM]: "RDRAMRegWrite: Writing to register [RDRAM_MODE_REG]."
[RDRAM]: "RDRAMRegWrite: Writing to register [RDRAM_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[RDRAM]: "RDRAMRegRead: Reading from register [RDRAM_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[RDRAM]: "RDRAMRegRead: Reading from register [RDRAM_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[RDRAM]: "RDRAMRegWrite: Writing to register [RDRAM_MODE_REG]."
[RDRAM]: "RDRAMRegWrite: Writing to register [RDRAM_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[RDRAM]: "RDRAMRegRead: Reading from register [RDRAM_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[RDRAM]: "RDRAMRegRead: Reading from register [RDRAM_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[RDRAM]: "RDRAMRegWrite: Writing to register [RDRAM_MODE_REG]."
[RDRAM]: "RDRAMRegWrite: Writing to register [RDRAM_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[RDRAM]: "RDRAMRegRead: Reading from register [RDRAM_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[RDRAM]: "RDRAMRegRead: Reading from register [RDRAM_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[RDRAM]: "RDRAMRegWrite: Writing to register [RDRAM_MODE_REG]."
[RDRAM]: "RDRAMRegWrite: Writing to register [RDRAM_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[RDRAM]: "RDRAMRegRead: Reading from register [RDRAM_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[RDRAM]: "RDRAMRegRead: Reading from register [RDRAM_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[RDRAM]: "RDRAMRegWrite: Writing to register [RDRAM_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[BUS]: "Write WORD to unmapped address [0x03f8000c]."
[BUS]: "Write WORD to unmapped address [0x03f80004]."
[BUS]: "Write WORD to unmapped address [0x03f04004]."
[RDRAM]: "RDRAMRegWrite: Writing to register [RDRAM_MODE_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[RDRAM]: "RIRegWrite: Writing to register [RI_REFRESH_REG]."
[RDRAM]: "RIRegRead: Reading from register [RI_REFRESH_REG]."
[VR4300]: "Unimplemented function: MTC0 [rd = 28]."
[VR4300]: "Unimplemented function: MTC0 [rd = 29]."
[RSP]: "SPRegWrite: Writing to register [SP_STATUS_REG]."
[RSP]: "SPRegWrite: Writing to register [SP_PC_REG]."
[RSP]: "SPRegWrite: Writing to register [SP_STATUS_REG]."
[ROM]: "PIRegWrite: Writing to register [PI_DRAM_ADDR_REG]."
[ROM]: "PIRegRead: Reading from register [PI_STATUS_REG]."
[ROM]: "PIRegWrite: Writing to register [PI_CART_ADDR_REG]."
[ROM]: "PIRegWrite: Writing to register [PI_WR_LEN_REG]."
[ROM]: "DMA | Request: Read from cart."
[ROM]: "DMA | DEST : [0x00000400]."
[ROM]: "DMA | SOURCE : [0x00001000]."
[ROM]: "DMA | LENGTH : [0x00100000]."
[BUS]: "[HACK] Copying payload to DRAM."
[ROM]: "PIRegRead: Reading from register [PI_STATUS_REG]."
[RSP]: "SPRegWrite: Writing to register [SP_SEMAPHORE_REG]."
[RSP]: "SPRegWrite: Writing to register [SP_STATUS_REG]."
[VR4300]: "MIRegWrite: Writing to register [MI_INTR_MASK_REG]."
[PIF]: "SIRegWrite: Writing to register [SI_STATUS_REG]."
[BUS]: "Write WORD to unmapped address [0x0450000c]."
[VR4300]: "MIRegWrite: Writing to register [MI_INIT_MODE_REG]."
[ROM]: "PIRegWrite: Writing to register [PI_STATUS_REG]."
[VR4300]: "Passed PIF/CIC security checks!"

VR4300 core is stable enough to pass the CIC/PIF checks again. Just a little more support in the core and it'll be at the magical game entry point.

EDIT: That was easier than I expected. The core crashes into a breakpoint at 0x80000400... so I can succesfully boot commercial CIC-6105 ROMs. Cool beans.

squall_leonhart
February 25th, 2013, 07:08
Yes and no. 64DD emulation is possible in HLE too, it's just a lack of information that makes it unheard of.

some 64DD titles already work in Pj64

DaFox
February 25th, 2013, 09:24
Damn nice!

MarathonMan
February 26th, 2013, 06:14
Dynamically determining the lockout chip and setting the seed accordingly...


[BUS]: "== Hardware Initialized =="
[BUS]: "Connecting devices."
[ROM]: "No hugepage support."
[ROM]: "Preparing the image."
[ROM]: "Loaded: [ZELDA MAJORA'S MASK ]"
[ROM]: "Detected: CIC-NUS-6105."
[CEN64]: "== Booting the Console =="

Also fixed a really annoying bug that cropped up yesterday and prevented aggressive optimizations.

And, of course, being a Linux freak... support for mmap'd ROMs with hugepages. Linux users should only see ~10MB of memory used, even with a ROM loaded:

[RSP]: "SPRegRead: Reading from register [SP_STATUS_REG]."
==6494==
==6494== HEAP SUMMARY:
==6494== in use at exit: 0 bytes in 0 blocks
==6494== total heap usage: 11 allocs, 11 frees, 8,404,112 bytes allocated
==6494==
==6494== All heap blocks were freed -- no leaks are possible
==6494==
==6494== For counts of detected and suppressed errors, rerun with: -v
==6494== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

chiburunga
February 26th, 2013, 11:08
Dynamically determining the lockout chip and setting the seed accordingly...


[BUS]: "== Hardware Initialized =="
[BUS]: "Connecting devices."
[ROM]: "No hugepage support."
[ROM]: "Preparing the image."
[ROM]: "Loaded: [ZELDA MAJORA'S MASK ]"
[ROM]: "Detected: CIC-NUS-6105."
[CEN64]: "== Booting the Console =="

Also fixed a really annoying bug that cropped up yesterday and prevented aggressive optimizations.

And, of course, being a Linux freak... support for mmap'd ROMs with hugepages. Linux users should only see ~10MB of memory used, even with a ROM loaded:

[RSP]: "SPRegRead: Reading from register [SP_STATUS_REG]."
==6494==
==6494== HEAP SUMMARY:
==6494== in use at exit: 0 bytes in 0 blocks
==6494== total heap usage: 11 allocs, 11 frees, 8,404,112 bytes allocated
==6494==
==6494== All heap blocks were freed -- no leaks are possible
==6494==
==6494== For counts of detected and suppressed errors, rerun with: -v
==6494== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)


You are the man!!!! I want you to be the father of my sons! And Im a guy!

squall_leonhart
February 26th, 2013, 11:34
so you want him to diddle your wife?

Zuzma
February 26th, 2013, 15:14
It sounds like there'd just be two dads unless someone else wanted some sandwich action or something. :D

Edit: Nice job with getting games booting MarathonMan! Haha, I shouldn't go off topic like this.. ugh.

mrmudlord
February 27th, 2013, 01:54
http://i.imgur.com/sdz2CAY.jpg
http://i.imgur.com/x9STeDN.jpg

MarathonMan
February 27th, 2013, 02:16
http://25.media.tumblr.com/tumblr_m0cdbrqqfb1rqfhi2o1_500.gif

didado
February 27th, 2013, 08:38
Nice pictures kidmudlord.. Self made emu? ;) Why you wanna always hate that much? or troll.. or is this humor you like.
I know you can code to. But i never see the reason of actions like these you made.

MarathonMan please ignore the haters. :)

Zuzma
February 27th, 2013, 10:13
Incredible work mudlord !

didado: he's just screwing around so no harm

MarathonMan
March 2nd, 2013, 01:51
Don't know how many of you followed my previous implementations, but: optimized my TLB module and linked it into the core tonight.

I take a completely different approach to TLB implementation than other emulators, so it'll be interesting to see how it plays out. I know for a fact that my lookups are considerably faster than any other emulator to date (as I filter out the entries using a tree and only have to look at a fraction of them to determine whether I have a hit or not), but my replacement logic is a bit more complex and certainly not as fast. It'll be interesting to see how games like Goldeneye are impacted by these changes.

Rodimus Primal
March 2nd, 2013, 16:40
I have a question about games and file extensions. I ask because some consoles are a mess with the various types of dumps (I'm looking at YOU, Sega Genesis!) but it would seem N64 is for the most part one type of file. Will your emulator be compatible with more then one type of file or will you go the byuu route and add a converter program?

Nintendo Maniac
March 2nd, 2013, 18:43
but it would seem N64 is for the most part one type of file

Not true, but it's on a pretty small scale. All I've ever seen are .Z64 .V64 and .N64

MarathonMan
March 2nd, 2013, 20:26
I have a question about games and file extensions. I ask because some consoles are a mess with the various types of dumps (I'm looking at YOU, Sega Genesis!) but it would seem N64 is for the most part one type of file. Will your emulator be compatible with more then one type of file or will you go the byuu route and add a converter program?

As of right now, I only support ROMs in little-endian (i.e., original, non-byteswapped) format. I don't see that changing, so I'll probably go the byuu route.

EDIT: s/little/big

ShadowFX
March 2nd, 2013, 20:42
Some interesting info I found on this: http://jul.rustedlogic.net/thread.php?id=11769
So does that mean you're probably going to use .n64 ? Seems only fitting... :)

MarathonMan
March 2nd, 2013, 21:32
Some interesting info I found on this: http://jul.rustedlogic.net/thread.php?id=11769
So does that mean you're probably going to use .n64 ? Seems only fitting... :)

z64 is big-endian, so that's what I'll support. Creating tools to convert to the other formats is a trivial process.

ShadowFX
March 2nd, 2013, 22:59
Your last post made it a bit confusing considering what you wrote two posts ago. Though trivial, I'll just see what's supported and go with that.

Fanatic 64
March 3rd, 2013, 01:18
You can just download a program to byteswap the ROM.

MarathonMan
March 3rd, 2013, 01:40
Your last post made it a bit confusing considering what you wrote two posts ago. Though trivial, I'll just see what's supported and go with that.

Whoops, sorry... misspoke. I try to recreate the console as best as possible, so _BIG_ endian (z64) format.

Started cycling the RSP core during the boot process. Have an unimplemented instruction (VADDC) that's preventing me from going any further, but code is being DMA'd from the cart to RSP DMEM/IMEM (and being executed), so I'm thrilled right now.

Been thinking about doing a pixel-accurate renderer until I get the rest of the console stabilized... undecided on it.

squall_leonhart
March 3rd, 2013, 04:30
settle for polygon accurate.

mrmudlord
March 3rd, 2013, 05:07
nope, thats not enough.
settle for per-cycle.

**** any speed cost, because according to byuu, none of that matters. Only when you are able to run your emu by 2050 is what matters.

MarathonMan can continue doing it the right way, and I can continue my RDP **** via the Max Power(tm) way! Everyone wins!

squall_leonhart
March 3rd, 2013, 05:23
lets stop giving a crap what byuu is doing then.

Guru64
March 3rd, 2013, 10:22
lets stop giving a crap what byuu is doing then.

And yet, you two are the only ones who keep mentioning him. It's scary to see how obsessed you two are with byuu.

Mantorok
March 3rd, 2013, 11:39
Each of them could probably have written their own SNES emulators in the amount of time they've spent *****ing about byuu across various message boards.

MarathonMan
March 3rd, 2013, 15:47
settle for polygon accurate.

Actually been thinking about this as there seems to be more of a following for high-res renderers.

Zuzma
March 3rd, 2013, 16:32
Even if you don't have a totally accurate one now you could always do it later as a selectable render output. Yabause (sega saturn) started out with an opengl renderer before they had a software based one. It doesn't rely on plugins either which is nice and the compatibility lately for it has been much better.

MarathonMan
March 3rd, 2013, 20:53
Okay, RSP is somewhat connected and VADDC is implemented.

Next requirement for boot appears to be properly handling interrupts. I'm faking everything on a grand scale at the moment. Interestingly enough, it seems that some/most emulators do not properly support interrupt handling in the same way the hardware does.

ShadowFX
March 3rd, 2013, 23:10
Actually been thinking about this as there seems to be more of a following for high-res renderers.
I would say this is because there hardly was any viable alternative back then. Even now, N64 software renderers are scarce so it would be a welcome addition if you'd include it by default (also for accuracy's sake).

Remote
March 4th, 2013, 00:01
Perhaps you could implement the plugin spec for graphics (and use an existing plugin at the moment) and as you get more and more things done? You remove it?

mrmudlord
March 4th, 2013, 00:18
Each of them could probably have written their own SNES emulators in the amount of time they've spent *****ing about byuu across various message boards.

Keep your abnormally large nose out of people's business please. You haven't done anything emulation related so how can YOU talk?


Even now, N64 software renderers are scarce so it would be a welcome addition if you'd include it by default (also for accuracy's sake).

Nice to see you byuu acolytes never change.

straightflushin
March 4th, 2013, 02:21
Keep your abnormally large nose out of people's business please.

That's the most hypocritical statement I've seen.

mrmudlord
March 4th, 2013, 02:23
it is my business when one of the people involved destroyed my life.

MarathonMan
March 4th, 2013, 02:55
Perhaps you could implement the plugin spec for graphics (and use an existing plugin at the moment) and as you get more and more things done? You remove it?

That's certainly an idea. Though I'm a little bit concerned about how "different" the interface is with my simulator -- it could turn out to be quite the wrapper and make a mess of things.

mrmudlord
March 4th, 2013, 03:06
With all due respect, thats something that sounds reasonable. Have completely *optional* plugin support for video plugins only.

That way, CA people get what they want, the rest get what they want too.

MarathonMan
March 4th, 2013, 03:37
With all due respect, thats something that sounds reasonable. Have completely *optional* plugin support for video plugins only.

That way, CA people get what they want, the rest get what they want too.

I always said that I was going to support RDP plugins. They'll just be static plugins instead of dynamic plugins to prevent dll and so files from flying all over the place.

Azimer
March 4th, 2013, 04:46
I don't want to single anyone out but can we please stay on topic with MM's project. If the post has nothing to do with MM's developments, perhaps it belong in another forum post instead of here. I'd hate to see people get the ban hammer for being passionate about emulation.

I don't believe there is anything necessarily wrong with plugins. It allows other people to contribute in different ways. However, the problem with the PJ64 spec is that it never updated to fix anything. I had so many problems with audio because I didn't have enough information to emulate the registers accurately. The register emulation belonged in the core, not the plugin.

squall_leonhart
March 4th, 2013, 05:27
That's the most hypocritical statement I've seen.

you don't watch the news enough.


Actually been thinking about this as there seems to be more of a following for high-res renderers.

:D
Its a waste of the consoles graphical feature set to limit it to whatever output res the game utilised.

Remote
March 4th, 2013, 12:35
Agreed, stop rambling about random stuff that doesn't add to this thread. Imagine if Shakespeare had a Mudlord :P


If the plugin specs are static perhaps you could use/interface your core with 1964js?

squall_leonhart
March 4th, 2013, 13:23
Agreed, stop rambling about random stuff that doesn't add to this thread. Imagine if Shakespeare had a Mudlord http://www.emutalk.net/images/smilies/tongue.gif


He does,

see: Hamlet, and The Tempest.


If the plugin specs are static perhaps you could use/interface your core with 1964js?

why would he want to introduce inferiority into his code?. JS engines still operate as restricted virtual machines (and no, im not confusing them with JavaVM) and are not truly dynamic. the current JS Recompilers are static and utilise prediction and predefined jump tables to 'guess' the best possible result.

ugh, not to mention the relative memory requirement ballooning for execution during heap collection.

Looking back in the thread, optimised (and minimal) memory use is one of the goals Marathonman has achieved so far.

Btw, thanks for the warning Remote, i'll treasure it. ;D

Remote
March 4th, 2013, 14:41
Who knows, perhaps he doesn't want to use js in his code, and more importanly, neither of us gets to decide if he does. :P

MarathonMan
March 4th, 2013, 14:44
If the plugin specs are static perhaps you could use/interface your core with 1964js?

Having performance issues as it is; wouldn't touch it with a 30 foot pole.