Jump to content

Photo

Object file format details?


9 replies to this topic

#1 TheBF ONLINE  

TheBF

    Chopper Commander

  • 155 posts
  • Location:The Great White North

Posted Wed May 3, 2017 9:20 PM

Does anybody know where I can get some information on how to make object files that can be loaded by E/A Option 3?

 

I want to add this output format to my cross compiler.

 

Thanks

 

BF



#2 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,267 posts
  • Location:Denmark

Posted Wed May 3, 2017 9:59 PM

Does anybody know where I can get some information on how to make object files that can be loaded by E/A Option 3?

 

I want to add this output format to my cross compiler.

 

Thanks

 

BF

 

http://www.unige.ch/...m#tagged-object



#3 Willsy ONLINE  

Willsy

    River Patroller

  • 2,949 posts
  • Location:Uzbekistan (no, really!)

Posted Thu May 4, 2017 3:27 AM

Also here http://turboforth.ne.../ea3loader.html

#4 mizapf ONLINE  

mizapf

    River Patroller

  • 2,306 posts
  • Location:Germany

Posted Thu May 4, 2017 5:55 AM

And here: http://www.ninerpedi...ged_Object_Code

 

;)



#5 TheBF ONLINE  

TheBF

    Chopper Commander

  • Topic Starter
  • 155 posts
  • Location:The Great White North

Posted Thu May 4, 2017 11:39 AM

 

Thanks everyone

 

BF



#6 TheBF ONLINE  

TheBF

    Chopper Commander

  • Topic Starter
  • 155 posts
  • Location:The Great White North

Posted Tue May 9, 2017 8:44 AM

So I created a little set of markup tags that let me create the output format.

Which makes the final program to generate an object file look like this.

HEX
: .EA3  ( -- )
        <NEW.EA3>
        LOADADDRESS <AORG>
        <HEADER>
        THERE ORGADR @
        DO
           <9> I <####>  I  B/REC <WORDS>  <CRC> <EOR> <LINE#> <BR>
        B/REC +LOOP
        <EOF> <FOOTER>  <LINE#> ;

Which I thought was pretty clever. :)

 

But I have something wrong with the checksum.

 

I thought it would be simple to create a little ASM program and compare the object file from the TI assembler,

but I cannot get Classic99 to generate one.

 

My program assembles with no errors.

What incantations do I need to create an object file in Classic99 E/A?

 

B

 

*EDIT*  OK I got a file but it is binary. (compressed)  But I did not use the C option. ??

 

EDIT2:  OK it's not compressed its in a CLASSIC99 format.  So I will have to create that around my ea3 file.

 

The fog is slowly lifting...


Edited by TheBF, Tue May 9, 2017 9:05 AM.


#7 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,596 posts
  • Location:BUR

Posted Tue May 9, 2017 10:51 AM

Classic99 does not have its own formats. So there is no "Classic99 format". This is very intentional.

 

If you used a disk image, then it's a V9T9 disk image (also called 'sector format'). The file would be inside that.

 

If you are using FIAD instead, then it's either a V9T9 file or a TIFILES file, depending on what you have configured. Both of these have a 128 byte header (which differs slightly) followed by the actual data, laid out as it would be on a diskette (that is to say, blocked into 256 byte 'sectors'.)

 

You can usually ask Classic99 to write a text file as a Windows text file by inserting a "?W" string after the device name (ie: DSK1.?W.OUTPUT.TXT). However, in testing here this trick does not work with the output filename from the assembler because it tries to work as DF80 (instead of DV80) and also tries to open the output file in UPDATE mode instead of OUTPUT mode. These two steps trigger an error message that stops the assembler.

 

There are two ways to work around it. The first, and the simplest way, is to assemble normally. Then use the PRINT option to write it out to a Windows file (thus Classic99 does the conversion for you). Just print to "DSK1.?W.OUTPUT.TXT". I've tried this and it works fine. (You can also print to "CLIP" to put it on the clipboard instead for pasting).

 

Attached File  pic.png   41.43KB   3 downloads

 

The second way if you will do this a lot is to change the option on the disk configuration and enable "Write DF80 as Windows Text". Just be aware that this can in some instances make it difficult to reload the file into the TI emulator again, since all the format information is thrown away. I'd recommend the print approach for now.


