24th of March 2022 DoD(3) – second thoughts…

You know – usually I just start doing things… and than I continue, till finished or bored.

I started DoD this way. By now I am actually quite aquainted with the source and I begin to understand them. The more I understand them, the more I understand the flexibility and the very losely used RAM computers have.

A few facts about the original sources:

• there can be up to 32 monsters “active” at any given time
• there can be up to 72 objects instantiated at any one time (carried by player, lying in the dungeon or carried by monsters)
• the task scheduler can have up to 38 “tasks” running in parallel
• there is a player which also can carry stuff…
• there are sounds
• there is text output
• it probably uses the stack 🙂
• etc etc etc

Doing it the “way” as the source code is programmed… I would probably need 30Kb RAM. But much of the variable data is actually constant and can be moved to “const” if one is not crazy about random dungeon generation (which was no option in the original either).

But still, the structures given by the sources are often probably 1:1 transcoding from the original assembler – and these also contain vital information which might not really be needed in RAM.

Let us do some estimations… but trying to keep it as original as possible:

Following I deem AT LEAST necessary (on first thought, … I might be missing vital parts though)

• 192bytes – 6*32 -> 32 creatures: y,x coordinates, hit points, some id, something carried
• 288bytes – 4*72 -> 72 objects: y,x coordinates, some id, something carried
• 111bytes – 3*37 -> 37 tasks (of sorts), timer (16bit – 8bit enough?) + some sort of id
• 60bytes – 1*60 -> player, coordinates, hitpoints, internal attack damage modifiers, rings, torch, weapons, right hand, left hand…
• 50bytes – 1*50 ->music, sound, sfx, heartbeat buffers for such
• 150bytes – 1*150 -> 3 lines of variable test, formatable, buffers

This takes already the complete RAM with about 850 byte.
There is no stack included, no other “housekeeping” (parser, input handling, buffer…)

Of course speed and memory is always a trade of.
Current implmentation of a monster carrying stuff is a linked list, which starts at the monster. One could e.g. skip the monster part and always “find” the items carried in the object array… that would be 32 bytes saved.

Coordinates, the coordinates are two 5 bit values, so the coordinates only use 10bit – one could probably squeeze the “id” into the six bits which are left, that would save another 104 byte.
One could probably examine the timer stuff more closely and perhaps can differentiate between 8bit and 16bit timers and perhaps save with that another 30 byte.

Doing this and some other “small” savings – we might be able to save about 200 byte.

That leaves us with a first estimate of 650 byte usage + stack + things I have forgotten, and already “squeezed” beyond recognition.

It <might> be doable – but I don’t like the odds.
I would hate to do all the work and than discover that I have to:
– give up
or
– “shorten” the original.

I have to ponder this.