Ideas to port UMoria (Roguelike game) with elks curses

[tyama501]

Hello,

As I noted it on #1387 (comment),

I could display UTF-8 with the serial terminal,

I started to think porting Angband (Roguelike game using UTF-8) with elkscmd/tui/curses.c.
https://github.com/angband/angband

The main for curses is angband/src/main-gcu.c.
Just Idea but subwindow fuctions are substituted with a single window.
Maybe no color for the first try.

It seems that at least getyx function is needed in elkscmd/tui/curses.c.
/* Get current cursor position */
getyx(stdscr, y, x);

mvwaddnwstr is preferred but maybe it can be substituted with mvaddch.

@ghaerr ,
Is it possible to add getyx(stdscr, y, x) in tui/curses.c?
Do you think there is a chance to port simplified version of the angband?

As @toncho11 saying it is nice to add if we could add some game.

Thank you!

EDIT :
Angband is too big to port to elks.
Currently targeting UMoria to port.
UMoria
https://github.com/HunterZ/umoria

ELKSmoria
https://github.com/tyama501/ELKSmoria

[toncho11]

I think @tkchia is working on porting some functions that will make it easier to port games.

[ghaerr]

Hello @tyama501,

I could display Japanese UTF-8 file using the serial terminal!

That is cool, but keep in mind that ELKS doesn't know anything about UTF-8. It doesn't parse the sequences, nor does it drop or rewrite any. Thus, it is merely just passing the stream contents through to your terminal, which interprets them.

I haven't looked at Angband yet, this could seemingly work, but only if the output were viewed on a UTF-8 terminal on a serial port.

I have been working on a library, also in elkscmd/tui, that allows for conversion of UTF-8 sequences to CP437, which is used for the matrix display. This works on the console as well as serial w/terminal emulator. Of course, that library could also be enhanced to display certain Japanese characters on the PC-98 console. The library allows UTF-8 as input, and then translates the characters to the local console font, or if serial connection, back to UTF-8 for output. We can discuss this in more detail later if desired, after you have looked more at the library.

Is it possible to add getyx(stdscr, y, x) in tui/curses.c?

You're welcome to enhance the routine. Perhaps just copy the entire curses.c into your port directory at first, we can then back port to TUI later. The function could should send an ANSI escape sequence to the console/terminal to report the cursor position, and then read it back. This is already done (and a bit complicated) in unikey.c::tty_getsize(). A much simpler way might be to just track the position in curses.c and report that back without emitting an ANSI sequence. This could get complicated, perhaps understanding why getxy() is needed would also help its implementation.

Just Idea but subwindow fuctions are substituted with a single window.
Maybe no color for the first try.
mvwaddnwstr is preferred but maybe it can be substituted with mvaddch.

The main for curses is angband/src/main-gcu.c.

Have you checked to see how large this program is compiled on Linux? It seems there's lots of code here, perhaps check early if it has much chance of fitting into 64k data (128 code for medium model).

I only tried to port a very simplified version of curses, which does not implement subwindows, nor lots of the routines. It does implement color support though.

Do you think there is a chance to port simplified version of the angband?

Yes. However I would advise not to attempt to interpret all the ./configure and other mess that is part of the standard distribution. I tried that for nano and the result is lots of incompatibility across ELKS builds, which resulted in having to remove nano build from the standard distribution. If you were to configure for your system, then take the C files and port them with an ELKS Makefile, along with a copy of the TUI curses and other routines, that would probably be a good start. We can then work to add the changed routines back to TUI later. I would like to move TUI to a library, which would make things simpler for you.

Thank you!

[tyama501]

Thank you @ghaerr ,

〉Have you checked to see how large this program is compiled on Linux?

I was worrying about this. I already closed PC for today but I think it was about 5MByte or so.
Well I don't know how big the original curses is.

〉I only tried to port a very simplified version of curses, which does not implement subwindows,

Yes, I know. I copied the curses.h of the tui and I am checking what is there and what is not.
Maybe hline is also needed.

