Starting elksdoom

[toncho11]

Hi

I could not run release 1. I do not get an error message. Just the cursor keeps blinking after pressing enter.

1. Is the release a 8086 build or higher? 286? 386?

2. What do you do to create a big continuous memory block in ELKS? Do you use any of the optimizations we discussed previously? What is the size of your free memory before starting it when using meminfo?

I think these are important to put on the front page.

Thank you!

[toncho11]

Wow!!!!!!!!!!!!!!!!!!!!

It is working the elksdemo.os2 pre-release 1 on a x86 pentium emulator. I see in-game in color.
The problem was that I was declaring the video memory as usable with umb. I noticed that because other VGA applications were disabled as well. Actually it works without umb.

What I did in /bootopts:

buf=8
cache=4
init=/elksdoom.os2

I copied elksdoom to / in a hdd image.

Here is the image to try it:
hd32-fat_elksdoom_pre1.zip

@ghaerr

It is working with emulator https://copy.sh/v86. Sometimes it fails. Either it halts or it prints out of memory, but it works.

[toncho11]

It also works in Box86 emulator. I used NEC 8088 at 16MHz.
It is slow, but it works.
86box config file
You need to set the above HDD image in Storage Controllers with my config file.

[toncho11]

@FrenkelS What mode of optimization do you use for the compiler? Or currently you avoid optimizations?

[FrenkelS]

Everything is compiled using 8086 instructions and optimized for the smallest size, except the drawing routines. Those are optimized for speed.

https://github.com/FrenkelS/elksdoom/blob/main/compelks.sh:

CCOPTSS="-os             -bt=none -0 -zq -s -mm -wx -zastd=c99 -zls"
CCOPTST="-oaxet -oh -ol+ -bt=none -0 -zq -s -mm -wx -zastd=c99 -zls"

        Optimization
-o{a,b,c,d,e[=<num>],f,f+,h,i,k,l,l+,m,n,o,p,r,s,t,u,x,z}
  a             - relax aliasing constraints
  b             - enable branch prediction
  c             - disable <call followed by return> to <jump> optimization
  d             - disable all optimizations
  e[=<num>]     - expand user functions inline (<num> controls max size)
  f             - generate traceable stack frames as needed
  f+            - always generate traceable stack frames
  h             - enable expensive optimizations (longer compiles)
  i             - expand intrinsic functions inline
  k             - include prologue/epilogue in flow graph
  l             - enable loop optimizations
  l+            - enable loop unrolling optimizations
  m             - generate inline code for math functions
  n             - allow numerically unstable optimizations
  o             - continue compilation if low on memory
  p             - generate consistent floating-point results
  r             - reorder instructions for best pipeline usage
  s             - favor code size over execution time in optimizations
  t             - favor execution time over code size in optimizations
  u             - all functions must have unique addresses
  x             - equivalent to -obmiler -s
  z             - NULL points to valid memory in the target environment

[toncho11]

I made a new hdd image with release v20240831:
hd32-fat_elksdoom_v20240831.zip

[toncho11]

I also tried Box86 with emulation of Amstrad 1640, 640kb memory, 8086 at 10 MHz (original is at 8MHz), ATI VGA Wonder XL and it is very slow, but you can still walk around and even kill a guard.
86box.zip

[toncho11]

For the memory usage reduction in ELKS @ghaerr has suggested an improvement in /bootopts that can free more memory in the future. Also we can always disable unused services in the kernel such as networking.

[toncho11]

@ghaerr Is this line
#define SETUP_HEAPSIZE 19744 /* force kernel heap size */
one of the places where kernel memory can be reduced?

[ghaerr]

For the memory usage reduction in ELKS FrenkelS/doomtd3#12 (comment) in /bootopts that can free more memory

#define SETUP_HEAPSIZE 19744 /* force kernel heap size */
one of the places where kernel memory can be reduced?

Yes, that can be done manually, but its tricky and requires recompiling the ELKS kernel. My plan is to introduce heap= in /bootopts, along with setting buf=8 cache=4 task=3 file=10 inode=10 heap=xxx in order to use as few resources as possible in the kernel. The final fix involves ELKS releasing its near heap memory to main memory which now requires a recompilation.

@toncho11. I ran your hd32 Doom image under QEMU and it comes up and runs! How do you move the cursor around, the arrow keys aren't working for me so its hard to run the menus and move around in the game for me?

[toncho11]

@toncho11. I ran your hd32 Doom image under QEMU and it comes up and runs! How do you move the cursor around, the arrow keys aren't working for me so its hard to run the menus and move around in the game for me?

Try clicking on the numlock. Sometimes it works with on and sometimes with off. Not sure if this is an emulator or Doom8088 issue. Does it help? Click until it start working.

[ghaerr]

Try clicking on the numlock.

There is no numlock on my Apple MacBook! I'm going to suggest that a version be made that just uses keyboard keys, as adding support for arrow keys is a bit arduous/

[toncho11]

I use the "Clear" key above 7 on an Apple keyboard on Windows and it works. Maybe if you have a full sized USB Apple keyboard with "Clear" key then it might work.

[toncho11]

Here is a new image with the ghaerr/elks#1993
hd32-fat_elks_doom_release3_heap_optimized.zip
It looks better. Previously the demo used to crash when you are killed, but now it restarted successfully.

[toncho11]

