Machine-code key-scan problem

discussion of beeb/electron applications, languages, utils and educational s/w
Post Reply
User avatar
lurkio
Posts: 1744
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Machine-code key-scan problem

Post by lurkio » Mon Feb 15, 2016 1:26 pm

Hi, all. Can anyone tell me why the following machine code, which just waits till the user presses "A" on the keyboard, always causes "A" to be printed at the commandline after it exits, even though the last thing it does is flush all buffers, presumably including the keyboard input buffer?! How can I suppress the printing of the "A"?

Code: Select all

 10 MODE7
 20 osbyte=&FFF4
 30 FOR O%=0 TO 3 STEP 3
 40 P%=&3000
 50 [OPT O%
 60 \ flush all buffers:
 70 LDA #&0F
 80 LDX #&00
 90 JSR osbyte
100 .scankey
110 LDY #&FF
120 LDX #&BE
130 LDA #&81
140 JSR osbyte
150 CPY #&FF
160 BNE scankey
170 \ flush all buffers:
180 LDX #&00
190 LDA #&0F
200 JSR osbyte
210 RTS
220 ]
230 NEXT
240 PRINT '"Press 'A' to exit"
250 CALL&3000
1.png
Screenshot
keydemo.ssd.zip
.ssd disc image of program
(525 Bytes) Downloaded 23 times

User avatar
roland
Posts: 2931
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: Machine-code key-scan problem

Post by roland » Mon Feb 15, 2016 1:54 pm

Probably the osbyte call also prints the character. In that case it is already printed at the moment you flush the buffers.

You have probably two options:
1. Suppress the output by doing a VDU 21 equivalent ( LDA #21:JSR &FFEE )
2. Use the keyboard scan OSBYTE &79 ( http://beebwiki.mdfs.net/OSBYTE_%2679 )

If you use the first option then don't forget to re-enable the output with VDU 6
256K + 6502 Inside
MAN WOMAN :shock:

User avatar
lurkio
Posts: 1744
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Machine-code key-scan problem

Post by lurkio » Mon Feb 15, 2016 3:36 pm

Roland, thanks for the reply.
roland wrote:Probably the osbyte call also prints the character. In that case it is already printed at the moment you flush the buffers.
Can you expand on that? The char is printed to the right of the BASIC commandline prompt, so doesn't that mean that BASIC has taken over before the char is printed? So shouldn't the *FX15,0 in the machine code prevent that from happening? I guess I don't understand the sequence of events that are taking place deep inside the Beeb here!
roland wrote:You have probably two options:
1. Suppress the output by doing a VDU 21 equivalent ( LDA #21:JSR &FFEE )
I'll get back to that if it's the only thing that'll work.
roland wrote: 2. Use the keyboard scan OSBYTE &79 ( http://beebwiki.mdfs.net/OSBYTE_%2679 )
I tried that. See code below. Same result! The "A" still gets printed on screen. Am I doing something wrong here? (Also, why does X need to be loaded with #&BE for OSBYTE &81, but with #&C1 for OSBYTE &79?!)

Am v confused, as you can probably tell!
1.png
Screenshot

Code: Select all

10 MODE7
20 osbyte=&FFF4
30 FOR O%=0 TO 3 STEP 3
40 P%=&3000
50 [OPT O%
60 \ flush all buffers:
70 LDA #&0F
80 LDX #&00
90 JSR osbyte
100 .scankey
110 LDY #0
120 LDX #&C1
130 LDA #&79
140 JSR osbyte
145 TXA
160 BPL scankey
170 \ flush all buffers:
180 LDX #&00
190 LDA #&0F
200 JSR osbyte
210 RTS
220 ]
230 NEXT
240 PRINT '"Press 'A' to exit"
250 CALL&3000

User avatar
BigEd
Posts: 2060
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Machine-code key-scan problem

Post by BigEd » Mon Feb 15, 2016 4:06 pm

Do you get any better results using
&15 Flush Selected Buffer
http://beebwiki.mdfs.net/OSBYTE_%2615
?

User avatar
lurkio
Posts: 1744
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Machine-code key-scan problem

Post by lurkio » Mon Feb 15, 2016 4:33 pm

BigEd wrote:Do you get any better results using &15 Flush Selected Buffer http://beebwiki.mdfs.net/OSBYTE_%2615 ?
No. Same result! :(

User avatar
billcarr2005
Posts: 1225
Joined: Fri Sep 09, 2005 3:01 pm
Location: UK
Contact:

Re: Machine-code key-scan problem

Post by billcarr2005 » Mon Feb 15, 2016 4:34 pm

Could you not continue using OSBYTE &81, but check X for being the value of "A" within the time limit or key press, and if not it'll repeat?
EDIT: Seems that you don't need to also check if Y was &FF for the time out since if X isn't correct, it'll loop again anyway.

Code: Select all

CPX#&41
BNE scankey
CPY#&FF     / not needed 
BEQ scankey /

User avatar
hoglet
Posts: 7450
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Machine-code key-scan problem

Post by hoglet » Mon Feb 15, 2016 4:43 pm

Bit of a cludge, but you could try adding:

Code: Select all

    205 JSR &FFE0
to consume the key press.

Dave

User avatar
lurkio
Posts: 1744
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Machine-code key-scan problem

Post by lurkio » Mon Feb 15, 2016 4:56 pm

billcarr2005 wrote:Could you not continue using OSBYTE &81, but check X for being the value of "A" within the time limit or key press, and if not it'll repeat? EDIT: Seems that you don't need to also check if Y was &FF for the time out since if X isn't correct, it'll loop again anyway.

Code: Select all

CPX#&41
BNE scankey
CPY#&FF     / not needed 
BEQ scankey /
That doesn't quite work for me -- although "A" isn't printed any more, you now have to press "A" twice to exit! I was doing this:

Code: Select all

 10 MODE7
 20 osbyte=&FFF4
 30 FOR O%=0 TO 3 STEP 3
 40 P%=&3000
 50 [OPT O%
 60 \ flush all buffers:
 70 LDA #&0F
 80 LDX #&00
 90 JSR osbyte
100 .scankey
110 LDY #0
120 LDX #0
130 LDA #&81
140 JSR osbyte
150 CPX #&41
160 BNE scankey
170 \ flush all buffers:
180 LDX #&00
190 LDA #&0F
200 JSR osbyte
205 JSR &FFE0
210 RTS
220 ]
230 NEXT
240 PRINT '"Press 'A' to exit"
250 CALL&3000
[/s]

Er, can you spot the deliberate mistake there?

:oops:

Code: Select all

 10 MODE7
 20 osbyte=&FFF4
 30 FOR O%=0 TO 3 STEP 3
 40 P%=&3000
 50 [OPT O%
 60 \ flush all buffers:
 70 LDA #&0F
 80 LDX #&00
 90 JSR osbyte
100 .scankey
110 LDY #0
120 LDX #0
130 LDA #&81
140 JSR osbyte
150 CPX #&41
160 BNE scankey
170 \ flush all buffers:
180 LDX #&00
190 LDA #&0F
200 JSR osbyte
210 RTS
220 ]
230 NEXT
240 PRINT '"Press 'A' to exit"
250 CALL&3000
Thanks, Bill! Although, the advantage of the code I pasted in response to Dave hoglet's suggestion below is that it's case-insensitive, whereas your solution will exit on an uppercase-A keypress only, not on a lowercase-A.

:roll:
Last edited by lurkio on Mon Feb 15, 2016 5:30 pm, edited 7 times in total.

User avatar
lurkio
Posts: 1744
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Machine-code key-scan problem

Post by lurkio » Mon Feb 15, 2016 4:57 pm

hoglet wrote:Bit of a cludge, but you could try adding:

Code: Select all

    205 JSR &FFE0
to consume the key press.
Cludge? Cludge? Seems like the height of elegance to me! More importantly, it works! =D> Thanks!

Code: Select all

 10 MODE7
 20 osbyte=&FFF4:osrdch=&FFE0
 30 FOR O%=0 TO 3 STEP 3
 40 P%=&3000
 50 [OPT O%
 60 \ flush all buffers:
 70 LDA #&0F
 80 LDX #&00
 90 JSR osbyte
100 .scankey
110 LDY #&FF
120 LDX #&BE
130 LDA #&81
140 JSR osbyte
150 CPY #&FF
160 BNE scankey
170 \ flush all buffers:
180 LDX #&00
190 LDA #&0F
200 JSR osbyte
205 JSR osrdch
210 RTS
220 ]
230 NEXT
240 PRINT '"Press 'A' to exit"
250 CALL&3000
Now to go off and try to figure out why it works (and whether it has anything to do with the difference between an input stream and a keyboard buffer)...

:? :-k

User avatar
sweh
Posts: 1950
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Machine-code key-scan problem

Post by sweh » Mon Feb 15, 2016 5:10 pm

Just as a silly thought; add a delay between returning from checking the scancode and then cleaning the buffer. It's possible you might be hitting a race condition ("scancode detected; buffered cleared; OS enters key into buffer").

OK... so I just tested with BeebEm

Doing

Code: Select all

LDY #20
LDX #0
.CL
DEX
BNE CL
DEY
BNE CL
just before flushing seemed to work. But setting Y to 10 didn't work. So definitely seems to be a race condition; you're clearing the buffer before the character has been inserted by the OS.
Rgds
Stephen

User avatar
lurkio
Posts: 1744
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Machine-code key-scan problem

Post by lurkio » Mon Feb 15, 2016 5:16 pm

sweh wrote:Just as a silly thought; add a delay between returning from checking the scancode and then cleaning the buffer. It's possible you might be hitting a race condition ("scancode detected; buffered cleared; OS enters key into buffer"). OK... so I just tested with BeebEm Doing

Code: Select all

LDY #20
LDX #0
.CL
DEX
BNE CL
DEY
BNE CL
just before flushing seemed to work. But setting Y to 10 didn't work. So definitely seems to be a race condition; you're clearing the buffer before the character has been inserted by the OS.
Wow! :shock:

Obvious, really. :wink:

User avatar
hoglet
Posts: 7450
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Machine-code key-scan problem

Post by hoglet » Mon Feb 15, 2016 5:18 pm

Does it depend on how quickly you release the key?

Or is it down to the interrupt latency from the initial key press?

Dave

User avatar
lurkio
Posts: 1744
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Machine-code key-scan problem

Post by lurkio » Mon Feb 15, 2016 5:25 pm

hoglet wrote:Does it depend on how quickly you release the key? Or is it down to the interrupt latency from the initial key press?
Erm, I'm not sure. (Mainly because I don't entirely understand the question! :oops: )

However, two points:

1. With Y set to 20, I can sometimes still get "A" to be printed, but only very rarely.

2. Still with Y set to 20, try typing "a" (lowercase A), instead of "A"!

Code: Select all

 10 MODE7
 20 osbyte=&FFF4
 30 FOR O%=0 TO 3 STEP 3
 40 P%=&3000
 50 [OPT O%
 60 \ flush all buffers:
 70 LDA #&0F
 80 LDX #&00
 90 JSR osbyte
100 .scankey
110 LDY #&FF
120 LDX #&BE
130 LDA #&81
140 JSR osbyte
150 CPY #&FF
160 BNE scankey
162 LDY #20
163 LDX #0
164 .CL
165 DEX
166 BNE CL
167 DEY
168 BNE CL
170 \ flush all buffers:
180 LDX #&00
190 LDA #&0F
200 JSR osbyte
210 RTS
220 ]
230 NEXT
240 PRINT '"Press 'A' to exit"
250 CALL&3000

User avatar
MartinB
Posts: 4909
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Machine-code key-scan problem

Post by MartinB » Mon Feb 15, 2016 7:21 pm

This is a latency issue and I've encountered it before - if you know there's a key coming into the buffer as in this situation, you can use an OSBYTE &91 loop to wait for and then remove the character from the keyboard buffer. The Carry flag returning clear indicates when we've caught the character so a simple BCS loop does the job....

Code: Select all

 
  <snip>
  170 \ remove the incoming kb character when it arrives
  180 LDX #&00
  190 LDA #&91
  195 .KGET
  200 JSR osbyte
  205 BCS KGET
  210 RTS
  220 ]
  230 NEXT
  240 PRINT '"Press 'A' to exit"
  250 CALL&3000

User avatar
sweh
Posts: 1950
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Machine-code key-scan problem

Post by sweh » Mon Feb 15, 2016 8:05 pm

MartinB wrote:This is a latency issue and I've encountered it before - if you know there's a key coming into the buffer as in this situation, you can use an OSBYTE &91 loop to wait for and then remove the character from the keyboard buffer.
If you know a character is arriving then a simple OSRDCH (FFE0, as hoglet suggested) is easier. Of course it depends on the main code loop; OSRDCH is "blocking" and will wait until the character arrives, but with your more complicated loop then other processing could be done in the mean time.
Rgds
Stephen

User avatar
sweh
Posts: 1950
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Machine-code key-scan problem

Post by sweh » Mon Feb 15, 2016 8:07 pm

lurkio wrote: 1. With Y set to 20, I can sometimes still get "A" to be printed, but only very rarely.
That's the problem with using timing loops to work around race conditions. They're "bad design" and shouldn't be in production code. Either use a blocking call (OSRDCH, as per hoglet) or a polling loop (as per MartinB) to be sure you're not racing.

I only added the code to demonstrate it was a race condition; not as a solution :-)
Rgds
Stephen

User avatar
sweh
Posts: 1950
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Machine-code key-scan problem

Post by sweh » Mon Feb 15, 2016 8:08 pm

hoglet wrote:Or is it down to the interrupt latency from the initial key press?
This.
Rgds
Stephen

User avatar
lurkio
Posts: 1744
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Machine-code key-scan problem

Post by lurkio » Mon Feb 15, 2016 8:35 pm

sweh wrote:That's the problem with using timing loops to work around race conditions. They're "bad design" and shouldn't be in production code. Either use a blocking call (OSRDCH, as per hoglet) or a polling loop (as per MartinB) to be sure you're not racing.
So, can we assume that in these circumstances this particular race condition (the buffer-flush coming too late) will always occur, and therefore there'll definitely be a char waiting to be consumed?

User avatar
MartinB
Posts: 4909
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Machine-code key-scan problem

Post by MartinB » Mon Feb 15, 2016 8:38 pm

Stephen wrote:If you know a character is arriving then a simple OSRDCH (FFE0, as hoglet suggested) is easier. Of course it depends on the main code loop; OSRDCH is "blocking" and will wait until the character arrives, but with your more complicated loop then other processing could be done in the mean time.
I mentioned knowing a character is coming to keep the 'fix' simple in lurkio's example context. I think the advantage of a polling loop is that even if you don't know whether or not an event may occur, you can remain in control by using a counter and polling for a finite number of cycles with the cumulative waiting (looping) time being far in excess of the maximum possible latency. In this way, the code won't ever hang if the event doesn't occur but if the event does occur, processing can promptly continue.

User avatar
sweh
Posts: 1950
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Machine-code key-scan problem

Post by sweh » Mon Feb 15, 2016 9:19 pm

lurkio wrote:So, can we assume that in these circumstances this particular race condition (the buffer-flush coming too late) will always occur, and therefore there'll definitely be a char waiting to be consumed?
The race is that your flush is coming too early, before the character has entered the buffer.

Now since your trigger condition is "keyscan code matched" and that can only happen (for this key, anyway) when a keypress has occured, you know a key has been pressed and so a character will enter the buffer.

You can't assume the same for non-inserting keys (eg shift, control) of course.
Rgds
Stephen

User avatar
sweh
Posts: 1950
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Machine-code key-scan problem

Post by sweh » Mon Feb 15, 2016 9:20 pm

MartinB wrote:
Stephen wrote:If you know a character is arriving then a simple OSRDCH (FFE0, as hoglet suggested) is easier. Of course it depends on the main code loop; OSRDCH is "blocking" and will wait until the character arrives, but with your more complicated loop then other processing could be done in the mean time.
I mentioned knowing a character is coming to keep the 'fix' simple in lurkio's example context. I think the advantage of a polling loop is that even if you don't know whether or not an event may occur, you can remain in control by using a counter and polling for a finite number of cycles with the cumulative waiting (looping) time being far in excess of the maximum possible latency. In this way, the code won't ever hang if the event doesn't occur but if the event does occur, processing can promptly continue.
Umm, we're saying the same thing, but using different words.
Rgds
Stephen

User avatar
lurkio
Posts: 1744
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Machine-code key-scan problem

Post by lurkio » Mon Feb 15, 2016 9:29 pm

sweh wrote:
lurkio wrote:So, can we assume that in these circumstances this particular race condition (the buffer-flush coming too late)...
The race is that your flush is coming too early...
Too early! Too early! That's what I meant, honest!

Oh, who am I kidding? It's back to the calm, still waters of BASIC for me...

duikkie
Posts: 2879
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: Machine-code key-scan problem

Post by duikkie » Tue Feb 16, 2016 3:48 am

TOO little,TOO late :)
i don't realy see the problem , but let me tell what my logical mind is telling me :)
you flush the input buffer, oke it is empty now. ( i think there was nothing in the firtst place)
then you ask for key scan, oke then
if you press A it goes to work , put A in keybuffer and then put A to screen. THEN THE KEYBUFFER IS ALREADY EMPTY
then you ask again to empty the key buffer ???

if you don't want A to screen , you can :

disable the KEY buffer, or you can DISable output to screen.

there is no error here. the machine is doing what it must do, the problem is that the human what something else :)


lurkio wrote:
sweh wrote:
lurkio wrote:So, can we assume that in these circumstances this particular race condition (the buffer-flush coming too late)...
The race is that your flush is coming too early...
Too early! Too early! That's what I meant, honest!

Oh, who am I kidding? It's back to the calm, still waters of BASIC for me...

User avatar
billcarr2005
Posts: 1225
Joined: Fri Sep 09, 2005 3:01 pm
Location: UK
Contact:

Re: Machine-code key-scan problem

Post by billcarr2005 » Tue Feb 16, 2016 8:19 am

lurkio wrote: Thanks, Bill! Although, the advantage of the code I pasted in response to Dave hoglet's suggestion below is that it's case-insensitive, whereas your solution will exit on an uppercase-A keypress only, not on a lowercase-A.

:roll:
Then the solution could be

Code: Select all

TXA
AND#&DF  /put any alphabetical input into uppercase
CMP#&41  /compare it with "A"
BNE scankey
That way there's no flushing,no timing and no consuming keypresses required!

User avatar
lurkio
Posts: 1744
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Machine-code key-scan problem

Post by lurkio » Tue Feb 16, 2016 5:48 pm

billcarr2005 wrote:Then the solution could be ... That way there's no flushing,no timing and no consuming keypresses required!

Code: Select all

 10 MODE7
 20 osbyte=&FFF4
 30 FOR O%=0 TO 3 STEP 3
 40 P%=&3000
 50 [OPT O%
 60 \ flush all buffers:
 70 LDA #&0F
 80 LDX #&00
 90 JSR osbyte
100 .scankey
110 LDY #0
120 LDX #0
130 LDA #&81
140 JSR osbyte
145 TXA
146 AND#&DF
150 CMP #&41
160 BNE scankey
170 \ flush all buffers:
180 \LDX #&00
190 \LDA #&0F
200 \JSR osbyte
210 RTS
220 ]
230 NEXT
240 PRINT '"Press 'A' to exit"
250 CALL&3000
Thanks again! So, this particular OSBYTE &81 routine (the time-limit scan) is implemented in such a way that it doesn't put the char on the buffer, whereas the other OSBYTE &81 routine (the specific-key scan, which takes different params) does put the char on the buffer, I guess..?

:?

duikkie
Posts: 2879
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: Machine-code key-scan problem

Post by duikkie » Tue Feb 16, 2016 6:20 pm

why tolk about key scan ? , &81 is readkey, &7a and &79 is keyboard scan.
with x=0 and y=0 timelimit=0 and because it checks until x has value it waits :)
lurkio wrote:
billcarr2005 wrote:Then the solution could be ... That way there's no flushing,no timing and no consuming keypresses required!

