Next Generation Pandora

[Exophase]

jb0yx, not meaning to offend you in any way, but there's hardly anything radical about putting an x86 in a handheld - people have been trying to do this for eons, long before the masters of the x86 domain, intel, decided power efficiency mattered, and even longer before atom was as much as a figment of somebody's imagination. now, the reason you have not been hearing much about those attempts is that none of them has been particularly successful. and even today, with the oh-so-amazing atom at hand, the most this tech can achieve is netbook-size. that's it. so, to put this into perspective: one of the most advanced lithography techs in the world - intel's - is not sufficient to put their most power-efficient x86 designs on the handheld map. it's like the world's most renowned vendor of steam engines is trying to make those suitable for cessnas - why? why do you want to see a steam engine on a cessna, when there are so much better ways to power a cessna! - so you could use all that coal you have lying around? - come on.

Eh? There are x86 devices that are much smaller than netbooks and there have been for years. Things that are Pandora sized. Or are you saying that the battery life on them is too low to be considered?

 

[darkblu]

Eh? There are x86 devices that are much smaller than netbooks and there have been for years. Things that are Pandora sized. Or are you saying that the battery life on them is too low to be considered?

*re-reads own post*

ok, i see how you read it the way you did, but yes, of course by success i meant commercial success. otherwise plenty of them reached market, and some even had major backing.

*still has the sdk from nokia's 9k communicator lying around*

 

[SNESFAN]

jb0yx, not meaning to offend you in any way, but there's hardly anything radical about putting an x86 in a handheld - people have been trying to do this for eons, long before the masters of the x86 domain, intel, decided power efficiency mattered, and even longer before atom was as much as a figment of somebody's imagination. now, the reason you have not been hearing much about those attempts is that none of them has been particularly successful. and even today, with the oh-so-amazing atom at hand, the most this tech can achieve is netbook-size. that's it. so, to put this into perspective: one of the most advanced lithography techs in the world - intel's - is not sufficient to put their most power-efficient x86 designs on the handheld map. it's like the world's most renowned vendor of steam engines is trying to make those suitable for cessnas - why? why do you want to see a steam engine on a cessna, when there are so much better ways to power a cessna! - so you could use all that coal you have lying around? - come on.

No offence taken at all, did you read the rest of my posts on page 6-this one? While not a total success there are plenty of handheld x86 MID's (sub UMPC/netbook size) floating around I just found what appeared to me was the best to make an example of. Sony's UX series would have been an somewhat poor example but still an example of a successful handheld UMPC that is smaller than a netbook. I personally tried one of these for about a month and it was complete garbage for gaming as it lacked gaming controls, if it had what the pandora had I'd be using that right now instead of returning it like I did.

The reason I said this was radical thinking is because it's against the normal thinking round here "if you go handheld, you go ARM proc" I do keep up on my underground gadgetry (probably more than most) and there are quite a few examples of roughly 4.3 inch sized x86 based pocketables, mainly the ones from this site http://www.dynamism.com I could dig you up a bunch of examples if you wanted but the key feature I'm looking for is missing, the controller. Mainly the dpad & analog nubs are what these are missing.

While not officialy out on the market yet, the next gen atom procs and chipset that I mentioned that are being rushed to the market almost a year before the previously projected CES 2010 should be hitting the market sometime this fall to target the area that is ever increasingly controlled ARM proc currently holds, the handheld device. Taking the specs of the most thermal and power efficient atom proc and cutting the power and heat produced in half.

I just seen what I think is the first example of these http://www.engadget.com/2009/09/19/video-via-epia-p720-pico-itx-motherboard-plays-1080p-doesnt-s/ Not too much info is given on chipset but it is fanless and damn small

So my thinking might not be so "never thought of before" but it's definitely the unpopular one around here, thusly I branded it as radical.

 

[ldesnogu]

The VX855 on that board consumes 2.3W by itself, which is more than a full BeagleBoard

As far as Intel goes, they have everything to prove in the low power segment. I simply don't trust marketing, wherever it comes from, be it ARM or Intel. So we'll see! OTOH I have no doubt that Intel can succeed in doing really low power, but again they'll make sure such a chip won't cannibalize the segment just above, and so you'll get severe HW restrictions such as screen rez.

 

[Monk]

Ah. Innovative use of the term "radical". I suspect a few of us are aware of x86 "System on a Chip" products going back decades... "make it lighter, smaller, more powerful" has been a basic goal for "System On A Chip" for embedding a PC of sorts into the smallest possible package since...well, I remember 286 CPU level SOCs.

