'Stealing' vertical blank vectors; immediate, deferred and their interrupts

[morelenmir]

"Atari Roots" had a fairly short section on this and in one place is very confusing.

 

i understand you use SETVBV ($e45c) to safely install your interrupt routine - however AR is not clear whether you do this directly by giving it the low and high bytes of the actual routine you want run at every vblank, or if you specify a routine whose task is to do the installation. For instance say I have these two routines:

 

@INSTALL_HANDLER LDA #@READ_STICK&255 ;routine to overwrite OS vertical blank vectors, possibly duplicating SETVBV

STA VVBLKI

LDA #@READ_STICK/256

STA VVBLKI+1

RTS

 

@READ_STICK <SOME CODE>... ;actual routine to be called on each vertical blank

...

JMP SYSVBV

 

Do I give SETVBV, through the X, Y registers the address of @INSTALL_HANDLER or @READ_STICK? In either case A should be #$7 I believe?

 

As a second point, the example given in AR overwrites the VVBLKD vector - and uses it to determine the joystick state and then manipulate PM graphics accordingly. However, in 'mapping the Atari' it is written that you should not perform graphics actions using the deferred vector. This is obviously a contradiction. Which would do you chaps suggest I use?

[phaeron]

You give it the address of the routine you actually want installed, @READ_STICK. VVBLKI/VVBLKD should not be written directly -- otherwise, if the VBI strikes between the two STA instructions you're toast. SETVBV does the job that you're trying to do in @INSTALL_HANDLER, but taking this issue into account.

 

There are two reasons that the deferred VBI is not a good place to do graphics. The first is that it runs after the OS VBI handler, so any changes to OS shadow variables like COLOR0-4 won't take effect until the frame after the next one. The second is that the deferred VBI is skipped whenever an IRQ handler is running at the point where the VBI fires, notably including the keyboard interrupt. Pretty much the only benefit of hooking the deferred VBI instead of the immediate VBI is that it keeps you from interfering with disk access.

[morelenmir]

MANY THANKS Avery!!! Your post came at EXACTLY the right time!

 

I had tried it by using SETVBV to call a routine which itself then set the VBLANK interupt. It actually seemed to work, but PLAYR0 kept flickering even when stationary. When the joystick, through this newly installed interrupt routine told the player to move that movement was jerky and uneven! I was also following the 'Atari Roots' example of using the deferred VVBLKD and XITVBV. After all the hard work over the last few days the results seemed no better than a piece of animation I could have done in BASIC! I was ready to peg out completely - possibly for good!

 

However, after your post I used SETVBV to install the actual @READ_STICK routine itself and swapped over to immediate VVBLKI and SYSVBV - and everything works!!!! PLAYR0 motion is silky smooth with no flicker whatsoever!!!

 

What would you say WAS the cause of the flicker and jerky motion though?

Edited June 4, 2013 by morelenmir

[kenjennings]

I take it you're using the code from the fine scrolling example in chapter 14:

. . .
0840 ;
0850 ; ENABLE INTERRUPT
0860 ;
0870	 LDY #TCKINT&255
0880	 LDX #TCKINT/256
0890	 LDA #6
0900	 JSR SETVBV
0910 ;
0920 ; TICKER INTERRUPT
0930 ;
0940 TCKINT
0950	 LDA #SCROLL&255
0960	 STA VVBLKI
0970	 LDA #SCROLL/256
0980	 STA VVBLKI+1
0990 ;
1000 INFIN
1010	 JMP INFIN; INFINITE LOOP
1020 ;
. . .

 

This isn't the right way to set the interrupt vector. The code at 870-900 correctly sets the vector to point to TCKINT . The TCKINT routine, though, directly sets the vector again to the SCROLL routine. That's bad (or at least not good form.) And then it goes into an infinite loop (this is during the VBI) without exiting. That's bad, too, if that was executed during a vertical blank interrupt.

 

However, the code seems to be self-repairing. The main code that called SETVBV falls directly into TCKINT. Since TCKINT resets the immediate VBI vector to the SCROLL routine the VBI should be using the SCROLL routine. There is only a slight statistical chance that the system may call TCKINT during the VBI.

 

The whole TCKINT thing was not necessary. If the code in 870-900 simply used the address of the SCROLL routine then it would be correct.

