Alternatives To TIMER

[mrdalliard]

So, STOS has a function called TIMER. However, it only displays the time in 50th/second, which isn't accurate enough for my purposes.

I've coded a demo in STOS but it uses rasters. Because whatever happens during the VBL (it runs at 50hz) can take a variable amount of time, my rasters have a habit of being a bit "wobbly". I'd like to use a more precise timer to control that and draw them at precisely the same time.

Anyone encountered this issue? Or found a way to be more precise with cycles during a VBL?

Thanks,

M.

[charles]

install your own timer using the a timer at whatever frequency desired

[ThorstenOtto]

You could use the 200Hz timer, but this isn't much more accurate either. Timer-A could be set to a much higher frequency, but

a) it s often used for sound
b) might be already in use by STOS or some extension
c) setting it to a high frequency uses quite some cpu time just to process the exceptions.

[evil]

Using MFP Timer B in HBL event mode is the solution.

Save the MFP registers and restore them at exit, save and restore the Timer B vector ($120) as well.

Then the code at VBL and interrupt can look a bit like this:

Code: Select all

vbl:
clr.b $fffffa1b.w ;Timer B control (stop)
bset #0,$fffffa07.w ;Interrupt enable A (Timer B)
bset #0,$fffffa13.w ;Interrupt mask A (Timer B)
move.b #100,$fffffa21.w ;Timer B data (number of scanlines to next interrupt)
bclr #3,$fffffa17.w ;Automatic end of interrupt
move.b #8,$fffffa1b.w ;Timer B control (event mode (HBL))

timerb:
move.w #$0700,$ffff8240.w ;set a colour
clr.b $fffffa1b.w ;Timer B control (stop)

How to translate this into basic I don't know :-/

Here's a source I made for Spiny many many years ago (not speed optimized at all, but easy to read, I hope):
https://files.dhs.nu/files_source/spiny.s

[mlynn1974]

Are your rasters using the raster examples from here?
https://www.exxosforum.co.uk/atari/STOS ... /index.htm
These are examples written in assembly language, loaded in a memory bank, setup and then the rasters are refreshed every frame.

Neil W. Stewart also wrote some raster examples. They use MFP Timer B in HBL event mode.
I can't remember if they were bundled with the registered copy of Misty or if they were written before that.
They were not included as extension commands.

[thomas3]

There's a RASTER command in the registration version of the Missing Link iirc.

@op - are you trying to do your rasters in pure STOS?

[spiny]

Here's a source I made for Spiny many many years ago (not speed optimized at all, but easy to read, I hope):
https://files.dhs.nu/files_source/spiny.s

and it is still helping me learn

[mlynn1974]

I have attached the raster routine written by Neil (from Flair) and Colin (from ACO).
This may have been included with the registered version of Misty but I had it on a disk I exchanged with Colin back in the day. I used it in 2 demos.

The rasters run on an interrupt so it frees up the main loop. You cannot use INKEY$ when running the rasters so I use hardkey instead.

Developer note: I couldn't save the PRG from an existing demo and load it into a new demo.
STOS must do some relocation when PRGs are loaded into memory banks.

This is not the raster routine used in Neil Halliday's BPOM demo.

[mrdalliard]

Sorry for the delayed reply on this one. What I originally did was this:

for n=1 to 16: doke $ff8240,C(N): for W=1 to 4: Next W: Next N

C is an array of colours. There's 16 values.

So when it draws, there's a tiny bit of "wobble" to it. Obviously it's not using any form of timer or interrupt within the STOS code to keep it constant.

I'll take a look at the other examples given. Thanks.

M.

[thomas3]

It's a brave person who tries this in STOS alone - I like it!!

But yeah, even in assembly language, to do this without interrupts would involve synchronising your code to the electron beam - i.e. cycle-precise stuff. STOS, in contrast, will have jitter added from all over the place (it keeps the system timer C running for example), plus command execution time is unpredictable.

Try the raster command in the Missing Link. It also will save you having to burn CPU time.

Elsewhere on this forum, I provided a patch to disable the system timer C (to kill jitter when using commands like this) which mat be of interest - let me find the link

[thomas3]

Here ya go
viewtopic.php?t=39305

[mrdalliard]

It's a brave person who tries this in STOS alone - I like it!!

Yeah, is "brave" the word?

I'm having some fun, though. I've coded two screens in the last month or so and just need to put a few things to bed like this which don't make things look so good.

I'll give your post a look. Thanks for that!

