nxtBasic: A New Compiler for Basic Code on the X16

[unartic]

nxtBasic is a new compiler for Basic code. If you're familiar with any Basic language, you'll find nxtBasic easy to use.

• The current version is the first beta release, so please expect some bugs, although it has been extensively tested.

• nxtBasic is available for Windows, Linux and MacOS

• nxtBasic comes with comprehensive documentation, including a complete language reference with syntax information and several example programs to help you get started.

• It integrates seamlessly with the Commander X16 emulator. Check the "Getting Started" section in the documentation for more details.

• I plan to add many extra functions to nxtBasic, including support for tilemaps, sound, functions and subs. There is also a lot to improve still, which will be done over time. If you have any requests, remarks, or suggestions, please post them below or send me a direct message.

• nxtBasic is highly customizable. If you know a bit of assembly, you can create new built-in functions or even modify the behavior of existing ones.

Documentation and download are available here:
https://github.com/unartic/nxtBasic/



nxtBasic 0.6b is now released and ready to download.

Whats new?

- Bug fixes

• Fixed bug in ASC function
• Fixed bug in left$
• Fixed bug with loading basic constants
• Fixed bug with incorrect compile time errors when two return types are possible
• Fixed bug when returning a value in a function with using EXIT FUNCTION

- New:

• Commmand: 'HLT' to stop execution of code. Handy for debugging
• Added REPLACE$ to replace a portion of a string
• Added SPLITITEM$: a 'split in place' function
• Added Tally(): counts occurences of a char in a string
• Added INSTRREV(): same as INSTR but then check from right to left

- Improved:

• Performance improvement of about 50% on PSET
• Compile time error checking on using the '+' operator on a mix between string and number
• Implemented new way to load string and float literals, reducing prg size

Docs and download:
https://github.com/unartic/nxtBasic/ or https://nxtbasic.com/

[unartic]

I've just released nxtBasic v0.2b

Now also available for Linux (thanks for Tony for compiling)

What's new:

Bug fixes:

• Compiler: comparison operants mixing floats and integers didn't work correctly

• Assembler: Indirect label replacement for values >255, missing leading zero

• Fixed double declaration in drawbmx.bas example program

Added:

• support to play ZCM files from disk

• support to play ZSM files from disk

• INSTR-function

• LINPUT#-function

Improved:

• RESTORE {label}: can now be used with label

• #INCLUDE keeps track of which files are included and will not include a file with the same name more then once.

• If nxtbasic is called when not in the nxtbasic direcory, dependencys are read from the nxtbasic directory

More information:
https://github.com/unartic/nxtBasic/

[mgkaiser]

It seems like "ADDSPRITE" gives me a 256 color sprite no matter what I specify for "ColorDepth".

[mgkaiser]

"spritetest.bas" shows the behavior of it always giving a 256 color sprite regardless the setting of "colordepth". "sprite.bin" is the sprite file I'm loading. "sprite.bin" contains 32 bytes which I expect to represent a 16x16x2bpp sprite.

[mgkaiser]

Bitwise AND does not appear to work...

"print 255 AND 128" should yield "128". Instead it yields "1". I think because 255 is "true" and 128 is "true" so it returns "1" or "true".

[ahenry3068]

Bitwise AND does not appear to work...

"print 255 AND 128" should yield "128". Instead it yields "1". I think because 255 is "true" and 128 is "true" so it returns "1" or "true".

Mr Unartic was using 1 for FALSE & 0 for TRUE. His AND/OR/NOT aren't proper bitwise operators. We had a discussion on DISCORD about this and he's changing it back to -1 for TRUE & 0 for FALSE as is usual in BASIC. He has assured me that this and Bitwise operators are fixed in the next release.

[unartic]

"spritetest.bas" shows the behavior of it always giving a 256 color sprite regardless the setting of "colordepth". "sprite.bin" is the sprite file I'm loading. "sprite.bin" contains 32 bytes which I expect to represent a 16x16x2bpp sprite.

Thanks for testing

I've checked and indeed there was an bug with 4bpp sprites. Also the documentation mistakenly stated 2bpp was also supported, but VERA does not support that, so I'll change that too.

However, your sample sprite is 32 bytes, which means it is 8x8pc in 4bpp. Just to let you know. Here is what you sprite should look like:

Schermafbeelding 2024-07-16 095329.png (296 Bytes) Viewed 1466 times

The fix will be released with the next release. Probably friday.

[unartic]

Bitwise AND does not appear to work...

"print 255 AND 128" should yield "128". Instead it yields "1". I think because 255 is "true" and 128 is "true" so it returns "1" or "true".

As Tony already mentioned this has already been fixed and will also be released with the comming release.

Again, thanks for your feedback

[mgkaiser]

"spritetest.bas" shows the behavior of it always giving a 256 color sprite regardless the setting of "colordepth". "sprite.bin" is the sprite file I'm loading. "sprite.bin" contains 32 bytes which I expect to represent a 16x16x2bpp sprite.

Thanks for testing

I've checked and indeed there was an bug with 4bpp sprites. Also the documentation mistakenly stated 2bpp was also supported, but VERA does not support that, so I'll change that too.

However, your sample sprite is 32 bytes, which means it is 8x8pc in 4bpp. Just to let you know. Here is what you sprite should look like:

Schermafbeelding 2024-07-16 095329.png

The fix will be released with the next release. Probably friday.

I meant for it to be 2bpp 16x16. Since 2bpp doesn't exist I will have to rework it.

[unartic]

I meant for it to be 2bpp 16x16. Since 2bpp doesn't exist I will have to rework it.

Does this come close?

Schermafbeelding 2024-07-16 170556.png (290 Bytes) Viewed 1417 times