GBE is short for 'GFA-Basic Editor'. It's fully compatible with v3.x tokenized files and offers many new features, most importantly multi-tasking. Work on documentation, resource files, or whatever without ever having to exit the editor. It's a full IDE, meaning there's no need for the old MENU.PRG shell that was used for compiling. Everything can be done from GBE. It supports building 68K and Coldfire V4E binaries regardless of the host machine. This is accomplished via two separate libraries. The entire GFA manual is included and GBE provides context sensitive help via ST-Guide.
GBE looks and feels like the old GFA editor, but has many new features. The main window has a scrollbar and the colors, font face, and font size can be changed. It remembers the line last edited when a source file is saved and returns to that line when the source is load later. Unlike the old editor, a subroutine can be folded at any line. It's also possible to jump from a subroutine call to the actual code segment. There are several options to help debug code and even a GEM validation feature to help users write clean GEM applications. It also supports import modules for loading other file types like GFA v2.x files. The interpreter and compiled code runs as a separate process completely independent of the editor. If the interpreter was to crash or the compiled code and it's not to severe, the source code will not be lost since MiNT is pretty good at recovering from such errors. GBE also adds a pre-processor that allows manipulation of the source before it's sent to the compiler. The pre-processor can be used to replace symbols with constants for smaller faster code or for making compile time decisions. It also supports re-using code (merging LST files) at compile time. The compiler and linker have been updated to work better under MiNT and many bugs have been fixed in the library. There's also a Coldfire V4E version of the library to support the FireBee. FireBee support is as easy as rebuilding a source with the Coldfire V4E version of the library. Some advanced INLINE + Assembler options are also available, this feature relies on Devpac.[68K/V4E compiling video]
GBE is GFA-Basic on steroids and as such, it requires at least a 16Mhz machine or better with 4mb of ram + MiNT.
A minimum resolution of 640 x 480 is required in any color depth up to 32-bit.
It is not designed for SingleTOS or 8Mhz machines. If you are using SingleTOS stick to the original GFABASIC editor!
You can however use the updated compiler, linker, and libraries on any machine.
N.AES (the defacto standard, used during development)
XaAes (should work, if not report it to the MiNT-list)
MyAes (not tested by me, heard it worked, if not contact the author)
Geneva (currently all versions crash/hang at Make: missing newer shel_write() modes)
Thing Desktop (used during development), or other desktop with an AVServer
ST-Guide (used during development), or HypView should work
Devpac (included in the GBE archive), supports 68000 to 68040 + FPU
MagiC (not tested)
You will also need an idea for a project of course. ;o)
If you want to code with GBE on real Atari hardware with a minimal MiNT setup (no Unix stuff), I recommend VanillaMiNT. Install VanillaMiNT and GBE and you're good to go.
Normally I would not recommend an emulator, however if the end result supports the platform, well then I guess that's all that matters.
I suggest ARAnyM since it's designed for MiNT and supports host network access.
ARAnyM can be installed on Mac, Linux, or peecee.
You have two options:
1) Setup ARAnyM + AFROS and install GBE yourself. (Pain in the ass!)
2) Get EasyAraMiNT and update GBE which is pre-installed. (Much easier)
You can take this one step further and install Hatari and point it at the same host directory. Then you can code and build in ARAnyM and simply switch windows and test the results almost instantly in Hatari. Such a setup could be used to code games or demos, but in a more comfortable way and with a better work flow. See my emulation page for tweaking ARAanyM on macOS.
GFA on the FireBee is not a native ColdFire application. This means it relies on the CF68KLib built into FireTOS. Under normal circumstances you cannot unleash the full speed of the FireBee with GFA. However, if you was to write your own 'CF clean' add-ons in assembler or 'C', then it's possible to fly. This is really the only limitation imposed on the FireBee. GFA allows access to all operating system interfaces (AES, VDI, GEMDOS, BIOS, XBIOS) and one only needs to write a binding to access system level functions not already built into the language. You will need additional documentation of course, such as TOSHYP.