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, highresolution graphics!
Moderator: Moderators

 Vic 20 Drifter
 Posts: 35
 Joined: Wed Oct 02, 2013 1:54 am
 Location: Italy
 Mike
 Herr VC
 Posts: 3016
 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 Ycoordinates 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 topleft 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 rewritten as "DRAW1,X,X:DRAW1,X AND Y,Y"  a nobrainer.
The POKE in line 1 and the FOR loop in line 45 are irrelevant. The program draws a helixlike 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 tablebased 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 Polarcoordinates (which specify length and angle) as TOparameter. Again, just some math necessary here  the conversion between Cartesian and Polarcoordinates (knowing that the "length;angle"syntax takes the current pixel coordinate as origin!). The only thing that makes this slightly more difficult is the nonsquare pixelaspect ratio of the VIC20, 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.
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
Some pattern effect. This one will already pose difficult to produce the intended output even on the plus/4! The pixels with Ycoordinates 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 topleft 160x192 pixels, and MAXIGRAFIK the (top)left 208x256 pixels.
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
Another pattern effect, with the same 'problems'. "DRAW1,X,X,X AND Y,Y" can be rewritten as "DRAW1,X,X:DRAW1,X AND Y,Y"  a nobrainer.
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
The POKE in line 1 and the FOR loop in line 45 are irrelevant. The program draws a helixlike 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 tablebased implementation for SIN() and COS()values, this will be roughly as fast as the original code.
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
The only 'issue' here is the alternative syntax for Polarcoordinates (which specify length and angle) as TOparameter. Again, just some math necessary here  the conversion between Cartesian and Polarcoordinates (knowing that the "length;angle"syntax takes the current pixel coordinate as origin!). The only thing that makes this slightly more difficult is the nonsquare pixelaspect ratio of the VIC20, 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.

 Vic 20 Drifter
 Posts: 35
 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: 3016
 Joined: Wed Dec 01, 2004 1:57 pm
 Location: Munich, Germany
 Occupation: electrical engineer
Re: Maxigrafik
Warning. Longer post.
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 coordinates, 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.
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.
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.
For that matter, here's the port of "XIX.PRG", 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 subroutine 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 subroutine 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 nonsquare pixelaspect ratio of the hires pixels with the VICI chip. There's already an optimization for nonrotated 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 coordinate 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 coordinate system (it's lefthanded here), that rotation angles work clockwise, and that start and endangles are defined from the 12 o'clock position (i.e. negative Yaxis in their own coordinate system). Mathematicians usually use righthanded coordinates, counterclockwise angles, and start and endangles defined from the 3 o'clock position (positive Xaxis)  but we want (near complete) compatibility to the CIRCLE command of BASIC 3.5/7.0.
What we can't get is the same resolution as on the TED, i.e. 320x200. With the VIC20 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 coordinates ranging from 65 to 245. The whole drawing ends up (nearly) symmetrical to X=160. The halfaxes 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 VIC20, we mainly have to take into account the halved resolution in X direction. *Both* halfaxes are divided by two (i.e. we take 30 and 17), but note the subroutine will rescale the Yaxis with "B=W*B" in line 12, so the original value of the Yhalfaxis is nearly restored. I did it this way, so if you set both values equal on entry to the subroutine, it actually draws a circle (and the user doesn't have to prescale the Yhalfaxis 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 subroutine, 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.
The Ycoordinates of the ellipse centers are assumed to retain their position relative to the vertical resolution: 80/200 = 40% (+4) => 40%*192 = 77 (VIC20, 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 rewritten 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 subroutine. For completeness, here's a crossreference list  the parameters of the circle subroutine are highlighted with "*)":
Ports of the other 3 programs (resp., to MAXIGRAFIK) left as exercise for the reader.
tl;dr just run XIX.prg on the +4, and the ported version (contained in the *.zip below) on the VIC20 with MINIGRAFIK and compare the visual result.
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.
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 coordinates, 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.
But how do you see it accepted and working[?]
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.
If you make any possible additions OK. [...]
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.
For that matter, here's the port of "XIX.PRG", 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 subroutine 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 subroutine 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*YV*X*W:X=U*X+V*Y/W:Y=Z
19 X=M+X+.5:Y=NY+.5:RETURN
20 Z=DF*INT(D/F)
21 IFZ<QTHENS=S(Z):C=S(QZ):RETURN
22 IFZ<HTHENS=S(HZ):C=S(ZQ):RETURN
23 IFZ<TTHENS=S(ZH):C=S(TZ):RETURN
24 S=S(FZ):C=S(ZT):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
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 nonsquare pixelaspect ratio of the hires pixels with the VICI chip. There's already an optimization for nonrotated 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 coordinate 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 coordinate system (it's lefthanded here), that rotation angles work clockwise, and that start and endangles are defined from the 12 o'clock position (i.e. negative Yaxis in their own coordinate system). Mathematicians usually use righthanded coordinates, counterclockwise angles, and start and endangles defined from the 3 o'clock position (positive Xaxis)  but we want (near complete) compatibility to the CIRCLE command of BASIC 3.5/7.0.
What we can't get is the same resolution as on the TED, i.e. 320x200. With the VIC20 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
[...]
This results in 61 ellipses, whose centers glide along a line at Y=80 (third parameter) and X coordinates ranging from 65 to 245. The whole drawing ends up (nearly) symmetrical to X=160. The halfaxes 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 VIC20, we mainly have to take into account the halved resolution in X direction. *Both* halfaxes are divided by two (i.e. we take 30 and 17), but note the subroutine will rescale the Yaxis with "B=W*B" in line 12, so the original value of the Yhalfaxis is nearly restored. I did it this way, so if you set both values equal on entry to the subroutine, it actually draws a circle (and the user doesn't have to prescale the Yhalfaxis 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 subroutine, 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.
The Ycoordinates of the ellipse centers are assumed to retain their position relative to the vertical resolution: 80/200 = 40% (+4) => 40%*192 = 77 (VIC20, 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
That translated command in turn is rewritten 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 subroutine. For completeness, here's a crossreference list  the parameters of the circle subroutine are highlighted with "*)":
Code: Select all
*) A: horizontal halfaxis (before rotation)
*) B: vertical halfaxis (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) xoffset, D temporary
J: old (transformed) yoffset
*) K: angle increment
L:
*) M: xcoordinate of midpoint
*) N: ycoordinate 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) xoffset
Y: (transformed) yoffset
Z: reduced angle, Y temporary
Ports of the other 3 programs (resp., to MAXIGRAFIK) left as exercise for the reader.
tl;dr just run XIX.prg on the +4, and the ported version (contained in the *.zip below) on the VIC20 with MINIGRAFIK and compare the visual result.
 Attachments

 xix.zip
 (574 Bytes) Downloaded 5 times
 Mike
 Herr VC
 Posts: 3016
 Joined: Wed Dec 01, 2004 1:57 pm
 Location: Munich, Germany
 Occupation: electrical engineer
Re: Maxigrafik
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 coordinates, 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 [...]
See here: ftp://ftp.zimmers.net/pub/cbm/plus4/manuals/Commodore_16_User_Manual_(IT).pdf on page 116 and 117, "Alcune informazioni sulle istruzioni Grafiche"

 Vic 20 Drifter
 Posts: 35
 Joined: Wed Oct 02, 2013 1:54 am
 Location: Italy
BINGOMaxigrafik
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
Who is online
Users browsing this forum: No registered users and 2 guests