Our New Machine, Pandora

[A_SN]

Platforms like the GP2X, scare them off when they realise to get decent performance they have to actually interact with the hardware to some extent instead of interfacing through a standardised API. Their wouldn't be many game programmers willing to write a software rasteriser.

That's true, and actually I think I'm one of the very very few ones (am I even not alone?) who has made his own rasteriser and uses it in his games. But anyways, if I made this choice, it's because I'm crazy, and the reason for that is that I'd rather do it all on my own, even when it comes to dealing with registers and stuff, rather than use a library, as SDL on the GP2X benefits from all the known hardware optimisations.

So yes, very few people are into wanting to control absolutely everything that happens in their game algorithmically like me, but I don't think it scares anyone away, because of hardware accelerated SDL and OpenGL ES http://wiki.gp2x.org/wiki/OpenGL_ES

 

[kfuse]

Platforms like the GP2X, scare them off when they realise to get decent performance they have to actually interact with the hardware to some extent instead of interfacing through a standardised API. Their wouldn't be many game programmers willing to write a software rasteriser.

That's true, and actually I think I'm one of the very very few ones (am I even not alone?) who has made his own rasteriser and uses it in his games. But anyways, if I made this choice, it's because I'm crazy, and the reason for that is that I'd rather do it all on my own, even when it comes to dealing with registers and stuff, rather than use a library, as SDL on the GP2X benefits from all the known hardware optimisations.

So yes, very few people are into wanting to control absolutely everything that happens in their game algorithmically like me, but I don't think it scares anyone away, because of hardware accelerated SDL and OpenGL ES http://wiki.gp2x.org/wiki/OpenGL_ES


but still you know...its like do you want to do or what you do you not you know...If you want something done you'll do it even if you end up nearly frying your brain in the process from lack of sleep and overdosage of caffiene and rockstar.

 

[Exophase]

When the OMAP2s were introduced in phones in 2005, they clocked the CPU at most to TI's stated standard of 330 MHz, and a lot of devices actually had them with a clock rate well under that. The corresponding clock rate for the MBX GPU is set at around 55 MHz.

OMAP3430 will probably come in at around 550 MHz for the ARM Cortex as stated, and the SGX GPU might correspond at 110 MHz as these chips are mainly aimed at phones.

That speed would put this new machine's graphics performance at about half of what PowerVR lists on their site since they're considering for 200 MHz.

Of note, however, is that a more recent OMAP2420 device, the Nokia N810, runs the SoC faster with the ARM core at 400 MHz.

How do you know that the clock rate won't be configurable by software like it is on many other handheld devices? For phones it would make sense for the vendor to not allow overclocking them since battery life is at a premium. Anyway, 550MHz isn't really clearly stated anywhere. ARM themselves specify 600MHz to 1GHz, last I checked. This isn't a cell phone, and it isn't even comparable to a tablet device like Nokia N810. TI has listed several applications for their SoCs, with high performance gaming being one of them, so I really don't think they'd be so locked down.

Chances are that the end users will be able to adjust the clock of at least the CPU, if not the GPU as well. Anyway, if OMAP3430 doesn't have highly clocked Cortex-A8 and SGX then what would? Barely anything else uses them..

 

[hlidegp2x]

Edit: The PSP also has both a VFP and FPU.... i guess i took this as an indication that a VFP by its self woudn't suffice.

You're wrong : FPU in PSP is standard MIPS FPU which gcc can naturally generate for float operations. Sony add a non standard VFPU as coprocessor 2 which can help PSP in 3D games a lot. But because it is not standard, the "homebrew" gcc cannot handle it to generate them from C/C++ source. Sony's offcial gcc can handle vfpu and output optimized vectorial float operations from c/c++.

This is not because VFPU by itself wouldn't suffice but because FPU wouldn't suffice for 3D games !!!!

 

[icurafu]

