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
Victor 6560 Replacement - Added graphics ops, just for fun
Moderator: Moderators
- JonBrawn
- Vic 20 Devotee
- Posts: 275
- Joined: Sat Sep 11, 2021 10:47 pm
- Website: http://youtube.com/@vicenary
- Location: Austin TX USA
- Occupation: CPU design engineer
Victor 6560 Replacement - Added graphics ops, just for fun
Working on FPGA replacement for 6560/6561
https://youtube.com/@vicenary
https://youtube.com/@vicenary
- Mike
- Herr VC
- Posts: 4941
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Victor 6560 Replacement - Added graphics ops, just for fun
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):on YouTube, you wrote: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.
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
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
- Vic 20 Devotee
- Posts: 275
- Joined: Sat Sep 11, 2021 10:47 pm
- Website: http://youtube.com/@vicenary
- Location: Austin TX USA
- Occupation: CPU design engineer
Re: Victor 6560 Replacement - Added graphics ops, just for fun
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.
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.
Working on FPGA replacement for 6560/6561
https://youtube.com/@vicenary
https://youtube.com/@vicenary
- Mike
- Herr VC
- Posts: 4941
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Victor 6560 Replacement - Added graphics ops, just for fun
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.JonBrawn wrote:I'm assuming (MX,MY) is the center point and that A and B are the major and minor radii?
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).Rounded rectangles would be neat, but that special-cases a whole bunch of pixels at the corners.
- JonBrawn
- Vic 20 Devotee
- Posts: 275
- Joined: Sat Sep 11, 2021 10:47 pm
- Website: http://youtube.com/@vicenary
- Location: Austin TX USA
- Occupation: CPU design engineer
Re: Victor 6560 Replacement - Added graphics ops, just for fun
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.
Working on FPGA replacement for 6560/6561
https://youtube.com/@vicenary
https://youtube.com/@vicenary
- Mike
- Herr VC
- Posts: 4941
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Victor 6560 Replacement - Added graphics ops, just for fun
I am very well aware of that.
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.Mike wrote: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.