Search results

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. The thing I'm burning with curiosity about is the OpenGL ES 1.1 implementation. In the marketing material we are allowed...

Sorry, I got temporarily distracted by the "new console" talk which led me to start reading about and experimenting with OpenGL ES. I have the attention span of a kitten. I'll get back to it soon. The next thing I have to do is build a "track generator" that takes as input a 3-D spline curve...

Thanks for volunteering to port Firefox, Sam! You da man!

I don't quite agree... from what we can gather off the sketchy documentation available, the clock speed is almost double, the memory speed is more than double, there's a nice extra chunk of "cache memory", and Squidge has hinted that the two processors will each get their own dedicated memory...

My arm assembly has gotten rusty... I forgot about conditional execution! This version is only two cycles per pixel slower than the nontransparent blit. Note, this isn't tested. CODE @ r14 = transparent color CMP r7,#0 BLE end SUBS r5,r5,#1 @ while...

Yes, the slow shared memory combined with the small caches is the major performance bottleneck on the gp2x and the reason it is difficult to put the 940T to work effectively in applications that are already pushing the bandwidth limits.

That would not be necessary. It would be more normal to store the sprite in that "other area" normally rather than copying it there when needed. That "other area" is just the upper 32 megs of memory which is not managed by Linux (a software decision). QUOTE Then the blitter would access this...

Something like the code below should work. I am not sure how it would be plugged into SDL (I don't use SDL), in this code I assume the transparent color made it magically into r14 somehow. I would think, though, that the hardware blitter on the gp2x should be able to handle this sort of...

Luckily there are a lot of gp2x devs who are finally used to referring to the MagicEyes databook for the MMSP2. When I first started playing with the gp2x I couldn't make heads or tails out of it, but I learned as time went on and now believe it will not be difficult to get up to speed on the...

That's pretty cool! I'm sure everything has a patent that is at least similar to the idea (as there are hundreds of devices with similar ideas), including the "miniature notebook computer" hinge. Somehow all these devices do manage to get built, often at very low prices for low spec devices...

If you post the code for the ARM_Blit1to2.s, it probably wouldn't be hard to modify.

I think the MMSP2+ (if that's what the new machine is based on) will be a lot of fun to play with. I'm sure you're looking forward to having the muscle under the hood to get your emulator running perfectly!

I'm not KeyboardCowboy (and I agree that fighting about this point is useless). But, in case you actually want to buy some, here's one link: http://www.futurecb.com/Store/ProductDetai...REESCALE1839042

I use Visual Studio to edit the code and invoke makefiles when I do a "build". Manually maintaining the makefiles is not too burdensome in my opinion.

That's certainly true, and no matter what features you decide to prioritize not everybody will even agree that you kept it "simple"! I think if your whole gang uses your prototype parts crudely mounted in the exact form factor you choose and beats their best score on their favorite game in some...

I'd buy that; looks slick.

That is an interesting point. Accessing a 800x480x32 frame buffer 60 times per second to send the data to the LCD uses 100 megabytes per second of memory bandwidth. At 100 mhz memory speed and 16-bit DDR memory, each of the two memory interfaces has a theoretical bandwidth of 400 megabytes per...

I wonder if it would be comfortable to use the gaming controls with the keyboard out, seems like it would be awkward to hold. I suppose "take the keyboard off if you want to play games" is an answer... The DS has the controls on the bottom part (for good reason), but doing that would mean that...

Yup, that's a fantastic bit of modeling there. If DaveC didn't hate wide screens we could maybe convince him to do a version with the actual screen they have said they are using, which will make the whole thing wider.