When the OMAP2s were introduced in phones in 2005, they clocked the CPU at most to TI's stated standard of 330 MHz, and a lot of devices actually had them with a clock rate well under that. The corresponding clock rate for the MBX GPU is set at around 55 MHz.

OMAP3430 will probably come in at around 550 MHz for the ARM Cortex as stated, and the SGX GPU might correspond at 110 MHz as these chips are mainly aimed at phones.

That speed would put this new machine's graphics performance at about half of what PowerVR lists on their site since they're considering for 200 MHz.

Of note, however, is that a more recent OMAP2420 device, the Nokia N810, runs the SoC faster with the ARM core at 400 MHz.

The Cortex-A8 can be created on two different processes. (LP) and (GP). All mobile phones use the (LP) process as it focuses on low power leakage on standby. If TI use this process we can expect all units can be clocked to 650MHz at 0.59mW/MHz. (Still very powerful, allowing standby mode like DS)

We know TI does use (GP) as well as there were reports of OMAPs clocked to 1GHz. This process has a lot more leakage on standby, but a user can expect to be able to overclock to 1.1Ghz at 0.49mW/MHz.

So, a 1.1Ghz clock will consume about 539mW. I'm not sure how linear the consumption is once you start underclocking.

Since under load, it is more efficient on the (GP) process, you would not expect the (LP) process to be used unless there was a desire to put the device on standby. (Or maybe, it would be cheaper to use LP as most of TIs OMAPs would be using it.)

http://www.arm.com/products/CPUs/ARM_Cortex-A8.html

In terms of the SGX at 110MHz. I'm sure phones use that, but the chipset is based on Kyro technology which will allow the clock to be underclocked and overclocked very easily. Mobile phones only clock at 110MHz to save power (Sweet spot). The chip is still rated at 200MHz and should only max clock lower if the environment is uses prevents it from clocking at 200MHz.

 

[StealthBagel]

To me, one of ARM architecture's best features is the low power consumption and extensive amount of low-power/standby options. The DS just proves to us how long a unit with an ARM processor can stay in standby (days!) and when you turn it on again, not skip a beat. Return immediately to what you are doing. This should be exploited by the new handheld.

When I turned on my gp2x even w/ FW 2.0.0 and up, the boot time was short compared to the old 40 second boot (closer to 13 in 2.0.0) but that, compounded w/ going thru menus to select the app I wanted-- let's say an emulator.. loading a ROM, then a savestate, getting back to where I was before took a minute or more to return to what I was doing...... and if I wanted to play for a moment or 2, like while I was waiting for a bus, etc.-- I could not just stick it in my pocket. The battery would rapidly die and the buttons would get pressed... etc.

So DS-like standby functionality, the way I see it, is critical in this new handheld. Ideally you would be able to put the machine into a 'deep' sleep state, like hibernating a PC but a little snappier to come out of it, and set the machine down for days at a time. I understand the PSP does this instead of really turning off, and while it does deplete the battery it's extremely slow. Also there would be options like on a PC for Shutdown-- Shut Down/Hibernate/Standby. Just some ideas...

 

[DaveC]

So DS-like standby functionality, the way I see it, is critical in this new handheld. Ideally you would be able to put the machine into a 'deep' sleep state, like hibernating a PC but a little snappier to come out of it, and set the machine down for days at a time. I understand the PSP does this instead of really turning off, and while it does deplete the battery it's extremely slow. Also there would be options like on a PC for Shutdown-- Shut Down/Hibernate/Standby. Just some ideas...

That is fine as long as it includes a true total power off mode too. If you are going to store for a longer period the battery will commit suicide with standby modes. When a Li-ion battery's voltage drops below a certain level it becomes un-rechargeable, and you have to buy a new one. Also those standby modes drain the battery constantly so if you don't use it for awhile and decide to do so you will often be greeted with a low battery. The PSP was like that and that aspect kind of sucked.

 

[MWeston]

