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.
Goobers said:
I think that if it has USB or serial in, it would be pretty easy to add support for these devices- SparkFun electronics has some nice 3 axis accelerometer boards, and my arduino has a serial to USB chip on it- if i can get the drivers to work on arm linux, it should be no problem at all to work something like that into it. I'm well up for having a go when the device comes out. I think that it's strength will lie in the things that you can add.

I'd like to think there could be a usb connection that sits below (or somewhere) on the unit so that usb peripherals don't stick out at angles..
The resolution increase makes me think about atari midi software control (ie usb to midi) device - if only I could get notator or pro24 to go without requiring their dongles :(
Another interface mentioned is mic input, good for (say) guitar effects software, voice recognition, ...

EDIT; speeplinks
 
Last edited by a moderator:
Dzz said:
Just speculation, but I'd expect that we'll see separate memory banks for the two main processors, but no dedicated bank for the "GPU" -- I am not sure that's even possible.
...
Yes I read that too, the memory of 926 core is shared with GPU, but like you have already write for homebrew we can use 400*240 resolution and keep high resolution for apps like (browser, launcher, frontend, sound player, picture viewer ...) which need generaly less cpu power than game ;)
 
Last edited by a moderator:
Exophase said:
cappuchok said:
And zodttd has already indicated PSX is also running fullspeed with sound as well.

No he hasn't.

Alright, I might have misunderstood him, then. In the "old" thread, he did mention this while discussing the capacity of the new machine:
zodttd said:
PS1's Strikers 1945, yes. Excuse me while I play Oddworld with sound and no interlacing.
I did take that as a not so subtle hint he was already adapting his PSX emu to the new platform and had had some success doing so, but if I misunderstood, I stand corrected.
 
Last edited by a moderator:
What might be a problem with voluntarily using a lower resolution, however, is that there would be about half of the screen real estate wasted. Unlike an analog display you can't specify a custom resolution and have the display adapt to fill all empty space with it, you'd need to have the 400x240 area and then blank space all around it. Unless, the image could be blown up to full size (albeit with some potential loss of quality) after the fact, thus still sparing memory bandwidth.
 
QUOTE
I too like it. Just a sidenote though that since with a true 2D GPU, there would be no need to implement transparency in software, rather in hardware, so it wouldn't cost CPU time and properly implemented, work without slowing down emulation one iota.


Someone obviously hasn't written a SNES emulator :D

QUOTE
There are quite a few sources- pricing of i.MX31 parts for example, was roughly $25 when purchased in a quantity appropriate for a device like the GP2X


and the prices of the Magiceyes part were approximately? I've no idea myself, so if you could give a clue between the two price points rather than "a very small increase" it would be interesting.

QUOTE
this was per correspondence I was provided during talks with GamePark regarding development of the XGP series


I wonder if development of the XGP ceased because key members of the project killed themselves after your constant reiteration of most important points? ;)
 
cappuchok said:
Exophase said:
cappuchok said:
And zodttd has already indicated PSX is also running fullspeed with sound as well.

No he hasn't.

Alright, I might have misunderstood him, then. In the "old" thread, he did mention this while discussing the capacity of the new machine:
zodttd said:
PS1's Strikers 1945, yes. Excuse me while I play Oddworld with sound and no interlacing.
I did take that as a not so subtle hint he was already adapting his PSX emu to the new platform and had had some success doing so, but if I misunderstood, I stand corrected.

He meant on the GP2X- oddworld is already fullspeed
 
Last edited by a moderator:
maybe i misunderstood one of the postings, but my impression was, that the magicEyes SoCs are the only ones that are affordable in small quantities. and for an independent project, you cant just buy 20.000 units in hope you can sell all these 20.000 handhelds.
 
JyCet said:
Yes I read that too, the memory of 926 core is shared with GPU, but like you have already write for homebrew
and for that you get a big fat red 'X' and zero points :)

QUOTE
Unless, the image could be blown up to full size (albeit with some potential loss of quality) after the fact


Of course it can! Do you think we are still in the 90's or something? ;)
 
Last edited by a moderator:
KeyboardCowboy said:
What might be a problem with voluntarily using a lower resolution, however, is that there would be about half of the screen real estate wasted. Unlike an analog display you can't specify a custom resolution and have the display adapt to fill all empty space with it, you'd need to have the 400x240 area and then blank space all around it. Unless, the image could be blown up to full size (albeit with some potential loss of quality) after the fact, thus still sparing memory bandwidth.
The screen is 800x480. Any 2d acceleration worth its salt should be able to scale a 400x240 image to fullscreen for little to no cost. There wouldn't be any loss of visual quality, either, because a 4.3" 800x480 screen has very small pixels, and the doubled pixels are probably about the same size as a single pixel on the Gp2X's screen.
 
Last edited by a moderator:
Goobers said:
cappuchok said:
zodttd said:
PS1's Strikers 1945, yes. Excuse me while I play Oddworld with sound and no interlacing.
I did take that as a not so subtle hint he was already adapting his PSX emu to the new platform and had had some success doing so, but if I misunderstood, I stand corrected.

