GFABASIC killing the environment

GFA BASIC-related articles in here please

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

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 742
Joined: Sun Aug 03, 2014 5:54 pm

GFABASIC killing the environment

Postby ThorstenOtto » Sat Jul 20, 2019 7:41 am

While doing some experiments, i found that either GBE or the interpreter seems to kill the GEMDOS environment. Running the following code in the interpreter:

Code: Select all

env%=LONG{ADD(BASEPAGE,44)}
PRINT
IF env%<>0
  WHILE BYTE{env%}<>0
    str$=""
    WHILE BYTE{env%}<>0
      str$=str$+CHR$(BYTE{env%})
      INC env%
    WEND
    PRINT str$
    INC env%
  WEND
ENDIF
QUIT 0


will just print

Code: Select all

ARGV=
u:\ram\_gbe_tmp.gfa
ARGH=u:\ram\_gbe_tmp.gfa
_GBE=0046
MINM=00040000
MAXM=00080000
SYSM=00020000


The same program, when compiled & executed, prints my normal environment (even when executed directly from GBE). Is that expected?

Edit: forgot to mention: this was tried with GBE v1.72

User avatar
charles
10 GOTO 10
10 GOTO 10
Posts: 2500
Joined: Tue Aug 17, 2004 12:11 am
Location: ont. Canada
Contact:

Re: GFABASIC killing the environment

Postby charles » Sat Jul 20, 2019 12:24 pm

are environmental strings larger than 32768 under gbe?
The radioactive half-life : )
Atari is a lifestyle,not a hobby.
HOLD ON ! ! ! Im printing unreadable characters ...!

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 742
Joined: Sun Aug 03, 2014 5:54 pm

Re: GFABASIC killing the environment

Postby ThorstenOtto » Sat Jul 20, 2019 1:04 pm

?? What's that got to do with the length?

User avatar
charles
10 GOTO 10
10 GOTO 10
Posts: 2500
Joined: Tue Aug 17, 2004 12:11 am
Location: ont. Canada
Contact:

Re: GFABASIC killing the environment

Postby charles » Sat Jul 20, 2019 1:15 pm

maybe gbe fixed string length but old gfa only allows 32768 byte length for string....
The radioactive half-life : )
Atari is a lifestyle,not a hobby.
HOLD ON ! ! ! Im printing unreadable characters ...!

User avatar
charles
10 GOTO 10
10 GOTO 10
Posts: 2500
Joined: Tue Aug 17, 2004 12:11 am
Location: ont. Canada
Contact:

Re: GFABASIC killing the environment

Postby charles » Sat Jul 20, 2019 1:16 pm

isn't your loop terminated early because of the padded strings ? env=0???
no I don't believe so on second inspection
The radioactive half-life : )
Atari is a lifestyle,not a hobby.
HOLD ON ! ! ! Im printing unreadable characters ...!

User avatar
charles
10 GOTO 10
10 GOTO 10
Posts: 2500
Joined: Tue Aug 17, 2004 12:11 am
Location: ont. Canada
Contact:

Re: GFABASIC killing the environment

Postby charles » Sat Jul 20, 2019 1:23 pm

tried the method from the gfa manual?
'''

Code: Select all

a%={basepage+44}
do
a$=char{a%}
exit if len(a$)=0
print a$
add a%,succ(len(a$))
loop

''''
The radioactive half-life : )
Atari is a lifestyle,not a hobby.
HOLD ON ! ! ! Im printing unreadable characters ...!

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2440
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: GFABASIC killing the environment

Postby lp » Sat Jul 20, 2019 1:34 pm

ThorstenOtto wrote:While doing some experiments, i found that either GBE or the interpreter seems to kill the GEMDOS environment. Running the following code in the interpreter:

removed code example

The same program, when compiled & executed, prints my normal environment (even when executed directly from GBE). Is that expected?

Edit: forgot to mention: this was tried with GBE v1.72


The interpreter is started with shel_write(). I assumed that call would pass along the parents environment. Will look into fixing this. Thanks for pointing it out.

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 742
Joined: Sun Aug 03, 2014 5:54 pm

Re: GFABASIC killing the environment

Postby ThorstenOtto » Sat Jul 20, 2019 3:05 pm

shel_write is actually taken care about by AES, so the interpreter should inherit the AES environment, Are you using any special shel_write modes of XaAES? Or explicitly pass an empty environment string instead of L:0? ("" and 0L are not the same, the first would give the result i experienced, the 2nd would pass the parents environment, which is what i would expect).

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2440
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: GFABASIC killing the environment

Postby lp » Sat Jul 20, 2019 3:20 pm

