ELKS port of Adventure - help needed :)

I grabbed the src of adventure

wget -r -l 1 -nH --cut-dirs=5 \
http://www.cise.ufl.edu/class/cop4600/minix/src/commands/advent/

make clean to get rid of the binaries.

I've fixed up the make file which compiles. (patch below)

Install the dat files to /usr/lib/advent and use elksemu to run adventure

[paul@bender advent]$ file advent
advent: Linux-8086 executable not stripped
[paul@bender advent]$ ./advent
<Generic Adventure -- Version:7.0, July 1994>
...

The game will accept y/n for the first input for instructions but the word processing is b0rked.

I didn't understand the word "north"

I imagine it's something fixable in the src's, I'd like to get it running though as I'm going to a lan party with only an 8086 laptop to take :)

Any adventure hackers got any clue

Paul

@@ -9,10 +9,11 @@
 #
 # On Minix, use '-m' in CFLAGS and '-i' in LDFLAGS.
  
-CC     = mcc
-CFLAGS = -D_POSIX_SOURCE
+CC     = bcc
+GCC    = gcc
+LD     = ld86
+CFLAGS =  -0
 LDFLAGS        =
-GCC = /usr/local/bin/gcc
  
 OBJS   = advent.o database.o english.o initial.o itverb.o score.o\
        travel.o turn.o utility.o verb.o vocab.o

@@ -22,7 +23,7 @@
 all:   $(DAT) advent
  
 advent:        $(OBJS)
-       $(CC) $(LDFLAGS) -o advent -S 16kw $(OBJS)
+       $(CC) $(LDFLAGS) -o advent $(OBJS)
  
 setup: setup.c advent.h
        $(GCC) -o setup setup.c

For the heck of it, and for nostalgia's sake,
I edited the Makefile to compile and run on
my Linux PC (changed CC=mcc to CC=gcc, got
rid of -S switch).

It runs fine on my PC - no problems parsing
commands. I'm guessing, without having looked
at the code, that this is not a source code
problem.

Phil
--------------

phil@castle:advent$ diff -u Makefile.old Makefile
--- Makefile.old	Mon Sep 22 09:46:59 1997
+++ Makefile	Wed Dec 11 01:48:14 2002
@@ -2,17 +2,17 @@

# Where to put the adventure text files, and the binary executable. # Need the trailing "/"s.
-TEXTDIR = /usr/lib/advent/
+TEXTDIR = ./

# Flags you may want to add to CFLAGS:
# -DHAS_STDC=0 or 1 We have Standard C. Default=1 iff __STDC__ is
nonzero.
#
# On Minix, use '-m' in CFLAGS and '-i' in LDFLAGS.

-CC = mcc
+CC = /usr/bin/gcc
CFLAGS = -D_POSIX_SOURCE
LDFLAGS =
-GCC = /usr/local/bin/gcc
+GCC = /usr/bin/gcc

OBJS = advent.o database.o english.o initial.o itverb.o score.o\
travel.o turn.o utility.o verb.o vocab.o
@@ -22,7 +22,8 @@
all: $(DAT) advent

advent: $(OBJS)
- $(CC) $(LDFLAGS) -o advent -S 16kw $(OBJS)
+# $(CC) $(LDFLAGS) -o advent -S 16kw $(OBJS)
+ $(CC) $(LDFLAGS) -o advent $(OBJS)

setup: setup.c advent.h
$(GCC) -o setup setup.c

phil@castle:advent$ make
/usr/bin/gcc -o setup setup.c
./setup
Processing file advent1.txt  completed
Processing file advent2.txt  completed
Processing file advent3.txt  completed
Processing file advent4.txt  completed
/usr/bin/gcc -c -D_POSIX_SOURCE -DTEXTDIR='"./"' advent.c
/usr/bin/gcc -D_POSIX_SOURCE   -c -o database.o database.c
...

phil@castle:advent$ ./advent
<Generic Adventure -- Version:7.0, July 1994>

Welcome to ADVENTURE!
...
Would you like instructions?

You are standing at the end of a road before a small brick building. Around you is a forest. A small stream flows out of the building and down a gully.

You are in open forest, with a deep valley to one side. Not far is a large billboard.

The billboard reads:
"Visit Beautiful Colossal Cave. Open Year Around. Fun for the entire family, or at least for those who survive." Below the headline is an impossibly complicated map showing how to find Colossal Cave. Not that it matters, because all the directions are written in Elvish.

Possible a source code or bcc problem - the area to look at is the function 'binary' in the 'vocab.c' file.

Put:

printf("binary.vocab: mid=%d lo=%d hi=%d\n",mid,lo,hi);

before and after the line:

mid = (lo + hi) / 2;

