Parameters following 'CALL' for pixel-plotting are limited to 8-bit-bytes only.

[netzerohero]

Parameters following 'CALL' for pixel-plotting are limited to 8-bit-bytes only.

For example, CALL HPLOT,x,y,color used on the original-graphics-implementation's 320h x 180v x 8bpp limits the x-pixel-parameter to values less-than 256. This is a limit stemming from EhBASIC's ability to only parse byte-parameters following the CALL keyword and its use of assembly code at label LAB_SCGB = "Scan-for-Comma-and-Get-Byte".

To allow for x-pixels beyond 255: e.g., 256 thru 319, one-additional bit of info would be necessary.

1. One option, an unattractive hack, would be to add an additional (4th) parameter to the CALL HPLOT to indicate x-pixels > 255.

2. Another option could be to abandon using "CALL" and perhaps move to using EhBASIC's "USR" keyword to bridge the basic-to-assembly/c gap with USR's more expressive parameter options callable from EhBASIC.

3. Yet another option could be to hook into the EhBASIC token/keyword methodology. This however will lead to having discussions about 'syntax' (should we use Apple-2-like HGR and HPLOT, or C-64 syntax, or something completely new). This option will divert attention from the main issue.

4. Other options?

[netzerohero]

Settling on Option-3 above.
8-bit-byte limitation can readily be overcome in moving the point-plot command-extension to an EhBASIC+ keyword. As discussion w/ vruumllc on RFC-3 has pointed out:

Could you get rid of the 8-bit parameter limit if you made them keywords, rather than use the CALL mechanism?
If so, I'd vote for doing that.

Yes - using keywords rather than CALL will get beyond the 8-bit parameter limit.

[netzerohero]

Before additional efforts pursued on Option-3 above; work through efforts on learning how to added new commands to EhBasic's token-system (such as adding XPEEK/XPOKE). See (#2 (comment)). Once tokenized-commands understood, then hook-up the new graphics-commands and overcome the 8-bit limitation on the x-axis.