Conference 7.286::atarist

    
    I can't tell you about V2, but in V3 you can switch compiler options
    like: - let the result be an integer whenever two integers are devided
    a.s.o. The compiled program then bombs you out when you assigned the
    result also with a x% (integer) in the source. This does not take
    affect in the interpreter, because he just sees the "%"...
    There are some more options in the V3-compiler that cause a program to
    bomb if you do not choose the right ones (e.g. malloc-stuff...).
    
    Bernd
    

    Jonathan,
    
    your problem description is not detailed enough for anyone to make
    anything other than wild guesses at what the cause may be. The most
    common cause of a problem occurring in the compiled code but not in the
    interpreter is some kind of bad poke or addressing which occurs in both
    environments but which you somehow get away with whilst in the
    interpreter simply because your environment is different and storage
    may be laid out in a different way.
    
    The first thing to do is to put a few debugging statements into the
    program to narrow down the line of code where the failure occurs. (eg
    before each major program section put in a PRINT "About to call routine
    ....."). When you've found the routine which is failing put in more
    debug statements within that module (PRINT "About to open files..." 
    PRINT "About to do that dodgy POKE....!!!!") You can keep on narrowing
    the field down. TIP: if you have a printer then send your diagnostic
    messages there (LPRINT) rather than the screen (PRINT), since the
    output is then not lost if the screen blanks following a crash, and
    does not interrupt normal screen output from the program.) 
    
    Try to find the exact line which causes the failure, then post it here.
    You also need to find out what 3 and 4 bombs mean. They're listed in
    the GFA manual (can't remember what they are off the top of my head).
                                                                         
    Tony I

    Hi, here i'll put a list what the bombs mean:
    
    2 Bombs	=	bus error (may caused by peek,poke)
    3 Bombs	=	adress error (not even PC-counter)
    4 bombs	=	illegal instruction (may caused by wrong compiler
    			switch or linker option)
    5 bombs	=	divide by zero
    6 bombs	=	CHK-exeption (should NEVER happen)
    7 bombs	=	TRAPV-Exection
    8 bombs	=	Privileg violation
    9 bombs	=	TRACE exeption, trace without monitor
    80 bombs	=	total system crash !
    
    Hope that will help all of us
    -Kay
    

    Years ago I used to write little Basic programs (both VMS and RT11)
    that used virtual arrays. What you did was open a file on disk and
    treat it exactly like you would an array in memory. Typically the
    format was something like:
    
    Open "myfile" as file #1%
    DIM #1%, A$(X%, Y%). 
    
    Now I'm trying to write a GFA V2.0 program to do some data manipulation
    that could make use of such virtual array capabilities. Much to my
    dismay GFA Basic (at least V2.0) doesn't know anything about virtual
    arrays, just memory arrays. Have I overlooked something or will I just
    have to come up with some other way of doing what I'm trying to do?
    
    Thanks,
    
    Al
    

I've known a few BASICs and in my experience BASIC-11 and BASIC-PLUS were the
only BASICs to implement 'virtual arrays'.

    I've used GFA basic V2 a fair bit and don't think there's anything there
    that will help you. HOWEVER... if you upgrade to V3 there are a couple
    of commands that load and save arrays direct to disk as a block of
    memory which avoids you having to read the array contents in record by
    record. Not quite what you want but maybe a good compromise?
    
    Tony I

    
    I have a problem now, that maybe some of you solved and will no point
    me to the right direction:
    
    I am working with the MATRIX M128 Graphics Card that will give me a 
    resolution of 1280*960 pixels on a 19" monochrome monitor. When I 
    want to get the actual resolution with XBIOS(4) it still returns with
    2 (=640*400). The system is a Mega STE with TOS 2.06 and GFA 3.5 btw.
    There must be a way to get the real resolution, because other programs
    adjust just perfect to the 1280*960. How can I find out?
    
    Second, I have a GFA program incl. source that does exactly what I
    need. It worked just perfect on the SM124, but passes out on the 
    bigscreen. The problem: it uses no windows, but writes directly with
    coordinates into the 640*400 screen. Also it loads 32000bytes picture
    files from disk and displays them with SPUT. They serve as background, 
    like lines and boxes to be filled with data that is calculated by the
    program. The program also uses a lot of direct coordinates for text,
    like TEXT 230,420,string$. Is it possible to open up a window of
    640*400 (that I can move around on the bigscreen) and refer all direct
    coordinates to that window, including the display of the picture files?
    Basicly I want to redirect the screen output like it is in the moment
    into a window without changing every line in that program that uses
    direct coordinates.
    
    And my last question: how, in general, do you program resolution-
    independant programs with GFA 3.5 (main focus on higher resolutions
    than 640*400)? Is there a procedure around that does the main setup?
    
    Thanks for any answers,
    Bernd
    
    

    
    First XBIOS-Funktion doesn't work with extended computer features.
    Like the TT, XBIOS support only the resolutions 320x200,640x200 and
    640x400!
    
    If you want to use extended Graphikfeatures, you must use the VDI-
    Routines and must install extended graphikroutines like GDOS.
    VDI is a sort of routines which create/handle graphikoperations
    on all resolutions/modes. 
    
    Look at your GFA-Manual for more informations on VDI. I think there
    must be shipped a program with your MATRIX M128, which automatically
    installed extended VDI-Convertion/Features.
    
    RALF
     

    Atari has a driver for the Moniterm monitor, which is 1280 x 960. You
    might ask either Atari or Moniterm for the sources.
    
    I use the large Monitor with TOS 1.4 and a MEGA ST4. Almost all new
    Atari SW works fine with the large screen, including WHACK. Some
    older stuff works fine too, using only the top left corner of the
    screen. But there is also a fair amount of older software that is
    unuseable, e.g., WordPerfect 4.1. Timeworks Wordwriter allows only a
    small portion of the screen to be used per document, but you can have
    four of them displayed at once.
    
    Gil