He meant on the GP2X- oddworld is already fullspeed

*ducks away in shame* :blush:

Oh, wasn't aware of that particular fact. My GP2X mostly runs homebrew games and Genesis, hadn't really looked at PSX emulation apart from the Final Fantasy games yet... :lol:
 
Last edited by a moderator:
@Alex.: The issue though is that if you're using the 2D acceleration to blow up the image, the 2D hardware must still transfer it across the bus to the framebuffer in memory and then it must make its way to the LCD controller and be physically drawn to the display. If you're using a lower resolution to reduce bandwidth utilization and bus contention between CPUs and RAM, you wouldn't put much of a dent in it that way.

I was referring instead to using the LCD controller, which would be one of the last steps in the chain of putting an image on the screen, to blow up the image to the full size of the LCD, as the scaler block in the MMSP2 did. This is after communication between CPU/2D/3D blocks and RAM and therefore would not have a negative impact on bandwidth use/bus contention. A look through the MMSP2+ public docs show this does appear to be supported, but it's hard to make a call either way. Since it was present in MMSP2, it is probably present in MMSP2+, but it's best not to assume.

Of course, hopefully the scaler unit in the MMSP2+ wouldn't use as much power as the one in the MMSP2 did, as it would have a highly adverse effect on battery life otherwise, potentially a very dramatic one at that.

@Squidge: My proposition regarding acceleration of the SNES' more complex PPU features like transparency are in the hypothetical, but are possible to implement as I am sure you well know. For example, SNES emulators on the Nintendo DS make use of VDP features on that system to accelerate video operations, and make gameplay acceptable even using a rather primitive (compared to the GP2X's 200 MHz+ ARM920T) 67 MHz ARM9. However such a feat would require heavy rewriting of an existing emulator that relied primarily on software rendering techniques. Even rewriting the graphical routines in an emulator like SquidgeSNES in full ARM ASM would be quite a task but provide quite a boost in performance. Easier said than done, I know. It might even be easier to work form the ground up; the end result would probably be more elegant.

Goobers said:
He meant on the GP2X- oddworld is already fullspeed
Pardon the slight tangent, but as long as we are going to be quantifying real-world application performance I feel it is important we set some standards on our terminology. What is the common definition of 'Fullspeed' on this forum exactly? In the literal sense it should be 60 FPS with no frameskip applied. However I've seen numerous interpretations of this, where 100% speed with only 1/3rd of frames displayed could be defined as "Fullspeed".

kanzlr said:
maybe i misunderstood one of the postings, but my impression was, that the magicEyes SoCs are the only ones that are affordable in small quantities. and for an independent project, you cant just buy 20.000 units in hope you can sell all these 20.000 handhelds.
Correspondence from Gamepark indicated a cost of $24 for i.MX31 SoCs in the amounts that would realistically be purchased for a niche handheld like the XGP or GP2X, etc.

QUOTE
I wonder if development of the XGP ceased because key members of the project killed themselves after your constant reiteration of most important points? wink.gif

While I cannot comment on Gamepark's financial situation prior to their shutdown, Gamepark engineers and PR personnel were very receptive to design suggestions including SoC selection, RAM speed/capacity, etc. However disputes between management, who lacked technical savvy (most notably the CEO of the company) and the engineers led to very little progress being made. Engineers would suggest a solid single machine, and the CEO would insist upon incompatible, irrationally designed units with strange feature combinations, like incompatible resolutions, RAM capacities, CPU types, and control schemes, aimed at markets that didn't always even exist (like that for the GP-KiDS). The CEO also had a tendency to become frustrated and take out his anger on his subordinates, literally screaming at them to vent anger. This led to low morale within the company and high employee turnover. I believe all of these factors led to the downfall of the company and dissolving of the XGP project(s).

Last I heard the project was being handed over to another company, who would attempt to launch the XGP KiDS and gauge public reaction to determine if the XGP/XGPmini were worthwhile investments. If I am permitted to do so and if issues develop further, and of course if there is interest, I will provide more information in the future. However for the time being that's neither here nor there so I digress.
 
Last edited by a moderator:
KeyboardCowboy said:
I was referring instead to using the LCD controller, which would be one of the last steps in the chain of putting an image on the screen, to blow up the image to the full size of the LCD, as the scaler block in the MMSP2 did. This is after communication between CPU/2D/3D blocks and RAM and therefore would not have a negative impact on bandwidth use/bus contention. A look through the MMSP2+ public docs show this does appear to be supported, but it's hard to make a call either way. Since it was present in MMSP2, it is probably present in MMSP2+, but it's best not to assume.
When I suggested in the other thread using 400x240 as a resolution for high-update-rate action type games I was assuming the LCD controller could do this simple pixel-doubling type of scaling to help free up the memory bus for other work. I don't have specific information about it though.
 
