How hard would it be to make the language modular enough that it could be extended with new keywords?

E.g. if I wanted 64 column printing to work with MICROPRINT AT 18,43;INVERSE 1; "TEXT"

I could publish a module that would add this functionality?

since i'm seeing so many good games from MojonTwins supporting ULAplus, and its implementation looked so simple, i tried to code some library and example for that - be welcome testing it (i think would be a good idea if this could be implemented defaultly on zxbasic-compiler, what do you all think?)
(for now i'm testing this on SpectEmu on Wine, while there are no native emulators for LInux)

library/ulaplus.bas

recently i were trying to use the zx-spectrum display like 8x8 patterns used on tms9918 (used on msx1, Sega-sg1000, Colecovision, ti99/4, etc. - and somehow similar on what is used on Sega-MasterSystem or NES)

i'm curious on using the display like this, specially when we see some games this way, if i'm not mistaking, 'Stop the ITA-Express' (Hudson), King's Valley (originally Konami, converted from Retroworks), etc.

besides tms9918 uses 2 banks of 2kb (one for bitmap, and another for 8x1 attributes), on the charmap01.bas i'm using 2k for bitmap and 256 bytes for attributes

issues: just like 32x24print example, and i'm not using asm routines, i'm having performance problems as expected (i really wished to be more skilled on assembly for that)

example.bas

just sharing a snippet i coded now - this is about handling 4 simultaneous players (just like those arcade games from early 90's) on one keyboard - the only issues is maybe some sprites ('printing' udgs for that) may disapear, and on emulators (due on keyboard hardware or driver limitation) more than few simultaneous keys (like 6, depending) are not recognized, but i think this doesn't happen on real hardware.

this code is relativelly similar to one in assembly i posted on Karoshi msx forum, with some help from there - the code below has some differences, like the lack of hardware sprites on zx-spectrum, being all in basic language (except asm defb), etc.

please share oppinions, feedback, suggestions, etc., about this! - in my oppinion, games behaving like this (4 simultaneous players on one keyboard) are really rare on zx-spectrum, afaik

the keys used are 'wsad' for 1, 'tgfh' for 2, 'ikjl' for 3, and cursor keys for 4

i did a test with the code below on both zmakebas (tokenizes zxspectrum-basic into a .tap file) and Boriel's zxbasic compiler, and it seems Boriel's compiler is missing colour 9 support:

does anyone know how to convert a sprite (in any format) to ASM defb statements?

say for example my sprite was like this:

1,0,0,0,0,0,0,1
1,0,0,0,0,0,0,1
1,0,0,0,0,0,0,1
1,0,0,0,0,0,0,1
1,0,0,0,0,0,0,1
1,0,0,0,0,0,0,1
1,0,0,0,0,0,0,1
1,0,0,0,0,0,0,1

i don't know if this is a bug, or if i'm defining variable kind wrongly ('j' is not stopping at '0') - thanks in advance!

Hi Boriel. I just adapted a ASM routine for key-redefining from WOS Forum to ZXBC for my next game, and noticed following:
EQU is not supported?
DEFM supports only Strings, but not mixed bytes+strings in one line like: DEFM 14,10,5,"Down",255
I adapted the lines by lacerating them to DEFB,DEFM and DEFB again, but maybe it would be a good idea to support bytes and Strings with DEFM, like other assemblers do.

any chance of OO programming features?

the compiler doesnt like it when #include statements are not the first thing in a line
so this will work:
#include
but this will not:
<space> #include
the error message complains about a period or full stop being in the wrong place which is not the right issue.

This may turn someone off the language if they cant solve the problem