CiderPress - DOS 3.3 - Raw binary $F2 to BIN

[groink]

Aloha!!!

I can't seem to find a solution to the following problem...

I'm using SBASM 3.0 cross-assembler, assembling in 6502 mode. It assembles the code just fine. The problem is that I'm trying to take the resulting raw object file, copy it to a DOS 3.3 disk using CiderPress, and change the file attribute to a BIN file. When I add the object file, the resulting file type defaults to $F2.

The problem is that when I change the file type to BIN $06, and add the starting address in the aux type field, the first four bytes of the resulting BIN file is trashed. I believe the reason is that the starting address and length are somehow tied to the file when saved on the DOS 3.3 disk, and CiderPress does something with the file in this regard. CiderPress does warn me that the binary file will get hosed. I'm not a DOS 3.3 expert, so this is just a wild guess on my part.

Is there something in my assembly listing I need to do to prepare the object file for DOS 3.3?

 

[george]

Aloha!!!

I can't seem to find a solution to the following problem...

I'm using SBASM 3.0 cross-assembler, assembling in 6502 mode. It assembles the code just fine. The problem is that I'm trying to take the resulting raw object file, copy it to a DOS 3.3 disk using CiderPress, and change the file attribute to a BIN file. When I add the object file, the resulting file type defaults to $F2.

The problem is that when I change the file type to BIN $06, and add the starting address in the aux type field, the first four bytes of the resulting BIN file is trashed. I believe the reason is that the starting address and length are somehow tied to the file when saved on the DOS 3.3 disk, and CiderPress does something with the file in this regard. CiderPress does warn me that the binary file will get hosed. I'm not a DOS 3.3 expert, so this is just a wild guess on my part.

Is there something in my assembly listing I need to do to prepare the object file for DOS 3.3?

The object files(s) should be linked by a linker to produce the binary (executable) file.

 

[groink]

The object files(s) should be linked by a linker to produce the binary (executable) file.

What you just described actually sounds more like MS-DOS than Apple DOS. I know because I used to write 8086/88 code in MS-DOS, and we did have to use a linker to produce an executable. I'm not trying to create an executable in Apple DOS 3.3, and I don't even think that's a term used in DOS 3.3.

I'm merely assembling a set of machine language routines, which is called within an Applesoft program. I don't have an assembler for my Apple IIe at the moment, and I already have SBASM, and using CiderPress I thought this would be a simple process.

 

[groink]

Figured it out! SBASM apparently allows for preparing assembled code for Apple II DOS 3.3. What threw me off is that I was looking for a directive that did this, but come to find out it involves more than just a directive. What I must do is have the assembler start four bytes back of the origin address (.OR), by having it subtract 4 from the origin address. The first two bytes is a 16-bit word containing the starting address, and the last two bytes is the length of the file. Here's an example:

    .CR     6502            Goes without saying, doesn't it?
    .OR     $2000-4         Let's start our example at addess $2000
    .TF     EXAMPLE,bin     No need to define a file extension

    .DA     PROG_BEGIN      Write the target address to the bin file
    .DA     PROG_END-PROG_BEGIN   Write the length to the bin file

PROG_BEGIN  ;               The intended target address of $2000
    LDA     ......
     :                      Your program goes here
     :
     :
    RTS                     Until here
PROG_END

Next, I add the resulting binary file to my disk image using CiderPress, which then defaults to $F2. With this addition, CiderPress now works correctly when I change the file and aux types. Hope some other poor sap like myself finds this helpful!

 

[george]

Figured it out! SBASM apparently allows for preparing assembled code for Apple II DOS 3.3. What threw me off is that I was looking for a directive that did this, but come to find out it involves more than just a directive. What I must do is have the assembler start four bytes back of the origin address (.OR), by having it subtract 4 from the origin address. The first two bytes is a 16-bit word containing the starting address, and the last two bytes is the length of the file. Here's an example:

    .CR     6502            Goes without saying, doesn't it?
    .OR     $2000-4         Let's start our example at addess $2000
    .TF     EXAMPLE,bin     No need to define a file extension

    .DA     PROG_BEGIN      Write the target address to the bin file
    .DA     PROG_END-PROG_BEGIN   Write the length to the bin file

PROG_BEGIN  ;               The intended target address of $2000
    LDA     ......
     :                      Your program goes here
     :
     :
    RTS                     Until here
PROG_END

Next, I add the resulting binary file to my disk image using CiderPress, which then defaults to $F2. With this addition, CiderPress now works correctly when I change the file and aux types. Hope some other poor sap like myself finds this helpful!

I guess you are BLOADing the resulting file later on with DOS 3.3... It doesn't matter if you are running the binary file directly from DOS or just loading it using DOS 3.3 -- there is a standard DOS 3.3 binary 4-byte header for B type DOS 3.3 files (starting address and length). I am not familiar with SBASM but I must try it, and yes I have programmed thousand times more low-level code for PCs than for Apple2s. Use a HEX editor with your resultant file on the PC side to check for the presence of this header which you are now constructing using assembler's directives within your source code. Remember -- it is a linker's job to add a properly generated header of the executable that you used to program for PCs . I still doubt that the object files generated by SBASM are meant to be executed directly or loaded by the target OS. Unless you are using some form of POKEing the same data from these object files generated by SBASM from AppleSoft BASIC there must be another step you are missing in binary file generation.

 

[gslick]

Use a HEX editor with your resultant file on the PC side to check for the presence of this header which you are now constructing using assembler's directives within your source code. Remember -- it is a linker's job to add a properly generated header of the executable that you used to program for PCs . I still doubt that the object files generated by SBASM are meant to be executed directly or loaded by the target OS. Unless you are using some form of POKEing the same data from these object files generated by SBASM from AppleSoft BASIC there must be another step you are missing in binary file generation.

If all that is needed is a plain binary file with the two start address and length words, with the code generated with the origin at the specified starting address then SBASM appears to do exactly what is needed.

Example.lst:

1FFC-                  5
1FFC-00 20             6           .DA     PROG_BEGIN      Write the target address to the bin file
1FFE-03 00             7           .DA     PROG_END-PROG_BEGIN   Write the length to the bin file
2000-                  8
2000-                  9       PROG_BEGIN  ;               The intended target address of $2000
2000-A9 55            10 (  2)     LDA     #$55
2002-                 11            ;                      Your program goes here
2002-                 12            ;
2002-                 13            ;
2002-60               14 (  6)     RTS                     Until here
2003-                 15       PROG_END

Example binary output file:

00 20 03 00 a9 55 60