gtBASIC

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
at67
Posts: 252
Joined: 14 May 2018, 08:29

Re: gtBASIC

Post by at67 »

Ver 1.0.9R, (Release, runtime 0104)

This release focuses on SDCard compatibility with Norgate's Pluggy Reloaded and emulator/tools/gtBASIC compatibility
with the Raspberry Pi 400.

Code: Select all

- More fixes for INIReader.h for GCC versions < 8.
- Fixed Linux strncpy warning in INIReader.h properly for the Raspberry Pi 400.
- Fixed a nasty lazy unsigned cast bug that should have been an explicit check in Operators::handleDualOp();
this was only causing issues for the Raspberry Pi 400
- Fixed compiler warnings and errors for the Raspberry Pi 400, thanks to Maniccyberdog.
- Added an SDCard browsing utility and ROM for Norgate's Pluggy Reloaded.
- Added more sytax error messages to the BASIC compiler.
- Added the SPC$() function to the BASIC compiler, this allows you to generate sequences of spaces, (max 255
within a print statement using a literal count, otherwise max 94).
- Added the STRING$() function to the BASIC compiler, this allows you to construct a string from a memory
address, e.g. s$ = STRING$(<addr>).
- Added the EXEC statement to the BASIC compiler, this allows you to execute vCPU code embedded within ROM,
e.g. EXEC <rom address>.
- Added literal characters as a shortcut to anywhere you would use the ASC() function, (including static initialisation
code), e.g. f = 'A'
- Added better name collision detection for ints, consts and arrays.
- Added uninitialised arrays as an option, thereby allowing .gt1 files to potentially be much smaller for the exact same
code, (this can be crucial when embedding .gt1 files into ROM). The side effect of this change is that previously 
'DIM a(9)' would initialise 10 words to 0 in the .gt1 file using DW ASM commands, now your array is initialised with
random values. To get the previous functionality, change your code to 'DIM a(9) = 0'
- Refactored horribly overloaded function names for Expression::tokenise() and Compiler::parse().
- Fixed ROM addresses in the disassembler and the hex editor from wrapping back to zero incorrectly.
- Fixed a sly nasty bug whereby int arrays were needlessly stealing a global int var slot during their construction.
Maniccyberdog
Posts: 14
Joined: 11 Nov 2018, 13:18

Re: gtBASIC

Post by Maniccyberdog »

Just tested on the pi400, builds fine. Can I ask do the sprites work on real hardware? Also when moving a sprite on screen does the old sprite need to be erased first, I’m seeing multiple sprites when updating the xy position.

Thanks for all your hard work!
at67
Posts: 252
Joined: 14 May 2018, 08:29

Re: gtBASIC

Post by at67 »

Maniccyberdog wrote: 27 Jan 2021, 11:52 Just tested on the pi400, builds fine.
Great.
Maniccyberdog wrote: 27 Jan 2021, 11:52 Can I ask do the sprites work on real hardware?
They sure do, whatever you see in the emulator you will see on real hardware.
Maniccyberdog wrote: 27 Jan 2021, 11:52 Also when moving a sprite on screen does the old sprite need to be erased first, I’m seeing multiple sprites when updating the xy position.
Yes it does, they aren't real sprites more like a memcpy that stamps an image into a destination on the screen. The easiest and probably most efficient way to erase the previous sprite is to include the background colour as a border in your sprite image. So if moving 1 pixel to the right a vertical 1 pixel stripe of the background colour on the left of your sprite image would erase the old sprite automatically. If moving 2 pixels, then it would need to be a width of 2, etc. For a generic sprite that can move in all directions you could build 4 versions of your image and switch between them appropriately, or build an image with a border all the way around it; there are multiple ways of achieving the same result.

The one thing that is difficult to do is to generically restore the background of multiple colour pixels, there is no native code to save on screen pixels to a buffer yet, so working with solid colour backgrounds is the most efficient thing to do right now.

Sprites can have any height, (up to screen height), and generally must have a width as a multiple of 6, you can produce sprites with widths that are not multiple's of 6, but then you need the SPRITE_OVERLAP parameter in the LOAD SPRITE command; you also need to add that overlap as an empty strip within the source image, (it's not as difficult as I am making it sound). See 'PucMonData.m' and the PucMon .tga files themselves for an example.

The 'SpriteBig.gbas' example under gbas/graphics should give you an idea of what the system is capable of by using a few shady tricks.
Maniccyberdog wrote: 27 Jan 2021, 11:52 Thanks for all your hard work!
Cheers.
Post Reply