CSB-linux for arm?

[raduga]

Hello all,

I'm attempting to build and run CSB (9.8.0) for the Zaurus platform-
an ARM pxa255 based handheld (not i386), running Linux.

I've built Hermes without trouble (1.3.3), and built CSB both with,
and without -dynwinsize, and with/without --enable-release
but it segfaults soon after launch, every time.

The screen is 640x480 native, but I can also run 320x240.
No FPU, so all floats are software computed.

It gets as far as:

Code: Select all

Chaos Strikes Back 9.8v0
SDL Initialized.
Timer: 10 ms established...
Fatal signal: Segmentation Fault (SDL Parachute Deployed)
Segmentation Fault

Running without --root-path, the UI dumps the requisite error notifies
and gracefully exits, so it's managing to get a little ways into the code.

Running without Hermes, or a size specified, it traps the Not Implemented (0x85f8) and exits about as gracefully as it can, after redrawing the window blue.

I'm assuming it would be more useful to start from the standard Linux port, than the PocketPC one- unless there's some devious arch specific code hidden away on the Linux side that the PPC might not. I'm running the same CPU as most PPC handhelds... just got a "real" OS on top.

Can anyone (paul suggest what I can do to debug things, and get CSB running?

Is there a hard requirement for 24bit graphics?
Hard requirement for large chunks of free ram?
Any weirdity with memory alignment?
I'm cross-compiling under i386, but that shouldn't really affect things.

specs:

400mhz ARM cpu
640x480x16 (or 320x240x16)
64mb ram (+ as much swap as needed)
gcc 3.3.2


Help? thanks!

[Paul Stevens]

Is there a hard requirement for 24bit graphics?
Hard requirement for large chunks of free ram?
Any weirdity with memory alignment?
I'm cross-compiling under i386, but that shouldn't really affect things

1-No
2-No
3-ARM requires 4-byte alignment for longs; 2-byte alignment for words. But
it works on my PocketPC. I spent a L-O-O-O-N-G time finding all of those
problems. When it died it died perfectly quietly. No error message. No
indication whatsoever that something was wrong. It simply exited.
4-I would bet you have found another byte-boundary problem because of
the way your compiler works.

What I did was to install dozens of try/catch (they are hard, even impossible,
to install in many places Hard work). Then try to narrow down the range.
Then fix one and start over again. The code does a LOT of flakey stuff.

I have an emulator for the PocketPC but it runs in Intel mode and does not care
about these byte-boundary problems. A lot of help that was!! I hope that
your "Real Operating System" will give you the program address at which the
failure occurred. You can use the Link map to pinpoint the location in the
source code and can ask me what might go wrong there.

Starting from the Linux port might be useful but I that is for you to decide.
I know nothing of Linux (or Unix, for that matter).

For your amusement I have posted the project that I used to build the
PocketPC version. I think it is the same as what you already have but
who knows?
http://dianneandpaul.net/CSBwin/CSBwinCE2002.rar

[Guest]

3-ARM requires 4-byte alignment for longs; 2-byte alignment for words. But
it works on my PocketPC. I spent a L-O-O-O-N-G time finding all of those
problems. When it died it died perfectly quietly. No error message. No
indication whatsoever that something was wrong. It simply exited.
4-I would bet you have found another byte-boundary problem because of
the way your compiler works.

aww... bummer.

What I did was to install dozens of try/catch (they are hard, even impossible,
to install in many places Hard work). Then try to narrow down the range.

hard work makes life more interesting.

Depending on the work.

I hope that your "Real Operating System" will give you the program address at which the
failure occurred. You can use the Link map to pinpoint the location in the
source code and can ask me what might go wrong there.
[Starting from the Linux port might be useful but I that is for you to decide.
I know nothing of Linux (or Unix, for that matter).

My apologies for unixy snobbery.
I thought you knew something other than nothing. (you did the port?)

anyway....

I found that CSB seems to die the first time it calls UpdateScreenArea()
in LinScreen.cpp.

This, only when actually initializing the game. UpdateScreenArea()
seems to get called ok, when CSB is started without the data files, or at an inappropriate screen size.

I will try to checkpoint through UpdateScreenArea() to find the exact location it fails.

thanks for your support

[Guest]

Okay. A little more resolution on the problems:

it turns out that I was only getting the Segfaults while running
without DYN_WINSIZE -

the configure test was silently failing, so all the previous builds were without Hermes being used....

Running WITH hermes libs actually linking, I get a nice, shiny:

Code: Select all

MessageBox: [(null)] You have encountered code at
relative address 0x0085f8 that I
thought was unused.  I guess I
was wrong.  Please let me know
about it and the circumstances in
which it happened.

Within Graphics.cpp
D5W has value: 160 when it dies.
(should be 0-150)

if I manually force values >150 to zero,
CSB runs! though with colors horribly mangled.

Also, I've realised that you weren't fully responsible for the Linux part of the port, so I won't expect too many miracles

Any idea what might be going on here, and what I might do to fix?

(also mouse is badly lagged, not tracking well, but I'm going to investigate that separately)

[Paul Stevens]

CSB runs! though with colors horribly mangled

That is amazing. If you got that far you are going to succeed for sure.

you weren't fully responsible for the Linux part of the port,

"Fully"????? I didn't do any of it. I know nothing of Linux.

D5W has value: 160 when it dies.
(should be 0-150)

Actually 0 to 159 so it is only one too big.

That is in ShrinkBLT. A piece of code that was undoubtedly written
in assembly language originally, was thoroughly optimised for
speed, and is totally unfathomable without many days' (weeks) of
labor.

But....D5W comes from an array passed as parameter P7 (I think).
So we have to back up a bit and determine the index into that array
and where the array resides and what is in it. Notice that the index
is certainly not greater than 255 because it only loads a byte value
and fails to clear the upper part of the word in D5. You must be
referencing beyond the end of the array of else the array is destroyed.
Gotta figure out which.

[Rebecka]

Within Graphics.cpp
D5W has value: 160 when it dies.
(should be 0-150)

if I manually force values >150 to zero,
CSB runs! though with colors horribly mangled.

That's a problem with the endian of the graphics function. I tried to write it so that it should work with any endian, but never got around to test this. What color is the in-game menu?
Unfortunately neither Erik or I will be working with CSBLinux for some time, because we have had a chrash. A hardware chrash... the computer starts smoking when we turn it on. We have been waiting for a replacement more than a month, and won't be able to do much until the matter is resolved.

[raduga]

That is amazing. If you got that far you are going to succeed for sure.

I didn't do much of anything, other than figure out how to build Hermes,
and read the logs that configure generates. I am glad you have so much confidence

"Fully"????? I didn't do any of it. I know nothing of Linux.

Well... you are listed as primary maintainer of a project called:
"Chaos Strikes Back For Windows and Linux"
On closer inspection, it seems the linuxy parts aren't very much yours.
Or possibly at all yours, but for the naive, it doesn't seem unwarranted.

Actually 0 to 159 so it is only one too big.

That is in ShrinkBLT. A piece of code that was undoubtedly written
in assembly language originally, was thoroughly optimised for
speed, and is totally unfathomable without many days' (weeks) of
labor.

But....D5W comes from an array passed as parameter P7 (I think).
So we have to back up a bit and determine the index into that array
and where the array resides and what is in it. Notice that the index
is certainly not greater than 255 because it only loads a byte value
and fails to clear the upper part of the word in D5. You must be
referencing beyond the end of the array of else the array is destroyed.
Gotta figure out which.

I find values of 160 and 227 being passed to the function.
Both seem to kill it, unless trapped accordingly.

I'm not sure where to proceed from here. Do you have any suggestion?

It's possible that just ignoring these values isn't hurting significantly....

Aside from graphics (color, content) corruption, I find that:

• running CSB with the Dungeon Master data tree gets as far as the initial Dungeon screen; with "Enter" and "Resume" options available. No response to pushing either button. No response to keyboard or mouse from there on.

• running CSB with CSB data tree gets:
  
  Prison -> redraws the screen, then "Error: PRINTLINE SAVED GAME DAMAGED" "System Error 2989" and sound of door closing/crashing, CSB exiting.
  
  Resume -> GUI game selector, which actually appears to work

Mouse tracking speed may be a game-killer. I won't be able to tell until I can do some dungeon crawling, and button-hunting.

[raduga]

That's a problem with the endian of the graphics function. I tried to write it so that it should work with any endian, but never got around to test this. What color is the in-game menu?
Unfortunately neither Erik or I will be working with CSBLinux for some time, because we have had a chrash. A hardware chrash... the computer starts smoking when we turn it on. We have been waiting for a replacement more than a month, and won't be able to do much until the matter is resolved.

Very sorry to hear that!

the colors are:

background : blue
text : green on black, with a red border. blue border around red border
vertical black and white stripes surround blue border

mouse is black cursor, blue background

Dungeon screen is dominantly blue, with green, blue-green, grey and black highlights

ARM-linux should be small-endian (like x86) . supposedly ARM can also operate in big-endian mode, but under linux its locked in small-endian.

graphics detail is corrupted (with vertical stripes) as well as color corruption. At least the computer hasn't crashed.

I hope yours feels better soon.

[mlvj]

Hi all,

Did anybody make it any further on the ARM and linux front?

I have a Nokia 770 I'd like to get this going with.

I had a similar few issues, but I don't yet actually get as far as raduga.

Learning from the above, I've put in protection in ShrinkBLT.

Anybody from the linux port around any more? - probably endian issues that's knocking it.

I had to change SDL_SetVideoMode to use 16 bit, 32 bit doesn't work on the 770. Hopefully that'll be ok - as Atari was only 16 bit (wasn't it? - Amiga was I think).

Anyhow, this was good information in any case, and I'll hopefully move forward.

[mlvj]

Not much luck yet.

I get the same 160 passed through to ShrinkBLT, and if I capture that (by just doing nothing, rather than setting it to zero - actually I tried both) I get the window up, with a menu, but no actual graphics, just a grey screen.

Is there a function I could call, or cause to be called, to directly past the front screen?

... and in case it is a platform thing I'm going to recompile against GTK+-2.0 and the latest sdl and libdb4... - although I realise that may cause even more issues, but what the heck!

Anybody know what libdb3 is used for in the linux version? I haven't spotted why it's in there yet

[Rebecka]

Not much luck yet.

I get the same 160 passed through to ShrinkBLT, and if I capture that (by just doing nothing, rather than setting it to zero - actually I tried both) I get the window up, with a menu, but no actual graphics, just a grey screen.

Is there a function I could call, or cause to be called, to directly past the front screen?

... and in case it is a platform thing I'm going to recompile against GTK+-2.0 and the latest sdl and libdb4... - although I realise that may cause even more issues, but what the heck!

Anybody know what libdb3 is used for in the linux version? I haven't spotted why it's in there yet

Ok. Some CSB/Linux news:

libdb3 was included by mistake. I think it got in via gtk.h, or possibly gnome.h if you are using really OLD code. Nothing uses it.

Most of the problems with the ARM processor seems to be due GCC not supporting a few MS pragmas, most notably "#pragma pack(1)". It's a packing problem, not an endian problem. The values you see is random garbage from the kernel. Strangely enough, GCC does support "#pragma pack(1)" on the intel platform.

[mlvj]

Some more CSB/Linux/ARM news.

Thanks very much to Rebecka and Paul, we now have what seems to be a fully working version on ARM Nokia 770.

The only differences (in the end) were packing (which were fixed by a new GCC release on Nokia 770), alignment of some structures (fixed by adding __attribute__((aligned(4))) in a couple of places, and a slightly different pointer arithmetic issue that Paul sorted out.

The Maemo packages (Dungeon Master and Chaos Strikes Back for Nokia 770) are all available from the Maemo Garage https://garage.maemo.org/frs/?group_id=68

Paul suggested I play through to the end, and record it all (gradually) and then play back the recordings on a windows CSB/DM.

That will take me quite a long time I am sure!!!