At present ARM seem to have the advantage over x86 when it comes to capability vs battery drain, and this seems likely to continue for a number of reasons - but don't mistake that as meaning everyone here is married to ARM architecture for life. Personally I'm interested in whatever will do the job for me best, at a reasonable price. Neither ARM nor even Linux are the primary considerations when it comes to Pandora fitting the bill.

 

[MDave]

Intel is certainly improving their Atom + chipset power usage though, and at quite a speedy rate too considering. Their next line of Atom's certainly seem to show it. But how much further can they go?

 

[jabz]

Instead of the Next Gen Pandora so soon, how about an upgrade? i.e. in a years time produce a PCB board that has upgraded ARM, Memory and GPU if possible and make that available for purchase for install to replace the current PCB. I imagine everything else on the Pandora is perfect you wouldn't to change the controls etc.

 

[JayFoxRox]

If the pandora team starts to think about making different hardware versions or upgrades I would think about cancelling my order.
I already dislike the idea of the L2 and R2 solder pads and would like to have a much more recommenditions and restrictions for use of librarys.

Giving too many options will make even simple applications hard to maintain for developers and it will split the community.

Just replacing the whole pcb is porbably as expensive as selling new Pandoras. And think about the number of problems experienced users will have. The pandora was not designed with this in mind and I think its a stupid idea to be honest.

 

[SNESFAN]

If the pandora team starts to think about making different hardware versions or upgrades I would think about cancelling my order.

I'm sorry this made me laugh a bunch, nothing pointed at you directly, just with hearing all the people complaining and threatening to cancel their orders. So OP team got that? Don't even think about it.

Oh... and if you don't get me a big mac with cheese and a coke, I'll cancel my order! I'll do it... I swear!

EDIT: Ya know I didn't even get past that line before I posted I was chuckling too much. Now that I have... I actually stopped laughing. Are you serious with not wanting L2 & R2 buttons?? I mean... adding more buttons wouldn't make your games not work? It's like just maping, having a numberpad on a keyboard doesn't make a program that doesn't use it not work?

EDIT: removed comments you were talking to someone else

 

[JayFoxRox]

It wasn't meant as a threat
Its just my personal opinion. Its completly fine if they decide that, but it wouldn't make the pandora that suitable for me anymore.

 

[christo930]

I was joking about the next gen Pandora (as I said in the other post that got brought into this one), but was just speaking of what I think would be an awesome machine. I have been able to run straight dos on my old 2.66P4 complete with sb support (of course, it was a real sb).

Naturally any machine made today (or in the last nearly 10 years...) isn't going to be using a soundblaster compatible audio chip. I'm surprised you even found a PCI one, but nevertheless.

While many dos games do require emm386.exe (to move drivers into the UMA) to be in the config.sys file, most of them don't need expanded memory, just extended(LIM EMS was rarely used). And there is always running dos games under windows 98 if need be. As for emulators, I was talking about older ones not N64 or PSX. But alas, it's just a pipe dream.

I don't really know what you're getting at here, emm386 isn't used to load things in the high 384KB of the virtual mode address space, it's for EMS which is definitely used at least as much as XMS was because starting with 386 CPUs it could be done using the MMU. emm386 relies on having a 64KB window in upper memory space which is impossible if there are devices mapping I/O at those spaces. It'll outright fail. I know because I used to maintain a piece of software (MegaZeux) that for a long time was 16bit DOS only and I got to watch fewer and fewer people be capable of using it because of problems like this.

You are 100% wrong. EMM386.exe with the noems switch can map memory into the UMA and loadhigh and devicehigh are used to install tsr's and device drivers into the uma. Why do you thing Dos=high,umb is found in the config.sys file? Very, very few games used ems largely because it wasn't needed with the 286 and the PC and PCXT don't have much in the way of graphics and didn't attract too many games. There are exceptions to the rule, but mostly old dos games used xms. Usually the F segment and a, b and c segments are taken up by the bios, video memory and video bios respectively. Because of the ability to begin a segment every 16 bytes, it is possible to start a segment 15 bytes before the end of conventional memory and that creates the high in dos=high and portions of dos are loaded above the 1mb limit. Of course, command.com could be dumped from memory when starting a program so that helped free up some conventional memory as well. As long as devices aren't in the first 10 segments, dos can work fine.

Chris

