Hisoft Basic V Gfa Basic

Hisoft Basic V Gfa Basic

Post by Richard Dav » Mon, 17 Jul 1995 04:00:00




GFA Basic? :-

C> Don't bother trying to write Falcon-Enhanced programs with GFA, I dunno
C> much about HiSoft, but it is probavly better for writing Falcon
C> programs,
C> you should probably dump Basic and get yourself a nice C compiler...

Stick with HiSoft Basic 2.10 with the Falcon and Speedo libs.
You'll not get any speed increase with C, only more headaches if anything.
As for GFA, it can be used for Falcon applications perfectly.  Delm Paint
is a True Colour art package for Falcon as is Indy Paint, both are GFA.
I've even seen a few Falcon demos written in GFA and some games.  If you
know what you are doing just about ANY language can be adapted for the
Falcon to take advantage of it.

RiCH
   _____                        + + + + + + + + + + + + + + + + + + + +
  (, /   ) ,    /)            /)        FALCON OWNERS GROUP (UK)
    /__ /    _ (/   _   __  _(/ 10 Oak Drive, Portishead, Bristol, BS20

(_/                             + + + + + + + + + + + + + + + + + + + +
 And when you looked your eyes didn't quite meet, but your hearts did  
  And when you cried your bodies didn't quite touch, but your souls did

* Kivi (unregistered) 1.37 *
 He's bluffing. He wouldn't shoot the nose.

 
 
 

Hisoft Basic V Gfa Basic

Post by Christian Mittendo » Fri, 21 Jul 1995 04:00:00


Hi!

 > anything. As for GFA, it can be used for Falcon applications perfectly.
 > Delm Paint is a True Colour art package for Falcon as is Indy Paint,
 > both are GFA. I've even seen a few Falcon demos written in GFA and some

Which one? And if so, IMHO only the frame program  was done in Basic and the
rest is mostly inline assembler.

 > games.  If you know what you are doing just about ANY language can be
 > adapted for the Falcon to take advantage of it.

Sure? IMHO C and Assembler seem to be the best languages to be used on a Falcon
- especially if it should be fast.

mvh,
chris

 
 
 

Hisoft Basic V Gfa Basic

Post by Auburn Placer County - Tahoe Cit » Wed, 26 Jul 1995 04:00:00


Quote:> is a True Colour art package for Falcon as is Indy Paint, both are GFA.
> I've even seen a few Falcon demos written in GFA and some games.  If you
> know what you are doing just about ANY language can be adapted for the
> Falcon to take advantage of it.

...I don't know for sure, but I get the feeling Dave Munsie writes in
GFA.  I have to wonder about the speed increase, though.  C is much more
flexable, and it could very well be that it some instances, a speed
increase could be found.  However, I was quite pleased with the speed of
a program in HiSoft BASIC.
 
 
 

Hisoft Basic V Gfa Basic

Post by Hutc » Thu, 27 Jul 1995 04:00:00



Quote:> ...I don't know for sure, but I get the feeling Dave Munsie writes in
>GFA.  

Of course, he does. Dave is one of the true GFA-guru's out there and
while he can program in other languages, he generally prefers GFA for
many of the same reasons I and many other programmers do... ease of use,
speed of development, and overall performance. It ain't ATARI BASIC. :)

Quote:>I have to wonder about the speed increase, though.  C is much more
>flexable, and it could very well be that it some instances, a speed
>increase could be found.  

It all depends on what you are trying to do. I generally found most
versions of C (I used to use Laser C quite a bit) could give me a
somewhat faster executable (especially with floating point math) and
almost always a _smaller_ executable than my best efforts with GFA.
But those relatively small gains came with a penalty in development
and debugging time. A 'real' C-guru would be more efficient, of course.
Make no doubt about it, C _is_ more flexible but it ain't a Godsend
for every programming chore. The skills of the programmer are MUCH
more important than the language specs.


 
 
 

Hisoft Basic V Gfa Basic

Post by Gaven Mill » Tue, 01 Aug 1995 04:00:00




> >I have to wonder about the speed increase, though.  C is much more
> >flexable, and it could very well be that it some instances, a speed
> >increase could be found.  
> It all depends on what you are trying to do. I generally found most
> versions of C (I used to use Laser C quite a bit) could give me a
> somewhat faster executable (especially with floating point math) and
> almost always a _smaller_ executable than my best efforts with GFA.
> But those relatively small gains came with a penalty in development
> and debugging time. A 'real' C-guru would be more efficient, of course.
> Make no doubt about it, C _is_ more flexible but it ain't a Godsend
> for every programming chore. The skills of the programmer are MUCH
> more important than the language specs.

I agree that C is more flexible when compared to BASIC.

<begin slightly-off-topic waffle>

Some years back, a "scurrilous" copy of Laser C managed to find me. I
tried it out, and liked the compiler. I was using a Mega 4 at the time,
and compilations were _FAST_ (until one reached 1500+ lines - then it
really slowed down)

The environment was good, but, unfortunately, took too many shortcuts. In
short, it was a little "flaky". After every fourth or fifth compile, I
would experience an "Exception 5" or "Exception 4" (division-by-zero and
"illegal instruction" errors), and the machine would hang.

The source-code de* was great. Unfortunately, it was an extra-cost
option, which I believe few took up. The ability to step through C source
code, press a few keys and then be looking at 68000 assembly language was
great. Another few keystrokes and I could be looking at C source code
again. This could happen at any time whilst debugging.

At the time I received it, I was part way through paying for a hard-drive.
I kept the compiler and used it whilst I saved the pennies to purchase the
compiler from a local retailer.

As a non-ANSI compiler, it was quite good. It was about to be upgraded to
ANSI standard when I received my copy.

I fronted up with the cash to purchase it from my local retailer. They
didn't have it in stock, but they told me of the soon-to-be ANSI upgrade.
I waited for it, but nothing came.

So, I bought Lattice C v5 from Hisoft, and disposed of Laser C (by
destroying all traces of Laser C that I had). Compared to Laser, it
[Lattice] was a disc-bound behemouth, sluggish and somewhat temperamental
until configured correctly.

I currently use Lattice C v5.6 from Hisoft, which, in my opinion, is a
much better product than v5. It is still a bit of a mongrel to set up, but
is more stable and more productive than the earlier version. It just isn't
very friendly when trying to run installed tools under MultiTOS.  The
linker is a pain as well, because if I have made it resident, the second
or third time it is run, it will hang the machine completely under
MultiTOS. It's not that I do not have enough RAM - I frequently have
between ten and twelve megabytes free when programming under MultiTOS with
Memory-Protection 'on'.

( Memo to Hisoft : Some of us run with MultiTOS all day, and require tools
which do not hang the computer and require a reboot. Your language
products seem to be "MTOS compatible" [runs under MTOS], but not "MTOS
friendly" [gets on well with other co-resident, simultaneously running
software]. Please fix as part of your "on-going support" for Atari
products. I, for one, will gladly pay a reasonable price to upgrade. )

<end of slightly-off-topic waffle>

Recently, I was asked to produce some code for Hisoft BASIC - to colour
expand 4-bit (16 colour) graphics to 8-bit (256 colours) and 16-bit
True-colour (65536 colours) for the Falcon running a screen expander. At
the time, I believed that the images could be quite large, possibly over
half-a-megapixel in size, so I coded it in Devpac 3.1 (an assembler).

In order to do so, I needed to know what sort of machine-code Hisoft Basic
produced - how parameters were passed, what CPU registers were sacred, how
results were to be returned, and so forth.

Looking at it, Hisoft Basic has a faster compiler, but produces worse
machine code than most C compilers I have used.

(The manual accompanying Hisoft Basic even has a few errors about how to
produce assembly-language modules for it. "Parameters passed in reverse
order"  means two different things, depending on whether you are coding
for Lattice C or Hisoft Basic)

Simple bit-fiddling, computation-intensive or low-level code is very much
poorer when produced by Hisoft Basic.

The best results are achieved when using a combination of BASIC, C and/or
assembler, using the strengths of each one.

Commented source code can also alleviate the development/debugging time
problem.

As can a source-level de*. Which the version of 'Mon' bundled with
Hisoft products definately isn't.

I should qualify that last sentence - Hisoft Basic, Lattice C and Devpac
3.1 allow you to compile with debugging info included in the programs.
Unfortunately, Mon [the de*] will only take note of the first lot of
debug info. If your code is at all like mine - spread throughout more than
one source file - then you are out of luck. As you step through your
program, a "source" window will stay in sync with the "disassembly" window
- but only for the one "debuggable" module, everything else is ignored.
(Laser C was a lot better in this regard - I once had a 50-module C
program to debug, and every one of those 50 modules were debuggable at the
C source level. This is not possible in Hisoft language products, as far
as I am aware).

I do agree with Hutch about the skill of the programmer being important. A
good programmer can make a computer do wonderous things when using the
right tools.

 
 
 

Hisoft Basic V Gfa Basic

Post by Hutc » Wed, 02 Aug 1995 04:00:00



Quote:> I do agree with Hutch about the skill of the programmer being important. A
> good programmer can make a computer do wonderous things when using the
> right tools.

Bingo! And conversely, a poor programmer can do horrendous things even
when using the best tools. :)

The programmer makes the choice as to what tools to use; but the user
shouldn't care didly what language was used as long as his needs are met.


 
 
 

1. Hisoft BASIC v GFA Basic?



        Don't worry about GEM and GFA Basic, OASIS (the internet off line
reader) is GEM based and written entirely in GFA Basic! E-Mail me if you would
like some details.

        I have used GFA Basic 3.6TT on a Falcon, it works fine in any TT
compatible screen resolution (320*480 256C,640*480 16C).

        As for Falcon enhanced programming with GFA, I couldn't agree more, I
just wish that somebody would finish version 4 of GFA Basic.

__

  ===========================================================================

     The Home Of      _/_/_/_/  _/_/_/_/  _/_/_/_/  _/  _/_/_/_/  
                     _/    _/  _/    _/  _/        _/  _/  
                    _/    _/  _/    _/  _/        _/  _/      
                   _/    _/  _/_/_/_/  _/_/_/_/  _/  _/_/_/_/
                  _/    _/  _/    _/        _/  _/        _/
                 _/    _/  _/    _/        _/  _/        _/  
                _/_/_/_/  _/    _/  _/_/_/_/  _/  _/_/_/_/


2. 3rd Party Oracle Training Materials/Courseware

3. Wang-formatted floppes in DOS

4. GFA basic vs. HISOFT basic

5. Spell checker??

6. GFA BASIC -> GFA BASIC for WINDOWS

7. UNIX Host -< NFS -> AmigaDOS

8. GFA BASIC ST <--> GFA BASIC PC Windows

9. ST Basic -> Hisoft Basic (quite long)

10. looking for gfa-basic v1 (same author as turbo basic xl)

11. Wanted: ST BASIC, True vs Hisoft vs GFA 2 or others?