M.

[mrdalliard]

I've tried using TML's Raster command, although I'm not sure it does what I'm after.

I want a single bar, like a little cluster of single rasters. They were going to envelope a scroller I was doing (ignore the font for the moment). Here's a screenshot https://imgur.com/a/dl5DUEk using my old "dokey" way...

When I tried to emulate the same thing using the Raster command, the whole bottom of the screen stays blue. Perhaps I've misinterpreted how it works.

Thanks,

M.

[thomas3]

Hi!
You should definitely be able to do this. Make sure you have black as the final colour of your data, and set the parameters so the invisible black final "bar" is included.

[mlynn1974]

So after all these years was the raster command in The Missing Link undocumented? It's not listed in LINK.DOC (v1.0)!
Was there another version? Looking at the example in the N_Z directory the raster command is very flickery.

I like Neil's routine - easy to setup and no flicker:
135 scanlines (black top),
16 * 4 scanlines = 64 scanlines for shades of blue,
1 scanline (black bottom).

How's this?

[thomas3]

Hey Michael,

RASTER was in the registration version iirc

The reason I suggested this rather than the above module is because the latter kills all interrupts including ACIA (iirc). You're right that this removes all flicker but as a trade off affects the functionality of a number of commands, and prevents certain music being played.

You're right that there's a timer C jitter on RASTER (because it kills nothing) which is the trade off. Stability can be improved by manually disabling timer C, using that patch I posted (or a couple of pokes).

Cheers
Tom

[mlynn1974]

Hi Tom,

With my original STOS installation which I still use on STEEM the raster command is present but I never used it because it wasn't in the documentation.

A couple of weeks ago I found a folder of printed documentation from 1993 with TML V1.0 document printed and the raster command is not mentioned. I guess it was present but not documented unless you registered it and got all the examples, which I didn't. Interesting. I wonder if I was the only person with a copy of Neil's raster routine? There was mention of an Interrupt Extension but as far as I know it was never made.

Excellent note about Timer C.

Cheers,
Michael.

[thomas3]

Ah how interesting re: the RASTER command! Perhaps they just forgot to document it first time; I attach the "registration" additional commands list you received when paying your £5/£10

If the Neil Stewart raster routine you mention is the one I think it is, it was actually bundled on one of the disks of the Cunning Demos. In fact, early in my assembly "career" (!) I disassembled it to form the basis of interrupt routines for https://demozoo.org/productions/195282/ code ripping!!!

Yeah, I remember seeing Top Notch talking about an interrupt extension with syncscroll etc around the time. It may even be mentioned in TML's registration documents as a "coming soon". I'm not surprised it was never released, though. When I hacked the DHS syncscroll to work in STOS I ran up against a number of issues, most notably the fact that you can't disable HBL because STOS uses it for its own purposes (!!). The HBL does NOT play nice with cycle precise coding, which you need for techniques such as syncscroll. Iirc, my solution was to (based on Evl's code) use timer A to sync roughly to scanline, switch off HBL, sync again, wait a bit, do the top border removal and syncscroll lines and then re-instate HBL. At the time that Top Notch were operating I don't think using timer A in this way for top border removal was a method used outside of the demoscene - hence, why top border removal STOS extensions/modules from that era ate 15% CPU and killed a lot of STOS's functionality (because they'd stop all interrupts in the VBL and then burn screen time with NOPs until the electron beam reached the top border). If Top Notch didn't have that code, they'd have really struggled to synclock in the right place for a syncscroll.

The other issue would have been that any advanced interrupt commands would likely have been incompatible with the timer B commands currently in TML. What would really be needed would be a single command where the user could specify a whole bunch of interrupt "events" (border removal. syncscroll, rasters/palette splits) in one go.

[mrdalliard]

So after all these years was the raster command in The Missing Link undocumented? It's not listed in LINK.DOC (v1.0)!
Was there another version? Looking at the example in the N_Z directory the raster command is very flickery.

I like Neil's routine - easy to setup and no flicker:
135 scanlines (black top),
16 * 4 scanlines = 64 scanlines for shades of blue,
1 scanline (black bottom).

How's this?

Hey, that's looking pretty awesome. I'll have to give it another try.

I've got the TML stuff and there's one basic example of it, with the documentation giving an example of how the command works - but I didn't even know this was a thing until yesterday. My previous version of this didn't have any reference to the command.

Thanks,

M.

[mlynn1974]

Thanks for the UPDATE.DOC Tom.