Yes, that one.
I thought that having 2 identical labels looked weird, my first thought was that it was some kind of weird syntax compatible with a specific assembler or something.

Using SLA allows you to bypass the need for any delay, because it just enables further groups.
However, yes, it's pretty inaccurate, because you end up potentially reading duplicate key bits at once.
The safest way to do this is to actually use RLC or RLCA, so that only 1 clear bit is sent to the port at a time.
However, that implies entering the "delay madness", more specifically using the safe values of 8 or 32 cycles between OUTs & INs (6 or 15mhz).
There is a trick to really optimise that, which is to design your code so that your INs are immediately followed by OUTs, but it's not easy to explain.
Feel free to check my keybscan.z80 if you need some inspiration.

About adding my routines, sounds great, though each of my .zip file has some separate info (.txt file) that definitely need to be read, so i guess it would probably be wise to wait until i manage to include that as comments in each .z80.

CHANGES

> Continued to improve descriptions & comments.
> Added necessary warnings for noobs.
> Code change : keybscan (slightly faster, different outputs).
> LCD snack pack was added, including 11 routines, and a fully Notepad-compatible font.

EDIT

Slightly updated the following, which are now slightly faster :
lcddisp
lcddispstrb
lcdfill
lcdinv
lcdinvchr
lcdinvstr
lcdsave

August snacks just arrived !
Added 19 new routines.
I will probably add 2 more packs in the future, lcd & archive stuff.

Just risked my ass on real hardware, port $24 bits aren't ignored.
So no matter how much rom pages you really have, both rom execution limits will always be defined using 9-bits values.
The good thing about it is that loading %00000001 in port $24 makes all rom executable with just 1 writing, no matter how $22 & $23 are configured.

Out of curiosity, what is your goal with unlocking the execution? Are you just trying to to it for the sake of doing it or do you have some specific use case in mind?

2 purposes :
1) a universal low-level routines collection, mostly for sharing
2) a long-term project, where execution from rom should be a thing

Welcome.

I'm currently writing a tiny routine that makes all ROM space executable.
So, it will of course write to ports $22 & $23, but i'm not sure about how they both interact with port $24.
According to the wiki, bits 0 & 1 of port $24 are working as bits 8 of ports $22 & $23 respectively.
Fine.
So, i would expect that no matter how those 2 bits are configured, it would not change anything to the actual execution permission range defined by $22 & $23, since no 8X+ calculator has more than 256 rom pages.

But then, here comes that statement, that makes no sense if those bits are actually ignored :
"Since no 8 MB flash chip exists, this port in effect overrides port 23 and is overridden by port port 22."
How should i understand it ?
Like, let's say i have port $22 set to $80, and port $24-bit0 set to 1.
Does that mean that the ASIC will allow execution on all pages below $180, in other words all of them ? (instead of pages below $80 like i expected)
Even if that's true, i still don't understand why port $24 would "override" port $23 but not $22.
Am i the only one confused ?

Thanks in advance for your time.

Hello there.

While testing a routine designed to check multiple key presses, i made an interesting discovery.
I didn't find anything about it anywhere, wikiti included, so the least i can do is to share it here.
Still can't believe i found that in 2019...

I decided to call the behaviour i'm about to describe "passive monitoring", as opposed to "active monitoring".

Active monitoring refers to the way most of you already know about, which is the regular sending to port $01, allowing you to specify which group(s) you want to monitor when reading the port afterwards.
Except for the need to use a variable delay between writings & readings, the port does what you expect it to do.
If you're new to that, you might want to check my old relic.

Passive monitoring is basically an alternate way to monitor groups, but you don't control it by writing to the port at all, instead, it is triggered by pressing specific keys.
Fortunately for you, i believe i understood how it works in its entirety.
I'm gonna first summarise how it works with just 1 sentence :
"When monitoring the group of a pressed key, you are also monitoring all other groups that have a key of the same bit pressed."
I know that sounds ugly, but i'm afraid that's the easiest way to describe it.
EDIT : Such "connections" aren't limited to 2 groups only, so with the proper pressed keys, you can actually monitor the entire keyboard, while actively monitoring only 1 group.

A visual representation might help to understand :

To be clear, in both scenarios, only group 4 was asked to be actively monitored, by sending %11101111 to the port beforehand.
In scenario A, group 4 is monitored and group 3 is ignored, as expected, so you would read %11111010 from the port.
But as soon as you press 1 (scenario B), group 3 gets instantly added to the list of monitored groups, so you would actually read %11110000 from the port, this time.
In short, having both 1 & 2 pressed together creates a bridge that "spreads" the monitoring from group 4 to group 3, because those 2 keys share the same key bit (1).

Fortunately, using bit checking|masking instead of the CP instruction helps us to filter potential trash keys in passively monitored groups.
However, there are some situations where such tricks simply don't work, depending on what you look for, see below.

A concrete example that shows how nasty passive monitoring can be :

Let's say you want to code a loop that waits until DOWN, LEFT, ENTER, and +, are all pressed together.
Despite the fact that those keys aren't in the same group, that's actually impossible, even by reading groups sequentially, thanks to passive monitoring.
But let's pretend that you can do it, to understand why you can't.
The most obvious algorithm would be something like :
1) Send group 0.
2) Read group 0, check DOWN & LEFT, repeat if not both pressed.
3) Send group 1.
4) Read group 1, check ENTER & +, go to 1) if not both pressed.
In this case, the problem isn't that the loop will never exit, but that it will once 3 of those keys are pressed, instead of all 4.
And there's absolutely nothing you can do to prevent it, it will behave like that no matter how you code it, and no matter in which order you press the keys.
For the sake of simplicity, let's say you press them in this order, to understand what happens :
DOWN : Nothing unusual. Reading group 0 would return %11111110, and reading group 1 would return %11111111.
DOWN+LEFT : Still nothing unusual. Reading group 0 would return %11111100, and reading group 1 would (still) return %11111111.
DOWN+LEFT+ENTER : The fun begins. No matter which group you asked the port to monitor, you will read both of them.
The unfortunate consequence is that when reaching step 4), you'll read %11111100, despite + was never pressed, but LEFT, which shares the same key bit, is.

