Our New Machine, Pandora

[Javacat]

Mupen64 is closed source open source, see next post by javacat

I thought you were talking about me, until I saw the next post... seems we have another javaSomething user. *growl*



Where?

 

[mavsman4457]

Mupen64 is closed source open source, see next post by javacat

I thought you were talking about me, until I saw the next post... seems we have another javaSomething user. *growl*



Where?

I think he was referring to me, Javamavsman.

As for the battery, I'm not much of an expert but it would be nice if it was removable. I find it very useful to remove the PSP's battery when I am having problems and can completely reset it. Also, with a removable battery, we could replace it with newer batteries, if newer more efficient batteries ever come out.

 

[DaveC]

I would assume that Craigix will have a case which has a user-removable battery cover, like on PDA's and the GP2X, although I wouldn't blame him if he used a single screw to hold it firmly shut considering the number of times you are going to need to open it (once every 5 years maybe?).

Well a big reason for easily swapped batteries is not just for when they wear out. As was mentioned if you are on a trip and not near a mains it is nice to be able to easily to swap out the drained battery for a spare charged one. This is one aspect of the zodiac that sucked about the built-in battery. If you were not near the mains and the battery drained, you were done until you got to a charger. It would not be too practical to dissasemble the zodiac and play with small screws, connectors, etc while on a plane, train etc just to sap batteries. Yes you can drag around external devices but that kind of ruins portability if you have to have some kind of battery brick with a wire connected while you use it. It would be much nicer if it was a quick swap like the GP2X or PSP, with NO tools needed.

 

[Exophase]

Yes you can drag around external devices but that kind of ruins portability if you have to have some kind of battery brick with a wire connected while you use it. It would be much nicer if it was a quick swap like the GP2X or PSP, with NO tools needed.

No it doesn't. On the plane/train whatever I'm sure it wouldn't bother you at all. I don't know what you mean by "brick", obviously it wouldn't have to be any bigger than actual battery (which is not going to be large), just like the spare you'd be carrying around.

 

[Javacat]

Somebody has recently ported Mupen64 to the gamecube, which I guess means it's reasonably portable.
They are apparently planning on making a dynarec to convert it to PPC. Maybe this could be a good starting point to make an dynarec to ARM?

 

[Squidge]

Maybe we should wait for the console to be released before porting stuff to it

 

[Javacat]

Spoil sport

 

[X-Code]

Maybe we should wait for the console to be released before porting stuff to it

You know... that sounds like quite a good idea actually :lol:


--


Any new news Craig ( as usual, just trying my luck ) ? B)


---

Donate you funky baboons, it may be late but surely it still counts ( only joking about the funky part ) :lol:
http://www.justgiving.com/craigix

 

[Exophase]

Somebody has recently ported Mupen64 to the gamecube, which I guess means it's reasonably portable.
They are apparently planning on making a dynarec to convert it to PPC. Maybe this could be a good starting point to make an dynarec to ARM?



