Right, OSes Like Windows are designed for multi-tasking and other things that slow everything down dramatically, where as the PSX OS was designed just to run a game and do nothing else...so whatever game you're making, if the OS is designed just for the game itself, it should run very fast without much memory requirements...

yep
i'm pretty sure that OS will die one day

why os if the boot lets place to a good application?

For multi-tasking, apparently. But then again, hypervisors fill that role more efficiently.

Make a Germ chase Row Col Flee/Chase balls to Get in DNA Kode http://www.members.tripod.com/cpu_bios/OUTPUT.WPP Make it in WackyPlusPlus W++ WALCULUS

It is not a problem to use the (E)SP register as a placeholder for temporarly values.
Beginning with to store the value of the (E)SP register into a specified ram location,
using the (E)SP-register for to temporarly place some values inside and if we done,
then we have to reload the (E)SP-register with our stored value from our specified ram location.
While we using the (E)SP-register for other things we can´t use our stack, example for to push/pop values or for to calljump into a subroutine.
(For to prevent of uncalculating behaviors if the stackpointer let push values far outside of our stack.)
Additional we can use temporary unused segment registers in the same wise and the first 4 debug registers can also be used as a placeholder for values (and/or for to prevent to debug the code).

...

It is possible to write a bresenham line routine without to store interim results of our calculation into the lazy ram using only cpu registers at runtime instead.
http://www.groupsrv.com/computers/about149518.html
(It is not the first posting, please scroll down this page.)

This routine is written for to use the linear framebuffer with an 8 Bit color mode using 255 colors and for using the 16 bit Unrealmode/Big-Realmode.
And this line routine use a table of startadresses of each horizontal line of the screen and this table starts at the beginning of our data segment.
With this table we can use the Y-corrdinate (exacly a muliple of this value related of the addresssize of each entry/record in this table) as an index inside of the table to get the line address of the framebuffer.

Additional we have only to add the X coordinate
(or a mutilple of this value ralated on how many bits per pixel we are using, if we modify the code for to use 16 bits or 24/32 bits per pixel.
Note for to modifying this code: There are more than only one mov-operation to write a pixel to the framebuffer).

Dirk