N64 to EBOOT

[SuperFury1]

Would it be possible to convert a .n64 rom to psp eboot?

(Read n64 rom command, create eboot version of that command, write eboot version to DATA.PSP etc, later creating icon0 (pic1).png and put it in eboot).

[Art]

no, the N64 ROMs might run with an emulator, but I don't know if there's an N64 emulator.

[Gefa]

Originally Posted by Art

no, the N64 ROMs might run with an emulator, but I don't know if there's an N64 emulator.

Sure, it there is, its name is daedalus and it works well enough too, so honestly there is no reason to convert a n64 rom to PSP EBOOT.

[Nielkie]

Originally Posted by SuperFury1

Would it be possible to convert a .n64 rom to psp eboot?

Yes. Assuming basic coding ability, it would be relatively trivial to create a program that bundles a rom with daedalus.

[SuperFury1]

Originally Posted by Nielkie

Yes. Assuming basic coding ability, it would be relatively trivial to create a program that bundles a rom with daedalus.

I mean, those roms must have some kind of command structure, just like a psp data.psp, a pc .exe (the executable data), a pc .com file etc has.
If we know that, we can change the data so the psp would understand, wouldn't we?

What daedulus does is translate it for the psp while executing it. If we pre-translated the rom for the psp, it would run much faster, wouldn't it (without the translation process slowing us down)?

[Dos]

Making an eboot for a PSX game only works because the PSX emulation is built into the firmware. I'm not saying that it can't be done, but you would essentially be emulating the same as daedalus based solely on one game.

[SuperFury1]

Originally Posted by Dos

Making an eboot for a PSX game only works because the PSX emulation is built into the firmware. I'm not saying that it can't be done, but you would essentially be emulating the same as daedalus based solely on one game.

But it will be faster, as it doesn't has to read the command and/or translate the commands for the psp, cuz it's already translated. Thus it can at least speed up things.

[slicer4ever]

Originally Posted by SuperFury1

But it will be faster, as it doesn't has to read the command and/or translate the commands for the psp, cuz it's already translated. Thus it can at least speed up things.

in short, Yes it's perfectly possible, however it's pretty much the same task as taking any executable file and converting it back into it's source, have fun doing that=-)

[SuperFury1]

Originally Posted by slicer4ever

in short, Yes it's perfectly possible, however it's pretty much the same task as taking any executable file and converting it back into it's source, have fun doing that=-)

Well, in fact you don't have to go back any further than assembler (binary) code, then converting that to psp's assembler (binary) code.

[UnknownToaster]

If YOU want to do it, go ahead, but I don't think that many people want to waste there time with it.

[indrora]

Yes you do. You have to create graphics routines that match 1:1 the graphics routines on the PSP. So you're going to have to

1. decompile from N64 (r4300i) assembly
2. do heuristical searches to find graphics routines
3. replace those with ones that do PSP graphical routines
4. replace any and all timing sequences that rely on the r4300i's internal clock with that of the MIPS that the PSP uses
5. Test with SHIPTONNES of roms
6. Hope you dont break your PSP in the process
7. Oh, and dont forget to make sure and properly replace the savedata routines too. There's a lot of different ones.

You'll see that Daedlus64's codebase is pretty big. And I mean really big.

[SuperFury1]

Originally Posted by indrora

Yes you do. You have to create graphics routines that match 1:1 the graphics routines on the PSP. So you're going to have to

1. decompile from N64 (r4300i) assembly
2. do heuristical searches to find graphics routines
3. replace those with ones that do PSP graphical routines
4. replace any and all timing sequences that rely on the r4300i's internal clock with that of the MIPS that the PSP uses
5. Test with SHIPTONNES of roms
6. Hope you dont break your PSP in the process
7. Oh, and dont forget to make sure and properly replace the savedata routines too. There's a lot of different ones.

You'll see that Daedlus64's codebase is pretty big. And I mean really big.

You got a point there. First, i'll need to have a decompiler for n64 rom. anyone knows one? (i'm gonna test it with loz oot. like the game, but hate the lagg)

