GamePark 32
Review
At the end of its product cycle, a small but fantastic toy finally gets
reviewed for Alive. Of course I am talking about the GP32, a somehow generic
game console from the Far East.
I was introduced to the GP32 by HAVOC. Actually it happened when I told him,
that I was considering buying a Gameboy Advance. This made him go into
advertising mode for the little wonder from Korea. I thought about it for a
few weeks, and then I finally bought it instead of a GBA :)
To let you get a picture of that little toy, I'll start off with a copy from
the specs:
# 32 Bit RISC CPU (ARM9), up to 133/166MHz
# TFT 3.5" Reflective TFT LCD Display (65,536 colours, 320 X 240 Pixels)
# Smart Media Card Compatible
# USB Port for PC Connection
# 16Bit PCM Stereo Sound, MIDI Support, 4 Channel WAV Mixing
# Powered by 2 AA Batteries (12 Hours Play-Time, NON-LIT)
# DivX, XviD and MP3 Compatible
Additional Information:
You have the option of 133 or 166MHz from the flexible CPU. The CPU's
standard clock is 133MHz, but it can be changed via software(!), from as low
as 22MHz up to something above 220MHz, but most units just about run stable
at 156MHz. With a little bit of work you can apply the "Volt-Mod", which is
as simple as replacing two resistors, and then you get it to run stable at
166MHz or maybe even more. But you also need to know that the main bus is
clocked at 66MHz, so the speedup of the actual programs you run gets more
non-proportional to the clock.
"NON-LIT" should be read as "Neither back nor front light". The first units
were produced with a reflective display. Therefore you only could use it in
well-lit environments. Later on they produced units with front light, the
Front Lit Units (FLU). I never saw one of those but they are said to show
washed-out colours. After this came the Back Lit Units (BLU). Those are the
ones to get! IF you can get one, because GamePark stopped using the displays
from Samsung and went for some Taiwanese LCD. This display was not 100%
compatible, therefore those units are know as (BLU+). But most programs are
patched or recompiled by now so you should not have the same problems the
early adopters had at the beginning with these screens.
I talked about the CPU, but in the end it is mainly a system on a chip, the
chip in question being the SC3243000 from Samsung. It has everything.
Starting with the arm 9 2 0TDMI core, SMC/MMC controller, LCD Controller,
16Bit DACs for sound and even a real time clock, which could be battery
backed, but GamePark misses on that. If they hadn't have done that, then
apps like a calendar and timer or stopwatch would have been possible.
What makes the GP32 really special is the fact that GamePark decided to
make their SDK available for everybody. Rumours say that it wasn't done
intentionally, but it seemed hopeless to make money with games for the GP32.
Since the SDK is freely available a lot of GP32 owners are also taking the
opportunity to code on it.
CODING DA THING
===============
As most others I didn't buy the gp32 for gaming only. I wanted to try some
ARM assembler on it! So let's have a look at how and what to code.
How to code?
------------
Coding on an Atari is quite straightforward. Launch DevPac and go ahead and
hack. But on a hand-held device (or game console), it's a bit different (and
also more comfortable in some ways). You code with your favourite editor on
Windows, Linux, or MacOS X, then compile it with gcc (if you don't want to
spend money) or the ARM Assembler. If you do want to spend some serious cash
it is a superb ARM compiler. I don't have to mention that I am going the gcc
way. There are some tool chains for LiNUX/ UNiX which are available as
Windows packages as well. The gcc 3.4 is said to have some optimizations for
ARM code, but I stick with the gcc 3.2 based tool chain, because I code the
critical stuff in asm anyway and the fastest code has to be generated when a
product is finished, for release that is, which won't happen with any of my
stuff :))
Coding, compiling and assembling is done on the PC but what about testing?
You have three possibilities. First, you can use the emulator GeePee32 which
is really a big help when debugging because of the tracing possibilities. It
runs slowly though. It can be compared with a GP32 running at 44MHz. And it
is for Windows only, although it runs with WINE, but not quite nicely. If
you want to check the speed of your stuff, you have to transfer the object
file to the GP32 and there you have the next two possibilities.
Firstly, put the file on the SMC via a card reader, or use your GP32 as a
card reader via a USB cable.
A more convenient method, but AFAIK only possible with LiNUX, is to execute
it directly on the GP32. Connect your GP32 with the USB cable to the PC, set
your firmware in a special mode and run a little tool on the (LiNUX) PC. I
don't have to mention that you can use it with MAKE.
Technical aspects
-----------------
If you expect lots of hardware support like the GBA has, such as sprites,
tile modes, or alpha-blending, you are looking in the wrong place. It's more
like the situation on the Falcon :)
You have memory, just a CPU and memory. The good thing is, that the frame
buffers are in the normal RAM, there is no slow chip RAM. The LCD controller
can do some tricks but the only one which is worth mentioning is the virtual
screen. You can tell the controller: "Let the screen be 480x400." but of
course just 320x240 pixels are shown at once. But this is no major drawback,
because the CPU is so fast :) I managed to code a tiling engine which could
do 170 fps. Let's say we want three layers and sprites, then we are running
at approximately 60 fps. OK, now if you want to add some transparency
effects as well, then it may get critical.
I never did anything with the sound, but it is said in the specs you have
some 16 bit DMA channels. Furthermore, there are MOD players with up to 8
channels available which you can use.
The actual processor is really great. It has some advantages over the
68000. The strangest feature, compared to 68k, are shift/ Rotate for free (0
cycles) and conditional execution of almost all instructions. The 68k set
has just the branch instruction executed conditionally. Ah and YOU are the
one to tell the CPU to update the condition codes. An example:
1 mov r0, #23 ; put #23 into reg. 0
2 subs r1, r0, #23 ; sub #23 from reg. 0. Result goes into reg. 1
; and set CC bits
3 add r4, r5, r1, lsr #2 ; add (r1 * 4) to r4 and result to r4
4 moveq r4, #128 ; IFF the sub produces a result of 0 then
; move #128 to r4. The "eq" is for equal
; condition. Not move-quick.
Closer look at line 3:
ARM (1 cycle):
add r4, r5, r1, lsr #2
MC68060 ( at least 2 cycles [ cause of superscalar pipeline]):
move d5, d4
lsr #2, d1 ; d1 gets destroyed
add d1, d4
If you need the contents of d1 later on you have to add at least one
"superscalar" cycle.
BUT, I won't go into details here. There will be another article coming up
for that topic. I just wanted to show you an example of some interesting
features of the ARM9 to tease you a bit. Ahh and it has Multiply-add as well
:) To keep the m68k lovers happy: ARM has no DIV instruction :)
SOFTWARE FOR THE GP32
=====================
What kind of software can you get for the GP32 you may ask. "Games!" you
might think. Well there are some commercial games of course, but it's
obvious that you do not get a big list of titles like there is for the GBA.
I think there are something like 20 or 30 mostly Korean games you can buy
for a budget price, something like 5-15 EUR. You can download those games
and put them on a SMC or purchase a (16Mb) SMC, but that is of course more
expensive.
Next we have the homebrew games, which are, TBH, not comparable to any
commercial games, but I must say I did not try them that much, because of
the 3rd kind of apps you can use on your GP32 ... eeeeEMMMMmmmuuuuUlatorz!
First a downer, GBA emulation is not possible, although some french dudes
have shown great promise with GPAdv. I want to mention it because they
exploit the fact that the GBA's CPU, the ARM7 core is almost identical
(opcode wise) to the ARM9. They do not have to emulate the CPU which leaves
more time for the hardware emulation. They managed this quite well. I played
three commercial GBA games on my GP32, but they were a bit slow. Another
problem was that some GBA roms are 32MBit. The GP32 has just 8MB RAM, so
they have to "load-on-demand".
Useful ones ( and used by myself) are:
- NES
- MegaDrive ( Genesis)
- Atari ST
- Atari800
- C64
- SNES ( some gfx features are missing, but for the great RPGs its good)
- MAME ( the older arcade machines. Green Beret works well f.e.)
I leave out those other old machines I never tried, but you can see the
SNES emulation as the upper limit of what is possible. And NO, there's no
AMIGA :)
As a side note: Everybody is waiting for "f-day". That's the day, when a
certain developer will release 13 emulators in one go. Those emus have a
great standard, as under the 13 are things like NES, MSX and GBC.
BUT, a big problem is that most dudes just code C/ C++, or port some
emulators written in C/C++, which is of course not optimal. Take the
MegaDrive. DrMD2.0 uses a 68000 core written in ARM9 asm and it is *almost*
full speed at 144MHz.
COMMUNITY
=========
There is an Internet forum ( http://www.gp32x.com ) where most of the
international discussions and gossip about the GP32 is going on. The GP32
seems also widespread in Spain and they have their own community, but of
course some of the Spanish dudes are on gp32x.com as well. Demos aren't too
popular on the GP32, or should I say: "Don't exist at all."?
CONCLUSION
==========
The GP32 could be considered a very useful retro-gaming console, able to
support games up to (and partly including) the SNES. And of course most
Atari ST games and demos will play on here. But don't expect the newest
productions to work, well at least the sound on some of these is not so
great.
Creature for Alive, 2005-11-16
|
