Hello
I do not want to critique absolutely
your work or that of others.
You invited me to enter my jobs
I thought you wanted to improve
the Maxigrafik program to get
miglir graphic results.
I understand that's not so.
I enclose four small lists attached
to let you know what I mean by limiting the graphic commands.
Anyway thanks ........ greetings Armando
MAXIGRAFIK: 208 x 256 true, high-resolution graphics!
Moderator: Moderators
-
- Vic 20 Hobbyist
- Posts: 107
- Joined: Wed Oct 02, 2013 1:54 am
- Location: Italy
- Mike
- Herr VC
- Posts: 4842
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Maxigrafik
Hi, Armando,
the kind of programs you put into the *.doc file actually confirm my presumptions.
I can tell you it's entirely possible to port these all over to MINIGRAFIK (and for that matter, MAXIGRAFIK) by taking into account the different resolutions and pixel aspect ratios. But first, let me comment on those four programs:
Some pattern effect. This one will already pose difficult to produce the intended output even on the plus/4! The pixels with Y-coordinates 200..255 are not going to be displayed. Any port will have to keep the 1:1 pixel mapping to retain the effect, that means MINIGRAFIK will only show the top-left 160x192 pixels, and MAXIGRAFIK the (top-)left 208x256 pixels.
Another pattern effect, with the same 'problems'. "DRAW1,X,X,X AND Y,Y" can be re-written as "DRAW1,X,X:DRAW1,X AND Y,Y" - a no-brainer.
The POKE in line 1 and the FOR loop in line 45 are irrelevant. The program draws a helix-like figurine from rotated ellipses. That will require both MINIGRAFIK and MAXIGRAFIK to 'emulate' the CIRCLE algorithm as it is implemented in BASIC V3.5 and V7. With a table-based implementation for SIN()- and COS()-values, this will be roughly as fast as the original code.
Finally:
The only 'issue' here is the alternative syntax for Polar-co-ordinates (which specify length and angle) as TO-parameter. Again, just some math necessary here - the conversion between Cartesian- and Polar-co-ordinates (knowing that the "length;angle"-syntax takes the current pixel co-ordinate as origin!). The only thing that makes this slightly more difficult is the non-square pixel-aspect ratio of the VIC-20, but it's doable.
Actually, what the last program intends to do is drawing five filled circles. And it does a pretty bad job at that.
...
Two options here: either you take my comments here as good hint how you could proceed with a port, and try it for yourself. Or you give me a few days to find a free evening after work, and I'll do the port.
Greetings,
Michael
P.S. actually, there's a third option - someone else from the forum chimes in and is faster at porting these programs than we two.![Smile :)](./images/smilies/icon_smile.gif)
the kind of programs you put into the *.doc file actually confirm my presumptions.
I can tell you it's entirely possible to port these all over to MINIGRAFIK (and for that matter, MAXIGRAFIK) by taking into account the different resolutions and pixel aspect ratios. But first, let me comment on those four programs:
Code: Select all
5 REM GR III
10 GRAPHIC1,1
20 FORY=1TO255:FORX=1TO255
30 DRAW 1,X,X AND Y
40 NEXT X,Y
Code: Select all
5 REM GR IV
10 GRAPHIC1,1
20 FORY=1TO255:FORX=1TO255
30 DRAW 1,X,X,X AND Y,Y
40 NEXT X,Y
Code: Select all
0 SCNCLR: REM GR XIX
1 POKE 774,156
10 GRAPHIC1,1
20 FOR X=0 TO360 STEP6
30 CIRCLE 1,65+X*.5,80,60,33,,,X
40 NEXT
45 FOR I=1 TO 10000:NEXT
50 GRAPHIC0
Finally:
Code: Select all
100 REM GRK 6
170 COLOR 4,1,1
180 COLOR 0,1,1
190 COLOR 1,5,1
200 GRAPHIC 1,1
210 :
220 FOR X=0 TO360 STEP 2
230 DRAW,160,100 TO 100;X
240 DRAW ,30,30 TO30;X
250 DRAW ,30,170 TO 30;X
260 DRAW ,290,170 TO 30;X
270 DRAW ,290,30 TO 30;X
280 NEXT X
Actually, what the last program intends to do is drawing five filled circles. And it does a pretty bad job at that.
...
Two options here: either you take my comments here as good hint how you could proceed with a port, and try it for yourself. Or you give me a few days to find a free evening after work, and I'll do the port.
Greetings,
Michael
P.S. actually, there's a third option - someone else from the forum chimes in and is faster at porting these programs than we two.
![Smile :)](./images/smilies/icon_smile.gif)
-
- Vic 20 Hobbyist
- Posts: 107
- Joined: Wed Oct 02, 2013 1:54 am
- Location: Italy
Re: Maxigrafik
Hello Michael
I have many manuals for Plus / 4 …..and Vic20
downloaded in pdf.
The remarkable thing is that
all these variants and others
which I found I am not described.
But how do you see it accepted and working.
Only notes for the "Circle" command are described.
You wrote
Two options here: either you take my comments here as good hint how you could proceed with a port, and try it for yourself. Or you give me a few days to find a free evening after work, and I'll do the port.
If you make any possible additions OK.
there is no hurry.
Greetings,
Armando
I have many manuals for Plus / 4 …..and Vic20
downloaded in pdf.
The remarkable thing is that
all these variants and others
which I found I am not described.
But how do you see it accepted and working.
Only notes for the "Circle" command are described.
You wrote
Two options here: either you take my comments here as good hint how you could proceed with a port, and try it for yourself. Or you give me a few days to find a free evening after work, and I'll do the port.
If you make any possible additions OK.
there is no hurry.
Greetings,
Armando
- Mike
- Herr VC
- Posts: 4842
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Maxigrafik
Warning. Longer post.
For that matter, here's the port of "XIX.PRG" (download), which draws the helical figurine with rotated ellipses. Lines 12..24 contain the translation of the CIRCLE command of BASIC V3.5/V7 with all its parameters. The sub-routine requires the array S() dimensioned in line 10 and S() - together with a few auxiliary variables - being initialised in lines 26 and 27. Lines 28..39 then call the ported circle sub-routine as equivalent to the FOR loop in XIX.PRG (+4):
This is for MINIGRAFIK. A version for MAXIGRAFIK would just leave out "@ON" and replace "@CLR" with CLEAR in line 28, and replace lines 38 and 39 with a single line with a SHOW command. In line 16, replace "@[...]" with "DRAW[...]"
The ported CIRCLE algorithm additionally needs to take into account the non-square pixel-aspect ratio of the hires pixels with the VIC-I chip. There's already an optimization for non-rotated ellipses (R=0) - the IF statements in lines 13 and 18 are only executed, when R<>0. In line 18, the IF statement contains a modified version for the co-ordinate rotation which honours the aspect ratio. Rotated ellipses take roughly 40% more time to draw because of the extra calculations.
It also takes some thoughts to honour the orientation of the co-ordinate system (it's left-handed here), that rotation angles work clock-wise, and that start- and end-angles are defined from the 12 o'clock position (i.e. negative Y-axis in their own co-ordinate system). Mathematicians usually use right-handed co-ordinates, counter-clockwise angles, and start- and end-angles defined from the 3 o'clock position (positive X-axis) - but we want (near complete) compatibility to the CIRCLE command of BASIC 3.5/7.0.![Smile :)](./images/smilies/icon_smile.gif)
What we can't get is the same resolution as on the TED, i.e. 320x200. With the VIC-20 hardware, MINIGRAFIK allows for the maximum resolution that can be displayed without using the lower 1K ($0000..$03FF) or interrupts (or both). And that is 160x192.
Therefore, if the overall look of XIX.prg is desired to be retained, we need to rescale some 'parameters' of the emulated circle command in advance. The original FOR loop reads:
This results in 61 ellipses, whose centers glide along a line at Y=80 (third parameter) and X co-ordinates ranging from 65 to 245. The whole drawing ends up (nearly) symmetrical to X=160. The half-axes are 60 and 33 - the missing two parameters mean start_angle=0, end_angle=360 - i.e. draw whole ellipse, not an arc. The last parameter specifies the rotation angle, i.e. the ellipses are ultimately turned over a full angle as they are drawn.
For the VIC-20, we mainly have to take into account the halved resolution in X direction. *Both* half-axes are divided by two (i.e. we take 30 and 17), but note the sub-routine will re-scale the Y-axis with "B=W*B" in line 12, so the original value of the Y-half-axis is nearly restored. I did it this way, so if you set both values equal on entry to the sub-routine, it actually draws a circle (and the user doesn't have to pre-scale the Y-half-axis to get a round circle). The definition of W=5/3 in line 26 is valid for PAL. NTSC users should replace it with W=3/2.
Normally, the CIRCLE command of BASIC V3.5/V7 uses a default angle increment value of 2° (in the sub-routine, parameter K). I set it to 10 for my program. Not only does it make it faster without any great loss of accuracy, actually, the smaller value leads to the jagged appearance of the ellipses in BASIC 3.5.![Cool 8)](./images/smilies/icon_cool.gif)
The Y-co-ordinates of the ellipse centers are assumed to retain their position relative to the vertical resolution: 80/200 = 40% (+4) => 40%*192 = 77 (VIC-20, MINIGRAFIK). If finally the figure is supposed to be centered at X=80, the "circle" command in line 30 then becomes:
That translated command in turn is re-written with parameter assignments (in the ported program, see lines 30, 33, 34 and 35) and a GOSUB to line 12. The FOR loop in the port replaces P for X, as X is committed for use by the sub-routine. For completeness, here's a cross-reference list - the parameters of the circle sub-routine are highlighted with "*)":
Ports of the other 3 programs (resp., to MAXIGRAFIK) left as exercise for the reader. ![Wink ;)](./images/smilies/icon_wink.gif)
tl;dr just run XIX.prg on the +4, and the ported version (contained in the *.zip below) on the VIC-20 with MINIGRAFIK and compare the visual result.
O.K. - I took a quick peek at the manuals for download at DLH/Bombjack and indeed I am puzzled: neither is there any mention of the "length;angle"-syntax, nor (what we hadn't discussed thus far) of relative co-ordinates, where an explicit "+" or "-" precedes the value, and which is used to position the next point relative to the current "hires cursor" position. Strange. My german instruction book bundled with my C116 (at those times, around 1985) was much more verbose in that matter.armypavarmy wrote:I have many manuals for Plus / 4 ... and Vic20 downloaded in pdf. [...] The remarkable thing is that all these variants and others which I found [are] not described.
Well, I happen to know what the graphics commands and their parameters are supposed to do. Didn't even require me to actually run those programs.But how do you see it accepted and working[?]
As I wrote, a port of these programs does not require any changes to MINIGRAFIK or MAXIGRAFIK. I just use the already available graphics commands.If you make any possible additions OK. [...]
For that matter, here's the port of "XIX.PRG" (download), which draws the helical figurine with rotated ellipses. Lines 12..24 contain the translation of the CIRCLE command of BASIC V3.5/V7 with all its parameters. The sub-routine requires the array S() dimensioned in line 10 and S() - together with a few auxiliary variables - being initialised in lines 26 and 27. Lines 28..39 then call the ported circle sub-routine as equivalent to the FOR loop in XIX.PRG (+4):
Code: Select all
10 DIMS(90):GOTO26
11 :
12 B=W*B:IFD>=ETHENE=E+F
13 IFRTHENI=D:D=R:GOSUB20:U=C:V=S:D=I
14 GOSUB20:GOSUB18:I=X:J=Y
15 D=D+K:IFD>ETHEND=E
16 GOSUB20:GOSUB18:@G,I,JTOX,Y:I=X:J=Y:IFD<ETHEN15
17 RETURN
18 X=S*A:Y=C*B:IFRTHENZ=U*Y-V*X*W:X=U*X+V*Y/W:Y=Z
19 X=M+X+.5:Y=N-Y+.5:RETURN
20 Z=D-F*INT(D/F)
21 IFZ<QTHENS=S(Z):C=S(Q-Z):RETURN
22 IFZ<HTHENS=S(H-Z):C=-S(Z-Q):RETURN
23 IFZ<TTHENS=-S(Z-H):C=-S(T-Z):RETURN
24 S=-S(F-Z):C=S(Z-T):RETURN
25 :
26 Q=90:H=180:T=270:F=360:W=5/3
27 FORZ=0TO90:S(Z)=SIN({PI}*Z/180):NEXT
28 @ON:@CLR
29 :
30 G=1:N=77:A=30:K=10
31 :
32 FORP=0TO360STEP6
33 M=35+P*.25
34 B=17:D=0:E=360
35 R=P:GOSUB12
36 NEXT
37 :
38 GETA$:IFA$=""THEN38
39 @RETURN
The ported CIRCLE algorithm additionally needs to take into account the non-square pixel-aspect ratio of the hires pixels with the VIC-I chip. There's already an optimization for non-rotated ellipses (R=0) - the IF statements in lines 13 and 18 are only executed, when R<>0. In line 18, the IF statement contains a modified version for the co-ordinate rotation which honours the aspect ratio. Rotated ellipses take roughly 40% more time to draw because of the extra calculations.
It also takes some thoughts to honour the orientation of the co-ordinate system (it's left-handed here), that rotation angles work clock-wise, and that start- and end-angles are defined from the 12 o'clock position (i.e. negative Y-axis in their own co-ordinate system). Mathematicians usually use right-handed co-ordinates, counter-clockwise angles, and start- and end-angles defined from the 3 o'clock position (positive X-axis) - but we want (near complete) compatibility to the CIRCLE command of BASIC 3.5/7.0.
![Smile :)](./images/smilies/icon_smile.gif)
What we can't get is the same resolution as on the TED, i.e. 320x200. With the VIC-20 hardware, MINIGRAFIK allows for the maximum resolution that can be displayed without using the lower 1K ($0000..$03FF) or interrupts (or both). And that is 160x192.
Therefore, if the overall look of XIX.prg is desired to be retained, we need to rescale some 'parameters' of the emulated circle command in advance. The original FOR loop reads:
Code: Select all
[...]
20 FOR X=0 TO360 STEP6
30 CIRCLE 1,65+X*.5,80,60,33,,,X
40 NEXT
[...]
For the VIC-20, we mainly have to take into account the halved resolution in X direction. *Both* half-axes are divided by two (i.e. we take 30 and 17), but note the sub-routine will re-scale the Y-axis with "B=W*B" in line 12, so the original value of the Y-half-axis is nearly restored. I did it this way, so if you set both values equal on entry to the sub-routine, it actually draws a circle (and the user doesn't have to pre-scale the Y-half-axis to get a round circle). The definition of W=5/3 in line 26 is valid for PAL. NTSC users should replace it with W=3/2.
Normally, the CIRCLE command of BASIC V3.5/V7 uses a default angle increment value of 2° (in the sub-routine, parameter K). I set it to 10 for my program. Not only does it make it faster without any great loss of accuracy, actually, the smaller value leads to the jagged appearance of the ellipses in BASIC 3.5.
![Cool 8)](./images/smilies/icon_cool.gif)
The Y-co-ordinates of the ellipse centers are assumed to retain their position relative to the vertical resolution: 80/200 = 40% (+4) => 40%*192 = 77 (VIC-20, MINIGRAFIK). If finally the figure is supposed to be centered at X=80, the "circle" command in line 30 then becomes:
Code: Select all
30 CIRCLE 1,35+X*.25,77,30,17,0,360,X,10
Code: Select all
*) A: horizontal half-axis (before rotation)
*) B: vertical half-axis (before rotation)
C: C:=COS(D)
*) D: start angle, running angle
*) E: end angle
F: F:=360
*) G: draw colour
H: H:=180
I: old (transformed) x-offset, D temporary
J: old (transformed) y-offset
*) K: angle increment
L:
*) M: x-co-ordinate of midpoint
*) N: y-co-ordinate of midpoint
O:
P:
Q: Q:=90
*) R: rotation angle
S: S:=SIN(D)
T: T:=270
U: U:=COS(R)
V: V:=SIN(R)
W: W:=5/3 (pixel aspect ratio)
X: (transformed) x-offset
Y: (transformed) y-offset
Z: reduced angle, Y temporary
![Wink ;)](./images/smilies/icon_wink.gif)
tl;dr just run XIX.prg on the +4, and the ported version (contained in the *.zip below) on the VIC-20 with MINIGRAFIK and compare the visual result.
- Mike
- Herr VC
- Posts: 4842
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Maxigrafik
See here: ftp://ftp.zimmers.net/pub/cbm/plus4/man ... l_(IT).pdf on page 116 and 117, "Alcune informazioni sulle istruzioni Grafiche"Mike wrote:I took a quick peek at the manuals for download at DLH/Bombjack and indeed I am puzzled: neither is there any mention of the "length;angle"-syntax, nor (what we hadn't discussed thus far) of relative co-ordinates, where an explicit "+" or "-" precedes the value, and which is used to position the next point relative to the current "hires cursor" position. Strange. My german instruction book bundled with my C116 (at those times, around 1985) was much more verbose in that matter [...]
-
- Vic 20 Hobbyist
- Posts: 107
- Joined: Wed Oct 02, 2013 1:54 am
- Location: Italy
BINGO-Maxigrafik
Hello ... here's for everyone
Bingo for Maxigrafik.
Random extraction of 90 numbers
after each extraction, press
space to continue.
To extract less than 90 numbers
change the value assigned to NE
in line 155.
good luck with Bingo ... Armando
Bingo for Maxigrafik.
Random extraction of 90 numbers
after each extraction, press
space to continue.
To extract less than 90 numbers
change the value assigned to NE
in line 155.
good luck with Bingo ... Armando