Updated GFA-BASIC Library released

[lp060]

This bug was actually not my fault. If you find a copy of the original 3.5 runonly from GFA it should produce the same bug! When Frank built the runonly and removed parts of the editor he introduces new bugs. Since there was no 3.6 runonly I used the 3.5 version as a guide to build mine and ended up duplicating his bugs.

For those that do not know GFA incorporates a 4kb read/write disk caching scheme. You can verify this by reading a byte from a file, pause, then read another byte and the drive LED will not blink on further reads until you exceed 4096 bytes read. It's somewhat redundant under MiNT since MiNT has its own disk caching scheme, but its never caused any problems. The caching scheme is so intertwined in the file I/O code that I am afraid to remove it, so it remains unchanged. It does make it extremely fast on plain TOS, so its all good. Anyway the above bug, was a missing call to flush the disk cache before the files were closed. I thought you would like some background info on how gfa works internally.

[lafleche]

It's indeed very interesting to know.
I'm also dealing with cache flushing at work (but in Java ...) so I can figure out the consequences.
So I guess it does also mean that you won't get your data written in real time ?
I'm asking because I'm thinking of a little experiment I would like to try :
-A laptop running Linux with Aranym booting automatically, a GFA program that polls the serial port and writes some data in a local file
-A linux script that polls that file as a background task to extend somewhat the possibilities of Aranym's "NatFeats". eg. : receiving a particular string starts playing an audio CD ...
In the later feature, I would have to ensure the cache is flushed, otherwise I would have to wait for 4k to be received to see my action triggered, right ?

[lp060]

You ask an interesting question. If you close the file it forces a flush of the cache, so maybe use Append mode? Open for append, write line, close it. The file is always growing if that is what you want and it would be flushed after each line written. Otherwise I think you would have to pad it to 4096 bytes to trick GFA into flushing the buffer.

Another idea, to avoid any problems, is use all direct gemdos() calls, fopen(), fwrite(), fclose() etc. and then GFA caching is never used and you have real-time I/O at least within GFA. However, MINT is caching the file I/O if you use aranym and I don't know how to force it to flush the cache. I think the disk caching in MiNT is configurable in MiNT.CNF. Possibly you can disable it, I'm not sure.

[lafleche]

I tried this morning and it seems Aranym/linux doesn't handle the serial port well (but it's a new, almost beta, feature after all).
So I'll definitely take your remarks into account as I'm planning to use a file instead of the emulated serial port, mostly based on the fact that with Linux every device is a file and I should be able to access the serial port just opening the "/dev/ttyUSB0" as a regular file.
My main issue will be the following : avoiding disk caching means getting rid of Mint, switching back to pure TOS, so means also forgetting about Natfeats and local file system access (If I'm not wrong about natfeats beeing reserved to Emutos and Mint).
So I'd better deal consider your clue and either try to disable Mint disk caching or try the append mode trick ...

[lp060]

Now that I have added Firebee support in GFA I wanted a way to detect the coldfire cpu from within the language. The init phase of GFA has already looked into the cookie jar, so it occurred to me I could use the unused bits of the STE? function to provide much more info to the coder.

I have expanded the STE? function to return the following new bits 2 thru 8:
bit 0 = if set, machine has enhanced joystick ports (STE/Falcon030)
bit 1 = if set, machine supports stereo 8-bit playback (STE/Falcon030/TT030)
bit 2 = if set, CPU => 68020
bit 3 = if set, FPU detected
bit 4 = if set, Coldfire CPU detected
bit 5 = if set, no AES init (started from auto folder)
bit 6 = if set, running as an ACCessory
bit 7 = if set, MiNT is present
bit 8 = if set, running compiled code

Bits 2/3 are also returned by the TT? function, but it has an annoying hidden feature where it installs CPU and FPU replacement code, so its no good for just polling. The TT? function shall remain as is for compatibility in case anyone has used it.

If you I want to know if the machine has a coldfire cpu, I can simply do this:
IF BTST(STE?,4)=TRUE THEN
or
coldfire!=BTST(STE?,4)

The function returns a full long, so there is more room to expand. I could put the _MCH value in one of the upper bytes as well.
Comments and suggestions welcome.