[morelenmir]

That's the one!

 

He also does the same thing in the last routine in the book - the one on pm graphics. Atari Roots is an excellent work and has made all the difference in my actually starting to pick up ASM. However I wonder if in this one case Mark Andrews genuinely did not fully understand the right way to install a interrupt handler? It is also an interesting comment on the editorial input from the publishers. I dare say at this point, in 1984 the only person who understood the content of the book was usually the author!

 

It feels... clumsy... somehow to end the routine with a infinite loop. IS there a 'proper' way to do this? When you use an interrupt vector it is very like installing a callback function in windows. But I suppose in some ways the message pump is an infinite loop with a built in method os escaping it.

[danwinslow]

In this case, the loop probably keeps you from going back to dos. As far as I know, you could go ahead and exit, and your VBI code will still execute ( as long as it doesn't get overwritten in memory ).

[kenjennings]

Yes, what danwinslow said.

 

The infinite loop is part of the main line code, not the VBI routine. It prevents the program from returning to the caller (which likely would be DOS).

 

And, yes, the VBI code will continue to run and if it is overwritten it will likely crash the system. So, if your program installs a VBI routine and you want it to exit cleanly, the program should also uninstall the VBI before exiting. (Use SETVBV to reset the vector to the original value.)

[phaeron]

Eh, looking through the various examples in Atari Roots... there are a bunch of errors in the code examples.

 

The code from chapter 9 for packing nibbles into a byte has a useless CLC instruction at the top, because ASL overwrites the carry flag. The code only works correctly because NYB1 is assumed to be in 0-15.

 

Several examples in the arithmetic chapters do lots of arithmetic on constants... which is a complete waste of bytes and source code lines.

 

There are a bunch of gratuitous NOP instructions on labels, for some reason.

 

The ATASCII-ASCII conversion routine in chapter 13 is particularly awful. It uses a big compare tree and add/subtract instructions instead of just XORing from a table based on bits 5 and 6.

 

The coarse scrolling example in chapter 13 updates a two-byte LMS pointer in the middle of a display list without synchronizing to vertical blank, so you'll get a rare but random glitch using this code. Bonus points for the bogus NOP in the middle of the display list.

 

And yes, in chapter 14 both of the examples showing how to call SETVBV are wrong and will rarely crash.

 

There's nothing wrong with an infinite loop in mainline code on the Atari. In a modern programming environment, this will get you flogged, because you'd be blocking the UI event loop and burning CPU instead of letting the CPU go to sleep or service other programs. On the Atari, there's no such thing as multitasking or sleep mode, so if there's nothing better for the CPU to do, it can run an idle loop.

[Mclaneinc]

This what I love about AtariAge, just look at this thread, loads of super talented people just queueing up to offer help..

 

Many other forums (Atari & not) have elitist coders who just look at people starting to get to grips with stuff and think its beneath them, saw this many times on the Bsnes forum (not Byuu).

 

Great to see people just saying "I can help" and doing it...

[snicklin]

There's not that many Atari coders nowadays, so it is good that new blood is being developed and retained.

[morelenmir]

Just like Mclaneinc says!!! MANY thanks chaps for giving my questions a read over and taking the time to reply. I feel like I am starting to reach 'critical mass' with ASM in that I can produce a basic programme myself now and try things out on that simple platform to learn more. It is step by step though and I am sure I will have MANY questions at each stage.

 

That is an interesting critique Phareon. I really like Atari Roots and have recommended it myself several times here. However there is nothing quite so corrosive as inaccurate material in a text book - especially for beginners like me who tend to take these things as holy writ. I guess it helps to develop a critical eye though and keeps you thinking at each stage. A definite case of 'do as I say,. not as I do'!!!

 

I can see I am really going to have to focus down on those bitsetting and logic commands - it sounds like you can use them in many places to shorten code.

[Mclaneinc]

Morelenmir, a Yorkshire man coding something properly, unheard of, I have to encourage it

 

Please, no whippet or Pigeon simulators tho

 

(For the Non UK folks, that s a bit of North / South banter)

 

Well done that man, keep the coding up...

[morelenmir]

Eeee baah gum lad, etc...

 

Maybe a brass band synthesizer??? No... A Sean Bean Synthesizer!!!

Edited June 9, 2013 by morelenmir