This is with release 20240902 of elksdoom and heap (and other) kernel memory optimizations:
hd32-fat_heep_optimized_elks_doom_v20240902.zip

[ghaerr]

It looks better. Previously the demo used to crash when you are killed, but now it restarted successfully.

Thanks for testing with the new minimum kernel options @toncho11! I was wondering whether the game automatically gained new features with new memory, or how that worked. It sounds like right now things are so tight that the game sometimes used to crash.

Is there a way to know when we have enough memory for a viable non-crashing game?

release 20240902 of elksdoom and heap (and other) kernel memory optimizations:

What /bootopts line(s) are you using the for min memory configuration, I am curious? I found when I was testing that ELKS itself didn't do too well with < 6 tasks, and tasks are the biggest kernel data segment memory user (~800+ bytes each). But of course now we're only talking a few Kbytes of memory gain, that may not matter for Doom.

[toncho11]

I am using the default line you did in /bootopts with task=6, heap=15000 and also I do init=/elksdoom.os2

[toncho11]

I just did some testing on x86box on a 386 and I could not make it crash. Others should test as well, but it looks very good!

[Vutshi]

This is with release 20240902 of elksdoom and heap (and other) kernel memory optimizations:

@toncho11 thanks for the image. It runs on my 8088 hardware with 1MB RAM at an impressive 15 seconds per frame :)

[Vutshi]

Hi @FrenkelS,

Does ELKS Doom support CGA, or is it VGA only?

Best

[toncho11]

This is with release 20240902 of elksdoom and heap (and other) kernel memory optimizations:

@toncho11 thanks for the image. It runs on my 8088 hardware with 1MB RAM at an impressive 15 seconds per frame :)

You are probably the first to test on real hardware, so it is good news that it works. There will be some optimizations with time. Also I am not sure if a better vga card will help at all. I tried above with emulation of 20 MHz Amstrad 1640 and I think it was better experience than yours.

[rafael2k]

It is running on qemu quite well! Which are the options to have some kind of sound in the game? May be just pc speaker at a start?

[FrenkelS]

It looks like pc speaker sound effects might be possible
https://github.com/ghaerr/elks/pull/1796/files#diff-24b523298205777394b0dda0b36ea50308d9efcd410df7c27b68f2e7c40b5d99

[rafael2k]

Cool! Would a Yamaha chip (like OPL3) be hard to program from Elks?

[ghaerr]

It looks like pc speaker sound effects might be possible

Yes, user programs under ELKS can play sounds by setting a frequency in channel two of the PIT and then gating the PC speaker on via the keyboard port just like DOS programs do. The kernel uses the same method to produce a bell when a ^G is received.

Would a Yamaha chip (like OPL3) be hard to program from Elks?

You'd want to have a sound library of some kind so you don't start from scratch I would think, and the code would then reside within Doom, accessing the OPL3 hardware directly. The original PC Doom used a third-party library for all the sound cards, I'm not sure if there's any Doom source for sound cards for the open source Linux version.

[FrenkelS]

In DOS Doom, the sound library is also responsible for the timer. Every tick the sound is updated. We're not allowed to change the timer in ELKS. So I'm not sure how to do the sound properly.

[ghaerr]

We're not allowed to change the timer in ELKS. So I'm not sure how to do the sound properly.

Now that I understand how Doom works on ELKS in a little more detail, I would say that it would be OK to access the PIT directly to change the tick rate to 35ms, if that's what it takes to get sound. On exit, the PIT should be reprogrammed to 10ms. Only the countdown timer has to be changed, the other PIT register can remain untouched.

The downside of playing with the PIT is that the date command and any created file times etc won't be correct during or after Doom is executed. But that may not be a big deal, and if PC sound could be added, I would vote for the PIT change. A message could also be displayed to run clock -s -u to reset the system time/date from the clock hardware if wanted (this is how /etc/rc.sys gets the time/date in the first place).

[FrenkelS]

I've tried to add PC Speaker sound effects without changing the PIT.
On a fast machine it sound okay, on a slow machine it sound hilarious.
#5

BTW, in vanilla Doom the ticrate is 35. So every second the timer is increased by 35. In other words, every 28.5ms (=1/35) the timer is increased by 1.
But for the sound the ticrate is 140 (= 4 * 35). So every 7ms (=1/140) the timer is increased by 1.

[ghaerr]

I've tried to add PC Speaker sound effects without changing the PIT.

Very cool having sound! Hearing any sound is great, and I think we should be able to reprogram the PIT on Doom start/exit with no big problems for the ELKS kernel, if only the countdown (timeout) value needs to be changed.

So every second the timer is increased by 35. In other words, every 28.5ms (=1/35) the timer is increased by 1.

Thanks, I keep confusing the timer tick rate of 1/35 with 35ms, I meant 28.5ms.

But for the sound the ticrate is 140 (= 4 * 35). So every 7ms

Does this mean that when the sound is compiled in for Doom, the PIT is reprogrammed only when sound is played to 7ms, or that Doom runs at 7ms from start? It probably doesn't matter, just wondering what the effect of a changed PIT countdown will be in ELKS during Doom execution.

On another note, we can save an additional 9K of RAM if we turn off floppy track caching CONFIG_TRACK_CACHE in .config, which will slow down program load but make more mem available for added features.

[toncho11]

Here I made a summary on how to optimize ELKS for running Elks Doom: https://github.com/ghaerr/elks/wiki/Increase-available-memory