For some reason interrupts don't work the way they used to (or I am just being stupid)
This code is supposed to increment a number on screen once every second, but it doesn't. It just increments T once and then never does the ISR again. Why is that?

Code: [Select]

.ISR fnInt(msc, 6)
0->T
FnOn
ClrHome
Repeat  getkey(15)
 Output(8,0,T/108>Dec
End
LnReg
Return

Lbl MSC
T++
Return

It seems that B_CALL(_DispHL), which is what Axe translates homescreen ▶Dec printing commands into, disables interrupts. You can turn them back on with FnOn, and I think that if you do this, B_CALL(_DispHL) is fast enough that no interrupts should be swallowed up while they're disabled for its duration.

I just got rid of the output altogether. This was a test program to check why interrupts were not working. In my soundplayer program I had a frame counter displayed on screen which was giving me these issues. I got rid of it and now it works great!

Do you use L2 as a screen buffer?

Try to use a different ram area and check if that'll still happen.

For 1.2.1, a few people wanted me to try to find a place for interrupt data other than L₂ because they wanted to have that space available in their programs that used custom interrupts. Basically all of the viable side-effect-free RAM was already in use, so I had to settle for something with as minor of a side effect as I could find. That ended up being 9200h, part of which stores some sort of data about tables (I'm not exactly sure what).

Anyways, when I made this change, I was aware it would screw up table stuff. To try to remedy this, I added the LnReg^r command, which theoretically restores the important table data that got clobbered by the interrupt code. Get the table data back in a valid state (possibly via a RAM reset), try using this instead of the plain LnReg, and tell me if it that works.

I can't think of any reason why Axe's interrupts would mess with the letter variables, at least in their default location. I just double-checked to make sure I didn't do anything really stupid, and I think I can confirm that no Axe routine or RAM location overlaps with the default location of the letter variables, at least since they were moved out of L₁ (saveSScreen) in 1.2.0. Do you use any parts of static RAM not "sanctioned" by Axe, e.g. not L₁-L₆?

For reference, the letter variables were moved to $9D2F for 1.2.0 and 1.2.1, and were moved again to smallEditRam ($90D3) for 1.2.2. Also, the changes to interrupt code in 1.2.1 made it use $8624-$86A4 and $9200-$9301.

Hmm, I guess I'm out of easy solution ideas then. Do you think you'd be capable of debugging the issue at the assembly level in an emulator? If not, are you able to post either the source or compiled code and tell me how to reproduce the issue so I could try it?