Hype, Maybe Fake.

[Ghanji]

There's no way a port of any N64 emulator would run this well. [...]
I've never actually heard of Devil64 - google reveals nothing but this thread.

Just because you haven´t heard about it doesn´t mean anything... obviously...
Maybe there has been some work beyond your horizon...?
I just don´t get why you are so offending...

 

[CrazyRetro]

Hey .

It s ok, please stop to fight about Fake or not Fake.

Just, i made my own in Silent, and if i release, you hear of it. That s all. I dont have to talk about fake or not fake, it was my foult, to release such a early movie, wos just to show - it can be, and not to talk about fake or no fake.

I have befoure postet a other Thread (other Communety) and ask for Help to GL. That s all.
After, an other Member have Renamed the Thread to N64 - so was no problem anymore, also to show some Screens,
and the Video was made for the Issues i have, not to talk about fake or no fake. That s all. But, no one look to the Problems, all look only "wow it runs great" , and no, it dont runs great, there more problems then fun, alone the system "hold" by pressing buttons, or the calculating of screens, is so slow, that ingame here or there is only a dia show, or a complete hold. For some dialoges, need to push 5 or 10 x an button, to cut them and other things.

But, help are rare, Comments are many, and Fake or not fake, how cares ? The Thing is i make my own, and will do this in background, so nobody hurts, becourse, i dont want anybody hurt. I just was happy, that the thing run, that s all. To post this video, was a mistake that i never do again for all, only for a small intern Circel of Peaple, they
nearlier to this projekt.

So, dont worry, no problem with this tread but, a good reference i have become here, thank you.

CR

 

[CrazyRetro]

ah, on thing again :

"never heard of it".

Her s the Story, so good i can write in english.

The Point was the Ultra HLE Emulator - a System to play a N64 on a P200 ( or Celeron 200) That s the Basic of Devil to. So Ultra HLE was written - not by us , and we writing Devil64. This on Linux Suse, in fvwm2 and under the Language of Python first.

After ULTRA HLE was running, our emulator just was a Joke at this time. So is made for ATI cards, and later a little Support for Nvidia. This is made up to running "ok" and in higher Resolution than Ultra HLE (best was 1280x124 by 1 - 5 Frames , ok , not playable, but running). ultra HLE was cancelt, (dont know the words) - nintendo have say - stop it (dont know how to write this better lol) - so we also have sayd, ok, it s to riski to bring the emu up, we dont
want to have truble.

After this, devil only was closed, for long time. And Projekt 64 was released, so no need to build an other emu.

So devil is only running by 4 or 5 Peaple, and not promotet to the internet. Without nintendos fight again emus, i think we have devil made for download, but at this time, we dont have fun to become Post from Nintendo.

That s all, so i understand :
never heard of it
is never exist , or ?

No problem, it s like i say, there was never the point, to hurt any one, or to talk about fake or not fake.
It was just my lucky thinking about the running, to make such a video, not to talk about fakes.

CR

 

[notaz]

ok since you are showing it, perhaps you can tell us some details then?

What HLE approach are you using?
How are you rendering graphics, are you using your own code, or some existing plugin from other emu?
How are you handling CPU emulation?
How many MIPS does Zelda need to run reasonable?

 

[CrazyRetro]

hm

first you need to know :

Ultra HLE or sonthing, is not Devil - it s only a Brother, like Brother is the wrong word, a parallel Production.
I think you mean with "HLE" that it s based on this - that means - no

Clearly :
Devil is emulating an own Operating system, that includes 3 Forms of CPU 2 Grafik CPU , a Managing for Plugins (firstly the Grafik Plugin ) and an Rom Management, that emulates the complet Rom Bus to transfere Datas (indeed :
a Rom is made to an Install, and the Installet file contents the Rom himself, also dumped files and a swap file,
dumpad as a rom.temp in the roms Section of the Emulator)

Basicly is emulatet a VR4300 you can also change a R4300i processor line but this is alpha and works weak.
The basic set of N64 is the most of 32 bit, not 64 bit, the 64 Bit command lines, mostly skippet or rom patchet
so we like to use an own emulator for the 6300, and run mostly games on this. This is taktet ?? ( i dont know the word) on a cpu clock of 100 mhz, this is not the real speed of that thing, but it was best work. The speed of the interpreter is so fast as possible, and will not crash on slower systems (indeed, simply : if you run it, and you have a pentium 133 -you need many time to load up a rom and run it, so you have a image gallery of 1 frame every minute, but it works)

The good things are :
the System is based on celeron without mmx, or on k2 prozessors of amd (nothing newer Prozessors now) this is
ground based, so it s good to build change for arm - but you cant compere it with better or moderner emulators
like the Projekt64 (wanna see the Source *g* never seen)

Grafic is emulatet by plugins. We wrot on hand a open source projekt for the ati rage pro http://82.114.193.227/vga/image/sbirky/palcal/ati/rage2cpci.jpg and have later take of some of the functiones, so make it compatible to the nvidia Cards (first we have the same issues like today on witz on Nvidia) a 3DFX import never was really made, but it runs also on a 3DFX Scanline Interface System - but have many issues there, and crashs more than fast.

The Sound early never was clocked, we only take an second stand alone plugin, but not to change, only for soundblaster16 (works never again on my newer soundblaster live, and dont work today on my XFi - so only the true hardware of SB16 and the SB 16 Libs as open source projekts to linux suse 7.0 taken for the pugins to make. They are just includet in a second line of the Sound system, global in N64 under the co processor. Here on wiz, no sound works, i dont know if it s possible to build in sound but i think is a no go, becourse the main system 43 iss always set to 800 mhz and i do not believe that a sound plugin will work, i think it slows down.


Control is at this time implemented, and no change in emu can be mad. I dont know if this as a plugin work, i think this will also slow down to much. The basic system have on this so his own os, like a N64, and just runs stand alone. the lib of ati card i choos at this time, is global and have no parameters or luxury at this time, first run was a crash, i dont know what have made this, how i say - i must ask my frind for, he knows,i dont know, but i testing like i have time with the open gl port.

the most of the includet software is status 2000 and ist just a bad running package, there is like i say, hard work to do.

Zelda64 uses firstly the VR4300 , it s a 32 Bit system (like mario or sonthing ) but takes here or there the 4300i parameters you can cut or patch.

I hope you understand my poor english.

CR

 

[Exophase]

hm

first you need to know :

Ultra HLE or sonthing, is not Devil - it s only a Brother, like Brother is the wrong word, a parallel Production.
I think you mean with "HLE" that it s based on this - that means - no

Almost every N64 emulator uses HLE, high level emulation, and the available emulators not using HLE are much more demanding. If you are the author of an N64 emulator you should be able to describe what parts are being implemented with HLE instead of LLE.

Clearly :
Devil is emulating an own Operating system, that includes 3 Forms of CPU 2 Grafik CPU , a Managing for Plugins (firstly the Grafik Plugin ) and an Rom Management, that emulates the complet Rom Bus to transfere Datas (indeed :
a Rom is made to an Install, and the Installet file contents the Rom himself, also dumped files and a swap file,
dumpad as a rom.temp in the roms Section of the Emulator)

I don't understand what you're saying here.

Basicly is emulatet a VR4300 you can also change a R4300i processor line but this is alpha and works weak.
The basic set of N64 is the most of 32 bit, not 64 bit, the 64 Bit command lines, mostly skippet or rom patchet
so we like to use an own emulator for the 6300, and run mostly games on this. This is taktet ?? ( i dont know the word) on a cpu clock of 100 mhz, this is not the real speed of that thing, but it was best work. The speed of the interpreter is so fast as possible, and will not crash on slower systems (indeed, simply : if you run it, and you have a pentium 133 -you need many time to load up a rom and run it, so you have a image gallery of 1 frame every minute, but it works)

A version of VR4300 is what N64 uses. It's an implementation of R4300i which was licensed from MTI. Your statement of offering options to emulate both makes no sense. An N64 emulator developer would also probably know its CPU is 93.75MHz and wouldn't call it at 100MHz.

notaz was really just asking to describe the recompiler you're using. It's clear you don't claim to be using a recompiler. Achieving the performance in Zelda: OoT's title sequence the video demonstrated with an interpreter is very unlikely, especially the software rendering that you imply you're using. Why would a recompiler crash on a slower CPU?

The good things are :
the System is based on celeron without mmx, or on k2 prozessors of amd (nothing newer Prozessors now) this is
ground based, so it s good to build change for arm - but you cant compere it with better or moderner emulators
like the Projekt64 (wanna see the Source *g* never seen)

So what changes did you do for ARM, or are you just saying you did a build for ARM?

Grafic is emulatet by plugins. We wrot on hand a open source projekt for the ati rage pro http://82.114.193.22...i/rage2cpci.jpg and have later take of some of the functiones, so make it compatible to the nvidia Cards (first we have the same issues like today on witz on Nvidia) a 3DFX import never was really made, but it runs also on a 3DFX Scanline Interface System - but have many issues there, and crashs more than fast.

What is it you could have done to make it ATi specific? I don't recall ATi having a unique video API in 1999/2000. Obviously anything like this wouldn't translate to Wiz. It's clear from your comments that you're not using OGL but want to, so you must be software rendering on Wiz.

The Sound early never was clocked, we only take an second stand alone plugin, but not to change, only for soundblaster16 (works never again on my newer soundblaster live, and dont work today on my XFi - so only the true hardware of SB16 and the SB 16 Libs as open source projekts to linux suse 7.0 taken for the pugins to make. They are just includet in a second line of the Sound system, global in N64 under the co processor. Here on wiz, no sound works, i dont know if it s possible to build in sound but i think is a no go, becourse the main system 43 iss always set to 800 mhz and i do not believe that a sound plugin will work, i think it slows down.

Again, unless you were emulating in DOS or something I don't think the soundcard type would play much of a role.

 

[ari64]

How many MIPS does Zelda need to run reasonable?

The intro scene with the views of hyrule field needs about 250M cpu cycles per second to emulate the r4300i on a OMAP3530, plus however much CPU time is needed for graphics rendering. Some other parts of the game have higher CPU requirements, up to 300-400 million cycles/sec.

Obviously the Wiz CPU is slower, but you might get it to run ok if you overclock enough. Really it's going to depend on what the 3D accelerator is capable of.

It should be possible to compile mupen64plus on the Wiz if someone wants to benchmark the dynarec. Make sure you remove -mcpu=cortex-a8 and #define ARMV5_ONLY. You won't be able to actually play anything without writing a OpenGL ES 1.1 renderer though. Also the Wiz has only 64MB RAM, so you might want to try a smaller game than Zelda.

 

[CrazyRetro]

@ exo -. are 2 cpus possible, 4300 is first choice, so 2 includet, and 4300i is not run perfect (you can choose, if i can write german, i can better say what i mean)

ATI have open gl and d3d.

@Ari64 - mupen? on wiz ?
any one try to test this ? or, better : any one have ever made a benchmark with ?

 

[CrazyRetro]

@exo i forget :

i make you an offer (hope this is right)
letz me just correct the menu, and take a look at the gl at this time -

so, a little help is also ok, if any one have a good open gl plugin for wiz, i will test, becourse, more help is
faster ready.

this is no problem , i ever open for help.

ah ( should i say )
C++
or Python.


CR

 

[ari64]

@ari64 - mupen? on wiz ?
any one try to test this ? or, better : any one have ever made a benchmark with ?

As far as I know, no one has tried it. I was suggesting that someone try it.

 

[Exophase]

The intro scene with the views of hyrule field needs about 250M cpu cycles per second to emulate the r4300i on a OMAP3530, plus however much CPU time is needed for graphics rendering. Some other parts of the game have higher CPU requirements, up to 300-400 million cycles/sec.

Obviously the Wiz CPU is slower, but you might get it to run ok if you overclock enough. Really it's going to depend on what the 3D accelerator is capable of.

It should be possible to compile mupen64plus on the Wiz if someone wants to benchmark the dynarec. Make sure you remove -mcpu=cortex-a8 and #define ARMV5_ONLY. You won't be able to actually play anything without writing a OpenGL ES 1.1 renderer though. Also the Wiz has only 64MB RAM, so you might want to try a smaller game than Zelda.

I think notaz meant how many MIPS on the N64, not how many mupen64plus needs. I realize there's some correlation, but MIPS on the N64 isolates the CPU demand for emulation; if it's some menu screen that's using only 1% CPU time (or say, the spinning logo part of Zelda's opening) then an interpreter won't hurt you. But for the numbers you're looking at for the horse riding opening you probably really need a recompiler to get anywhere and he's already made it pretty clear he isn't using a recompiler but a "fast interpreter."

How many MIPS are used on Wiz should be obvious, "all of them."

Since you're on this thread, would you care to give your opinion regarding CrazyRetro's claims? He took the video down now but it looked perfectly smooth and with correct, albeit very blurry graphics. In the thread he's claimed the graphics are "bad" and the real framerate is something like 13 with frameskip of 9 (definitely not evident in the video, this would make the real displayed rate something like 1FPS)... with an interpreter on Wiz none of this should be possible. The ROM size is another good point; Wiz won't provide 32MB of contiguous memory so you at least have to work around that somehow. Linux can memmap the file in dynamically though.

mupen64plus performance is probably going to be much worse on Wiz than Pandora too... if it's as memory bandwidth dependent as you say. Wiz doesn't have L2 cache and its main RAM isn't that fast or wide either.

 

[ari64]

I think notaz meant how many MIPS on the N64, not how many mupen64plus needs. I realize there's some correlation, but MIPS on the N64 isolates the CPU demand for emulation; if it's some menu screen that's using only 1% CPU time (or say, the spinning logo part of Zelda's opening) then an interpreter won't hurt you. But for the numbers you're looking at for the horse riding opening you probably really need a recompiler to get anywhere and he's already made it pretty clear he isn't using a recompiler but a "fast interpreter."

With no L2 cache, it's going to be largely bound by memory latency. Interpreter will be slower, but maybe not by a huge factor.

I haven't counted the number of CPU cycles in the idle loop, but I know that that sequence doesn't max the CPU. The only really high-cpu part shown was where Zelda rides the horse out of the castle.

Since you're on this thread, would you care to give your opinion regarding CrazyRetro's claims? He took the video down now but it looked perfectly smooth and with correct, albeit very blurry graphics. In the thread he's claimed the graphics are "bad" and the real framerate is something like 13 with frameskip of 9 (definitely not evident in the video, this would make the real displayed rate something like 1FPS)... with an interpreter on Wiz none of this should be possible. The ROM size is another good point; Wiz won't provide 32MB of contiguous memory so you at least have to work around that somehow. Linux can memmap the file in dynamically though.

The text seemed to be rendered incorrectly. No idea what he was running.

 

[Exophase]

With no L2 cache, it's going to be largely bound by memory latency. Interpreter will be slower, but maybe not by a huge factor.

In-order CPU performance is never "bounded" by memory latency, that statement has always been a pet peeve of mine ;p Cache miss cost is an additive effect, you end up slower but it doesn't overlap an awful lot. There will be plenty of cycles where the CPU still won't have anything to put on the bus, even with critical word first loading. The only way you can max out memory bandwidth on Wiz is by writing a constant stream of data somewhere in a loop, due to the efficiency of the writeback buffer. But you couldn't be performing loads or doing much else in the way of useful work.

