Daedalus Shifty Beta 1 release

[zidanerick]

I still say this is crap, you are just ripping off all the hard work that wally and strmnNrmn have done, and you could not have accomplished much because Wally had not released the source of his Spiffy Updates.

[Shifty_]

To everyone on right now

I am sorry for my bluntness, but i did not mean to be rude to you, I was trying to be more focused on the ppl who were giving me bad comments for my work, i'd thought ppl would be happy for what i am trying to do, sorry i hadn't realised that everyone is so defensive here.
About the question before gunntimms,


"If you are very proficient in C/C++ inprove on the dynarec. I think the one that sttrrrnnnm has in place in an incomplete one or at least a unfinished one. Also you should create some sort of interpreter to increase speed rendering, If possible something in real time that reads and buffers the frameskip rather quickly giving you near full speed. Also would it be possible to have a (JIT) into the code to convert MIP's in real time. If im not mistaken that was exophases approach to gpsp.

I dont know the exact specifications on the n64 hardware to emulate it to the psp so i could be wrong about all of this....
"
I am not an expert on N64 hardware either, nor am I as profficient in C/C++ as strrrnnnm, nor am I sure that would be the right path to take for what I want to accopmplish.
I haven't read over the entire deadalus source yet, just some of the bits and peices of it that I may want to work for rewriting a rom file. I think i know what you mean by an interpreter that will increase speed rendering that reads and buffers the frameskip in real time, and you know what, that is going to have nearly the same result of what I had originally intended to do with this. I see what you mean, because if I just edit the rom to run faster, there will be a constant frameskip, which would be bad for some parts of the games. Perhaps I could take that into consideration. And I am not entirely sure about converting MIPs in real time, as I said before I will take all this into consideration, thank you for your ideas.

shifty_

[gunntims0103]

* Processor: 93.75 MHz NEC VR4300 (info), based on MIPS R4300i-series 64-bit RISC CPU (image)
          o L1 cache: 24 KiB (split: 16 KiB instruction, 8 KiB data). No L2 cache.
          o Buses: 32-bit address and data.
          o CPU to RCP Bandwidth: 250 MiB/s (non-DMA). CPU can not directly access RAM.
          o Instruction Set: MIPS R4000 32-bit. Addressable Memory Space: 4 GiB (Virtual 1 TiB).
          o 5-stage scalar pipeline. Integrated FPU. 93 million operations per second.
          o 4.6 million transistors
          o Manufactured by NEC using 0.35 µm process.
    * RAM: 4 MiB RDRAM (image) (upgradeable to 8 MiB with 4 MiB Expansion Pak)
          o Data path: 9-bit width at 500 MHz
          o Potential Memory Bandwidth: 562.5 MiB/s
          o ≅640 ns RAM latency
    * Graphics: SGI 62.5 MHz 64-bit RCP (Reality Coprocessor) (image) contains two sub-processors:
          o RSP (Reality Signal Processor) controls 3D graphics and sound functions
                + MIPS R4000-based 8-bit integer vector processor
                + Programmable through microcode (µcode). Allows functions to be modified or added.
                + Transformation, clipping, lighting, triangle setup, and audio decoding (audio could be done on main CPU as well)
                + Geometry throughput: initially ≅100,000 polygons per second with full quality. Some later games go higher with highly optimized microcode.
          o RDP (Reality Drawing Processor) rasterizer handles all pixel drawing operations in hardware, such as:
                + Z-buffering (maintains 3D spatial relationships, is Mario in front of the tree or vice-versa?)
                + Anti-aliasing (smooths jagged lines and edges)
                + Texture mapping (placing images over shapes, for example mapping a face image to a sphere creates head)
                      # Bilinear filtering (prevents texture blockiness by blurring when resizing)
                      # Mip-mapping (creates distance textures of varying degrees of fidelity)
                      # Trilinear mip-map interpolation (filters mip-maps and textures smoothly without blockiness). Nintendo 64's filtering is not entirely accurate. Precision was reduced to lower mathematical demands.[3]
                      # Perspective-correct texture mapping (keeps textures from "warping" when viewed at different angles)[4]
                      # Environment mapping (best seen with metal Mario in Super Mario 64)
                      # Gouraud shading, Level of Detail (LOD)
                + Fillrate: ≅30 megapixels/sec with Z-buffering enabled
          o 128-bit internal data bus between RSP and RDP. ≅1.0 GiB/s bandwidth.
          o Resolution: 256 × 224 to 640 × 480 pixels flicker-free, interlaced
          o Color depth: 16.7 million colors (32,768 on-screen)
    * Sound: 16-bit Stereo (usually lower quality). ADPCM, MIDI, Tracker, and MP3. All software-driven by CPU or RSP.
          o Channels: 100 PCM (max, 16-24 avg.). Each channel consumes about 1% CPU time.
          o Sampling: 48.0 kHz (max, 44.1 kHz is CD quality)
    * Media: 32 to 512-MBit (4 to 64 MiB) cartridges
    * Dimensions: 10.23 × 7.48 × 2.87 inches (260 × 190 × 73 mm) W×D×H
          o Weight: 2.4 lbs (1.1 kg)
    * Controller: 1 analog stick; 2 shoulder buttons; one digital cross pad; six face buttons, 'start' button, and one digital trigger.
    * Motherboard photo. On the left, under an aluminum heatspreader, is the VR4300 CPU. Right of that is the RCP graphics processor. The lowermost aluminum block covers the pair of RDRAM memory chips. These heatspreaders make contact with a larger heatsink when assembled. There is no fan.

so knowing this now i think it is possible to process MIP's for n64 in real time. At least i think. The psp specification has i think what it takes to emulate n64 at a decent or full speed.

