LINE and other graphics commands in X16 BASIC V2

mobluse

Member
Sep 20, 2019
35
15
8
I tested the new LINE command in Commander X16 BASIC V2 with an example from Commander X16 Programmer's Reference Guide in newly compiled x16emu with matching rom.bin.

Code:
10 SCREEN 128
20 FOR A=0 TO 2*π STEP 2*π/200
30 LINE 100,100,100+SIN(A)*100,100+COS(A)*100,5
40 NEXT
2019-11-03-011317_640x480_scrot.png

There is one name of the new commands that I'm skeptical of: CHAR. It prints a string in graphics mode, which is great, but CHAR is used in other BASICs and other programming languages for other things. It's e.g. a type or conversion function in some BASICs. I think a better name would be GPRINT or GPUTSXYC.

Code:
10 SCREEN $80
20 A$="THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG."
30 FOR I=0 TO 5
35 READ GC
40 CHAR 0,6+12*I,0,CHR$(GC)+A$
45 PRINT
50 NEXT I
55 PRINT:PRINT
60 DATA $1B,$0E,$12,$18,$19,$1A
2019-11-03-012026_640x480_scrot.png
https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md
 
Last edited by a moderator:
  • Like
Reactions: gammaray

BruceMcF

Active Member
May 19, 2019
139
42
28
It's a C128 keyword for printing on a bitmap screen. I guess they've re-arranged the parameters ... clearly the push to compatibility with "vanilla" V2 programs doesn't extend to C128 programs.
 

kktos

New Member
Oct 28, 2019
9
6
3
It's a C128 keyword for printing on a bitmap screen. I guess they've re-arranged the parameters ... clearly the push to compatibility with "vanilla" V2 programs doesn't extend to C128 programs.
ok, but it is a pitty that from a brand new computer we need to inherit from past bad choices..... when we can have a proper and meaningful name, don't you think ?
 
  • Like
Reactions: gammaray

BruceMcF

Active Member
May 19, 2019
139
42
28
ok, but it is a pitty that from a brand new computer we need to inherit from past bad choices..... when we can have a proper and meaningful name, don't you think ?
It IS a meaningful name: output (one or more) CHARacter(s) on a bitmap screen.

It's not the SAME meaning as in some other versions of Basic, and people who are regular users of those Basics ... or who were back in the day ... will whinge. Same as bourne shell users whinge about cshell and visa versa.

After watching nearly innumerable naming arguments on Forth discussion fora, my view is there is NEVER going to be a consensus on what is a proper and meaningful name once you have a large enough number of onlookers with a varied enough set of backgrounds.

It's better in USE than "PLOTCHAR" or some other such computer science clunky neologism, and it's intuitive enough for new users who've never used any Basic before, which is a lot bigger chunk of new users than it would have been back in the day.

Overall, using CBM V3.5 and V7 keywords where they are applicable seems like a design decision to get the project done rather than letting it get bogged down in interminable arguments over what is the ideal set and naming and parameter specification.
 

BruceMcF

Active Member
May 19, 2019
139
42
28
That looks like maybe the GEOS font. Note that it's proportional, so it's definitely not the standard Commodore 64 font. I believe that's built in, yes.
Yes ... while I haven't had time to dive through the code at Github, they've confirmed on FB that these are exporting some of the GEOS support routines into Basic. Calling them from assembly might use the far call Kernel routine into the GEOS ROM (rather than the ordinary BASIC ROM) and involve handing the graphic support locations in a chunk of the $00-$7F user zero page locations back for system use.
 
Last edited:
  • Like
Reactions: TomXP411

kktos

New Member
Oct 28, 2019
9
6
3
It IS a meaningful name: output (one or more) CHARacter(s) on a bitmap screen.
to you, yes. not to me. but that's a matter of opinion and I respect yours.

It's not the SAME meaning as in some other versions of Basic, and people who are regular users of those Basics ... or who were back in the day ... will whinge. Same as bourne shell users whinge about cshell and visa versa.
After watching nearly innumerable naming arguments on Forth discussion fora, my view is there is NEVER going to be a consensus on what is a proper and meaningful name once you have a large enough number of onlookers with a varied enough set of backgrounds.
for the one used to this, I agree, they'll at home.

It's better in USE than "PLOTCHAR" or some other such computer science clunky neologism, and it's intuitive enough for new users who've never used any Basic before, which is a lot bigger chunk of new users than it would have been back in the day.
I'm a new user and with my background, char looks like chr() or similar hence my surprise. That's because I'm a new user I'm a tad doubtful about the choice of name for that function. It is far from obvious.

Overall, using CBM V3.5 and V7 keywords where they are applicable seems like a design decision to get the project done rather than letting it get bogged down in interminable arguments over what is the ideal set and naming and parameter specification.
Okay, that's about compatibility. Makes sense, no question about it.
 
  • Like
Reactions: gammaray

BruceMcF

Active Member
May 19, 2019
139
42
28
I'm a new user and with my background, char looks like chr() or similar hence my surprise.
Perhaps I should have said "novice user".

