gtBASIC

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
at67
Posts: 319
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: 319
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.
lb3361
Posts: 40
Joined: 17 Feb 2021, 23:07

Re: gtBASIC

Post by lb3361 »

Is there a comprehensive reference documentation that explains all the GTBasic keywords ?
at67
Posts: 319
Joined: 14 May 2018, 08:29

Re: gtBASIC

Post by at67 »

lb3361 wrote: 08 Mar 2021, 22:43 Is there a comprehensive reference documentation that explains all the GTBasic keywords ?
I'm working on it now, it's a rough slog.
rob
Posts: 3
Joined: 20 Feb 2021, 23:17

Re: gtBASIC

Post by rob »

I am trying and failing to use gtemuAT67.exe's "download to HW-Gigatron via right click .gt1 files in its file browser"-function with Pluggy reloaded.

First question: Is this a supported function of gtemuAT67.exe v1.0.9R (Windows 10)?

If yes: I tried to use Babelfish from Norgates Gihub:
https://github.com/pkupper/gigatron-rom ... /BabelFish

and AT67's version:
https://github.com/at67/gigatron-rom/tr ... elFish_nor

both times gtemuAT67.exe starts with resetting the Gigatron and subsequently starting the loader. After that it hangs with upload progress bar at 0%.


What am I doing wrong?


(Also gtemuAT67.exe's serial terminal seems to show results too late on my machine.
Example:
In: h[Enter]
Out: :Gigatron OK
Cmd?
In: [Enter]
Out: [shows help message]

whilst with a different terminal babelfish behaves as expectded.)
at67
Posts: 319
Joined: 14 May 2018, 08:29

Re: gtBASIC

Post by at67 »

rob wrote: 10 Apr 2021, 19:58 I am trying and failing to use gtemuAT67.exe's "download to HW-Gigatron via right click .gt1 files in its file browser"-function with Pluggy reloaded.

First question: Is this a supported function of gtemuAT67.exe v1.0.9R (Windows 10)?
Yes it is.
rob wrote: 10 Apr 2021, 19:58 If yes: I tried to use Babelfish from Norgates Gihub:
https://github.com/pkupper/gigatron-rom ... /BabelFish

and AT67's version:
https://github.com/at67/gigatron-rom/tr ... elFish_nor

both times gtemuAT67.exe starts with resetting the Gigatron and subsequently starting the loader. After that it hangs with upload progress bar at 0%.

What am I doing wrong?
If the hardware is being reset, then there is some sort of communications happening.
rob wrote: 10 Apr 2021, 19:58 (Also gtemuAT67.exe's serial terminal seems to show results too late on my machine.
Example:
In: h[Enter]
Out: :Gigatron OK
Cmd?
In: [Enter]
Out: [shows help message]

whilst with a different terminal babelfish behaves as expectded.)
This means that gtemuAT67 and BabelFish on the Arduino are out of sync, when this happens you generally can get away with just exiting gtemuAT67 and hitting the reset button on Pluggy Reloaded. Sometimes though, (rarely), you have to re-upload BableFish to Pluggy Reloaded.

I recommend you upgrade to the new SDCard version of BabelFish, this should solve your sync issues and also enable you to browse the contents of SDCards inserted into Pluggy Reloaded; there are 2 versions, an SDCARD_ROM version and a NO_ROM version. If you don't want to or don't have the capability to burn new EPROM's, then use the NO_ROM version of BabelFish, full instructions and downloads are here: viewtopic.php?f=4&t=279
rob
Posts: 3
Joined: 20 Feb 2021, 23:17

Re: gtBASIC

Post by rob »

Thanks at67, that did it.
at67
Posts: 319
Joined: 14 May 2018, 08:29

Re: gtBASIC

Post by at67 »

rob wrote: 11 Apr 2021, 08:28 Thanks at67, that did it.
8-)

If you exit the emulator mid upload to the hardware, then that is a guaranteed way to get BabelFish out of sync with whatever tries to talk to it next. The upload process in the emulator is handled by a separate thread, so it's very easy to exit whilst a long upload is in process; try not to do that if possible.

Follow the previous BabelFish reset instructions if it does happen, you can also pull the USB cable out of Pluggy Reloaded as well as hit Pluggy Reloaded's reset button, (I guess the Arduino's USB/Serial stack is reset every time it detects a USB insertion).
Post Reply