When my PSP battery was new, I found that I could leave it in that standby mode for weeks and the battery level didn't change much.

Now that my battery is starting to show its age, I can now agree with you that sleep mode does seem to drag it down quicker than I like. Have you bought a new battery or are you still on the original? That might make a significant difference.

 

[God Ginrai]

So DS-like standby functionality, the way I see it, is critical in this new handheld. Ideally you would be able to put the machine into a 'deep' sleep state, like hibernating a PC but a little snappier to come out of it, and set the machine down for days at a time. I understand the PSP does this instead of really turning off, and while it does deplete the battery it's extremely slow. Also there would be options like on a PC for Shutdown-- Shut Down/Hibernate/Standby. Just some ideas...

That is fine as long as it includes a true total power off mode too. If you are going to store for a longer period the battery will commit suicide with standby modes. When a Li-ion battery's voltage drops below a certain level it becomes un-rechargeable, and you have to buy a new one. Also those standby modes drain the battery constantly so if you don't use it for awhile and decide to do so you will often be greeted with a low battery. The PSP was like that and that aspect kind of sucked.


Yea, I find that I like the DS's standby much better than the PSP's. (Although I don't own a PSP, so I have only had 2nd hand observance of the standby for it)

-God Ginrai

 

[DaveC]

When my PSP battery was new, I found that I could leave it in that standby mode for weeks and the battery level didn't change much.

Now that my battery is starting to show its age, I can now agree with you that sleep mode does seem to drag it down quicker than I like. Have you bought a new battery or are you still on the original? That might make a significant difference.

My PSP has always been like that. It held a charge for about 2 weeks before being drained at least half way not leaving much play time. I suppose I could have always had a dodgy battery from the start. It is OK though as I don't use the PSP much anymore anyway. I play my 360 for 3D stuff and the GP2X is fine for my emu needs.

 

[Exophase]

To me, one of ARM architecture's best features is the low power consumption and extensive amount of low-power/standby options. The DS just proves to us how long a unit with an ARM processor can stay in standby (days!) and when you turn it on again, not skip a beat. Return immediately to what you are doing. This should be exploited by the new handheld.

When I turned on my gp2x even w/ FW 2.0.0 and up, the boot time was short compared to the old 40 second boot (closer to 13 in 2.0.0) but that, compounded w/ going thru menus to select the app I wanted-- let's say an emulator.. loading a ROM, then a savestate, getting back to where I was before took a minute or more to return to what I was doing...... and if I wanted to play for a moment or 2, like while I was waiting for a bus, etc.-- I could not just stick it in my pocket. The battery would rapidly die and the buttons would get pressed... etc.

So DS-like standby functionality, the way I see it, is critical in this new handheld. Ideally you would be able to put the machine into a 'deep' sleep state, like hibernating a PC but a little snappier to come out of it, and set the machine down for days at a time. I understand the PSP does this instead of really turning off, and while it does deplete the battery it's extremely slow. Also there would be options like on a PC for Shutdown-- Shut Down/Hibernate/Standby. Just some ideas...

Maybe there could be a way for it to save state to the memory stick and boot from this. It'd still take a little bit of time (few seconds? Depends what you're running obviously) to save + restore off of memory sticks and it'd use a decent amount of space but it would be persistent and pretty reliable. Not sure if it'd be healthy for the memory sticks though.

 

[Vorporeal]

Maybe there could be a way for it to save state to the memory stick and boot from this. It'd still take a little bit of time (few seconds? Depends what you're running obviously) to save + restore off of memory sticks and it'd use a decent amount of space but it would be persistent and pretty reliable. Not sure if it'd be healthy for the memory sticks though.