EDIT: My mobo has an isa slot. I never, ever buy mobo with don't have an isa slot. I still use an ISA SB64, although with modern games the bus can really slow down with so much audio data being pumped across a 16 bit isa slot which if my memory serves me correct is only 12mhz.

 

[Exophase]

You are 100% wrong. EMM386.exe with the noems switch can map memory into the UMA and loadhigh and devicehigh are used to install tsr's and device drivers into the uma. Why do you thing Dos=high,umb is found in the config.sys file? Very, very few games used ems largely because it wasn't needed with the 286 and the PC and PCXT don't have much in the way of graphics and didn't attract too many games. There are exceptions to the rule, but mostly old dos games used xms. Usually the F segment and a, b and c segments are taken up by the bios, video memory and video bios respectively. Because of the ability to begin a segment every 16 bytes, it is possible to start a segment 15 bytes before the end of conventional memory and that creates the high in dos=high and portions of dos are loaded above the 1mb limit. Of course, command.com could be dumped from memory when starting a program so that helped free up some conventional memory as well. As long as devices aren't in the first 10 segments, dos can work fine.

Chris

EDIT: My mobo has an isa slot. I never, ever buy mobo with don't have an isa slot. I still use an ISA SB64, although with modern games the bus can really slow down with so much audio data being pumped across a 16 bit isa slot which if my memory serves me correct is only 12mhz.

Very, very few games used EMS? Are you sure about that? You do realize that games were still being made for DOS that were meant for 386+ but still used 16bit mode, right? You know, something about DOS games that were made after the PC and PCXT era but were still using 16bit tools. If all you care about are games that required that kind of hardware then this whole discussion becomes ridiculous because you can just use DOSBox to attain those levels. Now, for the games that WOULD be interesting to run natively on x86 hardware, a lot do require EMS.

If the target machine has a 386+ then using XMS over EMS is a bad idea because XMS API was made for 286 in mind. Meaning that in order for a game to use it the manager must switch into 286 protected mode, copy the memory in from beyond the extra memory space, then switch back to real mode. On 386, on the other hand, EMM386 runs legacy programs in virtual mode and only has to use the MMU to remap things. Sure, prior to 386 XMS made sense since EMS required external hardware, but afterwards? It's not like all games jumped to using protected mode immediately. The migration was, in fact, quite slow.

But, you know, if you're only talking about really old games that a Pandora could easily emulate in DOSBox then yeah, I guess I'm "100% wrong."

 

[christo930]

You are 100% wrong. EMM386.exe with the noems switch can map memory into the UMA and loadhigh and devicehigh are used to install tsr's and device drivers into the uma. Why do you thing Dos=high,umb is found in the config.sys file? Very, very few games used ems largely because it wasn't needed with the 286 and the PC and PCXT don't have much in the way of graphics and didn't attract too many games. There are exceptions to the rule, but mostly old dos games used xms. Usually the F segment and a, b and c segments are taken up by the bios, video memory and video bios respectively. Because of the ability to begin a segment every 16 bytes, it is possible to start a segment 15 bytes before the end of conventional memory and that creates the high in dos=high and portions of dos are loaded above the 1mb limit. Of course, command.com could be dumped from memory when starting a program so that helped free up some conventional memory as well. As long as devices aren't in the first 10 segments, dos can work fine.

Chris

EDIT: My mobo has an isa slot. I never, ever buy mobo with don't have an isa slot. I still use an ISA SB64, although with modern games the bus can really slow down with so much audio data being pumped across a 16 bit isa slot which if my memory serves me correct is only 12mhz.

Very, very few games used EMS? Are you sure about that? You do realize that games were still being made for DOS that were meant for 386+ but still used 16bit mode, right? You know, something about DOS games that were made after the PC and PCXT era but were still using 16bit tools. If all you care about are games that required that kind of hardware then this whole discussion becomes ridiculous because you can just use DOSBox to attain those levels. Now, for the games that WOULD be interesting to run natively on x86 hardware, a lot do require EMS.

If the target machine has a 386+ then using XMS over EMS is a bad idea because XMS API was made for 286 in mind. Meaning that in order for a game to use it the manager must switch into 286 protected mode, copy the memory in from beyond the extra memory space, then switch back to real mode. On 386, on the other hand, EMM386 runs legacy programs in virtual mode and only has to use the MMU to remap things. Sure, prior to 386 XMS made sense since EMS required external hardware, but afterwards? It's not like all games jumped to using protected mode immediately. The migration was, in fact, quite slow.

