Drawing a circle in BBC BASIC

[BigEd]

This in-browser emulator of a CoCo2 has Extended Color Basic 1.1, copyright 1982.
http://www.haplessgenius.com/mocha/
There's a manual for Extended Color Basic here (pdf)
http://www.colorcomputerarchive.com/coc ... ndy%29.pdf

[leenew]

Well we got all of this capability (and more) in 1985 with Acornsoft's "Graphics extension ROM".

Lee

[rmbrowngr]

Came across this article while searching for other things for drawing circles. http://www.acornelectron.co.uk/mags/eu/ ... /s-p38.jpg

[fuzzel]

I've written my own circle drawing program in BBC Basic but would like to attempt the conversion to assembly language.
I think I can work out how to calculate the points of the circle but what are the assembly language equivalents of MOVE (x,y), DRAW (x,y), PLOT (x,y), GCOL (0,x), SIN (x), COS (x) and RAD (x) ?

[geraldholdsworth]

MOVE, DRAW, PLOT and GCOL are easy, as they are just VDU commands.
RAD, COS and SIN are BASIC functions inside the BASIC ROM. You might find it easier to convert one of those listed above that doesn't use these...or use a lookup table created by a BASIC program.

[fuzzel]

Thanks for the reply Gerald, my main priority is speed, would using VDU commands and BASIC rom functions, albeit within Assembly language, slow the program down ?

[0xC0DE]

Definitely

[BigEd]

If you want speed, you almost certainly need to implement something like a Bresenham algorithm. No trig, and maybe even no multiplies either. See the listings posted upthread by lurkio.

... from the December 1984 issue of Practical Computing magazine...

[Richard Russell]

Well we got all of this capability (and more) in 1985 with Acornsoft's "Graphics extension ROM".

As far as I can see the 'Graphics extension ROM' provided, for the 6502, only the same functionality that came as standard in RISC OS, and didn't include elliptical arcs and sectors (only circular ones) or Bézier curves. If I'm wrong, and those features were supported, I'd be interested in the details. Otherwise I remain of the view that the graphics features available to BBC BASIC (even now) are seriously limited.

[SimonSideburns]

This code:

Code: Select all

L.
   10MODE2
   20REPEAT
   30r%=RND(512):h%=RND(1280):v%=RND(1024):c%=RND(8)-1
   40IFRND(2)=1 PROCcircle(h%,v%,r%,c%) ELSE PROCfilledcircle(h%,v%,r%,c%)
   50UNTIL FALSE
  100DEFPROCcircle(h%,v%,r%,c%)
  110VDU 29,h%;v%;:GCOL 0,c%
  120x%=r%:y%=0
  130LET z%=x%/2
  135REPEAT
  140PLOT 69,x%,y%
  150PLOT 69,x%,-y%
  160PLOT 69,-x%,-y%
  170PLOT 69,-x%,y%
  180PLOT 69,y%,x%
  190PLOT 69,y%,-x%
  200PLOT 69,-y%,-x%
  210PLOT 69,-y%,x%
  220LET y%=y%+1
  230LET z%=z%-y%
  240IF z%<0 THEN z%=z%+x%:x%=x%-1
  250UNTIL x%<y%
  260ENDPROC
  300DEFPROCfilledcircle(h%,v%,r%,c%)
  310VDU 29,h%;v%;:GCOL 0,c%
  320x%=r%:y%=0
  330LET z%=x%/2
  340REPEAT
  350MOVE x%,y%:PLOT 5,-x%,y%
  355MOVE y%,x%:PLOT 5,-y%,x%
  360MOVE x%,-y%:PLOT 5,-x%,-y%
  365MOVE y%,-x%:PLOT 5,-y%,-x%
  370LET y%=y%+1
  380LET z%=z%-y%
  390IF z%<0 THEN z%=z%+x%:x%=x%-1
  400UNTIL x%<y%
  410ENDPROC
>

Provides both filled and unfilled circles in BASIC using only INTEGERS, ADDITION and SUBTRACTION.

I'm sure it would be trivial to convert into machine code if speed was vitally important.

Hope that helps.

[jgharston]

Well we got all of this capability (and more) in 1985 with Acornsoft's "Graphics extension ROM".

As far as I can see the 'Graphics extension ROM' provided, for the 6502, only the same functionality that came as standard in RISC OS, and didn't include elliptical arcs and sectors (only circular ones) or Bézier curves. If I'm wrong, and those features were supported, I'd be interested in the details. Otherwise I remain of the view that the graphics features available to BBC BASIC (even now) are seriously limited.

The functions available with the graphics extension ROM, or the VDU driver in MOS 3 and later are as in http://mdfs.net/Docs/Books/Manuals/AcornGXR.txt, summerised on page 63, and the only ellipse plotting supported are full outline or filled ellipses. The PLOT numbers that logically would be the ellipse equivalent (&D0-&E0) of the circle plots (&A0-&B0) are listed as reserved. Logically, if anybody implemented ellipse arcs, sectors, and segments, those are the plot numbers that should be used.

[jgharston]

Provides both filled and unfilled circles in BASIC using only INTEGERS, ADDITION and SUBTRACTION.
I'm sure it would be trivial to convert into machine code if speed was vitally important.

It could be sped up a bit as it plots each physical horizontal line twice, due to using logical pixels instead of scaling for physical pixels. I've got 6502 code for this method somewhere, from memory from the Subset column of Personal Computer World from 1985-ish.

It also doesn't let you do XOR plotting, but that's a bit fiddlier.

[Richard Russell]

Logically, if anybody implemented ellipse arcs, sectors, and segments, those are the plot numbers that should be used.