Yes a special shel_write mode related to later versions of the AES and nothing specific to XaAES. Get the same results with NAES. The strings you dumped are passed by GBE. I have already fixed it. Do you want a new binary?

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 742
Joined: Sun Aug 03, 2014 5:54 pm

Re: GFABASIC killing the environment

Postby ThorstenOtto » Sat Jul 20, 2019 3:31 pm

I've worked around it in the meantime, using shel_envrn() instead of (the equivalent of) getenv(). The problem appeared when trying to use Slbopen(): if you don't pass an explicit path, MiNT will try to locate it via getenv("SLBPATH"), which did not exist...

But if you want me to test it, i can do that.

BTW is there some way to detect at compile/run time whether it generates 68k or coldfire code?

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2440
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: GFABASIC killing the environment

Postby lp » Sat Jul 20, 2019 4:27 pm

ThorstenOtto wrote:BTW is there some way to detect at compile/run time whether it generates 68k or coldfire code?


There's no rush to test my changes. I'll make a new archive at some point.

If I follow you correctly, you wish to compile specific code blocks based on the target cpu?

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 742
Joined: Sun Aug 03, 2014 5:54 pm

Re: GFABASIC killing the environment

Postby ThorstenOtto » Sat Jul 20, 2019 5:15 pm

Yes, in this case i want to check the loaded library whether it matches the running version. Not very important, but i could omit either one of the tests and save a few bytes. So what i was looking for was the equivalent of "#ifdef __mcoldfire__"

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2440
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: GFABASIC killing the environment

Postby lp » Sat Jul 20, 2019 5:39 pm

Well not as elegant as 'C', but you can do this in GBE:

Code: Select all

REM #KEY M68K|CV4E      !prompt user for target cpu
'
REM #IFK 0
REM   #BRK              !abort make/run
REM #EIK 1
REM   #LIB new lib      !select 68K library
REM #EIK 2
REM   #LIB cf v4e       !select CF library
REM #FIK
'
' then anywhere you wish to compile specific code blocks
'
REM #IFK 1
PRINT "M68K"
REM #EIK 2
PRINT "CV4E"
REM #FIK
'
EDIT

You will have to adjust the library names as mine don't match the release.

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 742
Joined: Sun Aug 03, 2014 5:54 pm

Re: GFABASIC killing the environment

Postby ThorstenOtto » Sat Jul 20, 2019 7:21 pm

Yes, thanks, i've seen similar constructs already. Problem is that i don't want to be asked every time ;)

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2440
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: GFABASIC killing the environment

Postby lp » Sat Jul 20, 2019 7:53 pm

I could add a new feature, but I don't know much about 'C'. For example does the compiler get "__mcoldfire__" from the library or is that a user defined equate?

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 742
Joined: Sun Aug 03, 2014 5:54 pm

Re: GFABASIC killing the environment

Postby ThorstenOtto » Sun Jul 21, 2019 12:42 am

Its something that the compiler itself defines, when generating coldfire code. So it should be a symbol of some kind that could be queried independently of how the query at the start is constructed (to keep your example, someone else might have used "1" for coldfire, and "2" for 68k). If that is not to difficult.

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2440
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: GFABASIC killing the environment

Postby lp » Sun Jul 21, 2019 1:18 pm

There's also this option. You can then hand edit the top line to change the 'Build Type'.
Can I inquire what you are writing? I though you was more of a 'C' coder. ;)

Code: Select all

REM #BT= 0               !0=68K 1=CF / at the top of you code
' select the correct library
REM #IFT 0
REM #LIB gbe 68k
REM #EIT 1
REM #LIB gbe v4e
REM #FIT
'
' anywhere you wish to compile specific code blocks
'
REM #IFT 0
PRINT "68K"
REM #EIT 1
PRINT "CF"
REM #FIT
'
EDIT

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 742
Joined: Sun Aug 03, 2014 5:54 pm

Re: GFABASIC killing the environment

Postby ThorstenOtto » Sun Jul 21, 2019 4:34 pm