I don't see any problems that would arise from writing/reading a 128mb file to/from an SD card every so often... Repeated accessing of small files would probably be a larger issue, and even it doesn't manifest itself much. (How often does your camera's SD card cease to function?)

Don't quote me on any of this, I'm mostly just hypothesizing.

 

[atomicthumbs]

Maybe there could be a way for it to save state to the memory stick and boot from this. It'd still take a little bit of time (few seconds? Depends what you're running obviously) to save + restore off of memory sticks and it'd use a decent amount of space but it would be persistent and pretty reliable. Not sure if it'd be healthy for the memory sticks though.

I don't see any problems that would arise from writing/reading a 128mb file to/from an SD card every so often... Repeated accessing of small files would probably be a larger issue, and even it doesn't manifest itself much. (How often does your camera's SD card cease to function?)

Don't quote me on any of this, I'm mostly just hypothesizing.


Or we could save it in some sort of battery-backed RAM. Hmmm...

EDIT: Happened to see this: http://www.engadget.com/2007/11/01/silicon...age-applicatio/

It's an SSD the size of a postage stamp for integration onto PCBs.

 

[leathco]

Dunno if power system has been confirmed as of yet, but....

I'd LOVE to see a standard, replaceable battery size with a charging system built into it. How would it run on between 4 to 6 rechargeable AA batteries, with a charger built into it so you could charge them with a simple power cord, than change them out as needed if the batteries fail completely, or if you have a spare set to put in.

 

[atomicthumbs]

Dunno if power system has been confirmed as of yet, but....

I'd LOVE to see a standard, replaceable battery size with a charging system built into it. How would it run on between 4 to 6 rechargeable AA batteries, with a charger built into it so you could charge them with a simple power cord, than change them out as needed if the batteries fail completely, or if you have a spare set to put in.

It's going to be a standardized Lithium-Ion battery pack.

Hopefully we'll be able to buy more, and some sort ofexternal charger.

 

[Squidge]

Dunno if power system has been confirmed as of yet, but....

I'd LOVE to see a standard, replaceable battery size with a charging system built into it. How would it run on between 4 to 6 rechargeable AA batteries, with a charger built into it so you could charge them with a simple power cord, than change them out as needed if the batteries fail completely, or if you have a spare set to put in.

Do you know how much 6xAA batteries would weigh ? Not mentioning the bulky format of them. I think 2xAA is about the most before you should move on to a different battery technology (unless the item your putting them into is the size of a A4 ream of paper of course)

 

[TyBO!]

Dunno if power system has been confirmed as of yet, but....

I'd LOVE to see a standard, replaceable battery size with a charging system built into it. How would it run on between 4 to 6 rechargeable AA batteries, with a charger built into it so you could charge them with a simple power cord, than change them out as needed if the batteries fail completely, or if you have a spare set to put in.

Do you know how much 6xAA batteries would weigh ? Not mentioning the bulky format of them. I think 2xAA is about the most before you should move on to a different battery technology (unless the item your putting them into is the size of a A4 ream of paper of course)

For more information on mistakes in handheld design, see Sega Game Gear.

 

[Vilmos]

Dunno if power system has been confirmed as of yet, but....

I'd LOVE to see a standard, replaceable battery size with a charging system built into it. How would it run on between 4 to 6 rechargeable AA batteries, with a charger built into it so you could charge them with a simple power cord, than change them out as needed if the batteries fail completely, or if you have a spare set to put in.

Do you know how much 6xAA batteries would weigh ? Not mentioning the bulky format of them. I think 2xAA is about the most before you should move on to a different battery technology (unless the item your putting them into is the size of a A4 ream of paper of course)


Ahh that brings back fond memories of the Atari Lynx. :lol:

 

[Mr. Ksoft]

6xAA batteries is why I never play my Game Gear. I emulate it on the PC or 2X instead because it's more power efficient =P

So AA's is a BIG no-no.

 

[Squidge]

Ah yes, Game gear and Atari Lynx (didn't the lynx require 3 batteries at each end?). I remember those well.

Also, didn't the lynx eat up those 6 batteries in about 3 hours or so?