[Coco] Assembly help: Corrupted bin file ?

[Roger Taylor]

At 05:25 PM 12/18/2008, you wrote:
>I'll add to what Art and William wrote about multiple ORG statements.
>
>The term "multi-segment source file" is somewhat deceptive. The 
>precise meaning relates not to the source code at all but the manner 
>in which the compiled file is stored on disk.
>The Coco does not store bare binary programs on disk. The only way 
>to create these file with just a Coco is to create a data file. The 
>Coco always has at least a preamble and postamble defining where the 
>program loads into memory, how long it is, and where the execution 
>address is located.

Except for CCASM which can produce direct code files (a.k.a. ROMs, 
raw binaries, etc.).  Use the switch -rom=8k   -rom=16k   etc.
All RMBs or gaps in the program counter will be filled with zeros to 
pad out the file.

Multiple ORGs are still possible if you're building a ROM image as 
long as each subsequent ORG address is higher than the last, I do 
believe the space gets filled with zeros just as if you were using RMB's.

A single-segment CCASM program is exactly like a ROM file but it can 
be LOADM'ed into the CoCo.


>If the only the initial preamble and postamble are present, then the 
>file is a single segment file. This type of storage is not the 
>default for the Tandy EDTASM program. It defaults to multi-segment 
>files that typically have segments of 256 bytes. Each segment has a 
>preamble. This happens even if the is a single ORG statement in the 
>source code.
>If there are multiple ORG statements, then each ORG could engender a 
>preamble in the stored file.
>
>So, how does the above apply to EDTASM or RainbowIDE? EDTASM has an 
>assembly option to force the single segment format if there is no 
>more than one ORG statement. A "FILENAME" /SR   which stands for 
>single record. RainbowIDE offers many more options in the Output 
>Object drop-down entry.
>
>The net result is that the number of ORG statements and assembler 
>options determine how or if the resulting binary is segmented.
>
>===============
>You already got from another reader the answer to controlling the 
>the start of the PMODE screens. To restate it, bytes $FFC6-$FFD3 do 
>this. Each even byte is a 0, each odd byte a 1. The bits are 
>combined into a seven bit word that points to the start of the video 
>address for a Coco1, Coco2, or Coco3 in Coco1 mode. $FFC6/$FFC7 is 
>the least significant bit and $FFD2/$FFD3 the most significant bit.
>Screen start / by $200 = video offset
>Low res text screen is $400/$200=2=%10  = $FFC9 $FFC6
>Beginning of the PMODE screen on a non-disk system
>  $600/$200=3=%11 = $FFC9 $FFC7
>Beginning of the PMODE screen on a disk system
>  $E00/$200=7=%111 = $FFCB $FFC9 $FFC7




-- 
Roger Taylor

http://www.wordofthedayonline.com