But, you know, if you're only talking about really old games that a Pandora could easily emulate in DOSBox then yeah, I guess I'm "100% wrong."

When I said you were 100% wrong (and I didn't mean it a smart-alec way), I meant that emm386 was capable of mapping memory into the UMA because you said it was only used to simulate the page frame and ems. It's kind of funny, 99% of the people here probably have no idea what we are talking about because it's so old. I got my first IMB compatible PC in 1993, an old (even then) compaq luggable and later that year I upgraded to a 286 and by then there were nearly no games that used ems. That I can recall, there really weren't many games that used ems. The biggest use of ems was 123 (lotus-Intel-Microsoft, lim-ems) and I don't remember if WP could use it. There were some games early on that used it, but the overwhelming majority didn't use ems. In fact, many games stayed under 640k altogether. Later in 94 dpmi dos extender was released and games ran in 32bit mode with full access to (16MB, I believe). Most games that were targeting a 386 level machine used the dos 32 bit extender. Some, like zone 66, took full control of the hardware and needed to boot you pc without himem.sys or emm386.exe, but if an early dos game needed a great deal of memory, it would be better to get it through ems but very few early games really needed more than 640k. The big problem with most old games is not ems or xms, but getting the largest executable program size over 600k and that is why MS eventually included memmaker (althoug I could do a much better job by hand). I'd like to see at least 486-66 level performance in a dos environment, preferably with at least VLB level video performance. I know on my 700mhz powerpc, I don't get even 286-12 performance with dosbox. Someone mentioned a dos emulator that uses virtualzation that is much faster (on x86 hardware) than dosbox, do you know the name of that software?

Chirs

 

[Tom`]

Someone mentioned a dos emulator that uses virtualzation that is much faster (on x86 hardware) than dosbox, do you know the name of that software?

I only followed a small percentage of what you guys were talking about, but DOSEMU for Linux might be what you were thinking of. No good for Pandora, of course, since it requires x86, but it works great on x86 Linux.

 

[Exophase]

When I said you were 100% wrong (and I didn't mean it a smart-alec way), I meant that emm386 was capable of mapping memory into the UMA because you said it was only used to simulate the page frame and ems.

I'm not sure what I said that made you think I was contradicting this.

There were some games early on that used it, but the overwhelming majority didn't use ems. In fact, many games stayed under 640k altogether. Later in 94 dpmi dos extender was released and games ran in 32bit mode with full access to (16MB, I believe). Most games that were targeting a 386 level machine used the dos 32 bit extender. Some, like zone 66, took full control of the hardware and needed to boot you pc without himem.sys or emm386.exe, but if an early dos game needed a great deal of memory, it would be better to get it through ems but very few early games really needed more than 640k.

We may be thinking about different sort of games here. The kinds I particularly have in mind are a lot of old shareware games, like the sort you'd get from Epic, Apogee, iD (particularly earlier), or many individuals. The thing is, even after DPMI and other extenders were out the cheaper compilers (Borland C, Turbo C) were 16bit and DOS itself was still 16bit. So doing a full protected mode game was more expensive and took more programming. Sure, big companies could easily manage but a lot of the small shareware groups wouldn't have bothered. I don't know about not needing more than 640K, but even with every allocation trick in the world you would be very hard pressed to get even close to 640KB of available conventional memory.

I understand that you got your PC and even 286 machine when they were pretty damn old. In 1993 most PC users would have been on 32bit x86s and I'm sure many games were comfortable targeting these people, since the difference in what you can do in software between those CPU generations is pretty immense. Then, 32-bit machines would have all this extra memory sitting around which in DOS would just be wasted if not utilized. The are a lot of things extra RAM can do to improve game coding, even if it's only available 64KB at a time.

The big problem with most old games is not ems or xms, but getting the largest executable program size over 600k and that is why MS eventually included memmaker (althoug I could do a much better job by hand). I'd like to see at least 486-66 level performance in a dos environment, preferably with at least VLB level video performance. I know on my 700mhz powerpc, I don't get even 286-12 performance with dosbox. Someone mentioned a dos emulator that uses virtualzation that is much faster (on x86 hardware) than dosbox, do you know the name of that software?

Chirs

DOSEmu would be a good choice for an x86 handheld, but I've always felt that it's kind of a mess. Also, it requires Linux, which would be at ends with the people who want these machines so they can run Windows. Windows has its own DOS emulation, but it has its own problems. Really, there's a reason why DOSBox gained most of its popularity on x86; running DOS games just isn't guaranteed anymore. I stayed on Windows 98 for longer than I should have because of DOS compatibility w/EMS, but if I had the wrong motherboard or didn't have a Sound Blaster compatible then I would have been sunk anyway. Yes, I know back in the day hardware didn't tie up a lot of the high 384KB address space but things have changed now that they pretty much can. Besides, even when it's possible theoretically, configuring this stuff can still be a nightmare.

DOSBox sounds woefully unoptimized for PPC. Probably needs at least a recompiler.

 

[christo930]

When I said you were 100% wrong (and I didn't mean it a smart-alec way), I meant that emm386 was capable of mapping memory into the UMA because you said it was only used to simulate the page frame and ems.

I'm not sure what I said that made you think I was contradicting this.

There were some games early on that used it, but the overwhelming majority didn't use ems. In fact, many games stayed under 640k altogether. Later in 94 dpmi dos extender was released and games ran in 32bit mode with full access to (16MB, I believe). Most games that were targeting a 386 level machine used the dos 32 bit extender. Some, like zone 66, took full control of the hardware and needed to boot you pc without himem.sys or emm386.exe, but if an early dos game needed a great deal of memory, it would be better to get it through ems but very few early games really needed more than 640k.

We may be thinking about different sort of games here. The kinds I particularly have in mind are a lot of old shareware games, like the sort you'd get from Epic, Apogee, iD (particularly earlier), or many individuals. The thing is, even after DPMI and other extenders were out the cheaper compilers (Borland C, Turbo C) were 16bit and DOS itself was still 16bit. So doing a full protected mode game was more expensive and took more programming. Sure, big companies could easily manage but a lot of the small shareware groups wouldn't have bothered. I don't know about not needing more than 640K, but even with every allocation trick in the world you would be very hard pressed to get even close to 640KB of available conventional memory.

I understand that you got your PC and even 286 machine when they were pretty damn old. In 1993 most PC users would have been on 32bit x86s and I'm sure many games were comfortable targeting these people, since the difference in what you can do in software between those CPU generations is pretty immense. Then, 32-bit machines would have all this extra memory sitting around which in DOS would just be wasted if not utilized. The are a lot of things extra RAM can do to improve game coding, even if it's only available 64KB at a time.

The big problem with most old games is not ems or xms, but getting the largest executable program size over 600k and that is why MS eventually included memmaker (althoug I could do a much better job by hand). I'd like to see at least 486-66 level performance in a dos environment, preferably with at least VLB level video performance. I know on my 700mhz powerpc, I don't get even 286-12 performance with dosbox. Someone mentioned a dos emulator that uses virtualzation that is much faster (on x86 hardware) than dosbox, do you know the name of that software?

Chirs

DOSEmu would be a good choice for an x86 handheld, but I've always felt that it's kind of a mess. Also, it requires Linux, which would be at ends with the people who want these machines so they can run Windows. Windows has its own DOS emulation, but it has its own problems. Really, there's a reason why DOSBox gained most of its popularity on x86; running DOS games just isn't guaranteed anymore. I stayed on Windows 98 for longer than I should have because of DOS compatibility w/EMS, but if I had the wrong motherboard or didn't have a Sound Blaster compatible then I would have been sunk anyway. Yes, I know back in the day hardware didn't tie up a lot of the high 384KB address space but things have changed now that they pretty much can. Besides, even when it's possible theoretically, configuring this stuff can still be a nightmare.

DOSBox sounds woefully unoptimized for PPC. Probably needs at least a recompiler.

What made me think you were contradicting that is this statement:

I don't really know what you're getting at here, emm386 isn't used to load things in the high 384KB of the virtual mode address space, it's for EMS which is definitely used at least as much as XMS was because starting with 386 CPUs it could be done using the MMU. emm386 relies on having a 64KB window in upper memory space which is impossible if there are devices mapping I/O at those spaces.

It seem pretty clear that you were saying emm386 was incapable of mapping memory into the uma and I was pointing out that that is what it's most common use was. Networking in windows 3.x was not possible without dos device drives and you need a driver for the card, the protocol and the redirector. So just with networking alone you easily be at 150k of the bottom 640k being used. Add in smartdrv, a (cdrom.sys) and mscdex.exe and you are getting well bellow 500k. There was also a problem in the many tsr's took up more memory than they actually occupied (by running at a large size and then leaving a stub)and that made you have to experiment with the order they are loaded in and some things have to be loaded in the right order.

Chris