cca3157c66
* addHL and subHL affect flags, and are smaller Most importantly, addHL and subHL now affect the flags as you would expect from a 16 bit addition/subtraction. This seems like it'd be preferred behaviour, however I realise any code relying on it not affecting flags would break. One byte saved in addHL, and two bytes saved in subHL. Due to the branching nature of the original code, it's difficult to compare speeds, subHL is either 1 or 6 cycles faster depending on branching, and addHL is between -1 and 3 cycles faster. If the chance of a carry is 50%, addHL is expected to be a cycle faster, but for a chance of carry below 25% (so a < 0x40) this will be up to a cycle slower. * Update core.asm * Reworked one use of addHL By essentially inlining both addHL and cpHLDE, 100 cycles are saved, but due to the registers not needing preserving, a byte is saved too. * Corrected spelling error in comment * Reworked second use of addHL 43 cycles saved, and no more addHL in critical loops. No bytes saved or used. * Fixed tabs and spacing, and made a comment clearer. * Clearer comments * Adopted push/pop notation |
||
|---|---|---|
| .. | ||
| at28w | ||
| ed | ||
| lib | ||
| memt | ||
| sdct | ||
| zasm | ||
| README.md | ||
User applications
This folder contains code designed to be "userspace" application. Unlike the kernel, which always stay in memory. Those apps here will more likely be loaded in RAM from storage, ran, then discarded so that another userspace program can be run.
That doesn't mean that you can't include that code in your kernel though, but you will typically not want to do that.
Userspace convention
We execute a userspace application by calling the address it's loaded into. This means: a userspace application is expected to return.
Whatever calls the userspace app (usually, it will be the shell), should set HL to a pointer to unparsed arguments in string form, null terminated.
The userspace application is expected to set A on return. 0 means success, non-zero means error.