Vectrex programming question/help. JSR wont work?

Archived from groups: rec.games.vectrex (More info?)

I am having trouble using sub routines, they don't seem to get called..

I have a bit of code that looks like:

main:
;some code

jsr drawsomething
bra main


drawsomething:
;some code
drawsomethingloop:
;some code
blo drawsomethingloop
rts

This doesn't work.. However, this does:

main
;some code

drawsomething:
;some code
drawsomethingloop:
;some code
blo drawsomethingloop
bra main


Which is exacly the same except I am letting the program run onto my
subroutine instead of using the jsr... I'm new to assembly language so
am not sure if there are any special considerations when using jsr. Do
I have to store the return address somewhere?

Any help would be greatly appreciated!
19 answers Last reply
More about vectrex programming question help wont work
  1. Archived from groups: rec.games.vectrex (More info?)

    The 6809 stores your return address on the stack, and "rts" pops it back
    off. Are you initializing your stack pointers to someplace sane?
    --
    Michael White "To protect people from the effects of folly is to
    fill the world with fools." -Herbert Spencer, 1891

    mrjohnstrange@gmail.com (mrjohnstrange@gmail.com) wrote on Monday 14 March
    2005 11:30 am:

    > I am having trouble using sub routines, they don't seem to get called..
    >
    > I have a bit of code that looks like:
    >
    > main:
    > ;some code
    >
    > jsr drawsomething
    > bra main
    >
    >
    > drawsomething:
    > ;some code
    > drawsomethingloop:
    > ;some code
    > blo drawsomethingloop
    > rts
    >
    > This doesn't work.. However, this does:
    >
    > main
    > ;some code
    >
    > drawsomething:
    > ;some code
    > drawsomethingloop:
    > ;some code
    > blo drawsomethingloop
    > bra main
    >
    >
    > Which is exacly the same except I am letting the program run onto my
    > subroutine instead of using the jsr... I'm new to assembly language so
    > am not sure if there are any special considerations when using jsr. Do
    > I have to store the return address somewhere?
    >
    > Any help would be greatly appreciated!
  2. Archived from groups: rec.games.vectrex (More info?)

    I'm doing:
    Vec_Default_Stk equ $CBEA ;end of ram?

    and then
    lds #Vec_Default_Stk

    to initialise it. Is that wrong?


    Michael White <michael12@mindspring.com> wrote in message news:<ZisZd.9087$oO4.5404@newsread3.news.pas.earthlink.net>...
    > The 6809 stores your return address on the stack, and "rts" pops it back
    > off. Are you initializing your stack pointers to someplace sane?
    > --
    > Michael White "To protect people from the effects of folly is to
    > fill the world with fools." -Herbert Spencer, 1891
    >
    > mrjohnstrange@gmail.com (mrjohnstrange@gmail.com) wrote on Monday 14 March
    > 2005 11:30 am:
    >
    > > I am having trouble using sub routines, they don't seem to get called..
    > >
    > > I have a bit of code that looks like:
    > >
    > > main:
    > > ;some code
    > >
    > > jsr drawsomething
    > > bra main
    > >
    > >
    > > drawsomething:
    > > ;some code
    > > drawsomethingloop:
    > > ;some code
    > > blo drawsomethingloop
    > > rts
    > >
    > > This doesn't work.. However, this does:
    > >
    > > main
    > > ;some code
    > >
    > > drawsomething:
    > > ;some code
    > > drawsomethingloop:
    > > ;some code
    > > blo drawsomethingloop
    > > bra main
    > >
    > >
    > > Which is exacly the same except I am letting the program run onto my
    > > subroutine instead of using the jsr... I'm new to assembly language so
    > > am not sure if there are any special considerations when using jsr. Do
    > > I have to store the return address somewhere?
    > >
    > > Any help would be greatly appreciated!
  3. Archived from groups: rec.games.vectrex (More info?)

    In article news:1110821427.523112.255430@f14g2000cwb.googlegroups.com, mrjohnstrange@gmail.com wrote:
    >Which is exacly the same except I am letting the program run onto my
    >subroutine instead of using the jsr...
    verify the distance between the JSR call and the physical location of the subroutine is less than what is allowed. This *should* generate an assembler error but may not. For JSRs, I believe the disaance is smaller than JMP so changing JSR->JMP would be a good test...
    --
    For God, Family and Republic!
    My plan to save the world:
    more Jesus, less government!
    http://www.PalmYanoff.com
  4. Archived from groups: rec.games.vectrex (More info?)

    That looks like it should work. As Gregg said, you should also verify that
    the distance the JSR is taking you is not too large.
    --
    Michael White "To protect people from the effects of folly is to
    fill the world with fools." -Herbert Spencer, 1891

    Robert (mrjohnstrange@gmail.com) wrote on Tuesday 15 March 2005 05:31 am:

    > I'm doing:
    > Vec_Default_Stk equ $CBEA ;end of ram?
    >
    > and then
    > lds #Vec_Default_Stk
    >
    > to initialise it. Is that wrong?
    >
    >
    > Michael White <michael12@mindspring.com> wrote in message
    > news:<ZisZd.9087$oO4.5404@newsread3.news.pas.earthlink.net>...
    >> The 6809 stores your return address on the stack, and "rts" pops it back
    >> off. Are you initializing your stack pointers to someplace sane?
    >> --
    >> Michael White "To protect people from the effects of folly is to
    >> fill the world with fools." -Herbert Spencer, 1891
    >>
    >> mrjohnstrange@gmail.com (mrjohnstrange@gmail.com) wrote on Monday 14
    >> March 2005 11:30 am:
    >>
    >> > I am having trouble using sub routines, they don't seem to get called..
    >> >
    >> > I have a bit of code that looks like:
    >> >
    >> > main:
    >> > ;some code
    >> >
    >> > jsr drawsomething
    >> > bra main
    >> >
    >> >
    >> > drawsomething:
    >> > ;some code
    >> > drawsomethingloop:
    >> > ;some code
    >> > blo drawsomethingloop
    >> > rts
    >> >
    >> > This doesn't work.. However, this does:
    >> >
    >> > main
    >> > ;some code
    >> >
    >> > drawsomething:
    >> > ;some code
    >> > drawsomethingloop:
    >> > ;some code
    >> > blo drawsomethingloop
    >> > bra main
    >> >
    >> >
    >> > Which is exacly the same except I am letting the program run onto my
    >> > subroutine instead of using the jsr... I'm new to assembly language so
    >> > am not sure if there are any special considerations when using jsr. Do
    >> > I have to store the return address somewhere?
    >> >
    >> > Any help would be greatly appreciated!
  5. Archived from groups: rec.games.vectrex (More info?)

    JMP doesn't work either, but BRA does... Hmmm.. I've got around the
    problem now, but I think a JSR + RTS would be tidier.

    I'm having another problem though..

    I have something like this:

    mapdata:
    fcb 8 ;height
    fcb 16 ;width
    fcb 0,0,0,0,0,1,0.......... etc

    and then some code to read through it like this:

    ldx #mapdata
    lda ,x++
    sta Height
    lda ,x++
    sta Width

    In the mess debugger I can see that the ldx seem to be the wrong
    address...
    it looks like this:
    LDX #$82

    when if I look through the disassembly I can see that my data starts at
    0xA0

    If I change it from a label to the actual address in my code, like:

    ldx #$A0

    The first value is loaded correctly but the second one isn't. What am
    I doing wrong?
  6. Archived from groups: rec.games.vectrex (More info?)

    I am but I only lurk now.
    I have 3 children and 3 jobs and NO TIME for fun that doesn't generate
    revenue or salvation of souls (i.e. no video games)!
    http://www.PalmYanoff.com is where most of my "free" time went in 2004.
    One of the only reasons I even lurk is it is "job-related" to New
    Yanoff! :>
  7. Archived from groups: rec.games.vectrex (More info?)

    BTW are you the Gregg Woodcock creator of the original Vectrex FAQ ?


    Richard H.
  8. Archived from groups: rec.games.vectrex (More info?)

    I think the two problems you're seeing are related. With both of those, it
    sounds like a linker-type issue. JSR and JMP use absolute addresses. This
    address is filled in by the linker or some portion of the assembler that
    figures out an absolute address, e.g. 0xa0 as you specify below.

    BRA uses a relative address, i.e. adds to or subtracts from the current PC.
    This value can be calculated by the assembler and plugged in right away,
    e.g. -8 or +6. It does not care what address you're at.

    I'm not familiar with the Vectrex assembler, but there should be some
    directive telling the assembler at what address to start. A common one is
    "ORG", but you'll need to find it for your assembler. Make sure this
    address is specified.

    BTW, I haven't messed with a 68xx since the late 80's, so I'm a bit rusty.
    This is quite a jump back from 680x0 and PowerPC stuff.
    --
    Michael White "To protect people from the effects of folly is to
    fill the world with fools." -Herbert Spencer, 1891

    Robert (mrjohnstrange@gmail.com) wrote on Wednesday 16 March 2005 10:40 am:

    > JMP doesn't work either, but BRA does... Hmmm.. I've got around the
    > problem now, but I think a JSR + RTS would be tidier.
    >
    > I'm having another problem though..
    >
    > I have something like this:
    >
    > mapdata:
    > fcb 8 ;height
    > fcb 16 ;width
    > fcb 0,0,0,0,0,1,0.......... etc
    >
    > and then some code to read through it like this:
    >
    > ldx #mapdata
    > lda ,x++
    > sta Height
    > lda ,x++
    > sta Width
    >
    > In the mess debugger I can see that the ldx seem to be the wrong
    > address...
    > it looks like this:
    > LDX #$82
    >
    > when if I look through the disassembly I can see that my data starts at
    > 0xA0
    >
    > If I change it from a label to the actual address in my code, like:
    >
    > ldx #$A0
    >
    > The first value is loaded correctly but the second one isn't. What am
    > I doing wrong?
  9. Archived from groups: rec.games.vectrex (More info?)

    Robert wrote:

    >In the mess debugger I can see that the ldx seem to be the wrong
    >address...
    >it looks like this:
    >LDX #$82
    >
    >when if I look through the disassembly I can see that my data starts at
    >0xA0
    >
    >If I change it from a label to the actual address in my code, like:
    >
    >ldx #$A0
    >
    >The first value is loaded correctly but the second one isn't. What am
    >I doing wrong?

    This doesn't make any sense, X is a word (16 bit) value, you shouldn't
    be able to put #$A0 or #$82 into it.

    As someone mentioned, this does look like an assembler problem, what
    assembler are you using? You're not using, say, a 6502 assembler
    instead of a 6809 assembler (would explain single byte X values and
    possibly the JSR problem)? Or, are you using a multi-assembler and you
    need to tell the assembler what CPU to assemble for?

    There's no limit to the length of a JSR, btw and the BIOS sets the
    default stack pointer so you don't need to set it unless you want to
    move it.


    Chris...
  10. Archived from groups: rec.games.vectrex (More info?)

    christophertumber@rogers.com (Christopher Tumber) writes:
    > This doesn't make any sense, X is a word (16 bit) value, you shouldn't
    > be able to put #$A0 or #$82 into it.

    Certainly you can. The result in the X register will be $00A0 or $0082,
    unless your assembler is broken.
  11. Archived from groups: rec.games.vectrex (More info?)

    >lda ,x++

    Why are you incrementing X by 2 when your data are single bytes,
    shouldn't it be:

    lda ,x+


    Chris...
  12. Archived from groups: rec.games.vectrex (More info?)

    Eric Smith wrote:

    >Certainly you can. The result in the X register will be $00A0 or $0082,
    >unless your assembler is broken.

    Okay, this took me a while, I had written a big post explaining the
    6809's addressing modes and how you can't address individual bytes in
    X,Y,U or S, but I think what you're actually saying is: The assembler
    will *correct your error* and translate:

    LDX #$A0

    to

    LDX #$A000

    Before it assembles the instruction. If your assembler does not at
    least flag this with a warning (an error would be better) your
    assembler is broken.

    This is an unspeakably horrible, sloppy coding practice that will
    eventually come back to haunt you.


    Chris...
  13. Archived from groups: rec.games.vectrex (More info?)

    I wrote:
    > Certainly you can. The result in the X register will be $00A0 or $0082,
    > unless your assembler is broken.

    Christopher Tumber wrote:
    > Okay, this took me a while, I had written a big post explaining the
    > 6809's addressing modes and how you can't address individual bytes in
    > X,Y,U or S, but I think what you're actually saying is: The assembler
    > will *correct your error* and translate:
    >
    > LDX #$A0
    >
    > to
    >
    > LDX #$A000

    No, it most certainly does not!!!!!

    If you give any of the following instructions to the assembler, you get the same result:

    LDX #$A0
    LDX #$0A0
    LDX #$00A0

    The assembler evaluates the immediate operand as a 16-bit numeric value. It
    so happens that with $A0, the high eight bits are zero.

    The assembler does not EVER implicitly shift your operand left eight bits for you.

    > Before it assembles the instruction. If your assembler does not at
    > least flag this with a warning (an error would be better) your
    > assembler is broken.

    Absolutely brimming over with wrongability, as Rimmer would say.

    > This is an unspeakably horrible, sloppy coding practice that will
    > eventually come back to haunt you.

    No. If you want the value $00A0 in X, doing LDX #$A0 is a perfectly reasonable
    way to get it.

    If you want the value $A000 in X, you need to use LDX #$A000

    Let's look at it another way.

    Suppose you define some locations in low memory like this (syntax may vary by
    assembler):

    FOO EQU $9F
    BAR EQU $A0
    BLETCH EQU $A1

    The addresses assigned by the assembler are $009F, $00A0, and $00A1.

    Later in the code, I decide that I want to have X point to BAR. I simply
    say
    LDX #BAR

    And X winds up containing $00A0. *NOT* $A000.

    If I were to use
    LDX #$A0
    I would get the same result.

    I have *NEVER* seen an assembler for ANY processor do what you're claiming,
    and I've been writing assembly language for more than a dozen different processors
    over the last 29 years.

    Eric
  14. Archived from groups: rec.games.vectrex (More info?)

    Eric SMith wrote:

    >No, it most certainly does not!!!!!
    >
    >If you give any of the following instructions to the assembler, you get the same result:
    >
    > LDX #$A0
    > LDX #$0A0
    > LDX #$00A0

    Sigh, fine, you got me, I misread your post/mistyped mine. Whatever.
    You've still maned to completely miss my point. So here it is again,
    corrected:

    Okay, this took me a while, I had written a big post explaining the
    6809's addressing modes and how you can't address individual bytes in
    X,Y,U or S, but I think what you're actually saying is: The assembler
    will *correct your error* and translate:

    LDX #$A0

    to

    LDX #$00A0

    Before it assembles the instruction. If your assembler does not at
    least flag this with a warning (an error would be better) your
    assembler is broken.

    This is an unspeakably horrible, sloppy coding practice that will
    eventually come back to haunt you.


    Chris...
  15. Archived from groups: rec.games.vectrex (More info?)

    There are two ways that an assembler could extend an 8 bit value to 16
    bits - signed or unsigned. So LDX #$A0 could also become LDX #$FFA0.
    Now, most assemblers should treat the value as unsigned unless it it
    coded as LDX #-96 or LDX #-$60, but you never know sometimes,
    particularly with multi-CPU assemblers.

    I agree with Chris though, this should be a warning as a possible
    conversion error.
  16. Archived from groups: rec.games.vectrex (More info?)

    christophertumber@rogers.com (Christopher Tumber) writes:
    > X,Y,U or S, but I think what you're actually saying is: The assembler
    > will *correct your error* and translate:
    > LDX #$A0
    > to
    > LDX #$00A0

    It's not an error! $A0 is a perfectly legitimate value to load into X.
    It happens to be a 16-bit value of which the top eight bits are zero.
    The fact that someone didn't bother to type the extra hexadecimal
    zero characters is not a mistake, and there's nothing wrong with it.

    I should just as easily be able to say LDX #$A, or LDX #$ABC, without
    it being a mistake and without the assembler complaining.

    All the assembler is supposed to do is evaluate the expression and
    verify that it doesn't exceed the permissible immediate operand range,
    which is $0 through $FFFF.

    Would you expect the assembler to complain if you said "LDX #$02*$9E"?
    What if you said "LDX #$A0+FOO", where FOO was defined elsewhere? If
    so, which of these possible definitions of FOO should trigger that
    warning, and which shouldn't?

    FOO EQU 3 ; decimal
    FOO EQU 30000 ; decimal
    FOO EQU 65500 ; decimal
    FOO EQU $10B
    FOO EQU $010B
    FOO EQU $1234
    FOO EQU $FFF3
    FOO EQU 3*$FF2

    The assembler does not attempt to track how many extraneous leading
    zeros are in front of a number, nor should it. It only cares about
    the abstract numeric value the number (or expression) evaluates to,
    and the numeric values of "$A0", "$00A0", and "$00A0" are identical.

    The asembler may even allow you to write:
    LDX #$000000000000000A0

    Which still evaluates to the same numeric value.

    > Before it assembles the instruction. If your assembler does not at
    > least flag this with a warning (an error would be better) your
    > assembler is broken.

    Absolutely NONE of the assemblers I have used for the past 29 years
    would complain about that, nor would I want them to. It's a legal
    and reasonable instruction.

    If you're going to persist in claiming otherwise, please tell us what
    6809 assembler complains about "LDX #$A0", so we can verify it and then
    laugh at what a ridiculous assembler it is.

    > This is an unspeakably horrible, sloppy coding practice that will
    > eventually come back to haunt you.

    No, it isn't.

    Eric
  17. Archived from groups: rec.games.vectrex (More info?)

    "Eric Ball" <Eric.L.Ball@gmail.com> writes:
    > There are two ways that an assembler could extend an 8 bit value to 16
    > bits - signed or unsigned. So LDX #$A0 could also become LDX #$FFA0.
    > Now, most assemblers should treat the value as unsigned unless it it
    > coded as LDX #-96 or LDX #-$60, but you never know sometimes,
    > particularly with multi-CPU assemblers.
    >
    > I agree with Chris though, this should be a warning as a possible
    > conversion error.

    Why on earth should the assembler *ever* assume that a hex literal like
    $A0 is a negative value? I've *never* seen an assembler using 16-bit
    or 32-bit arithmetic that did such a thing.

    And if the assembler didn't assume that it was a negative value, on
    what basis could it give a warning?

    Should this hypothetical assembler give a warning about a possible
    conversion error for "LDX #$F00"? After all, by your reasoning maybe
    that F00 is intended as a signed 12-bit constant and should be
    extended to $FF00?

    And if the assembler should assume that I might have meant that the
    constant in LDX #$A0 should be sign extended, should it also believe
    that if I write LDX #160? After all, 160 decimal is the same 8-bit
    value as $A0. Surely you're not proposing that the assembler should
    have radically methods of interpreting the use of numeric values
    depending on what base they were entered in?

    What if I write:
    FOO EQU $C0

    Should the assembler warn in this case, because maybe I meant $FFC0?
    If it doesn't warn there, should it warn when I use it thusly:
    LDX #FOO

    I think we'd both agree that there shouldn't be a warning for:
    FOO EQU $00C0
    ...
    LDX $FOO

    Yet the only way the assembler would be able to distinguish those
    two cases is if the symbol table somehow tracked that FOO was defined
    using a hex constant of exactly two digits.

    Similarly, if I write
    BAR EQU $41
    which is obvioulsy positive unless it's a seven bit value,
    and later write
    LDX #3*FOO
    should the assembler believe that I might want the result of the
    multiplication, which is C3 hex, sign extended to FFC3?

    When I'm defining constants in hexadecimal, if I want them sign
    extended, I write them that way. If a 16-bit constant whose low
    eight bits are C0 is supposed to be negative, I write $FFC0.
    I have yet to see an assembler that doesn't expect that.

    Eric
  18. Archived from groups: rec.games.vectrex (More info?)

    Eric wrote:

    >Why on earth should the assembler *ever* assume that a hex literal like
    >$A0 is a negative value?

    That's not what he mean't. Specifically, he said "signed or unsigned"
    - as in two's compliment. You must have missed it somehow in your vast
    experience... It's SOP on the 6809, you might want to read up on it.

    >Should this hypothetical assembler give a warning about a possible
    >conversion error for "LDX #$F00"?

    Yes, it should give a warning.

    I don't want an assembler assuming *anything*. At the very least an
    assembler should warn me of ambiguity and tell me it's made an
    assumption.

    This kind of thinking leads to assemblers which assemble:

    "lda $A0" and "lda $00A0" the same (ie: assuming that they are both
    intended to be Direct instead of Extended for the later.)

    I wrote:

    > This is an unspeakably horrible, sloppy coding practice that will
    > eventually come back to haunt you.

    Eric replied:

    >No, it isn't.

    Hey, whatever, you do it however you want. Just one question though,
    "Mr. 29 years" - If you're such an expert, howcome you never actually
    helped Robert debug his code and only chimed in to pick nits and start
    a fight?


    Chris...
  19. Archived from groups: rec.games.vectrex (More info?)

    I wrote:
    >> Why on earth should the assembler *ever* assume that a hex literal like
    >> $A0 is a negative value?

    Christopher wrote:
    > That's not what he mean't. Specifically, he said "signed or unsigned"
    > - as in two's compliment. You must have missed it somehow in your vast
    > experience... It's SOP on the 6809, you might want to read up on it.

    I fully understand two's complement.

    In 16-bit two's complement notation, the constant $A000 is negative.
    The constants $A00, $A0, and $A are positive. There is no reason
    for the assembler to assume otherwise.

    >>Should this hypothetical assembler give a warning about a possible
    >>conversion error for "LDX #$F00"?
    >
    > Yes, it should give a warning.

    Should there be a warning for LDX #$30? If so, the two's complement
    argument is a red herring, because $30 would NEVER sign extend as a
    negative value.

    What about LDAA #$3? Should there be a warning for that? If not, why?

    > This kind of thinking leads to assemblers which assemble:
    >
    > "lda $A0" and "lda $00A0" the same (ie: assuming that they are both
    > intended to be Direct instead of Extended for the later.)

    All 6809 assemblers I've ever used do assemble both of those to the
    same object code, using direct addressing, provided that you've indicated
    to the assembler that the run-time value of the direct page register
    will be zero. (Many assemblers assume that as a default unless otherwise
    directed.) If you tell the assembler that DP will be $37 at run time,
    both get assembled as extended.

    I don't consider that a bug. There is assembler syntax to force the use
    of extended addressing when the assembler otherwise has reason to
    believe that direct would be sufficient.

    > Hey, whatever, you do it however you want. Just one question though,
    > "Mr. 29 years" - If you're such an expert, howcome you never actually
    > helped Robert debug his code and only chimed in to pick nits and start
    > a fight?

    1. I don't think it's a nit. It's important for people to know how
    tools work.

    2. I thought it would be useful for people to know how real assemblers
    work, as opposed to how people think they'd like hypothetical
    assemblers to work.

    3. I thought it would be possible to explain that quickly, and didn't
    think it would be controversial. While debugging someone else's
    code is something tedious that I usually only do if they're paying
    me, or if they're a friend. That said, if I'd looked over the code
    and noticed an obvious problem, I would have pointed it out. But
    I didn't even see that part of the thread.

    If someone can cite an example of an existing assembler that works as
    you propose, then I'll be willing to concede that maybe it's not a
    fringe concept after all, though I still probably won't want to switch
    to that assembler.

    Looking back at the original request, I see no reason why Robert's
    use of LDX #$A0 should cause any problem if his data is at $00A0,
    unless the DP register has nonzero contents.

    Eric
Ask a new question

Read More

Console Gaming Programming Games Video Games