Another trio of ideas, this time it's for hooks in the program editor:
[On] + [?] = Copy the current line.
[On] + [?] = Paste from the cache into the current line.  If Ans was a string from copy, it would act like Rcl-ing Ans, but without the quotes.
[On] + [?] = Bring up a menu of the current Lbls in the program so you can choose one and jump directly to it, like DCS' instant goto feature.  (reference to this.)

EditBuffers are scary, but that sounds good enough to try to implement, so I will probably try eventually.

Some bugs to poke you about:

1) APD is enabled for startup programs/RAM clear programs. It should be disabled since when it turns off, bad things happen (TM).
2) You should prevent users from enabling MathPrint in a 2.43 OS, since doing anything top-right-display worthy will show a flicker and disappear from sight. I puzzled over that, and after disabling all the option, I narrowed it down to that little but sinister option.

Feature requests:
1) Allow disabling of the "bypass" key for startup/RAM programs. Yes, I know that sounds dangerous, so you are free to smash a wall of WARNING text all over my screen. (If you're curious, I'm working on a special little program that shouldn't be disabled )

1) I don't see a problem with having APD occur there. I'm pretty sure APD is interrupt based and when it quits, it quits back to the program. I have that enabled for my grayscale pictures and I haven't had a problem with APD's. Besides, I only take action if the calculator is starting up from and OFF, not from an APD.
2) What happens specifically? Because in reality, I don't even think that OS 2.43 even checks that flag.

1) I can't do the bypass key because I can't check the appvar. The reason I put the bypass key in there to start with is so that you could boot your OS normally without even running any zStart code. Essentially, if you are holding [VARS], the OS jp's to zStart, sees that [VARS] is being pressed, then jp's to where the OS needs to go. In order to disable this, I would have to check the appvar first to see if the [VARS] abort should be accepted. But this completely defeats the purpose of the abort. Let's say that you have an archive glitch that is causing faulty VAT entries, even if you left the [VARS] abort enabled, you would still enter a boot loop.

Looks good, the last thing you should do to bring it up to optimized is change things like
;4 bytes
ld d, 95
ld e, 5

;to

;3 bytes
ld de, 95*256+5

And also
;10 bytes
ld a, 17
ld (penRow), a
ld a, 1
ld (penCol), a

;to

;6 bytes
ld hl, 17*256+1
ld (penCol), hl

Of course these are just small things. But in big programs, they can start to add up.

Indeed, if you are going to use DCS routines, you should probably throw a DCS header on it. The header ensures that shells that don't support DCS funcions won't try to run it. If they do, it will obviously crash (or do something really interesting.)

Also, this line of code made me laugh:
  ld de,24756
  ld h,d
  ld l,e
  call VDispHL

I'll let you figure out what's wrong Think of it as an exercise.

Well, I'm not going to make the first routine, either you can do it or find someone else, but don't wait for me to post it


As for relative positions, that's easy. There are two ways to go about it, and it depends on how you want your ship to move:

1. Ship is always dead center of screen:
    For this, we want to first see how the other ship compares relative to your ship. So (opponentX) - (yourX). That will tell you where they are relative to you. Then, just add the location of your ship on the screen. So lets say that your ship is on X=25 of the physical LCD, then you would add the little math problem from up above to 25 to get your location.

Example: (yourX) = 190, (opponentX) = 180, Your 50x50 screen is in the top left corner of the LCD. Your ship is displayed at (25,25)
     180 - 190 + 25 = 15. So you would display the enemy at X=15.

2. The ship can move freely and the screen scrolls when it gets close to the edge:
     I'll let you take care of the scrolling, we're only worried about displaying other ships. For this, the equation is just (opponentX) - (scrolledX) + offsetToScreen. It doesn't even matter where (yourX) is.

Example: (opponentX) = 180, (scrolledX) = 175, Your 50x50 screen is in the top left corner of the LCD.
     180 - 175 + 0 = 5. So you would display the enemy at X=5.

No, you'll have to do that yourself. You can either convert it to decimal yourself, which is what I do, or you can make it positive, put out a negative sign if needed, then use bcall(_dispHL). But that will look ugly.

Yes. It functions just like the NEG z80 instruction, except it operates on HL not A.

Aww... So close. Assuming the Mul16 works, the only problem I see is that you can't make a number positive by just resetting bit 15. You have to use the NegHL on each of them individually. Or make NegDE and NegBC.

-1 = %11111111 11111111
1 = %0000000 00000001

If you just reset bit 15, you get %01111111 11111111 = 32,767

I did it without memkit for the Psyche's level system using penguin's method, except I just headed everything with $1337 lol. link to dl in sig.

That seems a bit risky. I'm sure your not the first person to head files with $1337. Oh well though, if someone happens to ever have a conflict, I'm sure the results will be amusing.