Edited by Tursi, Tue May 9, 2017 10:52 AM.

  • RXB likes this

#8 RXB OFFLINE  

RXB

    River Patroller

  • 2,503 posts
  • Location:Vancouver, Washington, USA

Posted Tue May 9, 2017 12:08 PM

Classic99 does not have its own formats. So there is no "Classic99 format". This is very intentional.

 

If you used a disk image, then it's a V9T9 disk image (also called 'sector format'). The file would be inside that.

 

If you are using FIAD instead, then it's either a V9T9 file or a TIFILES file, depending on what you have configured. Both of these have a 128 byte header (which differs slightly) followed by the actual data, laid out as it would be on a diskette (that is to say, blocked into 256 byte 'sectors'.)

 

You can usually ask Classic99 to write a text file as a Windows text file by inserting a "?W" string after the device name (ie: DSK1.?W.OUTPUT.TXT). However, in testing here this trick does not work with the output filename from the assembler because it tries to work as DF80 (instead of DV80) and also tries to open the output file in UPDATE mode instead of OUTPUT mode. These two steps trigger an error message that stops the assembler.

 

There are two ways to work around it. The first, and the simplest way, is to assemble normally. Then use the PRINT option to write it out to a Windows file (thus Classic99 does the conversion for you). Just print to  I've tried this and it works fine. (You can also print to "CLIP" to put it on the clipboard instead for pasting).

 

attachicon.gifpic.png

 

The second way if you will do this a lot is to change the option on the disk configuration and enable "Write DF80 as Windows Text". Just be aware that this can in some instances make it difficult to reload the file into the TI emulator again, since all the format information is thrown away. I'd recommend the print approach for now.

I have found frustration with Assembler cutting off text files an 80 columns yet my RICH/NOTEPAD text files are much longer lines.

 

The GPL Assembler and Editor Assembler both do this. Does this still happen with "DSK1.?W.OUTPUT.TXT". as I assume they work without change?



#9 TheBF ONLINE  

TheBF

    Chopper Commander

  • Topic Starter
  • 155 posts
  • Location:The Great White North

Posted Tue May 9, 2017 2:35 PM

Classic99 does not have its own formats. So there is no "Classic99 format". This is very intentional.

 

If you used a disk image, then it's a V9T9 disk image (also called 'sector format'). The file would be inside that.

 

If you are using FIAD instead, then it's either a V9T9 file or a TIFILES file, depending on what you have configured. Both of these have a 128 byte header (which differs slightly) followed by the actual data, laid out as it would be on a diskette (that is to say, blocked into 256 byte 'sectors'.)

 

You can usually ask Classic99 to write a text file as a Windows text file by inserting a "?W" string after the device name (ie: DSK1.?W.OUTPUT.TXT). However, in testing here this trick does not work with the output filename from the assembler because it tries to work as DF80 (instead of DV80) and also tries to open the output file in UPDATE mode instead of OUTPUT mode. These two steps trigger an error message that stops the assembler.

 

There are two ways to work around it. The first, and the simplest way, is to assemble normally. Then use the PRINT option to write it out to a Windows file (thus Classic99 does the conversion for you). Just print to "DSK1.?W.OUTPUT.TXT". I've tried this and it works fine. (You can also print to "CLIP" to put it on the clipboard instead for pasting).

 

attachicon.gifpic.png

 

The second way if you will do this a lot is to change the option on the disk configuration and enable "Write DF80 as Windows Text". Just be aware that this can in some instances make it difficult to reload the file into the TI emulator again, since all the format information is thrown away. I'd recommend the print approach for now.

 

Thanks Tursi!



#10 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,596 posts
  • Location:BUR

Posted Tue May 9, 2017 3:01 PM

I have found frustration with Assembler cutting off text files an 80 columns yet my RICH/NOTEPAD text files are much longer lines.

 

The GPL Assembler and Editor Assembler both do this. Does this still happen with "DSK1.?W.OUTPUT.TXT". as I assume they work without change?

 

I expect it will still cut off. The Editor/Assembler package opens everything with 80 character record lengths, so no line can be longer than 80 chars.


  • RXB likes this




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users