Vectrex programming question/help. JSR wont work?

  • Thread starter Thread starter Guest
  • Start date Start date
Toggle sidebar Toggle sidebar
G

Guest

Guest
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!
 
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!
 
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!
 
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
 
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!
 
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?
 
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! :>
 
Archived from groups: rec.games.vectrex (More info?)

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





Richard H.
 
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?
 
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...
 
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.
 
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...
 
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...
 
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
 
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...
 
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.
 
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
 
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
 
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...
 
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
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom