Issue with Assembler includes (HATARI Linux)

[mrbombermillzy]

I dont have a Windows machine to test this out on currently, but having crossed over to Linux for my Atari development, Ive come across a strange problem. Not sure if its me missing something obvious or not.

Anyway, the issue: Im attempting to compile a file with Devpac v3.10 which Ive split into other files (for ease of readability).

I INCUDE these files at the exact place that I want the code.

Neither (of the 2 included) files have a DATA or BSS section, so shouldnt need any TEXT section reafirmations after the include directive (although I put them in just in case, to no avail.)

This should be straightforward, but when I segregated the included routines out of the main build, they were not actually included: The program compiled and ran, but did not do the tasks in the included file. I even changed the directory to search to the same as the main file one and also set assembly environment up for INCLUDE directory to match in Devpacs editor.

I then even added a Devpac syntatic error in the 2nd include, for the compile pass to trip on, but it didnt even see it.

The only thing that comes to mind as a long shot possibility is the Atari<>*nix pathname reverse slash being a problem on file access on a HATARI drive?
:shrug:

Has anyone else had this problem?

Im using HATARI v2.4.1.

[exxos]

I've had gayness as to where in the code the included files are placed :shrug: I remember it drove me nuts for ages. Think HISOFT was picky as well.

I remember I had to move a lot of routines to the start of the main source code because of bizzare include related issues. But can't remember much about it now :(

[TheNameOfTheGame]

Well, can't comment on the devpac issue there, but if you are using linux for dev, then vasm will do native assembly with devpac compatibility with the -devpac switch.

Code: Select all

vasm -Ftos -devpac -o TEST.TOS TEST.S

[mrbombermillzy]

@exxos Thanks for the gayness confirm. :lol:

You have saved me also going nuts.

I was thinking it could have been Linux, as Ive not had issue with it before now (recently crossed over from M$).

I will try to shuffle the code around then and see what happens.

Well, can't comment on the devpac issue there, but if you are using linux for dev, then vasm will do native assembly with devpac compatibility with the -devpac switch.

Code: Select all

vasm -Ftos -devpac -o TEST.TOS TEST.S

Thanks for the tip, but (as usual for me) Im going to be moving over to the 'real thing' in a few weeks (after the OS specific stuff is done), as the HW Im experimenting with is not emulated anyway.

[exxos]

I will try to shuffle the code around then and see what happens.

Also had odd path related problems. Might have mentioned that before with forward & back slashes doing different things and there's the path in the code for the includes, then paths in devpac for includes. :crazy:

[mrbombermillzy]

Also had odd path related problems. Might have mentioned that before with forward & back slashes doing different things and there's the path in the code for the includes, then paths in devpac for includes. :crazy:

Hmm. I will have to see what happens when I move over to the swanky new H5+TF536 dev machine next week.

I cant wait! :girldance:

EDIT: @exxos if it unscrambles your brain a bit, any commands in the code (like you mentioned INCLUDES above or processor type, etc) override anything set in the Devpac configuration pages.

[sporniket]

Another thing to take into account, maybe : do you use harddrive gemdos emulation (i.e. a native folder is mapped to a hardrive for TOS) or do you use an acsi hard-drive image ? I've heard that gemdos emulation can have some strange behaviour sometimes.

[mrbombermillzy]

@sporniket Yes. Ive always used GEMDOS drive emulation, but I have used includes several times over the years with no problems.

The switch to Linux appeared like the trigger (the differing use of the forward/back slash with filenames being a problem internally to HATARI looking like a potential culprit, I would have guessed), but perhaps that is not the case then.

I will see if exactly the same problematic file setup causes the same problems on real HW and investigate further from there.