UNUSUAL problem

[ac.tomo]

100 GRAPHICS 15+16
110 DEG
120 S=50
130 FOR D=0 TO 359
140 X=(COS(D)*S)+80
150 Y=(SIN(D)*S)+96
160 COLOR D
170 PLOT 80,96
180 DRAWTO X,Y
190 NEXT D

200 GOTO 200

 

The above program is a very simple circle drawing routine, but the problem I have is, that, when you type it in and RUN it up - the whole circle is NOT drawn, after so many degree's (roughly about 135') what's drawn dissappears EVEN THOUGH it stilll continues to finishing drawing the rest of the circle.

I remember encountering this problem many years ago, but used to work around it. Now, being a more experienced programmer I stumbled upon it by accident and remembered how I used to try to get around it, but still to this day don't understand 'why' this happens, and 'how' to stop it?

Anyone know why this happens, and how to overcome it?

 

Edited January 31, 2021 by ac.tomo

[globe]

Looks like the problem happens with COLOR command and D value 125.

If you skip 125 whole circle gets drawn so a simple workaround would be:

155 IF D=125 THEN D=126

This skips one beam though.

 

Other solution would be to use different variable for color, increment it and reset it to zero when it reaches 4.

125 C=0

160 COLOR C

165 C=C+1

167 IF C=4 THEN C=0

 

No idea why this happens though.

[FifthPlayer]

You could also solve the problem with:

 

160 COLOR D-INT(D/4)*4

 

which is simpler but has a bit more math overhead.  The Atari Basic manual defines only 0, 1, 2 and 3 as valid arguments for COLOR in this graphics mode.

 

[ac.tomo]

12 minutes ago, globe said:

Looks like the problem happens with COLOR command and D value 125.

If you skip 125 whole circle gets drawn so a simple workaround would be:

155 IF D=125 THEN D=126

This skips one beam though.

 

Other solution would be to use different variable for color, increment it and reset it to zero when it reaches 4.

125 C=0

160 COLOR C

165 C=C+1

167 IF C=4 THEN C=0

 

No idea why this happens though.

Many thanks for working that one out globe, I don't know the reason for it myself, perhaps its something in the OS drawing routines, but I'll remember now in future to avoid COLOR 125 lol. Thanks fifth player too, yh, plenty of methods now we know the problem.

[dmsc]

Hi!

1 hour ago, ac.tomo said:

160 COLOR D

 

Anyone know why this happens, and how to overcome it?

 

The Screen device plot code, that is a PUT byte over "S:", has an unusual property: writing character 125 clears the screen. So, when in your code variable D reach 125, the screen is cleared.

 

Note that "COLOR D:PLOT X,Y" is the same as "POSITION X,Y : PUT#6,D".

 

Have Fun!

[Wrathchild]

A small variant to reduce the loop size:

100 GRAPHICS 15+16
110 DEG
120 S=50
125 C=1
130 FOR D=0 TO 89
140 X=(COS(D)*S)
150 Y=(SIN(D)*S)
160 COLOR C
165 C=C+1
167 IF C=4 THEN C=1
170 PLOT 80,96:DRAWTO 80+X,96+Y
175 PLOT 80,96:DRAWTO 80-Y,96+X
180 PLOT 80,96:DRAWTO 80-X,96-Y
185 PLOT 80,96:DRAWTO 80+Y,96-X
190 NEXT D
200 GOTO 200

 

[drpeter]

 

You can also do

 

165 C=(C+1)*(C<3)

 

if you want to cycle C between 0-3. This flips C back to 0 after it's reached 3 so the calculation becomes (3+1)*(3<3) which is (4)*(0) as (3<3) is false (in Atari BASIC considered numerically equivalent to zero) whereas on the previous iteration (2<3) is true (in Atari BASIC considered numerically equivalent to one) and the calculation becomes (2+1)*(1).

 

which is neat, but not necessarily faster (and certainly less intelligible) than the IF....THEN construct

Edited February 1, 2021 by drpeter

[ac.tomo]

Thanks guys, especially DMSC, I never thought about issuing a clear command quite that way lol.

[drac030]

This is probably a bug in the "S:" driver, it seems to clear the screen even when the flag at $02FE is set which shouId prevent execution of control characters.

 

I actually had to block this behaviour in my VBXE driver, because there are 256 colors in pixel modes, obviously including the color 125.

 

This is what the program from post #1 produces on VBXE, by the way:

 

 

(it just needs line 100 to be changed to OPEN #6,12,3,"S2:")

 

Also, TBXL apparently clears $02FE when executing CLS #6 and restores it value afterwards.

 

[ac.tomo]

2 hours ago, drac030 said:

This is probably a bug in the "S:" driver, it seems to clear the screen even when the flag at $02FE is set which shouId prevent execution of control characters.

 

I actually had to block this behaviour in my VBXE driver, because there are 256 colors in pixel modes, obviously including the color 125.

 

This is what the program from post #1 produces on VBXE, by the way:

 

 

(it just needs line 100 to be changed to OPEN #6,12,3,"S2:")

 

Also, TBXL apparently clears $02FE when executing CLS #6 and restores it value afterwards.

 

That looks nice on VBXE, but what is the VBXE exactly?

[+Stephen]

33 minutes ago, ac.tomo said:

That looks nice on VBXE, but what is the VBXE exactly?

http://gury.atari8.info/vbxe.php

 

Upgraded video for the Atari, came out in 2005.  Sadly under appreciated and even more under utilized.  Perfectly emulated in Altirra too, for people that don't like upgrading their hardware but still might want to see some demos of it in action.

[phaeron]

5 hours ago, drac030 said:

This is probably a bug in the "S:" driver, it seems to clear the screen even when the flag at $02FE is set which shouId prevent execution of control characters.

DSPFLG ($02FE) is a Screen Editor variable and only affects E: processing, while this is a write to S: which has its own EOL and CLEAR processing. Bug or not, it's documented in page 59 of the OS manual, in the PUT CHARACTERS section of the S: handler:

 

Quote

NOTE: For all modes, if the output data byte equals $9B (EOL), that byte will be treated as an EOL character; and if the output data byte equals $7D (CLEAR) that byte will be treated as a screen-clear character.

Oddly, while the S: handling of $7D can't be bypassed, it can be printed through E: -- the E: handler is not cleanly layered on top of S: and can bypass the CLEAR handling.

[drac030]

In any case, it seems rather unfortunate that EOL cannot be sent to E: and CLEAR cannot be sent to S: without execution.