Testing passive monitoring in known projects :

Pick any game, that allows you to move a unit diagonally using the arrow keys.
Now, press & hold DOWN,0,1.
If i'm right about all this, there is a decent chance that the unit will move south-west.

INTRODUCTION

This is a pack of routines and various files i've built over the years.
I can't say i haven't been inspired by others, so some stuff expands|fixes existing work.
Optimisation is mostly towards speed, and system code is used as rarely as possible.
Each file includes deep documentation.



COMPATIBILITY

Except if specified, all TI-8X+ models (monochrome screen) are supported.
Same goes for official systems and boot codes.
Everything else should be considered unsupported.



DISCLAIMER

For each routine, you are expected to follow EVERYTHING that's in the "IN" section.
Also, when there's a "WARNING" section, it's to be taken seriously.
If something is unclear, feel free to ask there BEFORE using : https://www.omnimaga.org/asm-language/flash-snacks/



NOTE ABOUT "OUT" SECTIONS

? means a register is to be considered destroyed.

Unlisted registers are unchanged, except for :
pc,r : always destroyed
af',bc',de',hl' : unchanged if interrupts disabled beforehand | destroyed otherwise

When the f register is detailed, each bit can be :
0 : zero
1 : one
X : variable-known (see "flags")
? : variable-unknown (destroyed)



CONTENT & OVERVIEW

keyboard.inc : keyboard include file
ti83plus.inc : ultimate TI-83+|TI-83+SE|TI-84+|TI-84+SE include file

font_large_custom.png : preview of what's in font_large_custom.z80
font_large_system.png : system 6x8p character font preview (2.53+)

1_character_tokens.txt : token>character reference table for all valid 1-character-long tokens
READ.txt : this file
system_ram_structure.txt : system ram structure summary

arcpages.z80 : Identifies the reference pages of the archive.
battcheck.z80 : Checks batteries.
bootver.z80 : Identifies the boot code version.
cpirnc.z80 : Similar to cpir, but additionally halts if a bank edge is reached.
cpirz.z80 : Similar to cpir, but instead halts if the specified byte isn't found.
cpirznc.z80 : Similar to cpir, but instead halts if the specified byte isn't found, and additionally halts if a bank edge is reached.
flashlock.z80 : Locks the flash chip.
flashmanuf.z80 : Identifies the flash chip manufacturer.
flashunlock.z80 : Unlocks the flash chip.
font_large_custom.z80 : Custom 6x8p character font matching ASCII|ISO-8859-1|CP-1252.
guiselect.z80 : Provides interaction with a simple 6x8p-text-based option selection GUI, using a custom cursor.
intdefault.z80 : Sets all hardware interrupts to the default system configuration.
intdisable.z80 : Disables and acknowledges all hardware interrupts.
keybcheck.z80 : Checks if at least one key is pressed, and if it's [ON].
keybdebounce.z80 : Waits long enough for released keys to stop bouncing.
keybscan.z80 : Scans the whole keyboard, [ON] key excepted.
lcddispbuf.z80 : Displays the content of a custom fullscreen buffer.
lcddispchr.z80 : Displays a 6x8p character, using a custom font.
lcddispstr.z80 : Displays a string of 6x8p characters, using a custom font.
lcddisptxt.z80 : Displays the content of a custom fullscreen text buffer, using a custom 6x8p character font.
lcdfill.z80 : Fills the screen with the same byte, mostly used to clear all pixels.
lcdmode.z80 : LCD mode configuration.
lcdsavebuf.z80 : Stores the display to a custom fullscreen buffer in RAM.
poweroff.z80 : Turns off the calculator, and waits for an [ON] key press.
prgmedit.z80 : Exits, opens the program editor for the specified program, and sets the cursor to the specified location.
r16strdec.z80 : Converts a 16-bit value to a decimal character string, and writes it to RAM.
r8strbin.z80 : Converts an 8-bit value to a binary character string, and writes it to RAM.
r8strdec.z80 : Converts an 8-bit value to a decimal character string, and writes it to RAM.
r8strhex.z80 : Converts an 8-bit value to a hexadecimal character string, and writes it to RAM.
ramlock.z80 : Sets RAM execution permission to the system default configuration.
ramsize.z80 : Identifies the physical RAM size.
ramunlock.z80 : Makes all RAM executable.
romlock.z80 : Sets ROM execution permission to the system default configuration.
romsize.z80 : Identifies the physical ROM size.
romunlock.z80 : Makes all ROM executable.
romwrite1.z80 : Writes a byte to ROM.
romwritex.z80 : Similar to ldir, but instead writes to ROM, and additionally halts if a bank edge is reached.
secterase.z80 : Erases a sector.
sectstate.z80 : Checks a sector for protection against write|erase operations.
strdelz.z80 : Replaces the potential leading zeros of the specified character string in RAM by spaces.
sysver.z80 : Identifies the system version.
usbinfo.z80 : Identifies if USB is available, and its revision type.