Programming a delay in assembly language

[fuzzel]

I have a puzzle in my forthcoming text adventure, MIST, where I need to print a series of messages with a pause between each one.
Something like the following is what I have in mind:

<Message 1> . (1 second pause) . (one second pause) . (one second pause).
<Message 2> . (1 second pause) . (one second pause) . (one second pause).
<Message 3> . (1 second pause) . (one second pause) . (one second pause).

I'd like an extremely brief subroutine (.onesecpause) to call 3 times after each message, does anyone have a little subroutine they could offer?

[MartinB]

From some of my code, I /think/ the lower delay routine of 256 X by 256 Y is about 0.16s at 2MHz so at bigwait, setting wcount to 6 as shown would give about a second but you can easily have a play with that specific number and see what you get. Note that as it stands, it trashes all the registers so if you want to preserve any of A, X or Y, push them first and pull them afterwards and in your main code, you're just calling (JSR) bigwait.

Code: Select all

bigwait	LDA	#6
	STA	wcount
bw1	JSR	delay
	DEC	wcount
	BNE	bw1
	RTS

delay	LDY	#255		/about 0.16s @ 2MHz 
dloop2	LDX	#255
dloop1	DEX
	BNE	dloop1
	DEY
	BNE	dloop2
	RTS

This code-only method avoids any hardware dependencies other than the clock speed and you could just halve the number used at bigwait for a 1MHz system if you needed to.

[fuzzel]

Brilliant thanks, will play around with it.
It’s also brief which is ideal.

[MartinB]

No worries - you could also add a vdelay label at the STA wcount and then for variable delays, just perform LDA #nn , JSR vdelay in your main code to get variable delays. So if 6 is about right for 1 second, doing LDA #60 , JSR vdelay for example would give you a 10s delay if you wanted such flexibility.

[dv8]

If you don't need precise timing, you could do something like this:

Code: Select all

.delay1s  LDA #50
.delay    STA &70
.loop     LDA #19
          JSR &FFF4
          DEC &70
          BNE loop
          RTS

It uses OSBYTE 19 to wait for a vertical sync (which happens 50 times per second), so 50 times round the loop gives a delay of roughly 1 sec.

[Rich Talbot-Watkins]

That was the exact code I was going to post, although I would've left the LDA #19 outside the loop

Y'know... For speed!

[roland]

I think the osbyte delay is more precisely. Both routines will be interupted by interrupts and the first routine is definitively delayed by them. The second method has an independent time source so it might less suffer from the interrupts.

Although I didn't compare them on my Electron. Speaking of the Electron... The Elk runs at 1MHz when these routines are stored in program memory which makes the first method not compatible for both Elk and Beeb.

[MartinB]

A pause between messages in a text adventure doesn’t require millisecond accuracy and as I specifically said in my post, I was suggesting code that was hardware agnostic other than an assumtption of CPU clock speed. I also explicitly pointed out that for different processor clock speeds, you can vary the constants accordingly.
Importantly, in response to the thread title, I was offering generic code that demonstrates how to expend a delay in 6502 assembler which IMHO is a much better approach when someone is on the machine-code learning curve. Creating delays using machine-specific timers and hence exploiting bespoke hardware artefacts is a different concept and in my opinion, only teaches unique methods that cannot then be freely ported to other non-Acorn 6502 machines as you can do with ‘code-only’ routines such as the one I posted.
So yes, you could indeed use display timers or set up VIA timers or even use RTC’s but none of those methods demonstrate how to create a delay using only the native code of the host CPU which I personally thought was the most beneficial approach. Perhaps I was wrong.

[roland]

You're right Martin, your code is universal for all 6502 systems and can easily be ported to other processors as well. I just wanted to add my comments to mention the fact that interrupts will disturb this way of timing and they are often overlooked. Like I did on my ElkWifi project....

For a game this isn't any problem at all and no human will notice 5 ms extra waiting time a second. But if somebody uses this method for critical timing he or she is now warned

[MartinB]

No worries Roland, it's my own fault - I decided many years ago not to post code on here anymore because its always too stressful but, a simple delay sounded seductively easy so I dropped my guard....

(That's also the reason why you have to ask to see any of my project sources Roland, I'll definitely never be throwing myself into the Github pit of serpents.... )

[leenew]

No worries Roland, it's my own fault - I decided many years ago not to post code on here anymore because its always too stressful but, a simple delay sounded seductively easy so I dropped my guard....

(That's also the reason why you have to ask to see any of my project sources Roland, I'll definitely never be throwing myself into the Github pit of serpents.... )

Now I know why you chose you current avatar

Lee.

[fuzzel]

Thanks to everyone involved for the suggestions. MartinB's offering was something I was contemplating before I created the topic although he wrote it more efficiently than I would I imagine. dv8's solution involving OSBYTE 19 and being the very essence of brevity is not something I'd have considered as I'm not that au-fait with FX calls (which is a good reason why I asked the question) despite having the user guide and advanced user guide in close proximity for reference. I really should read them through one day. So I'll use the OSBYTE 19 solution because I'm not that bothered about the exact length of the delay but if I was I would use MartinB's which would enable precise timing I guess.

[MartinB]

Stewie small.gif (16.57 KiB) Viewed 2988 times