GP32 An Os For The Gp32


loki666

rtems gp32 bsp maintainer
Joined
Dec 27, 2003
Messages
288
Age
44
Location
Belgium
Website
loki666-gp32.blogspot.com
okay, in an attemps to build an multithread lib for the GP32, i faced the cruel fact that a real OS is needed to handle the dispatcher and signal events...

so here is why i post:
i seriously consider porting an RTOS for the GP32, i know there is linux project which want to reach the same goal but linux seems to me a bit too complex for a 'simple' gp32.
while my long inet searches i found an open RTOS (RTEMS) which should fit to the GP32, there is some arm support. a real OS would allow much more than just multithreading facilities ofcourse...

so, if anyone think like me (the GP32 need an OS) and wants to help this project, contact me here or by pm so we can coordinate ours efforts (maybe open an sourceforge project to get advantages of CVS)
 
although i cannot code (ha, you did not think of this!), i would like to help.
if there is any progress, i could create a logo or any sort of pixel-gfx you need. just PM. :)
 
Hey, this sounds interesting indeed.
Loki, what do you intend to use it for?

---
mithris
 
mithris: well, not sure exactly, since i dont really know what RTEMS can achieve yet... (lot of doc to read...)
it would allow a better GUI for application launcher first and multi-process/multi-threading facilities, thats for sure
but for the rest..., i dont have any application in my mind that would take advantages of the RTOS.

the aim of this project is of course what those supid koreans didnt make... a good devloppemnt platform for the GP32...look at the actual GPSDK shit, there is no debug, the doc is a light-weight one... etc. i thought mr.mirko sdk was the solution (btw: mr.mirko made a great work), but it still not enough

so i ask any CODER intersted by this porject to help (mithris may i count you in?)

dr.no: thanx, but acutal progress is '25% documentation read'... so i dont think i'm going to need some gfx until long time
 
Yep, you can count me in.
But, what i wonder is if there isn't a better OS around than RTEMS.
We would have to design a GUI system of our own..
(imo that will be nothing but fun anyway :)

and, btw, about debugging stuff on gp32, it is possible..
check http://gp32.misantrop.org

---
mithris
 
add cartride emulation support to frodo, make a ethernet adapter for gp32, run frodo, run contiki here you go.
 
ThunderZ: well it doesn't looks like a real OS to me... but more like an GUI environment i took a quick look at the code... it's clearly not an RTOS, it just has some non-pre-emptive cooperative multithreading facilities, but its really nothing
second, its targetted for old 80's computer like c64 and such...
i dont think its a good start for what we want to reach... the screenshots really looked ugly... like mithris said ,with RTEMS ,we'll have to design or own GUI and we can do much better that this simple text GUI.

mithris, i suggest you to install rtems environement on your box

take care

jlebrech: what are you talking about???
 
i meant u can try contiki now, thru frodo.

but for ethernet ull have to make a plug
 
oh ok... you'r crazy man :)
but i dont want to try contiki... its really no what we want... its not an OS

edit
i've found this uc/OS-II RTOS well there is even an s3c2400 port so its peice of cake...
but it's maybe a litle too µ :) no fs support, etc... buts its still a good resource
take a look and tell me
edit
 
So let me get this straight.

The purpose of this project is to create and real-time multithreaded OS and ultimately a GUI and new SDK for the GP32? So you can run and exit applications and even have background processes going on while other games/apps are running?

Am I on the right track?
 
Daz_Genetic posted on Apr 1 2004 at 04:17 AM said:
So let me get this straight.

The purpose of this project is to create and real-time multithreaded OS and ultimately a GUI and new SDK for the GP32? So you can run and exit applications and even have background processes going on while other games/apps are running?

Am I on the right track?
sounds like an OS to me.
 
Last edited by a moderator:
wip: i talked to a guys who allready made 3 port of rtems for arm (2 arm920)...
he said we can use a linux bootloader to load rtems, so that's what we need first...
we also need a console for firsts debug... so maybe we could use a null-modem but i dont know where to find the connector for gp32 ext port... anyone know where i can find one?
an alternative would be to use the usb cable but we also need a x86 app to make de bridge i guess... maybe we could use your debug stuff mithris, i've saw something with usb cable and gdb...
i think we gonna need mr.spiv's help for all the memory and isr stuffs, may i count on you mr.spiv?

for what i've understand, there is no rtems kernel which could be booted alone... instead each app is build wih rtems directly linked with, but i've saw so dynamic loading samples so maybe it's not a real limitation...
anyway i told to the guys our general goal for this project (the target hardware and what we want to do) and asked if we could achieve such a port, he answerd "I don't see any reason why you can't."
so all we need (as allways) is time

:lol: i got promoted to GP32X Guru B) B)
 
The EXT connector is the same as some brand of phone's connector (Samsung perhaps).

I think Mr Spiv made up some sort of reflashing kit to resurrect dead GP32s when flashing went awry. He'll be the guy to speak to about linking the EXT port to the rest of the world (well, a PC anyway!)
 
Hey, i'm a guru now aswell..:D

loki, about the ext connectors, i will get my hands on a few soon i think, i could send you one or smth.

And about the console, it's rather easy to build the uart cable, and i have written some uart comms code for the gdb-stub already, so it shouldn't be any problems to get that stuff running.

And using the USB should not be so hard either, it's just a swi to setup the comms interface so you don't have to link with the SDK.

Hooking the ISR's is rather simple, the default IRQ handler in the firmware uses a table in the system RAM area, just poke in your custom ISR address there.

Hooking the other exceptions could be a little trickier, since the default behaviour is to reset, i hacked around in the firmware and added some code so i could handle the exceptions myself (for the gdb-stub), spiv did the same for his multiFW.
To hook the exceptions you write the address of your ISR in entry 16 (i think) in the table i mentioned earlier. Otherwise if that entry contains NULL spivs traphandler will handle the exception.
 
Back
Top