It only does anything when you turn the calculator on after a reset.  And I'd guess it isn't documented anywhere because TI never anticipated people would ever need to use it - I think the main reason it exists is to allow you to boot the OS and reset the archive if it ever gets seriously corrupted.

Normally, for every archived variable, the OS keeps a VAT entry in RAM - i.e., the variable's name, type, and the address where it's stored in Flash.  These entries are used so that the OS, and other programs, can easily locate the variable.  Like DrDnar said, holding CLEAR when you first turn the calculator on stops the OS from scanning the archive and building these VAT entries; as a result, all your archived variables will be "hidden."

Oh, yeah, I was starting to write up documentation of the USB ports at one point.  Then I got distracted by something else.  That seems to happen a lot.

Yeah, I have the USB8X source code lying around, but it depends heavily on TIOS routines.  I would also probably write most of that stuff from the ground up, considering that it has no support for hubs, and is a bit outdated.

USB8x doesn't actually use the OS routines for very much - there's not very much interesting stuff the OS routines can do.  The main thing USB8x relies on the OS for is USB interrupt handling, and that's because there isn't any other choice if you're going to use IM 1.  (But that should be pretty easy to re-implement yourself if you want to.)

It does have some basic hub support - if a hub is connected, AutoSetup will turn on the ports one by one and try to connect to the first non-hub device it finds.  I'm not sure how much more is physically possible, as I'm not sure that there's any way to talk to, or listen to, more than one peripheral device at a time.  But I haven't tested anything to do with hubs myself.

Well, we know almost nothing about those ports.  We pretty much have to use TI's routines, which I can't steal and put in KnightOS unless I'm clever about it.  With the information we have, I could probably manage unit-to-unit file transfers, but for advanced stuff like unit-to-PC and peripherals such as flash drives we need more documentation.

Which ports are we talking about here?

And talking to a PC is easier than talking to another calculator: in the former case you only have to deal with peripheral mode, whereas in the latter case you need both host and peripheral modes.  And maybe SRP and HNP.

Does it have an RS232 "serial console" like the regular Nspire models do?

Are you saying that you want to take the image that is currently displayed on the screen, and dump it out as a hex string?  It would be pretty straightforward to do that in assembly language; I don't know if there's a simple way to do that with Axe.

For grayscale, you might be able to make it work with a GetKey hook, but for accurate timing I'd think you'd want to use an IM 2 handler.  To make grayscale look good, you generally want to have consistent timing regardless of whatever else is going on in your program, and regardless of whether the user is pressing keys.  I didn't think of mentioning IM 2 handlers before, but that might be the way to go.

On the other hand, a GetKey hook requires less memory to set up.

That code will not do what you want.  You can't load an 8-bit value from memory directly into a register, except for the A register.  TASM interprets "ld l, (foo)" as "ld l, foo"; i.e., a request to store the value "foo" in L, not to store the contents of memory location "foo" in L; the Z80 doesn't have an instruction to do the latter.  TASM is then complaining because you're trying to store a 16-bit value in an 8-bit register.

What you want to do is either "ld hl, (foo)" or "ld a, (foo) / ld l, a".  Obviously the former will destroy the contents of H, while the latter will destroy the contents of A.

Uh... no.  Not what he was asking.  There's GetCSC, which he mentioned, and GetK (BASIC's getKey), which he didn't.  Both of those routines return raw scancodes; they don't handle the shift keys, contrast control, APD, 2nd+Off, TIKB, or silent link.

Untested, but based on the source code provided, it looks like it's 47·n + 59 clock cycles per iteration (or on the 84+, 47·n + 61 in RAM, 55·n + 70 in a Flash app.)  Each iteration is only half a cycle of your square wave, though.  So if you wanted to play a tone of 440 Hz, you'd want the frequency parameter to be ((6,000,000 / 880) - 59) / 47 = 144.

For the time parameter, figure each tick is about 47/6 = 7.8333 microseconds, so a second would be 128,000 ticks.  This will vary depending on the frequency parameter, though.  (If you want to play notes longer than 65536, I think it would work so long as you ensure that the time parameter is a multiple of twice the frequency parameter.  Or maybe 1 less.)

Since it's all based on the CPU clock, your mileage will vary - you won't get perfectly precise hardware-independent tones in any case.  Still, you might want to experiment a little.

No, you can't play chords with that routine.