Assembly with Merlin 8
Robert Fletcher
some code that was made from sourceror, the error messes "Illegal Forward
Reference" is blinking in front of my face. How do I fix it.
_____
UUCP: cs.utexas.edu!wixer!pro-lep!robertf
ARPA: pro-lep!rob...@wixer.bga.com
INET: rob...@pro-lep.cts.com
Da...@damage.cleve.fnet.org
> I have a problem and need to know how to solve it. During assembly of
>some code that was made from sourceror, the error messes "Illegal Forward
>Reference" is blinking in front of my face. How do I fix it.
This means that MERLIN is trying to JMP or JSR to a subroutine that has not
yet been defined.
If you are using something like this...
ADDRESS = $C080
Then, make sure that these equates are always -FIRST- in the file.
--
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Internet: da...@damage.cleve.fnet.org | Sysop of Damage Incorporated +
+ FutureNet: #1@#6 | (216)-328-0374 +
+ "Spring break in Waco, Tx! 14 days of fun, sun and barbecues!" - Me! +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Robert Furman
I have had a little experincevwith Merlin, the error you speak of is
because there is a forward/reverse branch that is too far away....
i.e BNE LOOP...
Where the label loop is more than 128 bytes for a forward refrence or 127
bytes for a reverse refrence.....double check your BNE,BCC, ....and so
on....
Rob
ProLine: nuke@pro-nsdapple
Internet: nu...@pro-nsdapple.cts.com
UUCP: crash!pro-nsdapple!nuke
Victoria M Althoff
<Da...@damage.cleve.fnet.org> wrote:
* original problem with ILLEGAL FORWARD REFERENCE removed*
>
>This means that MERLIN is trying to JMP or JSR to a subroutine that has not
>yet been defined.
>
>If you are using something like this...
>
>ADDRESS = $C080
>
>Then, make sure that these equates are always -FIRST- in the file.
Ummm...I'm not too sure about that. I use the Big Mac Macro Assembler, which I
believe is nearly identical to (but distributed through a different channel
from) the original Merlin. It's been a while since I have run into that error,
but I think I have encountered it.
First of all, the location of the equates within the program doesn't seem to
matter, since the assembler makes multiple passes while generating source code.
First, it generates op-codes for all of the instructions, then it goes back
through and fixes address references. It is possible that putting absolute
equates at the end is causing problems, but I doubt it because I always end up
with data storage bytes reserved at the end of the program, and those never
cause problems.
My guess is that the problem is not with misplaced equates (although it is good
practice to put them first in the source). Instead, I'd look for a bad branch
error, where a conditional branch (i.e. BEQ, BNE, BCC, BCS, BPL, BLT,
BBC...oops...those two were my last meal, not opcodes!) is trying to jump
forward more than 127 bytes. In that case, the solution is to put less space
between the branch instruction and the destination.
Okay, so you have two opinions of the problem. So, what is the instruction on
the line that causes the assembler to crash?
--Dave Althoff, Jr.
(knows enough 6502 to be hazardous)
Robert Fletcher
some other problems now, the program is not working right. I well get back
to you on the new problem.
Thanks for your advice.
Robert Fletcher
of equal lables to the top of the code.
The code assembles now, but the program is not running right. For some
reason there are odd bands of graphics across the screen. I have not had
the time to look into this, but I hope to the problem is a simple one.
Da...@damage.cleve.fnet.org
<> wrote:
>My guess is that the problem is not with misplaced equates (although it is
>good practice to put them first in the source). Instead, I'd look for a
>bad branch error, where a conditional branch (i.e. BEQ, BNE, BCC, BCS,
>BPL, BLT, BBC...oops...those two were my last meal, not opcodes!) is
>trying to jump forward more than 127 bytes. In that case, the solution
>is to put less space between the branch instruction and the destination.
Nope...Under Merlin an illegal branch call is caught and handled as a separate
error.
Victoria M Althoff
Robert Fletcher <rob...@pro-lep.cts.com> wrote:
>
>The code assembles now, but the program is not running right. For some
>reason there are odd bands of graphics across the screen. I have not had
>the time to look into this, but I hope to the problem is a simple one.
Without knowing what your code is doing, let me suggest the following...
Take a close look at the memory locations your object code is using. If you
are displaying the graphic page AND your program is in the area of memory
occupied by the graphic page, the result will be strange bands of graphics.
And, if you erase those graphic bands, your object code will also go away...!
(that's why the default OBJ address is $8000...)
--Dave Althoff, Jr.
(remember...my assembler is older than your assembler!)
Da...@damage.cleve.fnet.org
>The problem was that the equals needed to be at the beginning. I am having
>some other problems now, the program is not working right. I well get back
>to you on the new problem.
>
>Thanks for your advice.
Your more than welcome! I wish that I had available the kind of help that
Usenet can provide when I was leraning Merlin! :)
David Empson
rob...@pro-lep.cts.com (Robert Fletcher) writes:
> I have a problem and need to know how to solve it. During assembly of
> some code that was made from sourceror, the error messes "Illegal Forward
> Reference" is blinking in front of my face. How do I fix it.
Well, I've seen two wrong answers to your question so far, and one
that is probably right (Hi Dave!)
In most cases, Merlin doesn't care what value an expression has during
pass 1 - it just needs to determine the number of bytes of code (and
address) of each line. The expression values are sorted out during
pass 2.
A problem arises if you use a forward reference (i.e. a reference to a
label which is defined later in the file) in an expression which
changes the location counter (such as ORG) or a DS statement.
Here is an example of each:
ORG START
START EQU $4000 <- illegal forward reference here
DS END-START <- illegal forward reference here
START
* Any code or data in here
END
There are probably other causes, but these are the most common ones.
In all such cases, you have to rearrange your code - all symbols
referenced in an ORG or DS expression must be defined before the ORG
or DS.
If it isn't either of these, then I suggest you post a code fragment,
indicating the line on which the error was reported.
Hope this helps.
--
David Empson
dem...@swell.actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand
Robert Fletcher
Sean Dockery
| Thanks to all for your help. The problem was solved by moving the long
| list of equal lables to the top of the code.
|
| The code assembles now, but the program is not running right. For some
| reason there are odd bands of graphics across the screen. I have not had
| the time to look into this, but I hope to the problem is a simple one.
I didn't catch the original post if it mentioned the goal of your program
(news around here is sometimes sporadic), but it sounds to me like you're
trying to use hi-res graphics while double hi-res mode is enabled.
If you only want to work in hi-res, try executing the following instruction
before activating the hi-res video mode:
CLRAN3 = $C05F ;disable annuciator #3 (DHR mode soft-switch)
STA CLRAN3 ;disable DHR mode
If your intention is to use double hi-res graphics, you're going to have to
handle drawing to it by page switching methods (which are quite elaborate
for drawing bitmapped/vectored shapes and best discussed in email).
| UUCP: cs.utexas.edu!wixer!pro-lep!robertf
| ARPA: pro-lep!rob...@wixer.bga.com
| INET: rob...@pro-lep.cts.com
--
Sean Dockery | C, Lisp, Pascal, ForTran, BASIC, 65C02,
doc...@griffin.cuc.ab.ca | 65C816, and Profanity (all dialects)