Slashdot Mirror
UltraHLE Source code
Well, it seems a person nicked GossiTheDog has released the sources
of UltraHLE (a good Nintendo 64 emulator). It's written in C++. This
person has released the source to see a Linux port and to see this
emulator still "alive". Anyone or any group to port it to Linux with
SVGA/DGA/GGI support?. You can also find instuctions
of how to run UltraHLE under Wine. Enjoy.
naturally
WHOA!!!!
Gentlemen....fire up your vims and lets start
the coding....
and it's really a conversion of .exe--> .c NOT the original source code. Hell, in the readme.txt it even says that it won't compile out of the box. Still good for some ideas... if you want to browse through what must be 200+ pages of assembly, though... good luck to all attempting.
So how do I get the ROMS off my current cartridges?
Let's get this sucker ported to Linux. Get it all fixed up, decked out and working tight as crazy then get it ported back to Windows.
I think if we perfect it in Linux first, then go back to do the Winblows junk, then it could be one great app.
But we have to start with Linux first.
As it is, the IDSA is going to be attacking everything in sight now, since the damn thing was released in the first place. I wish they'd have just let it die, but then someone goes and releases this. Great. Friggin' great.
I suggest we just leave it be.
Eric Kolb, a.k.a. Dygel
It's just in the beginning stages of reverse-engineering. Calling it C++ is like calling obfuscated C easy to understand.
The mips emulator, i/o, etc is all done; There are only a few things left to do:
1. Finish the COP0 paging support
2. Fix the last half-dozen or so RCP instructions.
3. Perform the memory initialization that the N64 boot code does.
I really don't think that TrueReality is that far from working once these few things are completed.
Let's get this working instead.
The mips emulator, i/o, etc is all done; There are only a few things left to do:
1. Finish the COP0 paging support
2. Fix the last half-dozen or so RCP instructions.
3. Perform the memory initialization that the N64 boot code does.
I really don't think that TrueReality is that far from working once these few things are completed.
Let's get this working instead.
The mips emulator, i/o, etc is all done; There are only a few things left to do:
1. Finish the COP0 paging support
2. Fix the last half-dozen or so RCP instructions.
3. Perform the memory initialization that the N64 boot code does.
I really don't think that TrueReality is that far from working once these few things are completed.
There are links on www.dextrose.com to where to buy rom dumpers. You can also look at www.cd64.com.
Or you could just go grab them off alt.binaries.emulators.nintendo-64, but nyah.. that would be illegal...
Put the freaking comment code back the way it was AND STOP SCREWING WITH IT!
I haven't been able to read replies all day!
I know Kev (aka GossiTheDog) and chances are, he'll never get around to it. I'm gonna try help him, but since my C++ skill are well, pretty crap, I might not be able to do much
It's a cool site with more n64 resources than you'll ever need. I'm in a bad mood, so I'll drop some mischief. go fuck with these guys -> peanuts.bud.co.jp . They're running apache 1.0.0 'nuff said.
You are forcing someone to be OSS when they did not intend it! You may disagree with there choice, but it was theres to make to not be OSS.
Why not help TrueReality? It wants to be OSS.
http://www.snes9x.com/n64emulators/
Mortal Kombat Triligy is displaying the title screen... I know thats not Zelda, but its a very good start.. I would imagine it is a better start than over a meg of assembly...
Why are people forcing UltraHLE to OSS. If the authors wanted to be OSS, they would have made it OSS.
Why dont all you anxious people help True Reality. It is OSS from the beginning.
http://www.snes9x.com/n64emulators/
Ive been helping lately and the mac port author got Mortal Kombat Triligy to display the title screen last week. (I know that is Mario at 30FPS, but its a start!) Probably a better start than a meg of assembly.
Remember awhile back when nVidia released source code that was slightly obfuscated and everyone bitched and moaned on /.? Why is this different? This doesn't even compile nor is it true C/C++. Someone just found a decompiler that output C and ran it on the binary. Look at all the people who say "great! source code!" when they themselves haven't even looked at it. No one in their right mind will attempt to port this to any platform. Why? Because its NOT portable. Infact you would have an easier time creating an emulator from scratch.
This code looks like the output of 'REC - the Reverse Engineering Compiler'. It has nothing to do with c or c++ surce code.
It schould be easier to write an N64 emulator from scratch, than to use this code.
Hey, it plays great on Windows right now.
Oh boohoo it diint come out for linux first.
Now go run off and fiddle with vi
I don't mind Slashdot fucking up (hell, we're only
human, of course), but what gets me is that VERY RARELY
does anyone print a retraction, or remove the
story once it's found it be incorrect/bad/false/etc.
THATS bad. Fucking up is natural, though.
Stick it to the IDSA. Fuck 'em. Let them scream
and holler, and get people mad. Once the courts
decide in favor of *US*, they're gonna look stupid
as shit. If, and I *HIGHLY* doubt, they happen
to decide against US, then we'll at LEAST have had
a few drops of enjoyment out of life instead of letting
them shit all over us, cowering and giving in to their
threats, lies, and greed. Stand up for yourself,
man, because once they see that people are scared and will
fall for this shit, they'll KEEP lying to us, just like Nintendo.
Wha? There's nothing to attack. Once the source is out of the bag, its out of the bag. Read it and weep Nintendo
Now if only the real authors would leak the actual code.
Let's get this working instead.
The mips emulator, i/o, etc is all done; There are only a few things left to do:
1. Finish the COP0 paging support
2. Fix the last half-dozen or so RCP instructions.
3. Perform the memory initialization that the N64 boot code does.
I really don't think that TrueReality is that far from working once these few things are completed.
I've posted a reply here like 5 times now and the nazi post-eater keeps deleting it. On the main page the number of comments keeps going up (23, 24, 25...) but no new responses show up. Weird.
this isnt the source , its a decompiled version
from teh binary, hardly a C source is it... its
useless unlres you want to spend 1000hrs decoding
the crap
I got this last week and was disapointed that its
not the real thing, check your data beforeposting
shit like this
blah
Just as I suspected. Another bunk de-asm.
damn, people. how bout someone do some social hacking, meet the authors and jack the damn source yourself.
enough of this bullshit. Why not just get a copy of an MS disassembler of some sort and give us a more worthwhile laugh?
sheeeit.
Decompiling something to C++ is not an easy task.. there are no decompilers that produce
re-compilable code. Hell have you ever tryed to decompile something to even asm and then recompile it? It takes a few weeks to get the asm code to recompile (modifying it by hand is the only sure fire way) let alone C++.
That's the silliest thing I've ever seen. I'd rather just use a disassembler myself. I'm amused that he called it "C++ code". Ugh.
Right. It appears that Slashdot have decided to post this on their web site. This is not something I had expected.
I would like to make it clear that Slashdot are INCORRECT in saying this is "the" UltraHLE C++ code.
This is a project run by about 10-20 of us where we are slowly reverse enginerring "ultra.exe".
Anyway, my PC is broken at the moment. Next source upload will be on Saturday. Complain away then.
http://www.udders.freeserve.co.uk
if you've ever used a decompiler you'll know that anything bigger than say, a 10k com file won't decompile right. the resulting 'source' usually doesn't compile without a lot of work
Uhh, this isn't the source code. This is an exe->c conversion using one of the many decompilers out there (none of which are very good). It's basically the disassembled asm code turned into C by a conversion utility.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Okay, I'm confused. As i mentioned above, it's a exe->C conversion, not the actual source code. However, if he used any halfway decent exe->c "decompiler," the source, while virtually unreadable, would still compile. Why does his source not compile?
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Posted by Tony Smolar:
A viable N64 emulator will surely bring all the WaReZ D00ds out. Not a crowd that Linux needs.
Posted by Tony Smolar:
This would be the "Killer App" for software pirates. I know FSF folk don't believe there's such a thing, but it's not a crowd that we want the rest of the world to associate with Linux at any rate.
I'm surprised noone has mentioned this yet, since it kinda blew my mind. It doesn't affect me, since I don't have an N64, or a 450 MHz Pentium, but it's still majorly cool that even through a layer of emulation and with the overhead of the X Window System, Linux still manages to be faster that Windows! Kinda makes you wonder what all those thousands of Microsoft programmers do all day.
fish and pipes
Okay - so who wants to do the Mac port? I'm sure that it can't be hard, just reverse the endian here and there and voila! Free Mac software. Linux port will be even easier, since the byte order is the same on any PC platform. What are you waiting for? Jump on board. Contribute to the "source tree", now that it's "Open Source".
From Gossi-the-aptly-named-dog's home page:
...it won't work. Maybe the biggest problem with UltraHLE isn't the GUI? Things like Win-only, GLIDE-only, imperfect emulation, no "flat polys only" mode, etc.? Not so easy to change these from the disassembly... This is such a joke.
...But something seems fishy here. I would have expected the original authors of the emulator to post the sources. IIRC, GossiTheDog wasn't one of them.
I'm half inclined to grab the archive, whatever it is.
Schwab
Editor, A1-AAA AmeriCaptions
This is indeed good news.. A while back someone released fixed asm de-compiled code of UltraHLE. I guess that was a bit weird.
/. ed.
Port it! Port it to the Palm Pilot! BTW, the site is already
PS: No glide based implementations please...
--
This is the real deal here... There is a file known as cpua.c which, after disassembling the UltraHLE exe into ASM much like Gossi, and compairing the two, this is the real deal. The site mentioned above, was the source of it, and now it has been removed... :/ I still have it though, but it isn't very useful on it's own.
// dump PC as executing (debug) (1=every group, 2=every new group) // profile execution (cmd 'stat3'), slows execution!
// these names are a bit short for global scope, but they were
// originally internal to this file. Then this file grew so large
// it had to be splitted. Well so it goes.
/************************************************* *************************
// select optimization settings
:)
#include
#include "ultra.h"
#include "cpua.h"
#define DUMPGO 0
#define EXECPROF 0
RState r;
CStats cstat;
dword ip[256];
** Routines for compiling a new group
*/
void a_optimizesetup(void)
{
r.opt_old=0;
r.opt_directjmp=0;
r.opt_rejumpgroup=0;
r.opt_adjacentvm=0;
r.opt_nospvm=0;
r.opt_novm=0;
if(st.optimize==0)
These were the first few lines, of the file, much to long to post here, but as you can see, it is just a small component of the much larger program... Hope the rest is released soon...
Baggio
Time flies like an arrow;
Time flies like an arrow;
Fruit flies like a bananna
EXE->C isn't quite right... it goes EXE->ASM, and I'm not sure there is an ASM->C as it is going from a lower level language to a higher one... EXE->ASM isn't really to hard to do. The opcodes are known, and the source is just parsed replacing the opcodes with ASM mnemonics. Using this method, anything can be "reversed", but it doesn't yield much to the original source. This is what goes on in an emulator, but the interpereted data, instead of being written to a file, it is "executed". If the opcode mnemonic was mov.b for instance, the emulator would move a byte of data into an imaginary register.
:) In this way the N64 can be emulated without emulating every single R4300i opcode.
:)
What makes UltraHLE unique, and in that sense "revolutionary", is that it takes the ASM and does generate C of sorts. The ASM instructions are examined at a higher level, and paterns are recognized as common routines, and further emulated using C... This is posible in part because the N64 is a based on a RISC processor (R4300i for those interested), and more complex CISC instructions can replace a "patern" of RISC instructions. Also, the N64 software is developed in C now as opposed to the older memory effiecient console programs... The more available memory means that programs can be developed faster, and it means that the generated ASM has repeating patterns, is bloated, and is eaiser to reverse to a higher level...
One thing that makes UltraHLE hard to reverse is the fact that it was compile for P5 (many disassemblers only cover 8086 instructions), and that much of the emulator is inline ASM for faster execution. Hopefully the developers will release their code in its entirety soon...
Baggio
Time flies like an arrow;
Time flies like an arrow;
Fruit flies like a bananna
Hey, I don't see any other programs having this problem, like the Playstation Emulator for Mac.
There isn't really a point to this other that to allow it to play more games. Which of course I am sure will be for totally legal pursuits.
Geez...
"I disapprove of what you say, but I will defend to the death your right to say it" - F. Voltaire.
It is NOT the full source, it's the first release of one guy's effort of converting the asm to C++. It doesn't even compile.
He is also NOT a member of the development team in any way shape or form, it is not condoned in any way by the authors.
This is what the releaser GrossiTheDog says: His page is here if you want to check out all he has to say about it. Next time, get the story right.
It takes a REAL stretch of the imagination to get from what this source code really is (a raw dissasembly into C) to a headline on slashdot such as "UltraHLE Source Code".
/. authors, please use a little more common sense in filtering what stuff gets posted. Lately you are leaning towards the sensational rather than the factual a little too much.
First the story about the massively parallel FPGA machine (which REALLY sounds fishy to the point of being a hoax), and now this?
Come on
Please turn up the BS filter.
Paul Bettner
Game Developer et al
The current version of the UltraHLE "source code" doesn't help further developments. It just contains a naive try to de-compile the executable.
The result contains some C constructs for conditionals and loops but is not more readable than what the average disassembler can produce.
Disassembled code is certainly not a good base for further developments...
The source that Gossi has released is his first attempt at tearing apart the ultrahle emulator. And not the actual source code which is yet to be found.
Just wanted to say that, but also, Well @ least the source is out... but on the other hand if NES's claims hold true it is STILL illegal I think...