Our New Machine, Pandora

Should this thread die?

  • Yes, kill it now!

    Votes: 0 0.0%
  • Maybe move it to off-topic?

    Votes: 0 0.0%
  • No, let it live until its natural death!

    Votes: 0 0.0%

  • Total voters
    0

Status
Not open for further replies.
Alex. said:
Cheap or not, you already have SD cards, so why increase the price of the unit for something redundant? Besides, flash memory has a limited life span, so it's better for a removable component to die rather than a built-in one.
true lifespan is pretty short for flash. how much ram is going to be on it is it 128 right?
 
Last edited by a moderator:
sam fisher said:
realyst said:
I second the power-through-usb thing. It would also help localization, since we all know we all don't all share the same power widgets:)

But a 5V USB current is the same in London as in Halifax:)
Its not the current that matters, not in the slightest. It's the voltage that matters. But never mind that, USB has a far to low current through put to charge this at any acceptable speed.



Pardon my incorrect terminology. However, seeing as my DS charges itself in 2 hours or so at 450mAH and USB through a powered hub can provide 500mAH, wouldn't that mean it would be realistic to see this thing charged within 4 hours via USB power alone? Or do we even know the power draw this device would have(and as such the type of battery needed to keep it aloft for a number of hours).

And why wouldn't it be possible for both to occur, a standard round-hole DC jack and a power-ready USB jack in case you want to sync this thing without draining the battery life?
 
Last edited by a moderator:
USB charging is a good starting point. Atleast if I buy the craiginator, I can charge my unit before I buy an adaptor.

We can't really expect Craig and Co. to support all power standards. Certainly I'm not expecting Australia to be supported from day one, and I'm not prepared to wait until an Australian store distributes it with an Australian transformer.
 
Squidge said:
Stealth Bagel said:
That brings me to another thing; on the gp2x you needed to edit text files and make configs, and use the right text editor as to insert the right kind of line breaks, and it was the biggest pain in the ass. Even the best
That's upto each and every developer to implement themselves, it's not really something for the console itself. Your going to get that everywhere - if the developer is happy editing text files and configs, they are likely to spend more spend on the emulation code than writing a pretty gui. Later on in the emulators progress, someone else may come along and make a replacement frontend that bypasses the text file, and someone else may decide to package it all up together to make it all seemless.

That's the GP32X community spirit. Don't knock it.


I agree, but there are ways of consolidating configs into one GUI. GConf (the Gnome configuration utility), for example, does a good job of this. Each program has its own configuration file that is "registered" with GConf and is editable through the GConf program. GConf provides one nice GUI to do all your configurations in. A program of this nature would alleviate the need for each developer to make a nice interface for configuration, and would make it easier for the end user to configure the emulators and such. If all the programs used one standard configuration file type, they could also just implement a small library that would read in variables from a specified configuration file (or something like that).

Of course, I'm not saying use GConf, but a similar idea might be a useful thing to implement.
 
Last edited by a moderator:
Vorporeal said:
Squidge said:
Stealth Bagel said:
That brings me to another thing; on the gp2x you needed to edit text files and make configs, and use the right text editor as to insert the right kind of line breaks, and it was the biggest pain in the ass. Even the best
That's upto each and every developer to implement themselves, it's not really something for the console itself. Your going to get that everywhere - if the developer is happy editing text files and configs, they are likely to spend more spend on the emulation code than writing a pretty gui. Later on in the emulators progress, someone else may come along and make a replacement frontend that bypasses the text file, and someone else may decide to package it all up together to make it all seemless.

That's the GP32X community spirit. Don't knock it.


I agree, but there are ways of consolidating configs into one GUI. GConf (the Gnome configuration utility), for example, does a good job of this. Each program has its own configuration file that is "registered" with GConf and is editable through the GConf program. GConf provides one nice GUI to do all your configurations in. A program of this nature would alleviate the need for each developer to make a nice interface for configuration, and would make it easier for the end user to configure the emulators and such. If all the programs used one standard configuration file type, they could also just implement a small library that would read in variables from a specified configuration file (or something like that).

Of course, I'm not saying use GConf, but a similar idea might be a useful thing to implement.


No offense, but I'd have to agree with Squidge there. Developers, like artists, are different creatures. If you tell them they HAVE to do something a specific way they probably won't do it. (especially if they were doing it for free in the first place) If a bunch of devs want to band together and create a config that all of their programs will use, that is their freedom, but I think that trying to force standards on devs will just drive some of them away. Although it is easier to have everything work similarly, it is not that hard to get used to the way each program works, no matter how unique.

-God Ginrai
 
Last edited by a moderator:
God Ginrai said:
No offense, but I'd have to agree with Squidge there. Developers, like artists, are different creatures. If you tell them they HAVE to do something a specific way they probably won't do it. (especially if they were doing it for free in the first place) If a bunch of devs want to band together and create a config that all of their programs will use, that is their freedom, but I think that trying to force standards on devs will just drive some of them away. Although it is easier to have everything work similarly, it is not that hard to get used to the way each program works, no matter how unique.

-God Ginrai
No offense taken.

I know what you mean - I've done my fair share of programming. I wasn't thinking solely from a end-user perspective, but I thought that it might just be easier for a developer to use a simple library that would read and write their configs for them, so that they don't need to write out their own functions and design their own configs. Of course, it wouldn't be a requirement, it could just be a useful tool.
 
Last edited by a moderator:
virual said:
http://www.compulab.co.il/x270em/html/x270-em-datasheet.htm

Take this, Add a shell with some controls and walla :)



no u

Seriously, why even mention this?