Maybe shifty if you approached n64 emulation by building a emulator from the ground up. That way you know exactly what your dealing with and you will have the leverage to make your own specifications and inplament your own dynarec.

no problem shifty, just putting out ideas as i myself dont know the n64 emulation to psp hardware specifications. I do realize that writting your own emu is extreamly difficult. Also to get a dynarec up is also a hard thing as to what happened to pacmanfan.

[Exophase]

Daedalus already converts N64 MIPS (it's singular everyone. MIPS.) to PSP MIPS and executes it. That's what a dynarec does. A "JIT" is just another (stupid) name for a dynarec.

And no offense, mostly because you're not actually claiming to be an emu dev, but your ideas didn't make any sense either gunntims. But the fact that Shifty actually said they did is pretty bothersome.

Shifty indeed.

[Shifty_]

To:
gunnTim0103

I will look up the specs for the psp and compare, that could be very useful, thanks, I think you may be pointing me in the right direction, except, I don't think I would be able to ever build an emulator as good as deadalus, maybe, like u'd said earlier, a group project. Thank you, i will definitly think hard, over that tonight.

[gunntims0103]

Daedalus already converts N64 MIPS (it's singular everyone. MIPS.) to PSP MIPS and executes it. That's what a dynarec does. A "JIT" is just another (stupid) name for a dynarec.

And no offense, mostly because you're not actually claiming to be an emu dev, but your ideas didn't make any sense either gunntims. But the fact that Shifty actually said they did is pretty bothersome.

Shifty indeed.

of course im not proficient in C/C++ as i cant code a emu myself, just simply giving ideas, as i think shifty has the right ideas

i make no sence ....... thanx exophase

no problem shifty

[zodttd]

"I see what you mean, because if I just edit the rom to run faster, there will be a constant frameskip, which would be bad for some parts of the games."

But even your approach doesn't make much sense. What does the ROM have to do with frameskipping? Frameskipping generally referred to a way the *emulator* handles skipping the rendering/blitting of a single frame. For example on the Playstation, in simple terms that disc is pretty much a series of instructions which are read, then "emulated". By "emulating" these instructions, this is accomplished by methods using fancy terms like an interpreter and dynarec. Each of those instructions is processed and determined to be a certain opcode by the bit layout, and then converted to something the target platform (such as the PSP) can understand. All of this takes into consideration different ways of handling input, memory cards, storage, video, audio, etc.

If you edit the ROM you're probably going to see a series of instructions of a certain number of bits. For instance the PS1 is a 32bit platform and uses a 32bit length instruction.

Guessing you aren't changing the instructions, you're probably more concerned with the chunks of data, specifically the textures.

And from what you've said the textures should be converted to a type that the PSP natively understands, such as BGR555. If you go through all the trouble padding the difference in size of the textures, and making some sort of way of processing ROMs to make this easier to do...I have a feeling it won't go much faster. ...The textures are converted to a color layout the PSP understands, and then held in a cache (RAM) until the cache gets full and that texture eventually gets kicked out of RAM. If that texture is needed again it gets converted.

Wouldn't it be smart to see how often textures in the cache are being converted more than once, before going through with this?

If they are being converted way too much, it might be a good idea to look at the way the texture cache is handled, and see if you can squeeze more textures into the cache, or go about it a different way.

And if not that, and you do edit each ROM and etc...what does this have to do with frameskipping?

[gunntims0103]

"I see what you mean, because if I just edit the rom to run faster, there will be a constant frameskip, which would be bad for some parts of the games."

But even your approach doesn't make much sense. What does the ROM have to do with frameskipping? Frameskipping generally referred to a way the *emulator* handles skipping the rendering/blitting of a single frame. For example on the Playstation, in simple terms that disc is pretty much a series of instructions which are read, then "emulated". By "emulating" these instructions, this is accomplished by methods using fancy terms like an interpreter and dynarec. Each of those instructions is processed and determined to be a certain opcode by the bit layout, and then converted to something the target platform (such as the PSP) can understand. All of this takes into consideration different ways of handling input, memory cards, storage, video, audio, etc.

If you edit the ROM you're probably going to see a series of instructions of a certain number of bits. For instance the PS1 is a 32bit platform and uses a 32bit length instruction.

Guessing you aren't changing the instructions, you're probably more concerned with the chunks of data, specifically the textures.

And from what you've said the textures should be converted to a type that the PSP natively understands, such as BGR555. If you go through all the trouble padding the difference in size of the textures, and making some sort of way of processing ROMs to make this easier to do...I have a feeling it won't go much faster. ...The textures are converted to a color layout the PSP understands, and then held in a cache (RAM) until the cache gets full and that texture eventually gets kicked out of RAM. If that texture is needed again it gets converted.

Wouldn't it be smart to see how often textures in the cache are being converted more than once, before going through with this?

If they are being converted way too much, it might be a good idea to look at the way the texture cache is handled, and see if you can squeeze more textures into the cache, or go about it a different way.

And if not that, and you do edit each ROM and etc...what does this have to do with frameskipping?

would it be possible n64 emulation wise to set up a rom catche that the emulator would read to speed up frameskip. Like in NJ's approach with cps2 emulation. I think this is something shifty "would" have meant if he means editing the rom and code....

i could be wrong

[zodttd]

Unfortunately you're wrong on this one. Your idea of caching the ROM image makes sense. His idea doesn't make sense, and is quite funny in fact!

[gunntims0103]

Unfortunately you're wrong on this one. Your idea of caching the ROM image makes sense. His idea doesn't make sense, and is quite funny in fact!

now im quite confused. What exactly did shifty mean by "i edited the Rom so that it would read faster", did he actually edit a rom file or did he actually edit the code that reads and interprets the rom and emulates it