Candidate EhBASIC+ command extensions.

[netzerohero]

Attached below is a spreadsheet containing candidate command extensions. The top-row has selection-filters; use the spreadsheet's pull-down available in each column to filter and de-clutter. After reviewing some heritage BASIC command syntaxes and source-codes, initial commands and implementation priorities are suggested.

EhBASIC_cmd_extensions_(20240128).xlsx

[netzerohero]

I suggest moving the 1st four commands (demonstrated via the CALL commands extensions) as the first picocomputer's specific EhBASIC+ new keywords:

1. SCREEN <dimension-#>
2. HPLOT (x,y)[,color]
3. CLS
4. TEXTMODE,#columns

In moving to EhBASIC's keyword architecture, the 8-bit limitation on HPLOT coordinates should be rectified.

[Hyenadae]

It looks like I missed a bunch in the past few weeks, I'll need to upgrade my firmware and join this branch of Ehbasic!

So far going through this list, I feel like it'd be a good idea to stick to AppleSoft BASIC syntax where it isn't "old computer magic spells" tier un-obviousness (ie, pokes/peeks), and if it is, substitute it for MSX Basic if that is sane?

The only issue with using SCREEN for selecting resolution/color bittage is it 'conflicts' I suppose with the other Applesoft-derived commands such as HPLOT/HDRAW. I wonder what preference others have, it mainly depends on which real/retro BASIC syntax is most favored among the community. If we were to make a monochrome 640x480 graphics mode, would we use SCREEN 3 then, or should we make it Screen 1 (where Screen 0 is our 256 color one we've mostly been messing around in?)

Also, If we were to stick to HPLOT but extend it to accept 4 values for #21 (Line To Plot), then, we could create a new HFILL alias for wide-area color fill with the same syntax as PAINT? Or in reverse, I guess use PAINT but it's HPLOT told to accept a range as that'll

For the XREG side, could a single command/keyword be created which accepts a string, then the value to work with?
ie, keyword is 'only' XREG, but you can do XREG PEEK 0000 to reduce the amount of individual keywords?

How would double buffer screens work on our platform, doesn't that require a full spare of XRAM to hold the buffered copy? I recall we're maxing out XRAM capacity with our modes, could we skip it?

[netzerohero]

Yeah - where have you been?! Time to get caught-up with all that's been happening.... :)

My current simple understanding of the pico-graphics HW/FW is that, from the user's perspective, has 4-screen dimension modes plus ability of a 80/40-column textmode/console of its 3 video planes (ignoring alpha-layer overlaying):

So the parameter for the suggested "SCREEN" command (or HGR if going the Applesoft way) would be those four: 1 through 4.
Command-parameter 0 would be used in selecting return-back to textmode/console. (Try out in the pre-release 'CALL' versions of EhBASIC+. Neither of the 640 pixel modes have been prototyped in EhBASIC+.)

On the XREG syntax side - I'm not sure where that is going yet. I completely buy into to the flexibility of providing such powerful low-level access from BASIC, albeit it's not user-friendly. But I've been grappling with the lower-level hardware-features and architecture to fully understand it all yet. To wit:

Double-buffering - My 8-bit days were teething with Apple-2's (not to mention the hand-built 1802) that until the picocomputer, were tabled for roughly 35-years. Double-buffering on its simple-HW was a significant feature. As I review the picocomputer's architecture-block-diagram, I see two VRAMs on each pico:

As far as 'dialect' of the new keyword syntax - as Rumble pointed out in his recent BASIC video, porting BASIC-code from one machine to another has always had some small measure of syntax conversion. Dialects from later generations (e.g, Commodore, MSX / GW-BASICs) may have some attractiveness. Let's see how these discussions coalesce before eventually settling on an implemented syntax. Unless the picocomputer's EhBASIC+ should be targeting a specific historical BASIC dialect, it may be that the best of all dialects may be settled upon.

[netzerohero]

From the simplest to increasing level of difficulty, the following issues of adding new EhBasic-plus commands should be worked in order:

1. XREG / XPEEK / XPOKE / XDEEK / XDOKE #2 (comment)
2. Provide BASIC access to clock()  #14 (comment)
3. Parameters following 'CALL' for pixel-plotting are limited to 8-bit-bytes only. #4 (comment)