Code: Select all

 10 MODE7
 20 osbyte=&FFF4
 30 FOR O%=0 TO 3 STEP 3
 40 P%=&3000
 50 [OPT O%
 60 \ flush all buffers:
 70 LDA #&0F
 80 LDX #&00
 90 JSR osbyte
100 .scankey
110 LDY #0
120 LDX #0
130 LDA #&81
140 JSR osbyte
145 TXA
146 AND#&DF
150 CMP #&41
160 BNE scankey
170 \ flush all buffers:
180 \LDX #&00
190 \LDA #&0F
200 \JSR osbyte
210 RTS
220 ]
230 NEXT
240 PRINT '"Press 'A' to exit"
250 CALL&3000
Thanks again! So, this particular OSBYTE &81 routine (the time-limit scan) is implemented in such a way that it doesn't put the char on the buffer, whereas the other OSBYTE &81 routine (the specific-key scan, which takes different params) does put the char on the buffer, I guess..?

:?

User avatar
lurkio
Posts: 1744
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Machine-code key-scan problem

Post by lurkio » Fri Feb 19, 2016 12:24 am

Thanks, everyone, for helping me try to see what was going on with the OSBYTE calls. I'm still not sure I completely get it, but that's entirely my fault. #-o

Anyway, the reason I asked the initial question is that I was trying to disassemble, annotate, and understand a Mode 7 text scroller that I found on some PD disc and shamelessly nicked.