I only think modifing the main_gcu.c, makefiles etc, and not whole configure.
Is it the only way to check whether it can be fit to medium model that compiling with ia16-gcc in elks, after deleting subwindow function?
(It's not working but I already compiled with experimentally deleted code with FreeBSD CLANG)

Thank you.

[ghaerr]

Hello @tyama501,

I think it was about 5MByte or so.
Well I don't know how big the original curses is.

Both are huge! If Angband is 5MB executable on Linux, I would guess you don't have a chance of a successful port.

Is it the only way to check whether it can be fit to medium model that compiling with ia16-gcc in elks,

Yes, pretty much you'll need to compile it to see how large it is. But even basic guessing would be looking at the 32-bit version. If its much over 128-200k, it will be too large. Most usually though the biggest problems come with the 64K data limitation. This can be ascertained using size *.o on Linux versions, just get an idea.

Thank you!

[tyama501]

This is 64-bit linux version but maybe it is too big.

I also forgot that my PC-9801BX has only 5MByte ram including protected memory...

[ghaerr]

Hello @tyama501,

my PC-9801BX has only 5MByte ram including protected memory

That amount of RAM does not affect the ability to run large programs on ELKS, as ELKS programs are limited to 128k max code and 64k data = 192k. (That is, a 512k RAM system would be able to run any ELKS executable). From the size listing above, angband is ~1.8M code size, and ~201K data, far too large for ELKS. Of course, sometimes the sizes can be made smaller (e.g. 32-bit pointers are only 16-bits on ELKS, so all pointers take half the space, etc), but a very large part of the code will have to be removed in order for angband to link and run as a 16-bit executable on ELKS.

For programs or games you really want to port, sometimes it's worth it to try to find very early versions, which are usually quite a bit smaller.

Thank you!

[tyama501]

I tried UMoria 5.6, the base of the angband.
https://github.com/HunterZ/umoria

It is much smaller than the angband,
although code exceed 128kB.
(still on clang, amd64)

5.6 has amiga, atari, ms-dos ports.

The main repository 5.7 moved to C++ and
these legacy ports have been removed.
https://github.com/dungeons-of-moria/umoria

[tyama501]

Hello @ghaerr ,

BTW, just curious
why the code size cannot exceed 128kB?
(limitation of kernel? compiler?)

Thank you.

[ghaerr]

Hello @tyama501,

It is much smaller than the angband, although code exceed 128kB.

Yes, but still huge. Perhaps the v5.6 DOS port would be something to look at.

why the code size cannot exceed 128kB?

With our ia16-elf toolchain on ELKS, only small and medium model are supported. In medium model, procedure calls are far, but they are each aggregated by the linker into a total of two segments: the main one (which is also used for near procedures), and a far segment, whose size is also limited to 64k. Thus the 128k limitation. Microsoft's DOS toolchain doesn't have this issue in their medium model, so one still needs to be careful trying to determine whether a DOS version can be ported to ELKS.

Thank you!

[tyama501]

Thanks, I will look other ports.

[tyama501]

I compiled it anyway (with deleting a lot of unimplemented io functions),
yes, it is "far" large.

ia16-elf-gcc -fno-inline -melks-libc -mcmodel=small -mno-segment-relocation-stuff -mtune=i8086 -Wall -Os -maout-heap=0xffff -o moria_e main.o misc1.o misc2.o misc3.o misc4.o store1.o files.o io.o create.o desc.o generate.o sets.o dungeon.o creature.o death.o eat.o help.o magic.o potions.o prayer.o save.o staffs.o wands.o scrolls.o spells.o wizard.o store2.o signals.o moria1.o moria2.o moria3.o moria4.o monsters.o treasure.o variable.o rnd.o recall.o unix.o player.o tables.o curses.o curses2.o tty.o runes.o unikey.o
/mnt/hdisk/git/elks_pc98/elks/cross/lib/gcc/ia16-elf/6.3.0/../../../../ia16-elf/bin/ld.gold: error: address of section '.fartext' moves backward from 0x35460 to 0x20000
/mnt/hdisk/git/elks_pc98/elks/cross/lib/gcc/ia16-elf/6.3.0/../../../../ia16-elf/bin/ld.gold: error: load segment overlap [0x10000 -> 0x35460] and [0x30000 -> 0x4cc40]
collect2: error: ld returned 1 exit status

[tyama501]

Just for Information,
size comparison,
amd64 vs ia16.
although configuration is (very) different (like limitted to minimum map size),
many obj is smaller for ia16.

-rw-r--r-- 1 tyama wheel 19848 Jan 4 00:38 ../source_tes | -rw-r--r-- 1 tyama wheel 11940 Jan 7 04:02 ./create.o
-rw-r--r-- 1 tyama wheel 42248 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 42516 Jan 7 04:02 ./creature.o
-rw-r--r-- 1 tyama wheel 21104 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 18204 Jan 7 04:02 ./death.o
-rw-r--r-- 1 tyama wheel 27832 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 18592 Jan 7 04:02 ./desc.o
-rw-r--r-- 1 tyama wheel 54056 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 53140 Jan 7 04:14 ./dungeon.o
-rw-r--r-- 1 tyama wheel 6232 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 7176 Jan 7 04:02 ./eat.o
-rw-r--r-- 1 tyama wheel 19144 Jan 4 00:38 ../source_tes | -rw-r--r-- 1 tyama wheel 17520 Jan 7 04:02 ./files.o
-rw-r--r-- 1 tyama wheel 37176 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 32288 Jan 7 04:02 ./generate.o
-rw-r--r-- 1 tyama wheel 9712 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 8704 Jan 7 04:02 ./help.o
-rw-r--r-- 1 tyama wheel 22336 Jan 4 00:38 ../source_tes | -rw-r--r-- 1 tyama wheel 15632 Jan 7 04:11 ./io.o
-rw-r--r-- 1 tyama wheel 10208 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 10284 Jan 7 04:02 ./magic.o
-rw-r--r-- 1 tyama wheel 11152 Jan 4 00:38 ../source_tes | -rw-r--r-- 1 tyama wheel 10812 Jan 7 04:02 ./main.o
-rw-r--r-- 1 tyama wheel 20312 Jan 4 00:38 ../source_tes | -rw-r--r-- 1 tyama wheel 21636 Jan 7 04:02 ./misc1.o
-rw-r--r-- 1 tyama wheel 30232 Jan 4 00:38 ../source_tes | -rw-r--r-- 1 tyama wheel 19792 Jan 7 04:02 ./misc2.o
-rw-r--r-- 1 tyama wheel 64672 Jan 4 00:38 ../source_tes | -rw-r--r-- 1 tyama wheel 60524 Jan 7 04:15 ./misc3.o
-rw-r--r-- 1 tyama wheel 3840 Jan 4 00:38 ../source_tes | -rw-r--r-- 1 tyama wheel 4844 Jan 7 04:02 ./misc4.o
-rw-r--r-- 1 tyama wheel 22000 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 18808 Jan 7 04:02 ./monsters.o
-rw-r--r-- 1 tyama wheel 52632 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 47496 Jan 7 04:02 ./moria1.o
-rw-r--r-- 1 tyama wheel 13808 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 15636 Jan 7 04:02 ./moria2.o
-rw-r--r-- 1 tyama wheel 34480 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 33600 Jan 7 04:02 ./moria3.o
-rw-r--r-- 1 tyama wheel 25440 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 29544 Jan 7 04:02 ./moria4.o
-rw-r--r-- 1 tyama wheel 24224 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 18704 Jan 7 04:02 ./player.o
-rw-r--r-- 1 tyama wheel 10664 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 11336 Jan 7 04:02 ./potions.o
-rw-r--r-- 1 tyama wheel 9112 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 9668 Jan 7 04:02 ./prayer.o
-rw-r--r-- 1 tyama wheel 163680 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 21316 Jan 7 04:02 ./recall.o
-rw-r--r-- 1 tyama wheel 1520 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 2048 Jan 7 04:02 ./rnd.o
-rw-r--r-- 1 tyama wheel 74280 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 39172 Jan 7 04:02 ./save.o
-rw-r--r-- 1 tyama wheel 15280 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 17268 Jan 7 04:02 ./scrolls.o
-rw-r--r-- 1 tyama wheel 11920 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 6104 Jan 7 04:02 ./sets.o
-rw-r--r-- 1 tyama wheel 6616 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 6580 Jan 7 04:02 ./signals.o
-rw-r--r-- 1 tyama wheel 56176 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 57472 Jan 7 04:02 ./spells.o
-rw-r--r-- 1 tyama wheel 7488 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 8980 Jan 7 04:02 ./staffs.o
-rw-r--r-- 1 tyama wheel 9368 Jan 4 00:38 ../source_tes | -rw-r--r-- 1 tyama wheel 10296 Jan 7 04:02 ./store1.o
-rw-r--r-- 1 tyama wheel 26600 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 31236 Jan 7 04:02 ./store2.o
-rw-r--r-- 1 tyama wheel 16560 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 13116 Jan 7 04:02 ./tables.o
-rw-r--r-- 1 tyama wheel 35584 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 28152 Jan 7 04:02 ./treasure.o
-rw-r--r-- 1 tyama wheel 3152 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 1040 Jan 7 04:07 ./unix.o
-rw-r--r-- 1 tyama wheel 4608 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 8024 Jan 7 04:02 ./variable.o
-rw-r--r-- 1 tyama wheel 7080 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 8848 Jan 7 04:02 ./wands.o
-rw-r--r-- 1 tyama wheel 11824 Jan 4 00:39 ../source_tes | -rw-r--r-- 1 tyama wheel 10520 Jan 7 04:02 ./wizard.o
> -rw-r--r-- 1 tyama wheel 5192 Jan 7 04:02 ./curses.o
> -rw-r--r-- 1 tyama wheel 4936 Jan 7 04:02 ./curses2.o
> -rw-r--r-- 1 tyama wheel 4912 Jan 7 04:02 ./tty.o
> -rw-r--r-- 1 tyama wheel 15452 Jan 7 04:02 ./unikey.o
> -rw-r--r-- 1 tyama wheel 1956 Jan 7 04:02 ./runes.o

[ghaerr]

Hello @tyama501,

yes, it is "far" large
ld.gold: error: address of section '.fartext' moves backward from 0x35460 to 0x20000

The error message shows that you are 0x35460 - 0x20000 = 0x15460 = ~84k over the initial 64k allowed in small model. That is, the linker puts the first 64k at 0x10000 internally then allocates a second (maximum) far segment at 0x20000. Thus it seems the program code segment required is approximately 64k + 84k = 148k, or at least 20k over the 128k max limit.

ia16-elf-gcc -fno-inline -melks-libc -mcmodel=small -mno-segment-relocation-stuff

You're still compiling in small model - you'd need -mcmodel=medium and -msegment-relocation-stuff in order to turn on medium model. This won't change the link result however, and the far calls will actually add more code requirement. See elkscmd/nano/Make.defs for more information on the nano build, which uses medium model.

Just for Information,
size comparison,
amd64 vs ia16.
although configuration is (very) different (like limitted to minimum map size),
many obj is smaller for ia16.

Running ia16-elf-size *.o would give a better display of the actual requirements.

It appears you could be close at just 20k over our 128k code size limit, it remains to be seen whether the data segment size might be too large.

Thank you!

[tyama501]

Thank you @ghaerr !

That is closer than I thought.
I will try the midium model later.

[tyama501]

Yes, with the medium model compilation
it has only the following.

/mnt/hdisk/git/elks_pc98/elks/cross/lib/gcc/ia16-elf/6.3.0/../../../../ia16-elf/bin/ld.gold: error: load segment overlap [0x20000 -> 0x38f10] and [0x30000 -> 0x4ccc0]
collect2: error: ld returned 1 exit status

[tyama501]

Hello @ghaerr , @toncho11 ,

I created the fork repository from Umoria 5.6.
ELKSmoria
https://github.com/tyama501/ELKSmoria

I modified Readme and update LICENSE file to GPL3(from GPL2) since 5.6 is GPL3.
Code modification is not yet added.
I will add first change to build later.

ELKS Moria
This fork repository is to port UMoria 5.6 to ELKS and just started.
ELKS is the Embeddable Linux Kernel Subset in the following repository.
https://github.com/jbruchon/elks

The code size is limitted to 128KB, and the data segment size is limitted to 64KB,
so some shrink is needed.

There are a lot to go but
one idea is separating to 2 scenarios (2 programs).
like
Human version and
Elf version
(or Warrior version and Priest version something like that)

Thank you.

[tyama501]

Hello @ghaerr ,

Thank you for the comment.

Nice! Does the game actually run yet?

It runs and we can work around town. (There are some people but no stores.)
If I tried step down to dungeon, then hung-up. I am debugging that now.

Thus, should you really want to implement the save and restore screen functions

I need some alternative since it gets no display after showing some files.

you could keep a copy of the contents written through mvaddch and similar by saving the character into an array, which would then be copied by save_screen and restored by restore_screen.

Yes, I think this is good for portability.

Another idea would be reading/writing the physical screen contents, but that may not work if multiple windows are used.

I don't think multiple windows are used, but this is similar to reading VRAM isn't it?
If there is a way to read physical screen contents regardless of architecture difference,
I think it is easier than follow curses commands to the array.

Since your application is very tight on data space, you might consider recoding the current approach and have moria redisplay the game screen itself, if that is possible.

I don't think it is easy to redisplay game screen itself for now, since it depends on curses saving,
but I will see it more.

Thank you!

[ghaerr]

If there is a way to read physical screen contents regardless of architecture difference,
I think it is easier than follow curses commands to the array.

The problem with reading/writing console RAM directly is that the game will only run on the console, and worse, if run on a serial port, would write to the console when dealing with the popup - so basically this is probably a bad design, especially since otherwise the game should run on a serial terminal from ELKS and over networking.

I don't think it is easy to redisplay game screen itself for now, since it depends on curses saving

I suppose it really depends on whether the game has data structures that determine what is shown, in which case a routine may be able to be written to use them to recreate the game screen at any point from scratch. In particular, the routine that updates the matrix area on the screen may be able to be enhanced to redisplay the entire matrix, rather than just the most recent player move. Then, redisplaying the more static portions of the screen may be easier.

[tyama501]

Hello @ghaerr ,

I found draw_cave() function already exists, so I used it to restore screen.
Although still there are a lot of bugs,
I could enter cave, fight with monsters, see help files and restore screen.

Here is playing video.
https://user-images.githubusercontent.com/61556504/216685029-d8732c38-2326-488a-9980-c81ed6f2a70c.mp4

Thank you!

[ghaerr]

Hello @tyama501,

Fantastic progress! Is the cave size required to be small because of lack of data segment space, or is this how the game starts?

Glad you've found the draw_cave() function, that simplifies curses considerably. Have you tried running on serial to see if that also works? (For the time being, you may have to set the terminal emulator lines/cols to 25x80 or larger on the serial line but the curses code should work for an ANSI terminal.)

Thank you!

[tyama501]

Now, it is 66x22 with 50floors. It is dark because I cannot use items including torch yet.
The size is the minimum setting to save memory.

I think the terminal is 80x25.
I haven't try it with real devices yet.
I will try it later.

I still have major issues for
using items,
placing treasures,
save and load files
There maybe more but if I solve these
I will release it for testing.

Thank you!

[tyama501]

Hello @ghaerr ,

It worked on PC-9801UV21 serial terminal.
(Although it is very slow with 1200bps)

One more thing I don't know why is that every time the game message says press [ESC] key,
I need to press ESC key for 3times.
This is same for the emulator, the real PC, and the serial terminal.
(This related to esc sequence or something?)

[tyama501]

Hello,

Additional video,
now I can save/load and
use torch to light up tunnel (a little bit).

elksmoria_20230212.mp4

[ghaerr]

That looks nice!

It looks like ELKS could use the capability to turn on and off the cursor to improve this display? Does Umoria try to control the cursor appearance or display through curses?

[tyama501]

Hello @ghaerr ,

I checked Umoria on FreeBSD, and the cursor is moving along "@" character, which is slightly different to my elksmoria.
It seems that it is not using curs_set().

[tyama501]

Hello @ghaerr , @toncho11 ,

There may be a lot of bugs, but I released the first binary for test play.
Any comments, feedbacks are welcome.
I hope it works on IBM PC :)

