GP32 Creating A New Game-console. Homebrew Project

[DaveC]

No 16:9. It would be bad for emus as all of those systems were 4:3. If you used 16:9 then you would have to stretch everything to that aspect which would make stuff squashed, bah.

Plus the resolution should be 320 x 240 as most systems emulated fit pretty well at that res. (face it this thing would be used primarily for emus) Go too high and everything would need to be scaled. Scaling doesn't look as good as 1:1. You could do 640 x 480 and then stuff could be pixel doubled when needed. But I still say use a 320 x 240 4:3 screen but BIG like 4"-4.5".

It should also have hardware support for tiling and transparencies for stuff like SNES.

 

[Squidge]

Hardware support for tiling would actually be a bad idea. The Zodiac supports hardware tiling, with tiles being any size between 1x1 and 8192x8192, but no one uses that feature for there emu's simply because it isn't practical when you think about it. Also, since you need to check for collisions between sprites and background, you need to read the entire background anyway, so may as well do it all in software.

What would be nice though would be multiple bitmaps and being able to get the hardware to mix them together for you for the final output. Scrollable support would make it even better, but we know it's not going to happen - graphics processors will cost just too much, and most companies will not even talk to you unless your buying thousands of them.

 

[Digitalrat]

A port which enables vnc-like-programs would be nice. The current usb-port of the gp32 is to slow for jobs like this, or?

 

[mr.mirko]

can someone check if my s3c2440 layout is correct ?

checking chars and numbers:

http://ninja.gp32x.de/s3c2440.png

 

[lek]

can someone check if my s3c2440 layout is correct ?

checking chars and numbers:

http://ninja.gp32x.de/s3c2440.png

​

All the values look correct to me, all letter/number pairs are in the correct order. Also checks out correct against the pin assignment diagram in the datasheet (the image in the datasheet is both a flip and mirror of your layout - although that doesn't matter).

 

[drocon]

being realistic: who will be responsible for making an extensive and massive sdk once the system *is* built, and firmware for the system, not to mention laying out the basic structure of the system (memory layout, pre-boot BIOS/firmware, etc.) easier said than done.

 

[lek]

being realistic: who will be responsible for making an extensive and massive sdk once the system *is* built, and firmware for the system, not to mention laying out the basic structure of the system (memory layout, pre-boot BIOS/firmware, etc.) easier said than done.

​

Mirko's SDK for the GP32 should need very little changing to it for it to work with the new CPU. As mentioned earlier in this thread, the main differences are to do with locations of registers, where/how particular hardware features are accessed, etc. I expect the only changes that need to be made are to do with low-level access, such as using a different LCD or how sound will be output. The bulk of the SDK's higher level code shouldn't need changing. (Correct me if I'm wrong someone )

Also the S3C2440 uses the ARM920T core, same as the S3C2400 used in the GP32. This makes it easy to just change the target CPU for compilation (using GCC for example) and should need only minor changes in code. I expect many homebrew apps made using Mirko's SDK wouldn't need any code changes and would simply need recompiling with a revised SDK.

 

[Vimacs]

i think it would be intresting to have all unused pins of the µc at one connector on the board for later expensions, what do you think mr.mirko?

 

[Seraptin]

yeah i thought of something like that too vimacs... would be really useful since you dont have to solder any mod you want to do to the chip itself.

+ i would be really cheap to do.

but you would need to get all those lines from the cpu and i would probably hard to design that :/

 

[meandu229]

correct me if im wrong but if the sdk is going to be similar for this system does this mean that the current games/apps for the gp will need little re-coding for the new system?

 

[Talyz]

The hardware is very similar to the GP too, only more powerful, so I gues porting apps from the GP32 to the Expedio (Ninja) will be quite easy...

 

[EvilDragon]

If the processor command set is REALLY similar (and I think it is), you could even write some kind of wrapper for the different command sets (and the SMC stuff) making it possible running GP32 software on it.

 

[Fishbong]

But if mr.mirko chooses a display with higher resolution, the GP32 software wouldn´t be fullscreen. Not saying that i woudn´t like a higher resolution (i would, and whoever has used LJZ emulation can approve that stretched and smoothed gfx can look brilliant).
This brings us back to the resolutíon topic. A resolution of 320x240 would be ok for emulators, and there would be no need for stretching, but hey, a highres screen would rock for multimedia and for ports (f.i. Quake).
As mentioned before, stretching can look very good if its smoothed out properly, but i think smoothing may require much cpu- time (unless there´d be a coprocessor for it) so a highres screen has also downsides.

 

[trooper]

But if mr.mirko chooses a display with higher resolution, the GP32 software wouldn´t be fullscreen. Not saying that i woudn´t like a higher resolution (i would, and whoever has used LJZ emulation can approve that stretched and smoothed gfx can look brilliant).
This brings us back to the resolutíon topic. A resolution of 320x240 would be ok for emulators, and there would be no need for stretching, but hey, a highres screen would rock for multimedia and for ports (f.i. Quake).
As mentioned before, stretching can look very good if its smoothed out properly, but i think smoothing may require much cpu- time (unless there´d be a coprocessor for it) so a highres screen has also downsides.

​

Don`t quote me on this, But i`m pretty sure these LCD`s support lower resolusion modes (Such as 320x240), Much in the same way as your LCD monitor (If you have one). So i am pretty sure that the programs will only use the higher resolutions if told to do so or are supported by the program, So won`t need to be stretched to fill the screen and thus won`t need anti aliasing or smoothing. But you will still have the higher resolutions for Quake, Doom, Linux and Amiga emulation etc.

Trooper

 

[lubidog]

Don`t quote me on this,
Trooper

​

 

[JyCet]

Everybody will be happy with this design

 

[Mr_Munk]

Everybody will be happy with this design

Apart from Gamepark

 

[mr.mirko]

i think it would be intresting to have all unused pins of the µc at one connector on the board for later expensions, what do you think mr.mirko?

​

Yes, i keep that in mind....

sound good...

 

[Talyz]

About the sound chip; Have you chosen one yet?
www.analog.com has a lot of chips, but I don't think they're vey cheap...
Anyway, IMO the sound chip shouldn't be too bad (like the GP32's...), as good sound quality really adds another dimension to the games...

P.S. The sound chip of the GP probably isn't at all bad for being made in 2001, but including it in a new console would be quite low...

 

[Charge]

Mr.Mirko,

I was wondering if you had considered basing the machine on an arm11 chip? According to Samsungs roadmap at the bottom of this page:

http://www.samsung.com/Products/Semiconduc...tions/index.htm

There should be an Arm11 based chip at 90nm that runs at 667Mhz out very soon, if not already. Since it is made with a smaller process it shouldn't be as big and wont use as much power. Any thoughts?

ps:

Here is some more info on the Arm11 core:

http://www.arm.com/products/CPUs/families/ARM11Family.html