This should also gauge what a quick and dirty port of it would be like (since we already know this will be weaker than Gamecube, especially Wii, it'd be worse)

 

[PeterM]

This should also gauge what a quick and dirty port of it would be like (since we already know this will be weaker than Gamecube, especially Wii, it'd be worse)

Additionally both N64 and GameCube are big endian, whereas presumably this new machine will be little endian and may have to do some more bit juggling to compensate.

I'm not sure the faster Wii speed is relevant at the moment, as a Wii in GameCube mode runs at the same speed as a GameCube (judging by Quake timedemos).

I've found the GameCube to run surprisingly fast, but I'm not sure whether that's down to GCC generating/optimising code well or the machine just being plain beefy. To be honest I've not looked at much of the code GCC has generated for Quake.

 

[Exophase]

This should also gauge what a quick and dirty port of it would be like (since we already know this will be weaker than Gamecube, especially Wii, it'd be worse)

Additionally both N64 and GameCube are big endian, whereas presumably this new machine will be little endian and may have to do some more bit juggling to compensate.

I'm not sure the faster Wii speed is relevant at the moment, as a Wii in GameCube mode runs at the same speed as a GameCube (judging by Quake timedemos).

I've found the GameCube to run surprisingly fast, but I'm not sure whether that's down to GCC generating/optimising code well or the machine just being plain beefy. To be honest I've not looked at much of the code GCC has generated for Quake.


Oh, okay, so Gamecube speed all around. I'm not really sure how the Gamecube's CPU compares to an ARM Cortex-A8's, I think they both have about the same in terms of execution units, but Gekko has out of order execution. Cortex-A8 should be clocked higher, as well as having a denser instruction set. Both have comparable L1 cache. Don't know what the OMAP3430 has for L2 cache (Gamecube has 256KB but it's only 2-way set associative which is pretty bad for a unified cache). NEON might be more powerful at crunching floating point values, since its 128bit instead of 64bit.

So it's actually kinda hard to determine which CPU is more powerful. With some very well scheduled code they might be about even.

Of course Gekko would probably mop the floor with i.MX31's CPU.

 

[Squidge]

Additionally both N64 and GameCube are big endian, whereas presumably this new machine will be little endian and may have to do some more bit juggling to compensate.

Little or big endian, software programmable.

 

[Eolair]

This should also gauge what a quick and dirty port of it would be like (since we already know this will be weaker than Gamecube, especially Wii, it'd be worse)

Additionally both N64 and GameCube are big endian, whereas presumably this new machine will be little endian and may have to do some more bit juggling to compensate.

I'm not sure the faster Wii speed is relevant at the moment, as a Wii in GameCube mode runs at the same speed as a GameCube (judging by Quake timedemos).

I've found the GameCube to run surprisingly fast, but I'm not sure whether that's down to GCC generating/optimising code well or the machine just being plain beefy. To be honest I've not looked at much of the code GCC has generated for Quake.


Oh, okay, so Gamecube speed all around. I'm not really sure how the Gamecube's CPU compares to an ARM Cortex-A8's, I think they both have about the same in terms of execution units, but Gekko has out of order execution. Cortex-A8 should be clocked higher, as well as having a denser instruction set. Both have comparable L1 cache. Don't know what the OMAP3430 has for L2 cache (Gamecube has 256KB but it's only 2-way set associative which is pretty bad for a unified cache). NEON might be more powerful at crunching floating point values, since its 128bit instead of 64bit.

So it's actually kinda hard to determine which CPU is more powerful. With some very well scheduled code they might be about even.

Of course Gekko would probably mop the floor with i.MX31's CPU.


Probably close to equal...

Gekko at 485 MHz: 1125 DMIPS
Cortex-A8: "over 2.0 DMIPS per MHz" which at 550MHz would mean ~1100+ DMIPS

 

[Xmas]

No, I was definitely after mA, considering that most people know the USB port supplies at most 500mA. Since I wasn't mentioning the battery providing the power and simply replying to a post asking whether or not it could run and charge the battery from a USB port, I didn't think it was necessary.

I only convert stuff to watts when there are multiple devices at different voltages.

There are most likely different components at different voltages (the SoC clearly doesn't use the 5V coming from the USB port directly).

The power draw of different components is given in W (or mW). An ordinary powered USB port can provide up to 2.5W. A portable console should draw much less than that.

 

[Squidge]

There are most likely different components at different voltages (the SoC clearly doesn't use the 5V coming from the USB port directly).

No, the SoC will not use the 5V coming from the USB port. However, we are not interested in just the power consumption from the SoC. We are interested in overall power consumption. Therefore, the console itself DOES use the 5V from the USB port directly, and this is the part we are interested in.

The power draw of different components is given in W (or mW). An ordinary powered USB port can provide up to 2.5W. A portable console should draw much less than that.

Actually, it's optional. A lot of components give the power draw in mA at a specified voltage. This is easily converted into (milli)Watts should you wish to take the power consumption of several components all running at different voltages.

Also, if you measure the power consumption of the GP2X @ 3.3V, it can use up 2.5W (>700mA) quite easily. Even going on the assumption that newer technology will reduce power consumption, the fact that we are more than doubling the clock rate, adding Wifi, 3D Accelerator and other gadgets would suggest its not going to be much less (if at all) than the power available via the USB port.

 

[moxie]

Move to ubuntu and use wine for any programs not on linux wine



Uh...why would you need to "move to ubuntu" for that? :blink:

 

[God Ginrai]

Move to ubuntu and use wine for any programs not on linux wine



Uh...why would you need to "move to ubuntu" for that? :blink:


I think the person to whom he was responding had mentioned that he was hoping that his Windows Emus would play on Linux when he made the move, the linux he was moving to was ubuntu, so that's why he said: "move to ubuntu"

-God Ginrai

 

[hlidegp2x]

Additionally both N64 and GameCube are big endian, whereas presumably this new machine will be little endian and may have to do some more bit juggling to compensate.

Little or big endian, software programmable.


even if programmable, I doubt Linux would accept both at the same time. I hope this OMAP has some instructions to make those conversation cheaper

 

[atomicthumbs]

craigix, we need tidbits

 

[Exophase]

Additionally both N64 and GameCube are big endian, whereas presumably this new machine will be little endian and may have to do some more bit juggling to compensate.

Little or big endian, software programmable.


even if programmable, I doubt Linux would accept both at the same time. I hope this OMAP has some instructions to make those conversation cheaper


Conversions between endian are cheap w/o special instructions. Byteswap the ROM and you only have to XOR the lower bits of byte and halfword accesses.