Anyway, I wouldn't like a unified configuration program. Maybe have one program that can be called (overlayed?) from inside another program that does the configuration. I don't want to have to quit (or change) from an emulator (or game) to change the config.
 
Last edited by a moderator:
Because of different games/emulators' control/config requirements I think the difficulty of implementing such a system that caters for them all is really being underestimated.

Not to mention that many games are cross-platform or have their own niggles which make using a common config dialog difficult.

What we would end up with would be a handful of apps which use the common config stuff while the rest just do their own thing.

Not to mention that unifying the GUI across apps isn't necessarily a good thing. The PSP does this for error messages and save game screens. It looks awful and never fits with the game's look and feel.
 
trooper said:
The power via usb seems a good idea, But as long as you can turn off charging (via a menu that pops up on the devices screen when you connect it) just like my nokia N73, So that the poor battery is not constantly being charged, Thus killing the battery when i don`t what it to.

Trooper
I think your confusing battery technologies - the battery in Project Bumblebee will enjoy being constantly charged at regular intervals, rather than just when flat.

What we might find however, is that if the running current is high, charging is turned off. The fastest way to charge would be to turn the device off (thus allowing the full 500mA to charge the battery rather than just using "leftovers")
 
Last edited by a moderator:
The menu button should just be a button. The programmer can do what he wants, but because theres a button labeled menu, he'll use it.
 
Squidge said:
I think your confusing battery technologies - the battery in Project Bumblebee will enjoy being constantly charged at regular intervals, rather than just when flat.

What we might find however, is that if the running current is high, charging is turned off. The fastest way to charge would be to turn the device off (thus allowing the full 500mA to charge the battery rather than just using "leftovers")
leftovers if the device uses less than 500mA.

Does that mean if we buy our own 2 masters to 1 slave, we can charge at an amp?
 
Last edited by a moderator:
Assuming the new unit supports usb charging, it would charge at whatever the charging circuit inside the device allowed. I doub't it would need more than 500mA though.
 
Squidge said:
Assuming the new unit supports usb charging, it would charge at whatever the charging circuit inside the device allowed. I doub't it would need more than 500mA though.
I know it can not be really compared and probably totally unrelated, But every windows mobile phone i have owned will not charge via usb (500mA) if the battery is completely flat (ie, the phone won`t even power up), It will only charge via usb if there is some power still left in the battery. The only way to charge from flat is via the original mains charger, Which is rated at 5v @ 2000mA.

Trooper
 
Last edited by a moderator:
Analog pads and screen look awesome... can't wait to see the whole design. Man, if the pads somehow can be used as scroll wheels, that'd be what, six analog axis? Sick. :D

My 2 cents on the buttons discussion: Have an Exit (or Quit) button and a Menu button, and let programmers do what they want with them, but try to establish an early convention that Exit/Quit immediately quits the current program, and Menu brings up the program's menu.
 
My SPV-500 has a 1A 5V PSU. When the phone complains of low battery, it usually uses up about 300mA from the USB port for 5-6 hours before changing to trickle mode. I've never let the battery go flat enough to refuse to switch the phone on.

For the console itself, I've no idea of it's power consumption, but hopefully TI will tell Craig the specifics soon so he can decide if USB charging is feasible (and then tell us his decision :) )
 
Squidge said:
For the console itself, I've no idea of it's power consumption, but hopefully TI will tell Craig the specifics soon so he can decide if USB charging is feasible (and then tell us his decision :) )
So the OMAP is a likely choice as SOC then! Excellent :)
 
Last edited by a moderator:
Idea for a game idea:

Use normal analog sticks to move. Click to do something. Spin to CONTROL TIEM OMG

How does that sound? Using the 4th analog dimension to control the 4th dimension?

:D

Oh, and when Craig releases the design, I'll get a Wiki page up for the Usability/Controls guidelines. :)
 
atomicthumbs said:
Idea for a game idea:

Use normal analog sticks to move. Click to do something. Spin to CONTROL TIEM OMG

How does that sound? Using the 4th analog dimension to control the 4th dimension?

:D

Oh, and when Craig releases the design, I'll get a Wiki page up for the Usability/Controls guidelines. :)
Wasn't he mistaken on the rotation doing anything? it would have been great for spinner games but never mind- midnight resistance/ikari warriors smash tv etc will still work with the dual analog.

I hope I'm wrong
 
Last edited by a moderator:
Squidge said:
Stealth Bagel said:
That brings me to another thing; on the gp2x you needed to edit text files and make configs, and use the right text editor as to insert the right kind of line breaks, and it was the biggest pain in the ass. Even the best
That's upto each and every developer to implement themselves, it's not really something for the console itself. Your going to get that everywhere - if the developer is happy editing text files and configs, they are likely to spend more spend on the emulation code than writing a pretty gui. Later on in the emulators progress, someone else may come along and make a replacement frontend that bypasses the text file, and someone else may decide to package it all up together to make it all seemless.

That's the GP32X community spirit. Don't knock it.


While yes, there are some things that cannot be standardized, there is a couple of things that should be standardized. Take for example, WiFi access. In my opinion Craigix & co. should make a internet module that allows easy access for all programmers of the Craiginator to access the internet for whatever reason. The configuration of that should be in the settings menu on the boot menu. Some features of wifi should include optional automatic connection to an unlocked WiFi if none known is available, and of course complete shutdown for power's sake. This module should then be able to give programmers access to the internet for whatever reason, and make it easier. There are a couple more examples too, like linking to other computers, linking to other Craiginators, etc.
 
Last edited by a moderator:
Status
Not open for further replies.
Back
Top