Ok that is what I needed to know - no need to build an NMI trap at 60h if there is no way to trigger it . I am using WikiTI - it is the most complete documentation I can find on the Z80/EZ80 based calculators. I was aware of the NMI traps used by the 84+CE, but I'm also aware that even though the rom call interface is written in such a way that programs written for CISPL and QSPL would be cross-compatible to an extent, assembly programs would require some translation due to the physical 24-bit bus(in particular, non-relative jumps and anything involving register loads from memory would require modification)(Since the QSPL/CISPL interpreters run within a logical 16-bit stack environment, anything that directly adresses the stack would need to be rewritten to work within 24-bit. Also, integers would overflow at higher numerical values, so programs relying on this behavior may behave abnormally unless I find some way to mask the MSB while preserving the sign bit, but then you wont have the benefit of 24-bit integers . And all of that is without mentioning that any ASM programs contained within the script would require a rewrite.). For this reason and others(for example, the fact that you cannot practically build an OS for the TI-84+CE), I'm going to first focus on getting this OS running on the 128k monochrome calculators, then get the 48k calculators working(did I mention that the kernel memory allocation routines work within the full logical 24 bit environment provided by the ASIC? They will need to be rewritten slightly to deal with the discrepancy between those two revisions), then if I'm feeling particularly daring I might try to get this thing running on the TI-84+CSE.

Oh of course. It has two functions, PUSH and POP
<Code>
PUSH(Stack Address, Value to push)
POP(Stack Address, Variable)
</Code>
I should also note that POP requires the variable to be passed by refrence

Oh and btw...would it at all be possible for me to help in this undertaking?

Good to know I just figured it was easier to port it to this calc than to port it to the (now obsolete) TI 84+CSE.(Namely because of the Memory-mapped LCD)

Unless of course that optimization I came up with works even faster . It goes something like this.
lbl something
..code goes here
conditional
asm(3E00BEC2(L(list token)something))
It effectively emulates a do...while loop, so it is probably faster, if the ? short circuit operates like I think it does .
Some HL abuse could probably be applied to the conditional as well, but that is program-dependent . The for variant would work like this
n
lbl something
-1->X
..code goes here
X
asm(3E00BEC2(L(list token)something))
It would start from n-1 and go until it hits 0
I know it's cheating to use an asm statement for a conditional jump, but oh well  .


EDIT: Conditional?goto something didn't work, so I made an assembly command.

I will remember that next time . I'm thinking about starting a new thread for the alpha, now that it works . Thanks to Runner112 for his advice on fixing this solver .

This is the fixed source code. I am still considering it pre-alpha since it has a couple of dealbreaking bugs . But this is the first version where the solver is actually functional. I have some screenshots as well. One of them is of what I call the Out-of-bounds glitch. It is caused by solving immediately after solving a sudoku . It also needs to be optimized.

I made some changes to the code, but it still isn't working. I will post the files here. I have also attached some screenshots. As you can see, when I input a blank sudoku it does not solve completely. I would appreciate some help here, as I am at a standstill.