An interpreter will have to add at least a dozen cycles per most instructions on ARM9, it's just unavoidable.

Lack of OGL is really the biggest red flag as a performance indicator. If it was written to the metal against Wiz's accelerator he shouldn't even want to do OGL. If it's in software there's no way it could perform like the video did.

How was the text rendered incorrectly?

 

[hardyx]

A binary will be released, but first the playing of game must be ok, i dont want any pandorra port befoure wiz.

Explain to me how to port a binary Wiz emulator to Pandora, please.

the hardware need for N64 is lower you think, and the Wiz - can display, you will see in future.

if you run it, and you have a pentium 133... so you have a image gallery of 1 frame every minute, but it works

How can the Wiz show the Zelda game smooth at 20-25 fps and a Pentium (that is more powerful cpu and graphic card) execute at 1 frame per minute?

 

[ari64]

In-order CPU performance is never "bounded" by memory latency, that statement has always been a pet peeve of mine ;p Cache miss cost is an additive effect, you end up slower but it doesn't overlap an awful lot. There will be plenty of cycles where the CPU still won't have anything to put on the bus, even with critical word first loading. The only way you can max out memory bandwidth on Wiz is by writing a constant stream of data somewhere in a loop, due to the efficiency of the writeback buffer. But you couldn't be performing loads or doing much else in the way of useful work.

The cache misses are unavoidable and take a certain amount of time. This is a lower bound on the amount of time the program takes to execute. It can't be made any faster without increasing the speed of the memory.

An interpreter will have to add at least a dozen cycles per most instructions on ARM9, it's just unavoidable.

I put a counter in the idle loop detection to see how many non-idle instructions were executed. Results from running OoT:

Nintendo 64 logo: 2.5 million instructions per second
Galloping horse: 10 million instructions per second
File select menu: 6 million instructions per second
Zelda fleeing castle: 16 million instructions per second

Note that Mupen64plus is designed to execute a maximum of approximately 19 million instructions per second.

If the interpreter takes a dozen cycles per instruction, then 10 million emulated instructions = 120 million cycles on ARM9.

How was the text rendered incorrectly?

A lot of the text was missing, including the story "In the vast, deep forest of Hyrule..." I didn't recognize the rendering errors as being characteristic of any particular emulator.

 

[Exophase]

The cache misses are unavoidable and take a certain amount of time. This is a lower bound on the amount of time the program takes to execute. It can't be made any faster without increasing the speed of the memory.

