Nintendo Sixty Fooooooooooooooooooour!

[Exophase]

MAME is going to dynarec the RSP too. Did you consider it?

I'm not sure you're aware of this, but Mupen64plus doesn't really emulate the RSP at all. The same thing applies to most other N64 emulators out, at least in their common configurations.

On N64 RSP has a small amount of RAM and is relatively complicated to program for. What Nintendo/SGI did was made a set of higher level languages for graphical and audio operation, called ucodes. You would select the ucode language for graphics and audio that your game uses, then appropriate ucode interpreters would be loaded onto the RSP.

Rather than emulate the RSP itself, Mupen64plus emulates the different ucodes. ucode type is autodetected based on the code that the CPU tries to upload to the RSP. This doesn't work for games that use custom ucode or ucode implementations, much less games that run code natively on the RSP. But since Nintendo didn't release RSP development tools until late in the N64's life the number of games that do this are few and far between. Furthermore, since the original ucodes used full 32bit precision (the RSP has effectively a sort of 8/16bit SIMD, but with accumulator side effects) the geometry/lighting throughput was limited; emulating this to the same level of precision isn't as much of a performance hike as it'd be to emulate twice as many vertices at half the precision.

Even with a very, very good dynarec low level RSP emulation is very taxing and it's extremely unlikely that Pandora could handle it. Its SIMD doesn't map well to NEON or any versions of SSE. There has been a recompiling low-level RSP plugin out for years, source is open too if you want to look at it.

 

[ldesnogu]

I certainly wasn't aware, thanks for the explanation

 

[ari64]

Right now one of the reasons why the iPhone 3GS version of Mupen64plus is slower is that zodttd hasn't found a way to map RDRAM to 0x80000000 in the process's address space. This is an optimization Ari64 used in order to avoid having to add something to N64 RDRAM addresses to convert them to emulated RDRAM addresses. zodttd is also currently generating a few too many instructions for this. With the location it's currently landing at it should take him 2 additional instructions to convert it, and chances are good that these instructions can be placed such that it only costs 1 extra cycle. The icache pressure will be a little worse, but the 2x icache should easily offset that.

Oh my. I hadn't looked at that. Can't use mmap on the iphone?

push r9
movw r9, #rdram_lo
movt r9, #rdram_hi
add r9, r9, rs
bic r9, r9, #0x80000000
ldr rt, [r9]
pop r9

That's just awful. Couldn't you do something like eor #0xa0000000 and map it at 0x20000000? or use r14?

He also had to do some nasty hacks to accommodate Apple's crappy assembler. Developers have been yelling at Apple about that for years and they never fix it.

Interestingly ZodTTD enabled the pld instructions. Does it help?

 

[Exophase]

Oh my. I hadn't looked at that. Can't use mmap on the iphone?

It's not conclusive, but what zodttd told me is that the mmap succeeds but then accesses to the supplied pointer crash. He wasn't checking the result of the mmap at the time; I told him that it's probably giving him a different pointer than the one he requested.

That's just awful. Couldn't you do something like eor #0xa0000000 and map it at 0x20000000? or use r14?

He should certainly try that. The r9 thing is pointless at the very least.

At worst, given an arbitrary RDRAM pointer, it should be the following three instructions:

movw r14, #(low(0x80000000 - rdram))
movt r14, #(hi(0x80000000 - rdram))
sub rt, rt, r14

Right now he says that rdram is around 0x4f000 or somesuch, so it could be accomplished with a bic and an add.

He also had to do some nasty hacks to accommodate Apple's crappy assembler. Developers have been yelling at Apple about that for years and they never fix it.

I don't think zodttd is using an assembler provided by Apple. I had some assembly code in Temper that completely failed because the parsing for exp​ressions in immediates (like #(1 + 1)) was incomplete. I had to go on their IRC channel and yell at them to fix it - I could see the actual limitations in the grammar definition which was available on the repository. I don't know whose idea it was to completely rewrite the ARM assembler from scratch instead of using the standard binutils one, but it was an incredibly silly move and the results are less than impressive.

Interestingly ZodTTD enabled the pld instructions. Does it help?

I don't know, sorry. The extent of my knowledge of the situation came from me asking him if he had to do anything that was slowing down the recompiler in order to get it working, and he told me he had to do all those instructions. To which I responded that he should only have to do two or three to adjust the pointer. For the record I have nothing to do with this port ;p

 

[ari64]

He also had to do some nasty hacks to accommodate Apple's crappy assembler. Developers have been yelling at Apple about that for years and they never fix it.

I don't think zodttd is using an assembler provided by Apple. I had some assembly code in Temper that completely failed because the parsing for exp​ressions in immediates (like #(1 + 1)) was incomplete.

Then he must be using Apple's assembler because he replaced all the expressions in immediates!

Specs on the GPU only. The Samsung CPU has the 32KB caches which we both know is better. I don't know what kind of memory the iPhone/Touch is using but if it is DDR2-333, that will add more latency on cache misses as well.

Well, if they are using DDR2-333 instead of DDR-333 then the cycle time would be 12ns instead of 6ns. It probably wouldn't make a huge difference since a 64-byte L2 line fill will still take 48ns (16 transfers x 3ns).

Hum you are wrong I think: DDR2-333 has the same bandwidth of 2664 MB/s as DDR-333. The reason is that it uses both rising and falling edge for transfers.

The bus is only 32 bits wide, so 1332 MB/s (which is equal to 64 bytes in 48 ns)

 

[Exophase]

Then he must be using Apple's assembler because he replaced all the exp​ressions in immediates!

What I was saying is that it's a non-Apple assembler that has this problem. Hence why I was able to go complain to the maintainer of it directly. I don't know why they still haven't fixed it.

 

[DaMummy]

you guys realize that this is general talk....and well what youre saying.....isnt?

 

[gruso]

Don't feel bad, most people don't understand it. But it's awesome to have these conversations going on for all to see. Welcome to GP32X.

 

[zhasha]

Don't feel bad, most people don't understand it. But it's awesome to have these conversations going on for all to see. Welcome to GP32X.

They're talking about how on pandora, Ari64 uses mmap to automatically map N64 RDRAM to the pandora's memory. mmap is evidently not working on iPhone which means ZodTTD had to recalculate the real address (which is simple, but requires unnecessarily many instructions) and thus we have a major slowdown, but only on iPhone thankfully.

 

[kin]

Don't feel bad, most people don't understand it. But it's awesome to have these conversations going on for all to see. Welcome to GP32X.

They're talking about how on pandora, Ari64 uses mmap to automatically map N64 RDRAM to the pandora's memory. mmap is evidently not working on iPhone which means ZodTTD had to recalculate the real address (which is simple, but requires unnecessarily many instructions) and thus we have a major slowdown, but only on iPhone thankfully.

yep, yourphone

 

[PokeParadox]

you guys realize that this is general talk....and well what youre saying.....isnt?

If you don't understand it either ignore it or gawp in awe!

But anyway let the nice devs have their conversations or we don't get nice things.

 

[HackModford]

Kinda like when we wander to the devs corner giving them praise and they kick us out because we're not devs... we kick them out here because they're not us...
I could care less... I like the tech jargon... make's me feel stupid

Also that mapping thing doesn't only affect iPhones... it affects iPod Touches too :lol:

As of right now Zod ruined the 64 emulator by mapping the c buttons to the joystick <_<

I want my pandora

 

[zhasha]

Also that mapping thing doesn't only affect iPhones... it affects iPod Touches too :lol:

As of right now Zod ruined the 64 emulator by mapping the c buttons to the joystick <_<

Yeah... you have absolutely no idea what they're talking about.

NAME
       mmap, munmap - map or unmap files or devices into memory

SYNOPSIS
       #include <sys/mman.h>

       void *mmap(void *addr, size_t length, int prot, int flags,
                  int fd, off_t offset);
       int munmap(void *addr, size_t length);

DESCRIPTION
       mmap()  creates a new mapping in the virtual address space of the calling process.  The starting address for the new mapping is speci-
       fied in addr.  The length argument specifies the length of the mapping.

He's using a virtually mapped address space to create a simple yet extremely effective speed-up. His dynarec doesn't have to insert extra instructions to add to or subtact from RDRAM addresses which means he can cut one of the most used operations to a bare minimum of instructions = awesomeness incarnate. The iPhone and of course also iPod Touch OS evidently has mmap, but it doesn't work as it should and thus ZodTTD needs to manually translate RDRAM addresses which reflects in the efficiency of the code generated.

 

[HackModford]

I'm still lost
No I kinda get it...

 

[danielaquino]

my report on n64iphone(only tested the roms in my collection):

[Sniip>

I suggest you try either Forsaken 64 or Rampage or Micro Machines 64 Turbo or any of the Jikkyou Powerful Pro Yakyuu games

Also I can't wait for High Def Rendering like we have on the PSP

Forsaken is still alive and well under the original name ProjectX. Basically a source port of the final patch release with various hidden features exposed, bug fixes, additions and reversals of unpopular changes that appeared in the patch (such as speed reduction). We have many of the original Forsaken players from the 90's, some Descent players, and new ones. Now that it has stabilized we have been focusing on enhancements such as true 3d surround sound, a level editor, enhanced lighting, bot framework (so you can write your own bots to join real games), and other ideas... The original pc game (unlike the n64 version) was always network capable and actively played online. To download the game and get more information check out the site (http://fly.thruhere.net).

Some interest has been shown to port ProjectX to Pandora. This should be fairly easy since it already compiles with gcc, uses cross platform libraries, and already has a simple shader based backend for opengl3 support. The game was always considered graphically stunning for it's time and runs rather efficiently since it was originally made for 100mhz systems. I believe it will be a nice addition to the list of Pandora games :]

 

[Prometheus]

We generally don't allow such incredibly ancient gravedigs here unless the new post contributes something useful and/or worthwhile. I'm happy to say that your post did. Hello, and I look forward to hearing more about your porting efforts.

 

[danielaquino]

We generally don't allow such incredibly ancient gravedigs here unless the new post contributes something useful and/or worthwhile. I'm happy to say that your post did. Hello, and I look forward to hearing more about your porting efforts.

Awesome! I have been digging Forsaken out of it's grave for the last 12 years :]

I was actually contacted by two Pandora users who found us, to bad I didn't know about the device sooner or we'd be playing already :]

Is there a more appropriate thread I should use for any developments ?

 

[Prometheus]

Making a new thread all about it (and also on the other forum, which is the official one) is probably the best way to draw attention to it and notify people about it.

 

[trooper]

@ Daniel Aquino

You could create your own topic either in the Pandora/Developers corner or Pandora/Homebrew
part of the forum. It will definitely get more exposure in it`s own topic, Rather than buried
deep within someone else's topic.

Btw, Welcome to GP32x, And good luck with your endeavor.

Trooper