Hi Guillaume,

>>I hope you remember my wish for better keyboard control of animation slideshows.
>
>	No, sorry!

There is a need for two more 'hotkey' commands.

1:  Using loops for slideshows does not allow for any way of breaking that
    loop except by resetting the computer, which is not acceptable. A new
    hotkey is thus needed which does two things.  It stops the currently
    displayed animation, and passes the script to the point immediately
    beyond the next '.endr' directive.  This way it will be possible to
    exit any number of nested loops one by one.

2:  Ever since you removed it I have missed the old hotkey command for
    looping a single animation.  The new 'R' option in  the dialog is
    not as convenient, and is not available when loading an animation
    slideshow anyway.  But the hotkey would work both for separate
    animations and for those in slideshows.

I realize that you cannot have a lot of extensive tests during a running
animation, but this sort of thing can be done with *no* extra time
cost at all for up to 14 different new hotkey commands.

I will illustrate the method below. I recommend you read it with a tab
setting of 8 characters, else some parts may look very messy.


The quickest way to read 'special' keys is to simply fetch their bit flags
from the variable where TOS keyboard interrupts store them.  As I think you
know, that address is given by the TOS header in modern TOS, and for older
TOS it can be found as the byte immediately preceding the keyboard tables,
found by Keytbl(-1,-1,-1), so for old TOS the variable is at the address
(Keytbl(-1,-1,-1) - 1).

Most of my own programs contain code for the above in their initialization
routines, which stores the pointer to that variable in a local pointer that
I name kbshift_p, and which is then used whenever I want a quick peek at
the status of the 'special' keys.

I assume that you already use something similar to check for the 'Control'
key today, but there is a simple way to do it that will allow for many
keys to be tested at no extra testing cost.

First, we can make all references to the Kbshift variable of TOS much faster
by patching the code to use absolute addressing, rather than having to fetch
a pointer to an address register each time.
;-------------------------------------
;NB: The initialization routine below should only be executed once, at start
;    of program.  If this rule is broken there may be invalid data in cache
;    for instructions.  (It is also inefficient to init this stuff twice.)
;-------------------------------------
init_kbshift_p:
	xbios	Keytbl,?,?,?
	move.l	d0,a0
	lea	-1(a0),a0		;a0 = Keytbl-1 (-> old TOS Kbshift var)
	move.l	a0,kbshift_p		;preliminarily use this for kbshift_p
	move.l	(_sysbase).w,a1		;a1 -> ROM header (possibly copy)
	move.l	8(a1),a0		;a0 -> real ROM header
	move	2(a0),d0		;d0 = TOS version number in BCD code
	cmp	#$104,d0		;check for TOS 1.04
	blo.s	.done_sys_fix		;if older, keep kbshift_p from above
	move.l	36(a0),kbshift_p	;set kbshift_p via modern TOS header
.done_sys_fix:				;kbshift_p is now valid for use
	lea	kbsh_reloc_t(pc),a1	;a1 -> Kbshift relocation table
	bra.s	.relocate_next		;go start kbshift relocation
;
.relocate_loop:			;loop target
	move.l	d0,a0			;a0 -> reference location of entry
	move.l	kbshift_p(pc),(a0)	;relocate this reference
.relocate_next:
	move.l	(a1)+,d0	;get next entry in Kbshift relocation table
	bgt.s	.relocate_loop	;loop back until all references relocated
	rts			;return to caller
;-------------------------------------
kbshift_p:			;local pointer to Kbshift variable of TOS
	dc.l	0		;initialized by routine above
kbsh_reloc_t:			;relocation table for Kbshift references
	dc.l	kbsh_ref_1	;-> code that refers to Kbshift
	dc.l	kbsh_ref_2	;-> code that refers to Kbshift
	dc.l	kbsh_ref_3	;-> code that refers to Kbshift
;etc, etc, etc,
	dc.l	-1		;marks end of relocation table