https://github.com/tyama501/ELKSmoria/releases
elksmoria_01.zip

I modified the binary name again to "elksmori" with in 8 letters since
I could not use cp or mv with the long file name.

Right now,
it is needed to place the following files under morifile directory of current directory.
(We need to discuss where to place these files later.)

./morifile/license
./morifile/newselks
./morifile/origcmds
./morifile/roglcmds

morisave and moriscor files are also created under current directory after save the game.

When starting the new game, you can select whether you use the Umoria original key or Rougue key.
./elksmoria without option will start the game with the former key which use numeric key(1-9) to move.
./elksmoria -r will start the game with the latter key which use "hjklyubn." key to move.

You can see the help file for keys by hitting "?" after creating character and starting the game.
Also, you can see what the character on screen means by hitting "/" then the character.

First you will be in the Town(without any stores...).
You can see "@" for player, ">" for down staircase to the dungeon, and maybe "P" for people.
Go on the ">" and press ">" to step down.

You have Soft Leather Armor, Cloak. Dagger, and 5 Woodden Torches at the beginning.
Press "i" to see the inventory, then press "w" and select these to Wear/Wield.

There is no potion at the begining, but you can heal yourself by
hitting "5" for original key, "." for rogue key several times to spend turns.

You can attack monsters by just moving toward them.

Ctrl-X will save the game and Exit.

Known ISSUE (but I don't know how to fix yet)
(1) ESC key needs to be hit 3 times
Whenever the message says hit ESC key, or
When you want to cancel something,
you need to hit it 3 times.

(2) Rest not working
"R" and number should have same effect for spending turns to heal but it seems not working.

Not checked
(3) Treasure appearance
I have seen "golds" appeared in the dungeon,
but I haven't seen any "object" yet.
(There only a few of thing like potion... Oh no DATASEG...)

Well, that's all for now
Thank you.
Enjoy !

[tyama501]

Oh, I think I found one more issue, now.

(4) Room with locked door without key or staircase.

I have trapped...

[tyama501]

(5) command "e" equipment list makes stack overflow. (although "i" works)

but I haven't seen any "object" yet.

I think I have found soft leather armor.

[tyama501]

Hello @ghaerr ,

(1) ESC key needs to be hit 3 times

It seems that ESC key has been defined as follows and it is compared to the result returned from getch().
\033 cannot be get with the single stroke? Is there a work around?

constant.h
#define ESCAPE '\033' /* ESCAPE character -CJS- */

io.c
char inkey()
{
...
i = getch();
...
if (i == EOF)
{
...
}
if (i != CTRL('R'))
return (char)i

create.c
void create_character()
{
...
put_buffer("Hit space to reroll or ESC to accept characteristics: ", 20, 2);
do
{
move_cursor (20, 56);
c = inkey();
if (c == ESCAPE)
exit_flag = 0;
...
}

(5) command "e" equipment list makes stack overflow. (although "i" works)

This worked with increasing stack from 2048 to 2240.

Thank you!

[ghaerr]

Hello @tyama501,

I'm not sure about the ESC issue, my first guess is that Umoria has ANSI keyboard processing built into the game, where, if a single ESC is found, it assumes that it is an incoming arrow/function key, and reads more bytes, in order to recognize the multibyte keystroke. you should look into this. However, curses is supposed to handle this. Otherwise, put a check within inkey and call exit immediately to determine if a single ESC is recognized at that level.

This worked with increasing stack from 2048 to 2240.

Great. I would assume you are quite tight on stack space, but if any other .data segment can be lowered, stack can be increased, since they live in the same segment.

Thank you!

[tyama501]

Thank you @ghaerr ,

I think Umoria is not using any allow keys nor function keys. It just use single ESC for accept or cancel command.

I thought ash is preventing to get single ESC.

[ghaerr]

No, ash isn't active when Umoria is running, so that isn't it.

Try calling exit() immediately after receiving a single ESC to see whether that level understands a single ESC.

[tyama501]

Thank you. I will try that.
It may also PC-98 keyboard issue since this maybe the first time using ESC.

[tyama501]

Sorry, one quick question.
If ash is inactive, then who is handling the sequence for the curses?

[ghaerr]

The curses2.c routine getch calls readansi which is handling the ANSI sequences. It is the routine that, when an ESC is read, it continues reading more input until an end of ANSI sequence occurs.

I'm sorry - now I realize that it is my TUI library that is causing this problem. That is, the TUI library allows curses programs to run on both the console and serial terminal lines, but since it has to recognize ANSI sequences, it waits to read more input, usually three characters, to determine the keystroke. Currently, it does not timeout after seeing a single ESC, due to complications. Instead, it thinks the beginning sequence of an arrow/function key was read, and continues blocking in a read.

Now that I realize the problem (which is that TUI library is working correctly), I recommend for the time being that we translate another single key sequence into ESC in your inkey routine, so that Umoria can work. That is, we need to think of another key, perhaps ~, that can be used to substitute for ESC. Then, in inkey you can do something like this:

    i = getc();
    if (i == `~`) i = ESC;
    ...

This will, at least temporarily, allow your program to cancel by using ~ while I think of a possible change to readansi inside TUI library.

Thank you!

[tyama501]

Thank you @ghaerr ,

Maybe I can substitute with the define ESCAPE in the constant.h like some other architecture that cannot use ESC key.

[tyama501]

I restarted this to debug since there may be chance to compile with the large model in the future.
It seems that currently having a build problem with recent update of curses and tty.
I merged them and now I can build it but exit immediately after opening message.
I will look further when I have more time.
Thank you.

[tyama501]

Yes, as in the chmem, it still uses about 100KB code space after I have removed huge codes and features.

[tyama501]

Oh, it seems that ESC still does not work.
Previously it worked if I hit 3 times,
#1505 (comment)
but now it exits if I hit it twice.

[tyama501]

Maybe I will replace it with the different key as we talked before if it is not the bug of curses.
Thanks.

[ghaerr]

Previously it worked if I hit 3 times,
#1505 (comment)
but now it exits if I hit it twice.

Yes, I think that behavior could have changed when I replaced readansi (which parses function key escape sequences) with a better version.

Maybe I will replace it with the different key as we talked before if it is not the bug of curses.

Unfortunately, there isn't a completely portable and easy way of waiting for a read from stdin and differentiating whether a function key is coming or just a single ESC. This can be worked around by read timeouts and counting milliseconds, but comes with its own problems. Better would be to assign an ASCII key for quit, if possible.

[tyama501]

Hello @ghaerr ,

I am still trying to find unused keys since many keys are already used somewhere.
I tried CTRL-E, but CTRL also does not work for the current application?
(I also noticed CTRL-Z crashes vi. Current ELKS does not have jobs/fg/bg so it seems that there is no way to get back to foreground?)

constant.h
#ifdef VMS
#define ESCAPE '\032' /* Use CTRL-Z instead of ESCAPE. /
#else
#ifdef ELKS
#define ESCAPE '\005' / Use CTRL-E instead of ESCAPE. /
#else
#define ESCAPE '\033' / ESCAPE character -CJS- */
#endif
#endif

Thank you.

[ghaerr]

I tried CTRL-E, but CTRL also does not work for the current application?

That is very strange! All control keys should work with curses. We can test that using the ttyinfo application in ELKS - it uses the TUI library (but not wrapped with curses) and displays the TUI library recognition of every keystroke. You might test that on PC-98, as I think it works on PC. I'll test too.

I also noticed CTRL-Z crashes vi. Current ELKS does not have jobs/fg/bg so it seems that there is no way to get back to foreground?

Oh geez! I'll look at that also. I had thought that UNIX-style jobs were disabled in the shell, and perhaps the kernel should that have that turned off as well. If bash is compiled with jobs support, fg should bring back the background application.

[ghaerr]

I just tested ^Z with vi, and also cat: neither seemed to crash, but it appears that ELKS and/or the shell isn't handling it properly. The shell reported "Terminal Stop" after a few more characters were typed, but the prompt didn't reappear and there seemed no way to recover.

Perhaps ^Z/SIGSTOP processing should be disabled in the kernel for v0.8.0 and then fixed afterwards.

[tyama501]

Thank you.

I don't know what TIOCGWINSZ fail is, but it seems that CTRL-E of PC-98 works as ^E in ttyinfo.

[ghaerr]

TIOCGWINSZ is an ioctl for the kernel to track a terminal window width/height; it's not (yet) implemented on ELKS.

The ^E test shows that ^E (and other control characters) are properly processed by TUI/curses. I would say it seems that the Moria program may be doing something special that prohibits control characters from being used or seen by the upper layers of the application?

[tyama501]

Hello @ghaerr ,

OK, I was inserting wrong ifdef. Now the CTRL-E worked.
I could start the game.
CTRL-E has been used in wizard mode (debug mode) of original codes,
but I have removed codes for the mode to shrink codes before,
so, I used it as ESCAPE for now.

Thank you!

[toncho11]

@tyama501 So now ELKSmoria can benefit from less code removal using OWC (Open Watcom Compiler) The compact model is currently available, which means more space for data.

[tyama501]

Hello @toncho11

Actually, it uses code space > 64KB, so it needs at least medium model.
(It still uses about 100KB code space after deleting features)

I will focus on debugging with current medium model until we get the large model support.

Thanks

[ghaerr]

@tyama501, attempting to compile and link each module of Emoria could be a good idea now, as it will immediately show which system calls the program uses that are not implemented yet. That list should be output after ewlink and it can be posted.

To build using OpenWatcom, each .c file will have to be compiled separately as the first argument to ewcc. Unfortunately, the script is very basic and won't take any other arguments, so replacing CC= or LD= inside a Makefile won't work yet. Perhaps just using a shell script for the compile and link will be easiest until the scripts are enhanced.

[tyama501]

Thanks, I will try it later.

[tyama501]

Release and Updates.

Second test release for ELKSmoria.
https://github.com/tyama501/ELKSmoria/releases/tag/elksmoria_0.2a

Updated

• Use CTRL-E instead of ESC for the curses of the ELKS.
• Fixed wrong score order of the score board.
• Increased stack for show_equip.

This version is built with gcc-ia16, medium model.
So, this version works with ELKS 0.7.0.

I will try to build with OpenWatcom large model for next release.

Thank you!

[ghaerr]

@tyama501, looks like you've got the game running pretty well! It will be interesting to see whether any source changes are required for OWC compilation or not. If there is no ASM source, I am hoping that the game ports and runs with no modifications.

[tyama501]

After merging the curses, I think the remaining fatal errors are the following.

death.c
https://github.com/tyama501/ELKSmoria/blob/elksmoria/source/death.c
type.h
https://github.com/tyama501/ELKSmoria/blob/elksmoria/source/types.h

I don't know why it is saying already defined yet.

signals.c
https://github.com/tyama501/ELKSmoria/blob/elksmoria/source/signals.c

I don't know why it is saying type does not agree yet.

Defines may not be applied correctly.

Thank you.

[tyama501]

One of the error is this.
(void) MSIGNAL(sig, signal_handler);/* Have to restore handler. */

[ghaerr]

Other than the MSIGNAL issue, these all look like C compiler compatibility issues, not ELKS or C library issues.

I don't know why it is saying already defined yet.

Look for multiple definitions of creature_type to get a clue as to this one.

death.c

No errors shown, not sure that's going on here.

(void) MSIGNAL(sig, signal_handler);/* Have to restore handler. */

It appears that ELKS requires a signal handler to be declared as void signal_handler(int sig). You should be able to fix this by using void instead of if you can find which of the many ifdef lines the signal_handler is declared (113-129?) in signal.c. I'm thinking that perhaps the ia16 compiler doesn't complain about this type mismatch but Watcom does. Try making that change and I'll look into this further.

More information on signal declarations are in libc/include/signal.h and linuxmt/include/signal.h.

[ghaerr]

@tyama501, #1934 completes porting of all curses and elkscmd/tui files to OWC. fm uses curses and now runs well. I have also compiled and run sash, kilo, hd, od, miniterm and other applications in large model and they're running well also.

[tyama501]

Hello @ghaerr

Look for multiple definitions of creature_type to get a clue as to this one.

It seems that somehow local .h have been read twice so I added ifdef.

(void) MSIGNAL(sig, signal_handler);/* Have to restore handler. */

I used void signal_handler(sig) instead of int signal_hander(sig).
I also removed some codes for SIGTSTP since currently CTRL-Z is not supported.

It seems that almost there.
Do we need to do something for setuid_, setgid_, abs_, and bsr?

Thank you.

[ghaerr]

Do we need to do something for setuid_, setgid_, abs_, and bsr?

I will add setuid and setgid system calls ASAP, you should be OK commenting out that code for the time being. I just added bsr in the last commit or so to ELKS, bring over file elkscmd/tui/bsr.c. I will add that to the watcom/ library I think.

For abs, you can write your own function for now:

int abs(int i)
{
    if (i >= 0) return i;
    return -i;
}

I will look into why abs is missing - it seems it is supposed to be standard but is many times a macro.

[tyama501]

Hello @ghaerr ,

elksmori.os2 worked!
Thank you!

[toncho11]

Is this your reduced version or the the complete version? I suppose you are trying with your modified reduced version for now.

[tyama501]

Hello @toncho11 !

Yes, it is still reduced version.
I will add functions one by one since all function may not fit in the conventional memory.

Thank you!

[ghaerr]

This is great @tyama501!

I'm excited you're able to use the new large model compilation and loading facilities with UMoria. It will be interesting to see just how large a program it ends up being. I expect you may be right that we now might exceed the amount of main memory before running out of addressable code or data segment space. IIRC ELKS starts up allowing for around ~450k of user program memory on a 640K system.