[Coco] Assembly help: Corrupted bin file ?
operator at coco3.com
Thu Dec 18 18:57:16 EST 2008
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
>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
More information about the Coco