Last edited by a moderator:
I see all of you guys point in one way or another. At this time I'm thinking about how easy it will be to access and tweak each component and power consumption management once they put all the pieces together. I know wifi components (at least from other hardware devices) have gone down in manufatcuring cost, as more different devices use them, however the whole damend for parts may bring the prices back up or at least push it towards the enduser. This is just an unarticulated thought of mine that I will make clear when I stop eating this chicken. :D
 
KeyboardCowboy said:
@Dzz: Reading I've done on the PowerVR MBX core utilized in the ARM reference standard indicates it can be tied to dedicated memory, though this is not strictly necessary.
Ok. I just meant that I doubt that the MMSP2+ has three separate address/data busses coming off the chip in order to provide three external RAM banks. I could be wrong.

Does the MMSP2+ use the MBX (Lite) core?
 
Last edited by a moderator:
Dzz said:
KeyboardCowboy said:
I was referring instead to using the LCD controller, which would be one of the last steps in the chain of putting an image on the screen, to blow up the image to the full size of the LCD, as the scaler block in the MMSP2 did. This is after communication between CPU/2D/3D blocks and RAM and therefore would not have a negative impact on bandwidth use/bus contention. A look through the MMSP2+ public docs show this does appear to be supported, but it's hard to make a call either way. Since it was present in MMSP2, it is probably present in MMSP2+, but it's best not to assume.
When I suggested in the other thread using 400x240 as a resolution for high-update-rate action type games I was assuming the LCD controller could do this simple pixel-doubling type of scaling to help free up the memory bus for other work. I don't have specific information about it though.


I would certainly think/hope so as even the GP2X has hardware scaling of the screen. Doubling is much simpler than doing fractional type stretching too.

Since stuff can be easily re-compiled from the GP2X according to Craig, I wonder if it will automatically go to 2:1 by some kind of flag or something when re-compiled?
 
Last edited by a moderator:
KeyboardCowboy said:
Correspondence from Gamepark indicated a cost of $24 for i.MX31 SoCs in the amounts that would realistically be purchased for a niche handheld like the XGP or GP2X, etc.
Knowing GamePark, they planned at least 100.000 of XGPs because they were sure it will be the new uber-system.
 
Last edited:
KeyboardCowboy said:
Correspondence from Gamepark indicated a cost of $24 for i.MX31 SoCs in the amounts that would realistically be purchased for a niche handheld like the XGP or GP2X, etc.
Thanks for the prices of the i.MX31, so we now have $24 and $25 for that, but still have no prices for the MMSP2+. I assume you have these prices also and just forgot to quote on that part of the post?
 
Last edited by a moderator:
KeyboardCowboy said:
@Squidge: My proposition regarding acceleration of the SNES' more complex PPU features like transparency are in the hypothetical, but are possible to implement as I am sure you well know. For example, SNES emulators on the Nintendo DS make use of VDP features on that system to accelerate video operations, and make gameplay acceptable even using a rather primitive (compared to the GP2X's 200 MHz+ ARM920T) 67 MHz ARM9. However such a feat would require heavy rewriting of an existing emulator that relied primarily on software rendering techniques. Even rewriting the graphical routines in an emulator like SquidgeSNES in full ARM ASM would be quite a task but provide quite a boost in performance. Easier said than done, I know. It might even be easier to work form the ground up; the end result would probably be more elegant.
SNES emulation on Nintendo DS is done at a compatibility hit because the 2D hardware of the DS just can't match the SNES exactly. Even then it's a much closer fit than standard 3D acceleration.

Accurate SNES emulation must be capable of rendering on a scanline basis. So you can't just blit a bunch of 8x8 blocks. I only see two ways around this. One is to blit 8x1 blocks, which are most likely not worth it because you have to set up too much in CPU for each tile (unless your GPU is capable of running shaders that can decode tilemaps). The other is to preprocess the maps to 2D bitmaps and composite them in hardware with full length strips (256x1). The problem with this approach is that it requires extensive tracking and caching management - if one tile of the background changes then you'll probably have to update at least significant portions of the background. The other problem is that it's a lot less cache friendly.

Then you have to consider that SNES supports subtractive blending, which may not be a feature of the 3D acceleration used. And if it's anything like GBA it'll have blending conditions, which would at least need sophisticated blend tests to handle, much more than what OpenGL offers.
 
Last edited by a moderator:
KeyboardCowboy said:
Pardon the slight tangent, but as long as we are going to be quantifying real-world application performance I feel it is important we set some standards on our terminology. What is the common definition of 'Fullspeed' on this forum exactly? In the literal sense it should be 60 FPS with no frameskip applied. However I've seen numerous interpretations of this, where 100% speed with only 1/3rd of frames displayed could be defined as "Fullspeed".
I believe it was running fullspeed if not faster before frameskipping was even implimented in the emulator :)

Could be wrong though.
 
Last edited by a moderator:
KeyboardCowboy said:
this was per correspondence I was provided during talks with GamePark regarding development of the XGP series (before they went bottom up.)
Hehehe. Still denying you're Epicenter?

At least you're trying to "behave" in this thread -- thanks.
 
Last edited by a moderator:
Status
Not open for further replies.
Back
Top