Yes, thanks, that should do it for now (for my tests at least; i think it would still be useful to have some global flag that is set automatically by GBE, since i also have to query the setting in a file that is #INCluded). In some older version of GBE i also found a sample referencing HIMEM+154, but that does not seem to work anymore.

Just another stupid question: the above setting only selects the library. When running "Make", it still calls gc_68k.prg (because it is *running* on 68k machine, not firebee). How does the compiler knows it has to produce v4e code?

User avatar
GokMasE
Captain Atari
Captain Atari
Posts: 218
Joined: Sun Mar 02, 2003 11:16 pm
Location: Sweden
Contact:

Re: GFABASIC killing the environment

Postby GokMasE » Sun Jul 21, 2019 7:09 pm

Regarding the reference to HIMEM, I believe that was a feature that changed during later development. Did you check out the internal data table accessed through SYSTAB? (see gbe_lib.hyp)

Not sure this is what you are looking for but SYSTAB+80 returns the address to a string reflecting the cpu build type ("M68K" or "CV4E").

Regards,

Joakim

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2440
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: GFABASIC killing the environment

Postby lp » Sun Jul 21, 2019 7:59 pm

That's not the best way to detect the cpu type. See http://gfabasic.net/stg/gbe_lib.htm#HARDWARE?

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2440
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: GFABASIC killing the environment

Postby lp » Sun Jul 21, 2019 8:19 pm

ThorstenOtto wrote:Yes, thanks, that should do it for now (for my tests at least; i think it would still be useful to have some global flag that is set automatically by GBE, since i also have to query the setting in a file that is #INCluded). In some older version of GBE i also found a sample referencing HIMEM+154, but that does not seem to work anymore.

Just another stupid question: the above setting only selects the library. When running "Make", it still calls gc_68k.prg (because it is *running* on 68k machine, not firebee). How does the compiler knows it has to produce v4e code?


HIMEM was abandoned and replaced by offering new commands and functions.

The required compiler is simply set via Setup->Paths. When you install GBE onto a fresh system it auto determines all the required paths. It doesn't really produce v4e code per say, instead it produces 68k code that's compatible with CF68KLib. The original problem with GFA on the FireBee was the use of move.b on the stack all over the place.

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 742
Joined: Sun Aug 03, 2014 5:54 pm

Re: GFABASIC killing the environment

Postby ThorstenOtto » Mon Jul 22, 2019 12:47 am

>It doesn't really produce v4e code per say, instead it produces 68k code that's compatible with CF68KLib.

Ah ok, that might be even better. Something that i'm still missing with GCC, when you compile for v4e, it does not only avoid the instructions that would not work on coldfire, but also uses instead instructions that *only* work there, like mov3q.

>use of move.b on the stack all over the place.

Yes, Pure-C and its library suffer from the same problem.

>See http://gfabasic.net/stg/gbe_lib.htm#HARDWARE?

Ah, very good, i missed that. Easier than having to check for a _CPU cookie or similar.

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 742
Joined: Sun Aug 03, 2014 5:54 pm

Re: GFABASIC killing the environment

Postby ThorstenOtto » Fri Jul 26, 2019 12:03 am

lp wrote:Yes a special shel_write mode related to later versions of the AES and nothing specific to XaAES.


Adding some traces to XaAES show that it is currently started with shel_write(0xc00, 0, 0, ....)

The first parameter is an extended mode, and indicates that cmd does not give the name of the program, but points to a structure with additional information. That's what i meant with "special modes" ;) Didn't know that NAES also implements that.

The flags say that in this structure, a default directory is specified (although it seems to be NULL), and also an environment. That's why this environment is used, and not the parents's one.

But i've got also another problem now. The current directory, when i run a program in the interpreter, it that where ro_68k.prg resides. Is there some way of getting the original directory, ie. the one of the source code? shel_read() cannot be used either, since that will also return only the path to the interpreter.

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2440
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: GFABASIC killing the environment

Postby lp » Fri Jul 26, 2019 3:29 am

The default directory entry should not be null. I used The Atari Compendium for this information. I've gotten burnt by the Compendium before. Will have to recheck my code and perhaps other documents.

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 742
Joined: Sun Aug 03, 2014 5:54 pm

Re: GFABASIC killing the environment

Postby ThorstenOtto » Fri Jul 26, 2019 7:21 am

The default directory entry should not be null.


Ah sorry, i was wrong with that. And it contains actually the value i expected. Still the program, when run, has the directory of the interpreter executable as current directory. Have to check what is going wrong there, maybe bug in XaAES or MiNT, or maybe the interpreter changes the directory again before executing code.

XaAES uses this structure:

Code: Select all

/* shel_write flags */
#define SW_PSETLIMIT   0x0100
#define SW_PRENICE      0x0200
#define SW_DEFDIR       0x0400
#define SW_ENVIRON      0x0800
#define SW_UID    0x1000   /* Set user id of launched child */
#define SW_GID   0x2000   /* Set group id of launched child */

struct xshelw
{
   const char *newcmd;
   long psetlimit;
   long prenice;
   const char *defdir;
   char *env;
   short uid;         /* New child's UID */
   short gid;         /* New child's GID */
};


Social Media

     

Return to “GFA BASIC”

Who is online

Users browsing this forum: No registered users and 1 guest