[Dos]

From what I can find there isn't a n64 decompiler. The closest thing out there is "N64 Disassembler" or "Hex-rays IDA pro / decompiler"

Originally Posted by http://www.hex-rays.com/support.shtml

You can also download a small freeware utility: an extensive file dumper. It supports virtually all popular executable file formats:
EXE, NE, LE, LX, PE, NLM, XCOFF, COFF, OMF, DBG, PRC, PEF, OS9, N64, PSX, EPOC, AR, AMIGA, ELF, ECOFF, HP SOM, GEOS, OLE2, AIF, AOF, AOUT, PE+, OMF166, MachO, XE/XBE, JPG, CIFF, TMOBJ, MRW, TIFF, MPG, CWLIB XCP.DAT, WMF, DSO, PDB

Good Luck

[indrora]

Well since the format is pretty well known, it wouldnt be hard to write an app that simply *reads* it and turns it into assembly.

[Davee]

That would be a ****ing crazy dynarec tbh.

[Zack_PSP]

Originally Posted by SuperFury1

Well, in fact you don't have to go back any further than assembler (binary) code, then converting that to psp's assembler (binary) code.

Note : I am not trying to be offensive with this post.

Ok, so if you know assembler (mips) why not just help optimize daedalus's dynarec, help kreationz move the cpu to the dynarec, optimize more stuff etc?

I guarantee if you know your stuff you will see OOT fullspeed on the PSP a lot faster by doing that than your other idea.

[SuperFury1]

Originally Posted by Zack_PSP

Note : I am not trying to be offensive with this post.

Ok, so if you know assembler (mips) why not just help optimize daedalus's dynarec, help kreationz move the cpu to the dynarec, optimize more stuff etc?

I guarantee if you know your stuff you will see OOT fullspeed on the PSP a lot faster by doing that than your other idea.

Well, in fact..... i know assembler from how a pc .COM program works. What i know is that, for example byte 50h is just a PUSH AX command,
And that when there are information parameters (numbers), they immediately follow the command identifier. So if MOV AH,0 would be XXh, then the bytes will be as following: XXh, 00h and if you have a parameter with a word (16-bit) number parameter, it will follow the command specifier with the lower byte first and higher byte last, so MOV AX,0012h would become: XXh, 12h, 00h etc. If i know what happens with the n64 commands and psp commands, just like i know how it works with the pc .com/.exe executables, you don't have to know anything more than their binary values (50h for example (no parameters) and the examples i just said). Just read in a command, as binary values, make the psp's command data from it and write it to the destination file, next byte/word etc will be the next command.

It's just that easy. Just need a list with the n64 assembler command's and psp's assembler commands (might need headers too).

... And for experience with assembler, i only used a bit some time ago when trying to make myself a custom-made bootable diskette (reading my executable from fat and run it from memory). Also made a simple compiler (for DOS .COM programs) with about 5 commands to use (write text(xxx), wait for keypress(), quit()), but lost the source...

[Skyline34]

I'd say go for it if you think you can, be the first!

[SuperFury1]

Originally Posted by SuperFury1

Well, in fact..... i know assembler from how a pc .COM program works. What i know is that, for example byte 50h is just a PUSH AX command,
And that when there are information parameters (numbers), they immediately follow the command identifier. So if MOV AH,0 would be XXh, then the bytes will be as following: XXh, 00h and if you have a parameter with a word (16-bit) number parameter, it will follow the command specifier with the lower byte first and higher byte last, so MOV AX,0012h would become: XXh, 12h, 00h etc. If i know what happens with the n64 commands and psp commands, just like i know how it works with the pc .com/.exe executables, you don't have to know anything more than their binary values (50h for example (no parameters) and the examples i just said). Just read in a command, as binary values, make the psp's command data from it and write it to the destination file, next byte/word etc will be the next command.

It's just that easy. Just need a list with the n64 assembler command's and psp's assembler commands (might need headers too).