What I'm saying is that your performance will be closer to cycles(cache_misses) + cycles(instructions) than max(cycles(cache_misses), cycles(instructions)). "Bounding" doesn't usually imply "lower bound" but "upper bound" (ie, "limiting").

I put a counter in the idle loop detection to see how many non-idle instructions were executed. Results from running OoT:

Nintendo 64 logo: 2.5 million instructions per second
Galloping horse: 10 million instructions per second
File select menu: 6 million instructions per second
Zelda fleeing castle: 16 million instructions per second

Note that Mupen64plus is designed to execute a maximum of approximately 19 million instructions per second.

If the interpreter takes a dozen cycles per instruction, then 10 million emulated instructions = 120 million cycles on ARM9.

Thank you for the breakdown. What I was saying is that the interpreter is at least a dozen cycles slower, but that was being pretty conservative. It would be interesting to know how many of these are floating point operations.

A lot of the text was missing, including the story "In the vast, deep forest of Hyrule..." I didn't recognize the rendering errors as being characteristic of any particular emulator.

Eh? Maybe I didn't run it long enough (too late to check now), but I thought it only went up to the title. Maybe I stopped it there.

 

[neko]

He took the video down now

http://tinyogg.com/watch/loAuP/

 

[CrazyRetro]

Right, it s like i say - i dont want to talk about Fake or not Fake, important is the "how to do" and "how to get it run best as possible", not the Question is fake or not fake.

So i have sayd - i will not post open files, only a binary than is ready. On the 5.6. we are sitting together on the basics and the Graphik, and will see what we can get better to run than today. After this, i report.

Help is ever welcome, but at this moment (since yesterday) we are thinking about a closed System.

CR

 

[fishybawb]

That video's far too blurry to see anything other than that the framerate appears to be a lot better than the author claims, which is a novel approach...

I propose a "binary or STFU" rule for emulator announcements like this

 

[CrazyRetro]

i dont understand the talk about the frame rate.

it s only 8 up to 13 frames, best frames are display of link himself by 22 fps. All other have nothing over 13 Frames. So you dont forget : N6 have a max frame of 25 here, so it means, 13 Frame is half of full speed. You may not get frame rates of 40 and more, on wiz no go, and all over 25 make be nice, but is not needet for n64. So you mey see : 13 Frames is half of full speed, the visual effekt is to think it s some great frame rate, but really it s not a great speed, only 13 frames. But 13 Frames are first ok for the wiz is great. There is the problem ? You dont need more than 25 frames to play with the full rate. The Wiz will not display 25 frames, its not importand, but 13 are ok, but i wish i have ever 13, dont have it, here or there only are 1 - 3 this is not playable. Dont take the visual effekt for "perfekt" or "running perfekt" or sonthing !!! I dont understand the Problem to talk about frames, the Basic should run, the frames are this, what you get than basic are ready.

I have like i say, more Help wished to find here, not so many diskussiones about unready alphas, and critics are on the way everythere her - but not really one that say "Hey, how we can fix it".

This means, this will be a closed projekt, only to waist no time on diskussions like this, how is this made or how you want to do this, or "this is XX frames and this only X frames" - that all ist bullshit, the system should be run, and not to diskuss about.

If i have know, that the video is made such comments, i never post it, that s the point to delete it. Further videos are only private, and not wordwide, and a Binary - take it by your own to the time i release it - all other talk is bullshit, and i dont like to diskuss about a System, that follow his own rules, and made as a stand alone.

There is no need to talk about frames.
and no need to talk about fake or not, in futur i give no infos out, before not a release here - and this i report.
I dont like to talk about "this or this or how do this or this is possible this not" - the ground Rule is :
All is possible, the Ask is how, the point is why and the Thing is - do it and test it, befoure is all oter only Bullshit. If it s not run - you see, if it s run, all mean it s fake, and if it s run and be ready, all will say great. My foult is to say : it runs - and to say, it s no release for today, please give me some time.

All other is bullshit, and time no on will give
help also no one will do
that s also the point, to discuss for ?
No one here - no point there, there is nothing to say, and my time is money, i do not only live for foren and wiz - i like it, but its not my doom or other : i have other things to do, than to talk about fakes, or to build fakes.

The Video and the blurry in this, i have explain for more than 1 thread, and this is enugh.

Just i say : Help is ever welcome, comments about fake and no fake, or sonthing about "this is made this not" are without any sence. So - how ever will help - write me, and can get more Infos about the Projekt, and also the codes, so he think he have any to build, to help for the release.

All others - please let us some time. Thx.

CR