Sure, someone who is used to what chr() means in Python or what CHARS means in ANS Forth that is guessing that those translate to the CHAR statement would be led astray ...
... but there is no hope to not do so, as it is literally impossible to use "CHAR" in anything remotely resembling "the normal way", since the wide ranges of ways it has been used in different families of languages means there is no 'normal way' to use it.

That's because I'm a new user I'm a tad doubtful about the choice of name for that function. It is far from obvious.
Except it's not a function. The function is CHR$(). CHAR is a statement, which is an imperative command.

In the above expert user hypothetically transitioning from Python, once they grasp that the string type in Basic is denoted by a trailing dollar sign and a true function has to have parentheses in Basic, then it shouldn't be too confusing that the equivalent of chr() is CHR$() and not a statement at all.

Inside close relatives in the Basic family tree, to "char" as a verb doesn't mean anything in QBasic, but to "line" or to "circle" means to plot the thing on a bitmap display, so it seems like it's the same basic idea behind the CBM V7 habit of to "char" or to "line" or to "circle" meaning "plot the thing on a bitmap display".
 

BruceMcF

Active Member
May 19, 2019
139
42
28
For me TEXT would have been a much better keyword as CHAR implies one char, not a string of chars.
Fair enough ... for the approach they've chosen, the challenge would be to go back to the early 80's and tell that to the programmers doing the first CBM Basic that included the command.
 

mobluse

Member
Sep 20, 2019
35
15
8
CHAR in X16 is not exactly the same as CHAR in C128.


CHAR in C128
Display characters at the specified position on the screen
CHAR [color source],X,Y[,string][,RVS]
This is primarily designed to display characters on a bit mapped screen, but it can also be used on a text screen. Here's what the parameters mean:
color source 0 = Background 1 = Foreground
X Character column (0-39) (VIC screen) (0-79) (8563) screen
Y Character row (0-24)
string String to print reverse Reverse field flag (0 = off, 1 = on)

EXAMPLE:
Code:
10 COLOR 2,3: REM MULTI-COLOR 1 = RED
20 COLOR 3,7: REM MULTI-COLOR 2 = BLUE
30 GRAPHIC 3,1
40 CHAR 0,10,10, "TEXT",0
CHAR in X16
CHAR X,Y,color,string
X,Y are pixel coordinates (0,0 through 319,199) when SCREEN $80 and not character positions. color is 0-255 when SCREEN $80.

LINE in X16 and DRAW in C128
LINE in X16 is similar to DRAW in C128 BASIC. LINE exists in GW-BASIC with a different syntax than in X16 BASIC.
https://www.pagetable.com/docs/Commodore 128 Programmer's Reference Guide.pdf
https://hwiegman.home.xs4all.nl/gw-man/
 
Last edited:

BruceMcF

Active Member
May 19, 2019
139
42
28
CHAR in X16 is not exactly the same as CHAR in C128.
Certainly, but they did not implement a CHAR from scratch, they are exporting the routine from GEOS, and the GEOS routine has it's own set of required parameters.

Unlike V2, they are clearly not requiring V7 tokens to be upwardly compatible ...
... and it's quite possible that that decision was made when they realized that the GEOS functions could be exported to provide something along the lines of the V7 graphics routines, for very little cost, just storing the parameters in the right place and making a farjsr call.

However, I am not aware of GEOS having sound in its kernel ... so between 8bit Keys and the decision to include the SAA1099, I wouldn't be surprised if they actually implement SAA1099 versions of the C128 sound keywords.
 

Wertyloo

Member
Sep 15, 2019
72
7
8
do we know now, what type of routines was used in the gfx libs? like in the line routine is a ddra/cfw/ccfw...
and what geom. primitives[circle,box,ellips,etc] are will be implemented in the _final_ ver.?
 

BruceMcF

Active Member
May 19, 2019
139
42
28
do we know now, what type of routines was used in the gfx libs? like in the line routine is a ddra/cfw/ccfw...
and what geom. primitives[circle,box,ellips,etc] are will be implemented in the _final_ ver.?
I haven't seen any commitment.

The graphics commands in C128 Basic are BOX CHAR CIRCLE COLLISION COLOR DRAW GRAPHIC LOCATE MOVSPR PAINT SCALE SCNCLR SPRCOLOR SPRDEF SPRITE SPRSAV SSHAPE/GSHAPE WINDOW and the graphics functions are BUMP(X) RCLR(X) RDOT(X) RGR(X) RSPRCOLOR(X) RSPPOS(X) RSPRITE(X) RWINDOW(X). C128 PRG

I don't know how closely the GEOS graphics model matches the C128 Basic V7 graphics model ... several of these may have a close analog be already implemented in the GEOS kernel, but clearly not all of them will. I know that GEOS64 has a filled box and an outline box which would equate to PAINT (filled rectangle) and BOX.

