What Basics Do We Have?


skeezix

Internal Development
Joined
Mar 11, 2003
Messages
8,063
Website
www.codejedi.com
Who has dev units? Perhaps we should start a registry of who 'claims' what, to avoid duplicating efforts right now? (ie: Is Squidge going ot 'take' Quake1? :p)

Anyway, my question is..

What assumptions do we get to make? I know very few dev units are out, but I hope to get a regular user advance unit soon so could start devving in a bit.

ex: Which shared libs do we have on the devices virtual filesystem?

Do we need to force any shared-lib paths into the LD_CONFIG_PATH with an ELF-stamp? etc etc.. (ie: in gcc-speak, you'd " -Xlinker -R -Xlinker <path>"

ex: Which SDL version are they using? Do we have the source of their compiled environment so we know what SDL options were used, and can recompile witrh our own optimizations and inclusions/exclusions?

ex: What format is the framebuffer, and whats the device name for it? Or does the gcc295 it come with a closed source SDL modded to work appropriately?

Or do we just static-link everything and go?

(I've not looked at any SDKs, since I assume the gcc295 kit that was floating around was broken and out of date. Or is it actually usable to produce working binaries?)

jeff

I suppose it harkens back to the question from a month or two back.. they'll have to release the full source in a week or two, or there'll be fit hitting the shan :)
 
skeezix posted on Oct 11 2005 at 07:59 PM said:
Who has dev units? Perhaps we should start a registry of who 'claims' what, to avoid duplicating efforts right now? (ie: Is Squidge going ot 'take' Quake1? :p)

I've passed Quake1 onto Woogal, I'm been playing with UAE for a good while. It's coming along nicely.

skeezix posted on Oct 11 2005 at 07:59 PM said:
Anyway, my question is..

What assumptions do we get to make? I know very few dev units are out, but I hope to get a regular user advance unit soon so could start devving in a bit.

ex: Which shared libs do we have on the devices virtual filesystem?

There's quite a lot in the devices /lib directory, but most are out of date and only work on GCC2.95 anyway. DJWillis has got GCC4 working, but it requires a completely static build. He did tried several dynamic builds, and also tried to update his lib directory, and his device is no more as a result.

skeezix posted on Oct 11 2005 at 07:59 PM said:
Do we need to force any shared-lib paths into the LD_CONFIG_PATH with an ELF-stamp? etc etc.. (ie: in gcc-speak, you'd " -Xlinker -R -Xlinker <path>"

Nope, as 2.95 is horrible, and GCC4 has to run with static enabled.

skeezix posted on Oct 11 2005 at 07:59 PM said:
ex: Which SDL version are they using? Do we have the source of their compiled environment so we know what SDL options were used, and can recompile witrh our own optimizations and inclusions/exclusions?

GPH's modified SDL can be downloaded from the usual place - Anna placed the URL at gpx2.com ages ago, and a few people have mirrored it. Source code is available.

skeezix posted on Oct 11 2005 at 07:59 PM said:
ex: What format is the framebuffer, and whats the device name for it? Or does the gcc295 it come with a closed source SDL modded to work appropriately?

FB is 565, starts top left and moves horizontally and then vertically like a normal frame buffer. It's /dev/fb. I've posted example source code here.

skeezix posted on Oct 11 2005 at 07:59 PM said:
(I've not looked at any SDKs, since I assume the gcc295 kit that was floating around was broken and out of date. Or is it actually usable to produce working binaries?)

It's capable, but so slow. Quake ran at 1.42 fps with full optimization :eek:

I'd recomend using DJW's GCC4.
 
Last edited by a moderator:
I used gcc295 for a lot of years, and thought it was pretty good; is going back.. that horrid? Damn :) Its one of My Theories - back in the day, not only were machines slower, less ram etc, but compilers and tools were less qualified.. if they had todays tools on the older machines, life would've been better. Ah well.

Silly of DJ to update his core /lib without trying with alternate names first, to avoid bricking :( Can he get reflashed? Getting a new device or jtag?

Thank Crom we've got a horizontal fb; I hated that rotated shit :)

For SDL, I suppose we'll have to merge in their changes to the current SDL and rebuild. Course, with /dev/fb we don't need SDL for display at all; what about controls? /dev/joy or somesuch? Wouldn't need SDL at all then :)

/me goes to find jr2swiss :)

jeff
 
skeezix posted on Oct 12 2005 at 03:09 AM said:
Silly of DJ to update his core /lib without trying with alternate names first, to avoid bricking :( Can he get reflashed? Getting a new device or jtag?

Easy to say that ;). I tried a lot of things when getting this working and then made one stupid mistake at 3am :p.

I have serial and u-boot access to it’s hardly bricked as I can boot code on the raw hardware (that said the LCD is a duffer anyway and always has been ;) so I frequently cant see a lot without a serial lead).

It takes about 3hr’s to upload a JFFS2 disk image over serial and then the MagicEyes docs are actually wrong on telling you where to put it on the NAND.
Getting very tempted to make up a jTag lead.

Still, GCC 4.0.2 / gLibC 2.3.5 (and a patch or 3) works well with static builds and when stripped, compressed etc. size is not too bad.

Dynamic linking with GCC4 is possible if you want to fag about with the LD_PREFIX(sp) stuff etc. but it looks like you start to open yourself for a whole lot of pain and statically linking is an old GP32 fav ;-).

One option is to put a /lib on the SD and put newer libs in there but that requires some faffing and GPH have still not finalised where they are going to mount the damm SD card yet so it makes it a real hack-job and I have backed off doing that for now. On the dev-kits you have to manually mount the SD.

skeezix posted on Oct 12 2005 at 03:09 AM said:
For SDL, I suppose we'll have to merge in their changes to the current SDL and rebuild. Course, with /dev/fb we don't need SDL for display at all; what about controls? /dev/joy or somesuch? Wouldn't need SDL at all then .

SDL 1.2.7 is VERY badly hacked up by GPH (debug crap etc.) but there is so little real patching and no effort to optimise SDL for the target hardware so I would not be at all surprised if 1.2.9 ./configured stock would not run fine. There is a little patch in 1.2.7 for sound but I am not sure it is actually needed.

You can write to the framebuffer just fine and all the inputs are exposed as GPIO, no natty Joystick emulation or stuff like that (this is GamePark after all).

skeezix said:
(I've not looked at any SDKs, since I assume the gcc295 kit that was floating around was broken and out of date. Or is it actually usable to produce working binaries?)

Nope, it really was/is what they expect people to use :( ;).
 
Last edited by a moderator:
skeezix posted on Oct 12 2005 at 03:09 AM said:
I used gcc295 for a lot of years, and thought it was pretty good; is going back.. that horrid? Damn :) Its one of My Theories - back in the day, not only were machines slower, less ram etc, but compilers and tools were less qualified.. if they had todays tools on the older machines, life would've been better. Ah well.

Well, GCC 2.95 kinda killed me, as I like using inline code rather than #define's, and 2.95 didn't seem to like inlining at all :/ So you can imagine my joy when DJWillis got a GCC4 build running. Also, Quake runs at 1.17fps on 2.95...

skeezix posted on Oct 12 2005 at 03:09 AM said:
For SDL, I suppose we'll have to merge in their changes to the current SDL and rebuild. Course, with /dev/fb we don't need SDL for display at all; what about controls? /dev/joy or somesuch? Wouldn't need SDL at all then :)

SDL tries to open /dev/GPIO for controls, but it fails at the moment, as /dev/GPIO doesn't exist on the latest Kernel from GPH :)

You can open /dev/mem though and read/write all the hardware directly, so if you don't want to use SDL, and prefer hardware hacking, you can go that way. It's my preferred route. I've already mapped all the buttons on the device to there various GPIO bits, and played with the scaler/etc...
 
Last edited by a moderator:
Squidge posted on Oct 13 2005 at 11:34 AM said:
SDL tries to open /dev/GPIO for controls, but it fails at the moment, as /dev/GPIO doesn't exist on the latest Kernel from GPH :)

Ooooops. shock, horror ;-)

Squidge, care to pass out your mapping code for the GPIO points save people having lots of versions of the same thing? (you can attach it)
 
Last edited by a moderator:
Sure, not very good at ascii art but here goes...

Code:
                                              C15
      M1  M0  M7                               Y
      M2  o   M6   < Joystick            C12 A   B C13
      M3  M4  M5                               X
                                              C14
      D6   D7
      < Vol >                             Sel Start
                                          C9  C8

Letters state which GPIO button is connected to, number states which bit in that GPIO. 
All buttons are active low.

I don't know what the shoulder buttons will be connected to, as they don't produce anything on the dev boards. We'll have to find out on later hardware.
 
/dev/mem .. sweet. So, the homebrew SDK has begun :)

Can the fb do 8bit, or is the hardwarelimited to 16bit? (ie: For one of the projects I'm bringing back from the long dead, I need palette cycling for running efficiently.. otherwise, fixing the fb for each palette cycle is brutal :)

I've been coding Unix/Linux for a decade, and it occurs to me.. I've never bothered with joystick in all that time. Its all mouse and keyboard based. Wow :)

jeff
 
Back
Top