(about line 596 - I've been messing with my file)

You'll see in the Linux compilation it follows a very nice textbook binary tree traversal.

In the ELKS version, it starts out badly and just gets worse.

I haven't found the cause yet - it's been a long day, and my brain isn't working properly :)~

I thought it might be something to do with overflow, but changing the int defs to long doesn't help.

Still, there should be enough pointers here for someone to figure it out... (I'm still working on it as well)

P.S. Phil - I think my mailer used your address rather than the list on my last post. Forward it if you like, but I think this supersedes it.

Richard Wallman
http://www.murkygoth.uklinux.net/elks

It's a bcc problem: strcmp doesn't return the right values.

I think on line 142 of libc/string/string.c:

sbb ax,ax ; Collect correct val (-1,1).

I'm not too hot on x86 assembly, but surely this command is subtracting the ax register from itself, using the status flags to show sign? Does the processor support a negative and positive zero value?

The next line (orb al,#1) then turns on bit 1. It is assuming that the scasb command has correctly set the right flag to indicate whether the comparison was negative or positive, and so give the sign.

I think this is what's wrong - every time, I'm getting a -1 result from strcmp.

Paul: short answer = rewrite strcmp. Only "vocab.c" and "english.c" use that function, so just replace all references. sed is your friend. :)

Richard Wallman
http://www.murkygoth.uklinux.net/elks

On 11 Dec, I wrote:

{SNIP: a load of rubbish}

Scratch all that, I did a quick test and bcc is fine.

I blame tiredness. >:)

Still getting -1 each time for the comparison in vocab.c though. I even tried "check=1" before the "check = strcmp(w, wc[mid].aword);" line, and it still comes up -1 each time.

Just tried pasting the bit of C from the end of the libc code:
--------------------------------------------------------------
int newcmp(d, s)
const char *d;
const char * s;
{
register char *s1=(char *)d, *s2=(char *)s, c1,c2; while((c1= *s1++) == (c2= *s2++) && c1 );
return c1 - c2;
};
--------------------------------------------------------------

Put that in vocab.c, replace the reference in the "binary" function, and it all works smoothly (for that function at least).

Looks like the only useful part of my last post was the suggestion to replace strcmp.

There's a problem here somewhere, but I'm damned if I can find it right now.

Yawn...time for bed...

Richard Wallman
http://www.murkygoth.uklinux.net/elks

Cheers that's a great pointer, oh well time to get my hands dirty...

Indeed - I'll hopefully have some time to do this tomorrow. I have the bcc archives to hand so can look at previous versions to brush up my asm.

Just got nice shiny 8086 laptop - but without floppy/serial. It's an Olivetti Quaderno, I may be able to use a flash pcmcia disk on it to get elks onto it, but we'll see. Else it's going to be pinouts from usenet and some soldering (eep)...

Paul

Yes, I was thinking either a compiler problem or a runtime library problem.

I think on line 142 of libc/string/string.c:

This is suspicious, as I would expect the result to be either -1 or 0 (I'm not an 8086 assembly guru, though), depending on the borrow bit.

The borrow bit should be unchanged (I'm assuming the 8086 arithmetic instructions work like all other 2's complement processors I've worked with).

I don't, think after the sbb, that the status bits resulting from a compare would be preserved, i.e. you would not be able to distinguish between a value being less than, equal, or greater than another value. The sbb would clobber the status, and just give greater than or not greater than (borrow or not borrow).

It's hard to say without seeing the code. If you want to email me the assembly code, that would help.

Sigh. Guess I'm going to have to set up the ELKS development environment to help here. If the orb is the very next instruction, after the sbb, it would change 0 to 1, but leave -1 unchanged.

Where does the scasb fit in?

This is a good idea. I'm surprised nobody's run into problems with strcmp before this, though.

Is strcmp written in assembly, or are you looking at the code generated by the compiler?

Sorry about asking such basic questions, but it's been a long time since I've actually tried to set up the ELKS development environment (and failed). So I don't have the source code on hand. I've been lurking ever since, but I thought here was a simple problem I could help with. Heh!

Phil

Two possible fixes - there is a new dev86 out which string.c has changed in (0.16.10). I'm going to test this out later when I get into work. Thanks Robert :)

Or you can use the C version from uclibc:

http://www.uclibc.org/cgi-bin/cvsweb/uClibc/libc/string/Attic/string.c?rev=1.3&hideattic=0&content-type=text/vnd.viewcvs-markup

Paul

I can confirm adventure *works* with bcc 0.16.10 which was released on the 5th of December.

This is a bleeding edge bcc with pre-processor, etc. But other than a complaint about:

advent.h:265: warning: Unexpected text following preprocessor command

But it compiles and runs :)

At least I get to play a game at the lan party now...

Paul

Gave it a bit of thought today, and I think I know what happened.

Looking at the libc sources, it looks like the strcmp and strncmp functions assume that both strings are in the same 64Kb segment. (There may be other functions that make this assumption as well, but I haven't really looked).

Looking at the file sizes, the "advent" program is 84Kb when compiled using bcc.

I put forward the theory that it fails because the two strings are not in the same 64Kb segment. The reason no-one has found this problem before is that so far all of the binaries have been <64Kb in size.

Still, looks like it's been fixed now, but if anyone was wondering why their port of their favourite app failed, that may be the reason.

Richard Wallman
http://www.murkygoth.uklinux.net/elks

They assume right! In ELKS DS=SS=ES.

By the way, the CVS ELKS tree solves many memory problems but requires a patch to the linker that I posted here some time ago and never got in the linker tree... :(

Harry

ELKS only supports a max of 64K code / 64K data per app...

Alan

Also, the file size is 84k, but that doesn't mean that the code segment is going to be more than 64k, does it? Does the whole file get loaded into memory and executed, or can there be other "stuff" in that file besides executable code that may not get loaded into the code segment? I haven't messed with this stuff in a while, so I don't remember :)

Dan

It is ok for a file to be bigger than 64K since initialized data exist in the file along with the code.

Harry

That's what I was thinking, just haven't done any x86 asm for a while.

Dan

"size" should tell you.

Basically you have code at CS:0 for upto 64K (and possibly shared). Then you have data at DS:0->n and stack at DS:[topsize] going down and the dynamic memory space settable using chmem.