Victor 6560 Replacement - Added graphics ops, just for fun

[JonBrawn]

I've not been working on Victor, the 6560/61 replacement FPGA, for a little while due to health issues. To break myself back into working on it I implemented some graphics primitives, just for fun.

Drawing points, lines, boxes, rectangles, circles and filled circles:
https://www.youtube.com/watch?v=PLyyZbsmuM0

Using the user-defined palette and point plotting to draw pictures:
https://www.youtube.com/watch?v=gmZlC_MBcGY

[Mike]

Regrettably, not perfect circles. They are perfect circles in memory, but the wild & whacky pixel aspect ratio of the VIC-20 squashes them into ovals.

That, and also with regard to your inquiry about the PAR for PAL/NTSC you might want to take a sharp look at my ellipse routine (snippet taken from one of my example programs for MINIGRAFIK):

Code: Select all

49 REM ** ELLIPSE DRAW
50 X=0:Y=B:S=B*B:T=A*A*(2*Y-1):U=2*B*B:V=2*A*A:E=0
51 X1=MX+X:Y1=MY+Y:P1=X1>=0ANDX1<160:P2=Y1>=0ANDY1<192
52 X2=MX-X:Y2=MY-Y:P3=X2>=0ANDX2<160:P4=Y2>=0ANDY2<192
53 IFP1ANDP2THEN:@1,X1,Y1
54 IFP1ANDP4THEN:@1,X1,Y2
55 IFP3ANDP4THEN:@1,X2,Y2
56 IFP3ANDP2THEN:@1,X2,Y1
57 IFX=AANDY=0THENRETURN
58 F=E+S:D=0
59 G=F-T:IFABS(F)>ABS(G)THENF=G:D=1
60 G=E-T:IFABS(F)>ABS(G)THENF=G:D=2
61 E=F
62 IFD<2THENX=X+1:S=S+U
63 IFD>0THENY=Y-1:T=T-V
64 GOTO51

This is a 2nd order Bresenham derived from the conic section equations. Only additions, subtractions, comparisons and taking the absolute value in the main loop, and a few multiplies during init. No 'expensive' operations like divides, sine, cosine or square root.

With suitably chosen half axes, you can then compensate for the non-1:1 PAR. Note though even for half axes 'just' in the range 0..255, the values in the work variables E, F, G, S, T, U and V can become rather large and need 32-bit registers to store them correctly.

[JonBrawn]

I'm assuming (MX,MY) is the center point and that A and B are the major and minor radii?

What you have here looks very similar to the code I have in Victor, give or take the ellipsy bits. I'll stare at this for a while and see if I can get it going.

Thanks!

Rounded rectangles would be neat, but that special-cases a whole bunch of pixels at the corners.

[Mike]

I'm assuming (MX,MY) is the center point and that A and B are the major and minor radii?

Yes - to be more specific, A is the half axis in parallel to the x co-ordinate and B the half axis in parallel to y.

Rounded rectangles would be neat, but that special-cases a whole bunch of pixels at the corners.

Alternatively, you might consider polygon fills. I have posted one example, also for MINIGRAFIK, in the 'MG batch suite' thread. However, even though the algorithm can be implemented with integers, it is probably best expressed in floating point. The latter allows the line segments to be defined with sub-pixel accuracy and the algorithm is guaranteed to only plot the pixels strictly within that polygon: polygons sharing sides can be 'stitched' without gaps, and also without overlapping pixels (except in very rare cases).

[JonBrawn]

...you might want to take a sharp look at my ellipse routine (snippet taken from one of my example programs for MINIGRAFIK):

If you're following in my footsteps, you might need to know that the range of some of those variables is somewhat larger than you'd imagine:

For a resolution of 172x184, e(-5735412:5685399) f(-5519016:17239104) g(-16635359:16303849)

These require 26 bits to hold the signed value.

[Mike]

I am very well aware of that.

Note though even for half axes 'just' in the range 0..255, the values in the work variables E, F, G, S, T, U and V can become rather large and need 32-bit registers to store them correctly.

CBM BASIC can represent these numbers within its floating point format without any rounding errors, and my implementation in 6502 machine code actually uses 4 bytes for these variables to store them as 32-bit signed integer.