There isn't an ELLIPSE keyword, the C128 Basic CIRCLE is really an ellipse/arc command, as it has a distinct X and Y radius available, as well as starting and ending angles, with the Y radius defaulting to X radius and the starting/ending angles defaulting to 0:360 for the actual circle version of the command.

Drawing commands: BOX CHAR CIRCLE COLOR DRAW GRAPHIC LOCATE PAINT SCALE SCNCLR SSHAPE/GSHAPE WINDOW.
... GRAPHIC is set graphic mode, LOCATE is placing the pixel cursor, SCNCLR is not "CLS" because it includes a parameter for WHICH screen to clear (same as the six graphics modes), SSHAPE and GSHAPE save and retrieve rectangular areas of bitmap screens to/from string variables. DRAW is a dot or line drawing command, DRAW {color source}{, X1,Y1}{TO X2,Y2}{...}. This might be the one renamed LINE if GEOS doesn't support multiline draw in a single routine. (Note V7 DRAW also supports polar coordinates relative to the current pixel cursor with #pixels;angle instead of X,Y).

Drawing functions: RCLR(X) {return color}, RDOT(X) {return position or color source of pixel cursor}, RGR(X) {return graphic mode}, RWINDOW(X) {return size of window or column width of screen}.

Sprite commands: COLLISION COLOR MOVSPR SPRCOLOR SPRDEF SPRITE SPRSAV
Sprite functions: BUMP(X) RSPRCOLOR(X) RSPPOS(X) RSPRITE(X).
 
Last edited:

Wertyloo

Member
Sep 15, 2019
72
7
8
The graphics commands in C128 Basic are BOX CHAR CIRCLE COLLISION COLOR DRAW GRAPHIC LOCATE MOVSPR PAINT SCALE SCNCLR SPRCOLOR SPRDEF SPRITE SPRSAV SSHAPE/GSHAPE WINDOW and the graphics functions are BUMP(n) RCLR(N) RDOT(N) RGR(N) RSPRCOLOR(N) RSPPOS(N) RSPRITE(N) RWINDOW(N). C128 PRG
nice... and greetings!
as it seems, this sys. could be really benefit some kind of hw-accel.ed primitive functions, like a dot and line, if any space left in the vera at all
i dont want to imagine,how "fast" would be a 640x200 screenmode with any filled primitives[like windows for geos] or just a simple box or line 0,0,639,199 diagonal
hope the devs sincerely testing on REAL APPLICATIONS the speed and usefulness,not just some synthetic benchmarks :grumpy_cat:

but a 3d mark like sys. test prog., what looks like beautyfull too, would be great... 😸
 
  • Like
Reactions: BruceMcF

BruceMcF

Active Member
May 19, 2019
139
42
28
nice... and greetings!
as it seems, this sys. could be really benefit some kind of hw-accel.ed primitive functions, like a dot and line, if any space left in the vera at all
i dont want to imagine,how "fast" would be a 640x200 screenmode with any filled primitives[like windows for geos] or just a simple box or line 0,0,639,199 diagonal
hope the devs sincerely testing on REAL APPLICATIONS the speed and usefulness,not just some synthetic benchmarks :grumpy_cat:

but a 3d mark like sys. test prog., what looks like beautyfull too, would be great... 😸
If they get to an 8MHz clock, it would be faster than a 320x200 screenmode on a C64 or a 640x200 screenmode on a C128.

I reckon they are likely to balk at including an hw acceleration of the graphics primitives ... it's a slippery slope from just adding a hw horizontal line for accelerated fills to having a full fledged GPU with an internal graphics processor doing the heavy lifting. and my guess is that they would rather stay off that slope.
 

Wertyloo

Member
Sep 15, 2019
72
7
8
I reckon they are likely to balk at including an hw acceleration of the graphics primitives ... it's a slippery slope from just adding a hw horizontal line for accelerated fills to having a full fledged GPU with an internal graphics processor doing the heavy lifting
with respect BruceMcF, how would be a "slippery slope" if they _only_ make the 2 most basic and necess.y primitives[plot+line] implement in hw level? no need more, as these 2 are enough to accel. considerably all the others,like 4x line for a square, or a filled square...
its good also for mem. size as for a fast plot routine needs a long lookup-table
and 'cos this is a small comp. no need for all hw accel on everything
use the stairs next to that slippery slope... 😸
 

BruceMcF

Active Member
May 19, 2019
139
42
28
with respect BruceMcF, how would be a "slippery slope" if they _only_ make the 2 most basic and necess.y primitives[plot+line] implement in hw level? no need more,
In the same sense that they do not need MORE than that, they also do not NEED those. They would just provide X benefit in Y circumstance, same as the DMA, the blitter, the coprocessor, the jpeg converter and etc. that there is some strand of people calling for.

The slippery slope is in the followup question "if benefit X1 in Y1 circumstance, why not benefit X2 in Y2 circumstance?"

They've already done one big pruneback after big feature creep in the original board design. I don't think they are keen on heading down the same road in the design of the Vera.
 
Last edited: