I took a quick look and the source code:
Is it really so slow that you had to use assembler for custom "incorrect" division  ? How much was the speedup?
And if you want to make it as fast as possible without any source changes, I'd advise you to use the genzehn tool and the zehn format from
my ndless fork and the same optimization options in the Makefile that I use in crafti (especially -flto, -mcpu, -Ofast). In crafti there isn't anything in assembler yet, pure C++ and it runs fast enough (I may change the asm thing, if your "incorrect" version makes a significant difference).
But if you really want to dig into the "every cycle counts" I may point you to __builtin_prefetch or the "PLD"(preload) arm instruction.

I didn't follow any of the steps and actually ran it, though, too much work to do for a game I'm not really a fan of, sorry. 
It looks really awesome though 

This is awaiting in the Omnimaga front page headlines queue right now. I am astonished by how fast it runs in the video above (although I guess it helps that you overclocked your calc to 264 MHz. Mine can only go up to 242 or so before it goes unstable). Still, awesome work!


Does it work under OS 3.1?

Vogtinator: The assembler file is missing the following comment because I am not quite done yet:

@ Division routines are implemented with using the book
@ "ARM System Developer's Guide: Designing and Optimizing System Software"
@ by Andrew N. Sloss, Dominic Symes, Chris Wright
@ as a reference.
@ I am not good at math

The division routine is called _incorrect because I removed the error correction of the quotient and remainder at some point but added them back later because of.. issues. So it is actually providing correct results. If you are interested in the mathematical proof and more ARM optimizing shizzle I strongly recommend the book. Speedup is significant if you have to do a division every 8 pixels.

DJ Omnimaga: I do not know if it runs on 3.1. My emulator setup is 3.1 and my calc is 3.6 and it runs in/on both.

mdr1: Quake cannot find the pak0.pak(.tns) in the /quake/id1/ folder. Are you sure its there ? I identified the reason you had to reset instead of just having to press a key so thank you for your feedback

mdr1: Well it should look something like in the attached picture:

New build. I fixed the system error message so you can exit graceful by keypress instead of having to reset. I also changed the keypad read routine for the touchpad which gave some speedup. I also added more keys for interpretation.

I also noticed that I never explained the key bindings. For the game you can bind any key nQuake understands. You can set these through the menus..
ESC opens the menu which you can navigate with the arrow keys. Enter goes to a sub-menu and ESC returns from it. In the sub-menu Options is "customize controls", if you select that you can remap all in game actions to different keys. nQuake currently understands the following keys:
Arrow Keys, A-Z, 0-9, SPACE, TAB, CTRL, SHIFT, SPACE, +/-/=, TRIG, ^, X^2, e^x, 10^x, (), .

The Quake console is bound to the "?!" key. There you can type commands like "map start" or "timedemo demo1" and other stuff from the 90s.

I included the Windows Visual Studio solution this time because its where I do development so it kind of belongs in the package.

Geezus, I didn't realize this was Quake. I kind of missed this topic since the title is really vague(I was also viewing it on my phone and the picture did not show up). This is fantastic! I can't believe how fast it runs in the video. I also didn't realize that quake could run at that low of a resolution. Anyhow, amazing job!!!

To be honest I'M not surprised, because Unreal Tournament GOTY came out 3 years after Quake, yet it supported resolutions as low as 320x200, which is smaller than calcs.

Geezus

At first I thought Drak (NSFW) was back on Omni

So I did some more optimizations and submitted it to ticalc.org as I was able to play through the first episode without noticing anything wrong.

ExtendeD: A problem I noticed with Ndless 3.1 in the emulator is that the stack was not aligned to 8 bytes upon entry of main() which leads to failure of functions taking 8 byte datatypes. ARM EABI requires the stack to be aligned to 8 byte. I worked around that by aligning the stack myself so printf and the likes work. This could be related to http://www.omnimaga.org/calculator-c-language/nspire-printf-syscall-is-not-ansi-compliant/ as I got the same symptoms. I have not tested with Ndless 3.6 or on the real HW.

rwill : thanks, I think Vogtinator's SDK fork ( https://github.com/Vogtinator/Ndless/ ) fixed this. It should hopefully be merged back soon.