[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