... And for experience with assembler, i only used a bit some time ago when trying to make myself a custom-made bootable diskette (reading my executable from fat and run it from memory). Also made a simple compiler (for DOS .COM programs) with about 5 commands to use (write text(xxx), wait for keypress(), quit()), but lost the source...

Just looked into the daedulus source. The commands for the n64 weren't that hard to find, they're in "opcode.h"

[Art]

It's just that easy.

Maybe if the hardware was exactly the same.
I somehow doubt anything will come of this.

[Davee]

Originally Posted by SuperFury1

Well, in fact..... i know assembler from how a pc .COM program works. What i know is that, for example byte 50h is just a PUSH AX command,
And that when there are information parameters (numbers), they immediately follow the command identifier. So if MOV AH,0 would be XXh, then the bytes will be as following: XXh, 00h and if you have a parameter with a word (16-bit) number parameter, it will follow the command specifier with the lower byte first and higher byte last, so MOV AX,0012h would become: XXh, 12h, 00h etc. If i know what happens with the n64 commands and psp commands, just like i know how it works with the pc .com/.exe executables, you don't have to know anything more than their binary values (50h for example (no parameters) and the examples i just said). Just read in a command, as binary values, make the psp's command data from it and write it to the destination file, next byte/word etc will be the next command.

It's just that easy. Just need a list with the n64 assembler command's and psp's assembler commands (might need headers too).

... And for experience with assembler, i only used a bit some time ago when trying to make myself a custom-made bootable diskette (reading my executable from fat and run it from memory). Also made a simple compiler (for DOS .COM programs) with about 5 commands to use (write text(xxx), wait for keypress(), quit()), but lost the source...

It's not that easy. Remember, PC uses a dirty CISC command-set and is nothing like RISC. Both the PSP and the n64 are MIPS based (n64 being 64 bit(?)) RISC processors so opcode parsing is totally different from CISC (where each opcode can be different lengths, where RISC is pipeline friendly same length opcodes).

You also need to know that you can't directly dynamically recompile the n64 binaries directly. You'll probably want to convert to PRX, which means you're gonna have to do a lot of maths and heuristical routines on the binary to get buttons, graphics, sound, intialization etc etc. Then you have to translate memory addresses and make it dynamically relocatable.

Basically, you'll need to learn the full PSP graphics routines and hardware as with the N64 and on top of that learn how the binaries are stored, how input is retrieved, how to modify binary asm without killing jumping routines or overflowing with jumps to external addresses and so forth.

[larryr]

in other words, hard or next to impossible.

[Nielkie]

Originally Posted by larryr

in other words, hard or next to impossible.

Far from impossible, greater feats have been achieved. On first glance however it seems SuperFury1 has far from the required skill, though you never know.

...

Also, it should be noted that static recompilation is not hugely faster, and in some cases can even be slower, than a good dynrec core.

[Mr_Shizzy]

Wouldn't it be easier to just modify the daedulus source code, to auto load a ROM. Then just change the icon0.png ect.. to match the game for xmb game menu?

[Dos]

Originally Posted by Mr_Shizzy

Wouldn't it be easier to just modify the daedulus source code, to auto load a ROM. Then just change the icon0.png ect.. to match the game for xmb game menu?

Originally Posted by SuperFury1

What daedulus does is translate it for the psp while executing it. If we pre-translated the rom for the psp, it would run much faster, wouldn't it (without the translation process slowing us down)?

SuperFury was trying to speed up the game by not using daedulus and rewriting the .n64 into an psp game file.

But you do bring up a good point. On DaedulusX64 A435 Mario64 is currently running at full speed with sound(frame skip 2). And Mario Kart64 is coming along. OOT is on there list, but they are focusing of 50+ games at the same time. Have you tried getting with the daedulus team to work solely on OOT.

[indrora]

The point is unless Superfury1 has some magical knowledge about platform translation that he hasnt told anyone about, its going to be a HEUG endevor. porting system to system is not like baking cookies. You dont just telnet your way into mordor and deliver cookies.