Using GFA Basic In 2016

GFA BASIC-related articles in here please

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm

Re: Using GFA Basic In 2016

Postby AtariZoll » Sat Mar 05, 2016 5:24 pm

Mikefulton wrote:...
The issue with CPX size wasn't really so much the overhead of a high-level language. It was the fact that they were all individually compiled and linked as stand-alone things. Meaning if you had a half-dozen CPX modules loading, you likely had half a dozen copies of the same C runtime code.
Beyond that, the real problem is something I've touched on in my blog... the way GEM AES was designed, your application had to do a fair amount of work just to do the "basic" minimum level of event handling for the GUI. So, in addition to that half dozen copies of the same C runtime code, you probably also had a half dozen copies of essentially the same code for processing messages, redraw events, etc.
Neither of those issues really has anything to do with "C" being inefficient or not. It wouldn't have been that hard to do a shared runtime library that only needed to be loaded once. And because of the differences in how the system has default behaviours for event handling, an executable for a simple program similar to a CPX might only be a kilobyte or two for MS Windows, versus probably at least 10-12kb with GEM.

Dozens of C overhead is still C overhead . Better said overhead of overhead :mrgreen:
I don't think that APPs need to do so much work for some simple dialog, window and like. In case of my disk imaging and copy SW, what is about 10 KB long, only about 1.5 KB is code for init AES, draw dialog, handle user inputs etc. RSC is much longer - some 3 KB. Other is disk code self. So. I don't think that we need some special library for that - although I use always same code for AES and VDI calls, but that's really short - not more than 300 bytes.
Certainly can do some ACC or CPX module like for setting 16 colors in 2-3 KB size - including simple dialog.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
Posts: 905
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden

Re: Using GFA Basic In 2016

Postby shoggoth » Sat Mar 05, 2016 6:09 pm

C compiler efficiency has evolved since 1985, generally you'd be amazed what GCC does with properly written source code. While you can shave off some instruction here and there, it's not as easy to beat the compiler any longer. Naturally there are exceptions, such as when exploiting neat side effects of certain instructions, but that's generally that's not the case for e.g. GEM applications.
Ain't no space like PeP-space.

Atari freak
Atari freak
Posts: 61
Joined: Sun Nov 14, 2010 3:08 pm

Re: Using GFA Basic In 2016

Postby Scottinnh » Sun Mar 06, 2016 6:28 pm

Scottinnh wrote:
Scottinnh wrote:I see both sides, and really IMO it's about more than GFA, it's any form of legacy programming.

My opinions (disclaimer: I don't code on Atari at all)

(EDIT: clarification; wasn't clear which the PROs/CONs referred to)

* the notion that C requires "experience" (lots of consultation against reference docs until concepts become muscle memory)
** perception that C requires greater effort for less result (see above)
* Docs for GUI C coding will assume the reader is versed in C fundamentals, putting novice C coder at great disadvantage
** ...talking C as a new language, on the ST, means considerable time spent practicing "boring" CLI applications
* Pure sentimental/nostalgia feedback (which is healthy -- as long as one doesn't get carried away..)

* C is relevant to the modern, real world.
** (Even if you don't "want" to become a professional programmer, simply having the skill opens many non-coding doors).
* C is useful for much more than than creating applications for users.
** Ability to interact with hardware, or communicate with cool stuff like Arduinos (which use a simplified C language).
** Being able to understand "cool stuff" done for other OS like the C64, Amiga, Linux... being able to interact with Arduino and sensors using Firmata protocol, and so on).

Personally, I'm not a C coder (except for things I forget from school, and more recent fun on the Arduino).
I'm competent enough with Python/Perl/Bash/PHP to be employed for those skills however these languages don't exist on the A8 or a 520ST
(I'm aware of Jeff Armstrong's awesome port of Python 3 to FreeMiNT -- looks nice -- but that OS requires 4MB I don't have on my 520ST... and no one's ported MicroPython to the Atari ST, as far as I know).

I could see some relevancy in the Contiki OS, as they're making a play for the Internet of Things space. But I expect that too relies heavily on C. I've found a few threads on Contiki and Atari 8-bit, but not much on the ST, and not much about the capabilities of the Contiki environment under Atari.
Atari since 1983 (1200XL, later ST). Now a Linux freak who uses a Mac at work.

Atari freak
Atari freak
Posts: 61
Joined: Sun Nov 14, 2010 3:08 pm

Re: Using GFA Basic In 2016

Postby Scottinnh » Sun Mar 06, 2016 6:33 pm

exxos wrote:Those pros and cons look backwards to me.

Fixed. They were not backwards, but it was unclear which language was under PROs..
Atari since 1983 (1200XL, later ST). Now a Linux freak who uses a Mac at work.

Social Media


Return to “GFA BASIC”

Who is online

Users browsing this forum: No registered users and 1 guest