;-------------------------------------
;The above means that every where in your code where you need the 'special'
;keys, you can get them with a single MOVE.B instruction. This means we can
;afford some slight extra processing to allow for multiple hotkeys, provided
;that it is done fast of course.
;-------------------------------------
;I believe that the code below, which does allow 15 different hotkey commands,
;is equally fast as, or faster than, conventional code for a single command.
;-------------------------------------
some_place_in_your_code_where_you_scan_keys:	;nice label, huh ;-)
kbsh_ref_1	=	*+2	;address in next instruction needs relocation
	move.b	$deadbeef.l,d0		;later it will be:  move.b (Kbshift).l,d0
	and	#$0F,d0			;we only want the 4 low bits
	add	d0,d0			;we jump 2 bytes per step in value
	jmp	kbsh_jumps_1(pc,d0)
kbsh_jumps_1:
	bra.s	.keys_0000
	bra.s	.keys_0001
	bra.s	.keys_0010
	bra.s	.keys_0011
	bra.s	.keys_0100
	bra.s	.keys_0101
	bra.s	.keys_0110
	bra.s	.keys_0111
	bra.s	.keys_1000
	bra.s	.keys_1001
	bra.s	.keys_1010
	bra.s	.keys_1011
	bra.s	.keys_1100
	bra.s	.keys_1101
	bra.s	.keys_1110
	bra.s	.keys_1111
;-------
.keys_0100:			;0100= Control => break current animation
	bra	break_current_animation		;in your own code
;-------
.keys_1100:			;1100= Control Alt => break script loop
	bra	break_script_loop		;in your own code
;-------
.keys_1101:			;1110= Control Alt R_shift => break slide show
	bra	break_slideshow			;in your own code
;-------
.keys_0010:			;0010= L_Shift => Loop animation
	st	loop_once_f	;=> animation loop, but only once (clears flag)
.keys_0000:			;0000= No special keys were pressed
.keys_0001:			;0001= as yet unimplemented hotkey combination
.keys_0011:			;0011= as yet unimplemented hotkey combination
.keys_0101:			;0101= as yet unimplemented hotkey combination
.keys_0110:			;0110= as yet unimplemented hotkey combination
.keys_0111:			;0111= as yet unimplemented hotkey combination
.keys_1000:			;1000= as yet unimplemented hotkey combination
.keys_1001:			;1001= as yet unimplemented hotkey combination
.keys_1010:			;1010= as yet unimplemented hotkey combination
.keys_1011:			;1011= as yet unimplemented hotkey combination
.keys_1110:			;1110= as yet unimplemented hotkey combination
.keys_1111:			;1111= as yet unimplemented hotkey combination
.continue:	;This is where you continue when no key command was given
;-------------------------------------

In the code above I have shown 4 keycodes as being implemented, as I feel
it would also be a strength to be able to break the entire slideshow when
the user is tired of it.  But this command should not be easy to give by
mistake, so I included the right shift to force the use of both hands to
give this command.


>>If you have visited my pages lately, I think you know what I mean.
>>If you have not, then perhaps you should.
>
>        I nearly never use the WEB: I spend too much money in phone calls
>and the WEB is "a hole for money" as we use to say in french, so I don't
>dare... cause I know that when I'm connected, I can't stop!

Well, it helps if you use the principle of not visiting links that you have
not planned to.  Just save those links and consider later whether they are
worth a visit or not.  It is not wise to link around wildly.  That can use
up days of online time without really leading anywhere.

But if you never use the web, or almost, then you can't find all the nice
updates other programmers have on their homepages.  More and more software
is being released only on homepages, rather than at FTP sites and BBS's as
was more common before.


>>Yesterday I uploaded some new client programs for the EZ-IP service.
>>But a lot of my time lately has been spent on mail and newsgroups,
>>where I mostly explain to various users how to install STinG 1.20 .
>>(Doesn't anyone read docs nowdays ?)
>
>        I couldn't use STING 1.2... But I won't ask you for explanations,
>I'm satisfied with the older one.

Ok, that's up to you, but if you want compatibility to any future drivers,
then you will need to update eventually, as port drivers in this version
are not compatible with older ones (a necessary improvement of structure).

That's probably why it didn't work for you, if you let some old port
driver STX remain.

Still, as long as you don't wany to update any parts, older STinG versions
will naturally continue to work as before (though no longer supported).