Here it is, for what it's worth. I've kind of sidestepped the keyboard buffer flush-fail issues by using Escape as the exit key, which doesn't seem to present any of the problems we've been discussing in this thread! So, er, sorry for wasting your time! :oops:

Code: Select all

  20MODE7
  30M$="Lorem ipsum dolor sit amet, consectetuer adipiscing elit. "
  40S%=TOP+LEN(M$)+&100:PRINT"Enter starting addr (&";STR$~(S%);" or higher):"'"&";:INPUT""S$:IFS$=""S$="0"
  50start%=EVAL("&"+S$):IF start%<S% start%=S%
  60PRINT'"Assembling at &";STR$~(start%);"..."'
  70oswrch=&FFEE:oscli=&FFF7:osbyte=&FFF4
  80FORO%=0TO2STEP2
  90P%=start%
 100[OPT O%
 110EQUB text MOD 256
 120EQUB text DIV 256
 130EQUB (end-&3E8) MOD 256
 140EQUB (end-&3E8) DIV 256
 150\*FX229,1
 160LDA#229:LDX#1:LDY#0
 170JSR osbyte
 180STX &76
 190\VDU22,7:
 200LDA #&16
 210JSR oswrch
 220LDA #&07
 230JSR oswrch
 240\*KEY0:
 250LDX #k0 MOD 256
 260LDY #k0 DIV 256
 270JSR oscli
 280\cursor off:
 290LDA #&17
 300JSR oswrch
 310LDA #&01
 320JSR oswrch
 330LDX #&08
 340LDA #&00
 350.vduloop
 360JSR oswrch
 370DEX
 380CPX #&00
 390BNE vduloop
 400\flush all buffers:
 410LDA #&0F
 420LDX #&00
 430JSR osbyte
 440\keybd autorpt delay = 0.01s (normally 0.1s):
 450LDA #&0C
 460LDX #&01
 470JSR osbyte
 480\current pos in &74-5:
 490LDA start%
 500STA &74
 510LDA start%+1
 520STA &75
 530.preblatt
 540LDA &74
 550STA &70
 560LDA &75
 570STA &71
 580\wait for vsync:
 590LDA #&13
 600JSR osbyte
 610LDX #&04
 620LDA #&7C
 630STA &73
 640LDA #&00
 650STA &72
 660.outerblatt
 670LDY #&00
 680.blatt
 690LDA (&70),Y
 700STA (&72),Y
 710INY
 720BNE blatt
 730INC &73
 740INC &71
 750DEX
 760BNE outerblatt
 770.scankey
 780LDY #&FF
 790LDX #&C6
 800LDA #&81
 810JSR osbyte
 820CPY #&FF
 830BEQ cursorup
 840LDY #&FF
 850LDX #&D6
 860LDA #&81
 870JSR osbyte
 880CPY #&FF
 890BEQ cursordown
 900LDY #&FF
 910LDX #&8F
 920LDA #&81
 930JSR osbyte
 940CPY #&FF
 950BEQ fin
 960BNE scankey
 970.cursorup
 980LDA &75
 990CMP start%+1
1000BNE scrollup
1010LDA &74
1020CMP start%
1030BNE scrollup
1040BEQ scankey
1050.scrollup
1060LDA &74
1070SEC
1080SBC #&28
1090STA &74
1100LDA &75
1110SBC #&00
1120STA &75
1130JMP preblatt
1140.cursordown
1150LDA &75
1160CMP start%+3
1170BNE scrolldown
1180LDA &74
1190CMP start%+2
1200BNE scrolldown
1210BEQ scankey
1220.scrolldown
1230LDA &74
1240CLC
1250ADC #&28
1260STA &74
1270LDA &75
1280ADC #&00
1290STA &75
1300JMP preblatt
1310.fin
1320\flush all buffers:
1330LDX #&00
1340LDA #&0F
1350JSR osbyte
1360\*FX138,0,128:
1370LDA #&8A
1380LDX #&00
1390LDY #&80
1400JMP osbyte
1410\*KEY0:
1420.k0 EQUS"*K.0MODE7|MREMÜFinal BASIC commands go here|M*FX229|M"
1430EQUB &0D
1440.text
1450]
1460T%=P%
1470N%=(1000DIVLEN(M$))*4
1480FORI%=1TON%:$P%=M$:P%=P%+LEN($P%):NEXT
1490$P%=STRING$(40-((P%-T%)MOD40),"-"):P%=P%+LEN($P%):?P%=0
1500[OPT O%
1510.end
1520]
1530NEXT
1540PRINT"&";STR$~(start%);" contains the text start-address   (lo-byte first). &";STR$~(start%+2);" contains text endaddress minus &3E7."''"Arrow keys scroll, ESCAPE exits."'
1550PRINT"Press RETURN to run code":REPEAT:*FX21,0
1560UNTILGET=13:*FX21,0
1570CALL(start%+4)

scrolldemo.ssd.zip
Scroller demo, disc image
(2.11 KiB) Downloaded 30 times
:idea:

Post Reply