[Coco] Assembly help: Corrupted bin file ?

[Robert Gault]

Fedor,

There could be several things wrong here depending on how you tried to 
use this with VCC. There is also a problem with the source regards CCASM 
or any of the assemblers that are used with a Coco.

It would help to know how you tried to use this with VCC.

Comments are inserted below.

> "Fedor Steeman" <petrander at gmail.com> a écrit 
> dans le message de news: 
> dcc956220812162330t4b8be888je63b60fd6321d19f at mail.gmail.com...
>> Hello everyone,
>>
>> I am still trying to learn assembly language but keep on running into
>> problems.
>>
>> I have been trying to have the following source code assembled:
>>
>> VIDRAM  EQU     $0400     *Start of Video Display location
>> V0CLR   EQU     $FFC0        *Clear bit for Sam Chip (Graphics mode)
>> V1SET   EQU     $FFC3        *Set V1 bit in Sam Chip (Graphics mode)
>> V2SET   EQU     $FFC5        *set V2 bit in Sam Chip (Graphics mode)
>> VOFSET  EQU     $FFC6       *Display Offset Binary, This is the CLR Bit
>> (Video page offset)
>> VDGSET  EQU     $FF22        *PIA1 data port B: VDG Control output
>> POLCAT  EQU     $A000        *Color Basic rom poll keyboard routine
>>
>>        ORG     $21FD
>>        LDX     #VIDRAM   *331D: 8E 04 00

This next can't be what you wanted. Almost certainly you intended to 
store the value $AAAA into memory. That means the next line should be 
changed to
           LDD     #$AAAA

>>        LDD     $AAAA     *3320: CC AA AA
>> Z3323   STD     ,X++      *3323: ED 81
>>        CMPX    #$1C00    *3325: 8C 1C 00
>>        BCS     Z3323     *3328: 25 F9

There is no reason for the next line. It is not required for a timing 
issue and certainly was not used to block out previous code. :)

>>        NOP               *332A: 12
>> PMODE4  STA     V0CLR     *2787: B7 FF C0
>>        STA     V1SET     *278A: B7 FF C3
>>        STA     V2SET     *278D: B7 FF C5
>>        LDA     #$F8      *2790: 86 F8
>>        STA     VDGSET    *2792: B7 FF 22
>>        STA     VOFSET    *2795: B7 FF C6

The next two lines have two problems, one already mentioned by another 
reader is the keyboard is only checked once so any key press is likely 
to be missed. The other is the use of JSR then RTS. Since the JSR 
already has an RTS at its end, that results in RTS RTS which is a waste 
of space and time.
There are several ways of changing the code depending on whether you 
need the value of the key pressed or are just waiting for any key to be 
pressed. I prefer in the latter case to just use the Disk Basic code and 
JSR $ADFB. In your code example, it would just be JMP $ADFB.
However, assuming you might want the value of the pressed key and using 
the example of POLCAT, the lines should be

    L1     JSR     [POLCAT]
           BEQ     L1
        do something with the key value
           RTS

>>        JSR     [POLCAT]  *332E: AD 9F A0 00
>>        RTS               *3332:

This needs and END statement and if you intended to LOADM the code it 
also needs a reference to the execution address. The following changes 
are needed.

 >>        ORG     $21FD
 >> Start  LDX     #VIDRAM   *331D: 8E 04 00
....
 >>        JSR     [POLCAT]  *332E: AD 9F A0 00
 >>        RTS               *3332:
           END     Start
>>
>> Using Roger Taylor's CCASM (as included in RainbowIDE) I get the following
>> binary file:
>>
The origin of the code is shown below (the 2421) but the length of the 
sequence is zero (the first two 00 00). CCASM did not know how long your 
program should be. Also you may not have selected the correct Object 
Output in RainbowIDE.

>> 00 00 24 21 FD 8E 04 00 FC AA AA ED 81 8C 1C 00
>> 25 F9 12 B7 FF C0 B7 FF C3 B7 FF C5 86 F8 B7 FF
>> 22 B7 FF C6 AD 9F A0 00 39

As mentioned by another reader, there is no footer to this code to be 
used by LOADM.

>>
>> When I try to run this binary file using the VCC emulator I get an error
>> message stating that the binary file is corrupt.
>>
>> Can anyone help me try to understand whether there is anything wrong with 
>> my
>> source code, the assembler (i.e. the resulting binary file) or the 
>> emulator?
>>
>> Thanks in advance!
>>
>> Cheers,
>> Fedor

You probably should indicate exactly how you asked RainbowIDE to compile 
your code because there might be something wrong at that end of the process.