lower border removal in STOS

[thomas3]

Hi!

Has anyone had any luck coding a stable lower border removal routine in STOS? (i.e. - no "border removal" extension or machine code calls - obviously I know you can do this, but this is no fun ).

I've been fiddling tonight and have managed to pull off a relatively stable routine (running in Steem though - I'm sure it would screw a monitor right up). But it can only display one bitplane (and definitely not on bitplane 1, which jumps about everywhere). And even though I'm burning processor time, if I add any code to each VBL before the switch (which I'm timing by peeking the video address counter medium byte) then it goes all flickery. I don't really understand the video address counter well enough to know why THAT is.

Anyone done any better?

CHEERS!
Tom.

[mlynn1974]

Hi Thomas,
I've done a few experiments without much success.

The first idea I had was to simply to wait for the scanline to occur, in a tight loop.
I know you said not to use assembly but this was just to see what effect the interpreter was having and how much it varied when the program was compiled with the STOS Compiler.

Code: Select all

loop: dbf d0,loop
rts


To call the routine in STOS:

Code: Select all

S15=start(15)+28
dreg(0)=looplength:call S15


Border removal switch:

Code: Select all

FREQ=$FFFF820A
poke FREQ,2:dreg(0)=dreg(0):poke FREQ,0


The effect of the dreg(0)=dreg(0) should be compiled to a move d0,d0 by STOS having no effect but the required delay.

The results show that the loop length has to be 9063 for a stable border removal effect on an 8MHz ST but when compiled the loop length has to be 10324. You can see a bit of graphics memory in the lower border.

Then I had a good idea:
Use the 200Hz timer to get us near scanline 199. We'd get 4 ticks per frame. If we wait until the 4th tick that leaves 75% CPU time free at the start of the frame for code and graphics updates. Surely we would only have to wait a few hundred clock cycles to get to scanline 199? But this was unstable.

10 hide : key off : mode 0 : curs off : flash off : click off : mouseoff
20 HZ=$FFFF820A
30 KBD=$FFFFFC02
40 THHZ=$4BA
40 S15=start(15)+28

60 rem ** it is crucial to wait for the vbl
70 rem ** and reset the timer as near as possible
80 wait vbl: loke THHZ,1

rem ** main loop
100 doke $FFFF8240,$70
110 gosub 200
120 if peek(KBD)=57 then goto 170
130 wait vbl
140 loke THHZ,1
150 goto 100

200 rem ** wait for the bottom quarter of the screen then the required line
210 while leek(THHZ) mod 4 <> 0 : wend
220 dreg(0)=100:call S15
230 poke HZ,2:dreg(0)=dreg(0):poke HZ,0
240 return

The problem is that the timing in STOS is so vague. This is why you really need to use Timer B interrupts and STOS doesn't have any call back handlers for that sort of thing. Does anyone else have other ideas?

[thomas3]

OMG, a reply - and it's cogent! Thanks!

I've managed a scroll in the bottom border that runs in the interpreter - at least for me, in Steem. Far from perfect though. I've attached it. To what extent does it work on your setup?

Haven't tried compiling it as I'm currently having much fun seeing what is possible *just* in the interpreter. (Christ - talk about a niche interest. In fact, I've very nearly finished an interpreter-only six screen old school megademo. I KID NOT!!! THE SHAME!!!!).

[shoggoth]

Sick s--t!!!

[distantminds]

https://www.youtube.com/watch?v=oXz-HOcd_WQ

[spiny]

brilliant stuff

[thomas3]

Hahaha! Thanks for the "appreciation"! Needless to say, this particular hobby is one that's even got my own kids responding like this - ...!!

[mlynn1974]

Well done Thomas! That runs well in STOS in the interpreter on Steem 3.2 and good old David Whittaker music as well!

The compiler initially wouldn't compile the program because of the declaration of DIM SX(LEN(T$)),SY(LEN(T$)) in a subroutine, but used earlier in the main. I fixed that by declaring T$ and the arrays at lines 141 and 142 and compiled it, but the lower border doesn't open in the compiled version.

I'm scratching my head at the maths:
There are 313 scanlines in a full screen at 50Hz. If the 200Hz timer ticks 4 times per VBL:
Tick 1=Absolute line 0
Tick 2=78.25
Tick 3=156.5
Tick 4=234.75
So I'd have to wait for 44 scanlines at Tick 3 to reach scanline 199. There is still a lot of jitter because it's STOS.
I don't think the 200Hz timer trick is really an advantage.

It's an interesting problem and I'll keep trying to improve my code.

[thomas3]

Hi!

I'm pretty sure I can fix mine to run in the compiler... just need to fiddle with some of the really dirty delay tactics in the border opener routine.

This is hilarious, but part of the problem is that Steem won't emulate the Help key on my laptop, which is why I'm not using the compiler at present!! HA! But I'll address this one day.

Think I'll do a open bottom border in the break screen (like a reset demo, but triggered with ctrl-c - cute, eh?) of this interpreter demo I'm working on (and am spending waaay too much time on, given that this will be of interest to <5 people on the planet)

[MiggyMog]

Exxos has the border prog on his site to download which may be helpful http://www.exxoshost.co.uk/atari/STOS/E ... /index.htm

[mlynn1974]

Those examples require the border extension. Neil Stewart also wrote an extension to remove the border, improved by Agrajag. I don't know if it was publically released. Maybe it was in PB Disk Maggie. You can pass it a parameter to turn off the upper, lower or both borders. Thomas wants to remove the border in STOS only including the switching code - no extensions!

I think this is a well worn path and most people agree it simply cannot be done with 100% stability in STOS without using ASM extensions. The timing is too flaky and the lanugage is too limited. You simply cannot do proper interrupt service routines in STOS.

[thomas3]

@MiggyMog

Just to say, the pointlessness of trying to open the border in STOS without ASM when extensions already exist is not lost on me

Basically, this has become an obscure intellectual challenge, fueled by nostalgia!

[MiggyMog]

Hehe. I tried too back in the day when I read sync changing was involved and had some success. But I got the horrid skewing effect as my timings were not as precise as we all now know they need to be. I think I missed getting Neil`s border prog free as I was not in first 100 registered for misty or whatever the rule was

[elliot]

I managed to get it removed with a flicker (off then on) every 8 seconds or so. From memory it MUST be compiled and you need to remove all other interrupt crap (such as mouse, clear the VBL list, etc).

My routine started out as a raster thing. I had three VU meters on each border (left and right) and you could see a "blip" slowly working its way down the screen as they worked (it was a slightly extended raster line). This was not so noticeable for bouncing raster but when doing the bottom border trick, when that blip reached the border it would flick off then on.

The problem was it was synced to the VBL and not an interrupt, it had some kind of creep. It may be more reliable with the top border... I never tried.

It was just a tight loop linked to the Wait VBL, one line of STOS, etc which simply "counted" to that point and had a fixed end value derived from experimenting. I spent many hours timing thousands of loops written in different ways.

It may be possible to adjust the timing.

[shoggoth]

This is soo kinky..