From: bob@kc2wz.bubble.org (Bob Billson)
Newsgroups: comp.sys.m6809
Subject: Re: Weird problem with OS-9 ASM -- help
Date: 24 Aug 92 18:49:17 GMT
Distribution: na
Organization: Color Computer 3: Tandy's 'game' machine

c23vgs@kocrsv01.delcoelect.com (Victor Sperry) says:
>
>In article <116@kc2wz.bubble.org>, bob@kc2wz.bubble.org (Bob Billson) writes:
>> Question for the net.  I am using the OS-9 Level I assember ASM in the Motorola
>> compatible mode.  The code will eventually be burned into an EPROM to run on a
>> single board 6809 computer.
>> 
>> For some reason the RMB pseudo-op is not reserving a block of empty bytes
>> at the end of the code.  Here is the editted output of ASM.  The deleted
>> code is unimportant as far as the problem goes.
>> 
>
>[stuff deleted]
>
>> 
>> 00579        *
>> 00580        * last 16 bytes in EPROM have to be $E000
>> 00581        *
>> 00582        
>> 00583   0440                     rmb   epromsiz-(endprgm-start)-16 
>> 00584        
>> 
>
>Try this instead of using RMB.
>
>      org  $1ff0

I tried this with the same result.  Actually I tried this originally and when
it didn't work I tried the above.

>> Notice bytes seem to have been reserved as the address counter is incremented
>> properly.  However, dump the resulting file shows this is not the case.
>> 
>> 00585   1FF0 E000                fdb   $e000 
>> 00586   1FF2 E000                fdb   $e000 
>> 00587   1FF4 E000                fdb   $e000 
>> 00588   1FF6 E000                fdb   $e000 
>> 00589   1FF8 E000                fdb   $e000 
>> 00590   1FFA E000                fdb   $e000 
>> 00591   1FFC E000                fdb   $e000 
>> 00592   1FFE E000                fdb   $e000 
>> 00593                            end
>> 
>
>[stuff deleted]
>
>> 
>> Starting at $043E, there should be a large chuck of reserved bytes.  Instead
>> there are two bytes immediately followed by the $E000 bytes.  Why isn't the 
>> assembler reserved the block of bytes?
>> 
>> Anyone point out what I am doing wrong?  Thanks for the help.
>
>
>Since your listing showed the vectors being placed at $1ff0 but the raw byte
>dump program showed them at $0440, you have a problem with one of the two
>tools (assembler or dump tool). I assume you got into this detail because the
>code didn't work, hence the assembler is probably wrong, not the dumper.

No the dump utility is okay.  The assembler lines at the end say that slightly
over 1K of code was generated, which should not be the case.  The dump merely
confirmed this.

>The only thing I can point out is that the "RMB" instruction is intended to
>reserve RAM, not EPROM, so you should probably use an "ORG" anyway (see above),
>but the inconsistency between the listing and the generated code does look
>like an assembler problem.
>
>Alternatively, many assemblers have some sort of "form constant BLOCK" (as
>opposed to "form constant BYTE") pseudo instruction which can be used to
>form a large block of constant-valued ROM. So you might be able to use:
>
> 00583   0440                     blk   $ff,epromsiz-(endprgm-start)-16
>
>to stick $ff's in EPROM. This will probably make your output file (.PTP is
>what mine would be) much larger, though.

Hmm...I'm not sure if the OS-9 assembler I have will support this, but
I'll investigate it.  Thanks.
-- 
  Bob Billson, KC2WZ                          | internet: bob@kc2wz.bubble.org
                                              |           kc2wz@amsat.org
  $nail:  21 Bates Way,  Westfield, NJ 07090  | uucp:     ...!uunet!kc2wz!bob
                  C code.  C code run.  Run code run...<please!>
Newsgroups: comp.sys.m6809