Interesting. Have you given any thought to how elliptical arcs, sectors and segments would be specified using only three points (I presume it's a fundamental characteristic of VDU graphics that any object can be specified as MOVE x1,y1 : MOVE x2,y2 : PLOT code,x3,y3). The most obvious adaptation of the 'circular' commands would be to require that the third point is actually on the ellipse, rather than somewhere on a radial line, but I wonder if it might be computationally tricky to go from that to a more conventional description.

[SimonSideburns]

Provides both filled and unfilled circles in BASIC using only INTEGERS, ADDITION and SUBTRACTION.
I'm sure it would be trivial to convert into machine code if speed was vitally important.

It could be sped up a bit as it plots each physical horizontal line twice, due to using logical pixels instead of scaling for physical pixels. I've got 6502 code for this method somewhere, from memory from the Subset column of Personal Computer World from 1985-ish.

It also doesn't let you do XOR plotting, but that's a bit fiddlier.

Yes, of course that's right. It was more about the algorithm and I was wondering if the OP was aware of it as it does seem a whole lot simpler.

[Richard Russell]

It also doesn't let you do XOR plotting, but that's a bit fiddlier.

Yes, that's a very good point. It can easily be forgotten that in order for XOR plotting to work correctly (specified either with GCOL 3 or 4, or by using an 'inverting' PLOT code) every pixel must be plotted just once. Quite recently I spotted a bug (since fixed) in Matrix Brandy's graphics which arose from this precise cause.

[SimonSideburns]

It also doesn't let you do XOR plotting, but that's a bit fiddlier.

Yes, that's a very good point. It can easily be forgotten that in order for XOR plotting to work correctly (specified either with GCOL 3 or 4, or by using an 'inverting' PLOT code) every pixel must be plotted just once. Quite recently I spotted a bug (since fixed) in Matrix Brandy's graphics which arose from this precise cause.

This modified version will happily do GCOL 3 or 4: Oops, just tried it and it doesn't work!

Code: Select all

   10MODE2:x%=RND(-TIME)
   20REPEAT
   30r%=RND(512):h%=RND(1280):v%=RND(1024):c%=RND(1024) MOD 8
   40IFRND(2)=1 PROCcircle(h%,v%,r%,c%) ELSE PROCfilledcircle(h%,v%,r%,c%)
   50UNTIL FALSE
   60DEFPROCcircle(h%,v%,r%,c%)
   70VDU 29,h%;v%;:GCOL 0,c%
   80x%=r%:y%=0
   90LET z%=x%/2
  100l%=2
  110REPEAT
  120l%=(l%+1) MOD 4
  130IF l%<>0 THEN GOTO 220
  140PLOT 69,x%,y%
  150PLOT 69,x%,-y%
  160PLOT 69,-x%,-y%
  170PLOT 69,-x%,y%
  180PLOT 69,y%,x%
  190PLOT 69,y%,-x%
  200PLOT 69,-y%,-x%
  210PLOT 69,-y%,x%
  220LET y%=y%+1
  230LET z%=z%-y%
  240IF z%<0 THEN z%=z%+x%:x%=x%-1
  250UNTIL x%<y%
  260ENDPROC
  270DEFPROCfilledcircle(h%,v%,r%,c%)
  280VDU 29,h%;v%;:GCOL 0,c%
  290x%=r%:y%=0
  300LET z%=x%/2
  310l%=2
  320REPEAT
  330l%=(l%+1) MOD 4
  340IF l%<>0 THEN GOTO 390
  350MOVE x%,y%:PLOT 5,-x%,y%
  360MOVE y%,x%:PLOT 5,-y%,x%
  370MOVE x%,-y%:PLOT 5,-x%,-y%
  380MOVE y%,-x%:PLOT 5,-y%,-x%
  390LET y%=y%+1
  400LET z%=z%-y%
  410IF z%<0 THEN z%=z%+x%:x%=x%-1
  420UNTIL x%<y%
  430ENDPROC

[joachim]

Logically, if anybody implemented ellipse arcs, sectors, and segments, those are the plot numbers that should be used.

Interesting. Have you given any thought to how elliptical arcs, sectors and segments would be specified using only three points (I presume it's a fundamental characteristic of VDU graphics that any object can be specified as MOVE x1,y1 : MOVE x2,y2 : PLOT code,x3,y3). The most obvious adaptation of the 'circular' commands would be to require that the third point is actually on the ellipse, rather than somewhere on a radial line, but I wonder if it might be computationally tricky to go from that to a more conventional description.

Ooh, this is a fun problem. Requiring the third point to be on the ellipse actually isn't a sufficient specification, because when you go from circles to ellipses you add not one but two degrees of freedom: eccentricity (the shape of the ellipse up to similarity) and tilt (the angle between the semimajor axis and horizontal).

So you have to scrounge up another degree from somewhere, within the constraint that the PLOT syntax only allows six degrees in total. Whole circles have three degrees of freedom; whole ellipses have five, as do circular arcs/sectors/segments; and elliptical arcs/sectors/segments have, er, seven.

A hack you could use to knock off a degree of freedom is to require all arcs to start at the semimajor (or semiminor) axis (but end in an arbitrary place); if you require an arc that starts and ends off axis, plot it in two pieces (additively or subtractively). This also works for filled sectors; for filled segments you'd have to subtract off a triangle. Doesn't work if you're not willing to plot in EOR mode, though.

[Richard Russell]

you add not one but two degrees of freedom: eccentricity (the shape of the ellipse up to similarity) and tilt (the angle between the semimajor axis and horizontal).

I had assumed axis-aligned ellipses, because that's all that are supported by most graphics subsystems (Windows GDI and SDL2_gfx to name but two). Hence BBC BASIC for Windows and BBC BASIC for SDL 2.0 both draw only axis-aligned ellipses, natively, as does Liberty BASIC. To draw tilted ellipses and elliptical arcs on those platforms you must resort to Bézier curves.

[jgharston]

I've been pondering this while fixing my carpet, and here are some notes on generalised ellipses:


To draw an arc/sector/segment as well as defining the closed curve you need to specify the start and end points on the curve. You can see this in going from a closed circle to a part circle, an additional MOVE is required to specify the start point, and the PLOT specifies the end point.

To draw a full ellipse the Acorn VDU driver requires two-and-a-half points to be specified, the centre, the point on the line to the right of the centre, and the top point. It's two-and-a-half points as the Y coord of the second MOVE is ignored.

So I thought the obvious thing be to use that unused Y. But that gives two possible end points, and forces the start point to be on the horizontal. For a generalised elliptical curse four whole points are needed, three MOVEs and a PLOT. Centre, Start Point, Top Point, End Point (or Centre, Start Point, End Point, Top Point).

The Acorn VDU driver only stores the two previous points, so an additional 'previous point' needs to be stored. This could be why the BBC Graphics Extension never did this, as the VDU workspace only had space for two previous points. Not a reason for the RISC OS VDU driver not to do it though.

Later, some thoughts on horizontally-aligned elliptical curves.

[jgharston]

I'm trying to convince myself that those four points specify a unique ellipse, so my Salas Hille & Anderson is tonight's bedtime reading.

[BeebMaster]

There's a discussion on plotting circles and ellipses in the Master Reference Manual part 1 section E: