5200 Display List Interrupt Questions

[SIO2]

I have been working on a program for the 5200 as a programming exercise. What I am stuck on though is I am using a display list interrupt to display a title screen that has two character sets. After the title screen, I no longer need the multiple character sets and so have set up a second display list that never calls the interrupt. After title screen, I set the display list vector to the second display list by a DLIST command. I should mention I am using 5200Bas but any help in 5200bas or assembly language would be appreciated. Screen shots are real 5200 2 port model.

 

I have two issues/questions I would appreciate if anyone has some help they could offer me to resolve.

 

1. The title screen has a line at the top that looks like spiral notebook holes. That is not intended. What causes it? How can I get rid of it?

 

2. The next screen (options screen) displays a rug pattern until, I press start, play the game and die. Then when I return to the options screen, it looks fine. I have tried sending the game directly to game over to cycle it once but that doesn't clear the rug pattern. So, what am I doing wrong?

Edited January 26, 2014 by SIO2

[kenjennings]

can you post the data for the display list, and the code for the display list interrupts?

[Synthpopalooza]

In regards to the rug pattern ... it looks like the wrong value is being stored in CHBAS when you get to that screen. Setting CHBAS to the proper location of your character set everytime you get to the game screen should fix things.

 

The spiral notebook pattern is also to do with CHBAS, and possibly your display list/display list interrupt. A look at the code might be helpful, but my best guess is that your DLI is firing incorrectly on the top line. There are several reasons for this, but the one most likely is that you have the wrong value for the top line of your screen.

 

It looks like you are using Antic 2 mode for the screen. The entry in the display list that corresponds to the top line of the screen must be set to $C2 (194 decimal). The breakdown:

 

$80 (enable display list interrupt on this line)

$40 (load memory scan, a requirement for the first line of the screen)

$02 (Antic mode 2)

 

which totals to $C2

Edited January 26, 2014 by Synthpopalooza

[Rybags]

If you use an emulator like Atari800Win+ or better - Altirra then you could use the monitor and show the Display List as well as inquire on Antic status.

 

Chances are the spiral stuff might be a corrupted DList. Other problem might be DLI not occurring at all. It might be a simple case of just having to re-enable the DLI NMI type.

 

Not familiar with 5200Bas here, but I imagine that certain operations might change NMI enable status.

[SIO2]

Thank you all for the responses. They got me looking at the right area to get the spiral problem and rug problem taken care of. I am going to try to post code this time so hopefully it will make things clearer. I am using Antic Mode 4 to display a title screen made with two character sets. However being expansion minded, I wrote the DLI to be able to change character sets every mode line. The DLI looks up the character set for the mode line in a table. What happened was, the top line was pointed at a wrong character set.

 

Now, the title screen looks right. The second screen (options screen) also looks okay but, in the wrong character set. What I am attempting to do is switch from the display list that calls the DLI each mode line to a display list that doesn't call any DLI when I change from the title screen to the options screen. Apparently, either the DLI remains in effect or, my change to chbase never takes place.

 

Any ideas?

HWD3DLIX.TXT

 

Edited January 26, 2014 by SIO2

[Rybags]

Note if you're using a counter variable in RAM in a DLI - it's often a good idea to zero it during the VBlank rather than rely on the DLIs to do it.

 

There is the chance that the variable value isn't what you expect, can happen if a DLI gets inadvertantly missed or if you enable DLIs partway down the screen, among other things.

[SIO2]

Note if you're using a counter variable in RAM in a DLI - it's often a good idea to zero it during the VBlank rather than rely on the DLIs to do it.

 

There is the chance that the variable value isn't what you expect, can happen if a DLI gets inadvertantly missed or if you enable DLIs partway down the screen, among other things.

Thank you I will have to look at zeroing the counter in the Vertical Blank.

[SIO2]

I did get the program to work as I intended though, the way it worked puzzles me. I am developing on a windows 98 SE machine so, choice of emulators is somewhat limited. 5200Bas came with Jum52 v 1.1 and I have written a batch file that compiles and launches JUM52 with my program. It is convenient but only about 85% accurate. I also have Atari800 on the Windows 98 SE machine. The 5200 title screen and options screen above worked on both emulators but not on real hardware until: I placed the DLIST $6400 command (to switch to my second display list) between two short delay loops.

 

For some reason, having a brief delay before and after the DLIST command allows the system to see it.

 

Does anybody know why this works?

[phaeron]

My guess is that you have a race between the DLI on the first screen and the charset change for the second. The DLIST command appears to write to SDLSTL/SDLSTH, which are shadow variables maintain by the OS. Those aren't actually copied into the hardware until vertical blank. That means when you attempt to switch the screen mid-frame, the old display list's DLIs are still running until the end of the frame and can still stomp CHBASE. Also, since the CHARSET command writes directly to CHBASE, running it mid-frame will cause a glitch. You can poll for a change in RTCLOK to ensure that vertical blank has started to keep changes off-screen and to wait for shadow variables to be pushed to hardware.

 

There is also a second, rarer issue that 5200bas' DLIST command doesn't appear to properly guard writes to SDLSTL/H -- it is possible for the OS VBI handler to run between the two byte writes and cause a garbage display list to be set, which can be fatal with DLIs enabled. To be done safely, this either needs to be done in vertical blank or CRITIC needs to be set during the change.

[SIO2]

My guess is that you have a race between the DLI on the first screen and the charset change for the second. The DLIST command appears to write to SDLSTL/SDLSTH, which are shadow variables maintain by the OS. Those aren't actually copied into the hardware until vertical blank. That means when you attempt to switch the screen mid-frame, the old display list's DLIs are still running until the end of the frame and can still stomp CHBASE. Also, since the CHARSET command writes directly to CHBASE, running it mid-frame will cause a glitch. You can poll for a change in RTCLOK to ensure that vertical blank has started to keep changes off-screen and to wait for shadow variables to be pushed to hardware.

 

There is also a second, rarer issue that 5200bas' DLIST command doesn't appear to properly guard writes to SDLSTL/H -- it is possible for the OS VBI handler to run between the two byte writes and cause a garbage display list to be set, which can be fatal with DLIs enabled. To be done safely, this either needs to be done in vertical blank or CRITIC needs to be set during the change.

Awesome. Thank you. I'm learning so much here.

[SIO2]

Note if you're using a counter variable in RAM in a DLI - it's often a good idea to zero it during the VBlank rather than rely on the DLIs to

There is the chance that the variable value isn't what you expect, can happen if a DLI gets inadvertantly missed or if you enable DLIs partway down the screen, among other things.

I did move the counter reset to the VBI. However, when I did that it caused something else to happen. With the counter reset in the VBI, I can press the start key to leave the title screen and that works as normal. The program then goes to an options screen which I would normally be able to press start at and continue with the default settings into the game screen. With the VBI, i have to press a numeric key before it will respond to a start key press.

 

I was able to work around this by storing the original VBI vector the restoring the original vector after I am done with the my VBI routine.

 

Is this normal? What causes it and is there a better solution?

[Rybags]

I suspect that's a 5200 specific problem. Might be a key debounce problem (I assume 5200 does that). Many of the keys are read via Pokey and generate IRQs - as with the computer there needs to be a debounce algorithm as it's common for one keypress to register twice.

 

On the computer it's handled by the OS Stage 2 VBlank - not sure about the 5200. It could be the case that your own VBI stuff isn't exiting correctly. I've not got any 5200 resources here so can't look up if there's 2 exit points like on the computers.

[phaeron]

The 5200 doesn't have debouncing built into the OS -- in fact, due to the funky way the keypad is wired up, depressed keys will be reported 8 times a frame. The 5200 OS's VBI handler is similarly set up to the 400/800 OS's, except that it has a lot less to do and it only skips stage 2 on CRITIC, not on the I flag.

 

What I'm guessing is problem here is that 5200bas has its own deferred VBI handler that is used for its own debounce logic. In that case, chaining to the original handler from the custom one should solve the problem.

[SIO2]

Interesting. Thank you guys for your thoughts.