If you can think of a simple way to fix the screen garbage issue I'd be happy to fix it.
Well, before loading ICET - with TD Line enabled under SDX - $230 (SDLSTL) points to $142C, which is the top of the TD Line Display List (this will vary depending on where in RAM the driver loaded). This display list ends with a JMP to $9C23, which is where the remainder of the OS display list resides. When the problem occurs, after typing "X ICET.XEX", the "X" command first disables the library and moves the screen and display list up in RAM by 8KB. When the garbage is displayed, the SDLSTL points at $BC20 (so the TD line has been disabled), but the end of the DL does a jump/wait to $BC2C, which is the wrong address. So the target of the jump/wait was not properly reset when the TD line was disabled (presumably by changing the DL vector, rather than calling the driver, which would have reset the DL properly).
While investigating this, I noticed that Altirra's .dumpdlist command always reports the target address of the Antic jump/wait command rather than the content of SDLSTL if the two differ (which they shouldn't in any case).
So - if you're going to shut off the TD Line by directly writing to the display list vector, you also need to trace through the DL (following the Antic JMP instruction, $01) and also amend the target address of the jmp/wait at the end of the OS display list.
The fact this issue only happens about half of the time would suggest to me that the stage 2 VBL is resetting the jmp/wait vector when the application is half way through changing SDLSTL. The solution might simply be to do an SEI prior to amending the vectors.
Edited by flashjazzcat, Thu Nov 28, 2013 8:02 AM.