Strange behaviour on screen doing directory read.

[TGB1718]

I've just found an old program I was writing to do Art using modes 9 and 11

I use 2 screens, one for the drawing and a mode 0 menu screen, however when

I do a directory listing the mode 0 screen shows garbage, (see video), if I pause the

listing the screen is completely normal and is normal when it completes.

 

The modes 9/11 screens are created by the OS as normal, the menu screen is a display list

located lower down in memory screen is @ $6C40, DL is @ 6C20

 

I've changed the channel number just in case there was some sort of conflict, but it's still the same.

What am I missing (probably something obvious  ) ?

 

Edit: Should have said, the program is mainly BASIC with some USR calls

 

Edited February 12, 2022 by TGB1718

[flashjazzcat]

What DOS are you using? The DL is in the banking window, so if it's a machine with extended memory, DOS may be accessing a RAMdisk or (in the case of SDX) actually paging code into the same address space as the DL.

[xxl]

This looks like a badly written driver for Ramdisk - imagine what happens if the garbage the ANTIC reads contains the command code that calls the DLI. A very big DOS bug.

[Rybags]

Another possibility - during SIO the CRITIC flag is set.   Most shadow register updates will be skipped while a disk operation is occurring.

If your Display List isn't constructed properly you can get corruption, so make sure the Jump & Wait for VBlank at the end is pointing back to the start address.

[TGB1718]

18 minutes ago, flashjazzcat said:

What DOS are you using?

Using SDX, U1M BASIC XE in CAR

 

9 minutes ago, Rybags said:

Another possibility - during SIO the CRITIC flag is set.   Most shadow register updates will be skipped while a disk operation is occurring.

If your Display List isn't constructed properly you can get corruption, so make sure the Jump & Wait for VBlank at the end is pointing back to the start address.

I changed the code to lower the memory below the graphics screen and just did a GR.0 call, so BASIC

is creating the text screen lower in memory, unsurprisingly it created the screen at the same addresses

I was using, so I must have figured out where the best place was to use a text screen (I wrote this in 1985  )

Not sure why I used a DL, it's not really required ⁉️

 

But still the same corruption. The Text Screen is still at 6C40.

 

DOH !!! lights come on ? ,  @flashjazzcat your right it's in the banking window

 

Thanks you both for your insights and help

[flashjazzcat]

No worries. If you can move that screen, the problems will go away. Unfortunately, if you want to inoculate your software against these kinds of glitches under SDX, keep all ANTIC data out of the $4000-7FFF area.

 

[TGB1718]

Simple fix in the end, just swapped the screens, drawing screen is never seen when any disk access is happening.

Seems to have introduces a little corruption on the cursor(s) which are players, but sure that's just a matter of making

sure the PM area is safe 

[_The Doctor__]

cursor indicates activity, sounds fine to me.