Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1849 > unrolled thread

Assembler Help. (AKA UMoria Video refresh loop.)

Started byGazza <usenet@garethlock.com>
First post2012-06-29 06:44 -0700
Last post2012-06-30 04:21 -0700
Articles 6 on this page of 26 — 8 participants

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Assembler Help. (AKA UMoria Video refresh loop.) Gazza <usenet@garethlock.com> - 2012-06-29 06:44 -0700
    Re: Assembler Help. (AKA UMoria Video refresh loop.) Gazza <usenet@garethlock.com> - 2012-06-29 13:52 -0700
      Re: Assembler Help. (AKA UMoria Video refresh loop.) chrisbazley@bigfoot.com - 2012-06-30 03:01 -0700
        Re: Assembler Help. (AKA UMoria Video refresh loop.) druck <news@druck.org.uk> - 2012-06-30 21:31 +0100
          Re: Assembler Help. (AKA UMoria Video refresh loop.) Gazza <usenet@garethlock.com> - 2012-07-01 04:02 -0700
          Re: Assembler Help. (AKA UMoria Video refresh loop.) Gazza <usenet@garethlock.com> - 2012-07-01 04:01 -0700
          Re: Assembler Help. (AKA UMoria Video refresh loop.) Gazza <usenet@garethlock.com> - 2012-07-01 04:15 -0700
            Re: Assembler Help. (AKA UMoria Video refresh loop.) druck <news@druck.org.uk> - 2012-07-01 19:59 +0100
              Re: Assembler Help. (AKA UMoria Video refresh loop.) Gazza <usenet@garethlock.com> - 2012-07-01 14:43 -0700
                Re: Assembler Help. (AKA UMoria Video refresh loop.) druck <news@druck.org.uk> - 2012-07-03 20:57 +0100
                  Re: Assembler Help. (AKA UMoria Video refresh loop.) Gazza <usenet@garethlock.com> - 2012-07-03 16:20 -0700
                    Re: Assembler Help. (AKA UMoria Video refresh loop.) Gazza <usenet@garethlock.com> - 2012-07-04 05:36 -0700
                      Re: Assembler Help. (AKA UMoria Video refresh loop.) Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-07-04 13:49 +0100
                        Re: Assembler Help. (AKA UMoria Video refresh loop.) Gazza <usenet@garethlock.com> - 2012-07-04 09:10 -0700
                          Re: Assembler Help. (AKA UMoria Video refresh loop.) Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-07-04 17:28 +0100
                            Re: Assembler Help. (AKA UMoria Video refresh loop.) Gazza <usenet@garethlock.com> - 2012-07-04 11:18 -0700
                              Re: Assembler Help. (AKA UMoria Video refresh loop.) druck <news@druck.org.uk> - 2012-07-04 20:03 +0100
        Re: Assembler Help. (AKA UMoria Video refresh loop.) Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-07-04 19:33 +0100
          Re: Assembler Help. (AKA UMoria Video refresh loop.) Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-07-05 18:41 +0100
            Re: Assembler Help. (AKA UMoria Video refresh loop.) Gazza <usenet@garethlock.com> - 2012-07-06 09:40 -0700
              Re: Assembler Help. (AKA UMoria Video refresh loop.) Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-07-06 18:13 +0100
                Re: Assembler Help. (AKA UMoria Video refresh loop.) Gazza <usenet@garethlock.com> - 2012-07-06 10:49 -0700
                  Re: Assembler Help. (AKA UMoria Video refresh loop.) Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-07-06 23:29 +0100
                    Re: Assembler Help. (AKA UMoria Video refresh loop.) Gazza <usenet@garethlock.com> - 2012-07-06 15:46 -0700
              Re: Assembler Help. (AKA UMoria Video refresh loop.) Fred Graute <fjgraute@casema.nl> - 2012-07-07 03:07 +0300
      Re: Assembler Help. (AKA UMoria Video refresh loop.) chrisbazley@bigfoot.com - 2012-06-30 04:21 -0700

Page 2 of 2 — ← Prev page 1 [2]

#1890

FromMartin Bazley <martin.bazley@blueyonder.co.uk>
Date2012-07-06 18:13 +0100
Message-ID<f89820ab52.martin@blueyonder.co.uk>
In reply to#1889
The following bytes were arranged on 6 Jul 2012 by Gazza :

> 1.  Still trying to position the stack allocation beyond the end of
> the initialized data at the end of the image. I've calculated the
> correct address at stackptr, but all I seem to be able to to is load
> R13 with the pointer's memory address, rather than the contents of
> that address. This is frustrating.

Without looking...

Is:

LDR R13,[pointer%]
LDR R13,[R13]

not enough for you?

-- 
  __<^>__
 / _   _ \           It is written that Geeks shall inherit the Earth.
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

[toc] | [prev] | [next] | [standalone]

#1891

FromGazza <usenet@garethlock.com>
Date2012-07-06 10:49 -0700
Message-ID<962adeb7-ccd6-44c2-9f23-c384094fb8af@8g2000vbu.googlegroups.com>
In reply to#1890
On Jul 6, 6:13 pm, Martin Bazley <martin.baz...@blueyonder.co.uk>
wrote:
> Without looking...
>
> Is:
>
> LDR R13,[pointer%]
> LDR R13,[R13]
>
> not enough for you?
>

Been trying...

.stackptr

EQUD (stacktop+stacksz%)
LDR R13,stackptr

... Loads the address contained in the variable stackptr which is not
what I want. I must admit I haven't tried loading the pointer to R13
and then loading the contents of that address into R13, so that might
be what I'm missing.

Trying...

LDR R13, #(stacktop+stacksz%)

... gives me "Unknown variable" when trying to assemble...

Trying...

LDR R13,stack

... which is a pointer to the location stacktop+stacksz% gives me "Bad
immediate constant" when trying to assemble.


Will give that double load method a go sometime over the weekend.

[toc] | [prev] | [next] | [standalone]

#1892

FromMartin Bazley <martin.bazley@blueyonder.co.uk>
Date2012-07-06 23:29 +0100
Message-ID<098d3dab52.martin@blueyonder.co.uk>
In reply to#1891
The following bytes were arranged on 6 Jul 2012 by Gazza :

> .stackptr
>
> EQUD (stacktop+stacksz%)
> LDR R13,stackptr
>
> ... Loads the address contained in the variable stackptr which is not
> what I want.

Are you absolutely sure you're using LDR and not ADR?  This behaviour is
consistent with ADR.

-- 
  __<^>__
 / _   _ \         You always find something in the last place you look.
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

[toc] | [prev] | [next] | [standalone]

#1893

FromGazza <usenet@garethlock.com>
Date2012-07-06 15:46 -0700
Message-ID<a7580757-090b-46b0-aecb-dcb140931fb4@q2g2000vbv.googlegroups.com>
In reply to#1892
On Jul 6, 11:29 pm, Martin Bazley <martin.baz...@blueyonder.co.uk>
wrote:
> Are you absolutely sure you're using LDR and not ADR?  This behaviour is
> consistent with ADR.
>
See for yourself... check the label "entry" on line 600.

http://www.garethlock.com/DemoASM/06-07-12/06-07-12.txt

[toc] | [prev] | [next] | [standalone]

#1894

FromFred Graute <fjgraute@casema.nl>
Date2012-07-07 03:07 +0300
Message-ID<b17f46ab52.fjgraute@casema.nl>
In reply to#1889
In message <4dc35184-4321-4614-9483-e4b6dddd6fbe@q2g2000vbv.googlegroups.com>
          Gazza <usenet@garethlock.com> wrote:

> Current listing is http://www.garethlock.com/DemoASM/06-07-12/06-07-12.txt
>
> 1.  Still trying to position the stack allocation beyond the end of
> the initialized data at the end of the image. I've calculated the
> correct address at stackptr, but all I seem to be able to to is load
> R13 with the pointer's memory address, rather than the contents of
> that address. This is frustrating.

Are you sure you are interpreting the disassembly correctly?

  LDR   R13,&00008090

Means load the value at address &00008090 (which is &000090F4) into R13,
it does not mean load the value &00008090 into R13.

> 2.  Creating a Disassembly listing using Zap in code mode hasn't got
> me much further in diagnosing where the object code is faulting. That
> listing is http://www.garethlock.com/DemoASM/06-07-12/DisASM.txt

Tip: you can 'follow' pc-relative loads in disassembly mode by placing
the cursor on the line and pressing cursor right. This will take you to
the address from which the value is loaded, use cursor left to return to
the original address. This works with both Zap and StrongED.

HTH

-- 
Fred Graute
http://www.stronged.iconbar.com/

[toc] | [prev] | [next] | [standalone]

#1854

Fromchrisbazley@bigfoot.com
Date2012-06-30 04:21 -0700
Message-ID<ba491512-7694-4814-8540-3d65a763bcf5@googlegroups.com>
In reply to#1852
On Friday, June 29, 2012 9:52:00 PM UTC+1, Gazza wrote:
> Just finished writing this...
> 
> http://www.garethlock.com/DemoASM.txt
> 
> 1. It bricks the machine. Don't know why this is yet. Had to use the
> Reset button to get out!

Some things I forgot to mention:

Absolute files are loaded into memory at &8000, so you need to tell the assembler to assemble code suitable for execution at that address. If I recall correctly, the magic integer variable O% should be set to the target address at the head of your loop. You might get away with this if there are no absolute addresses (e.g. EQUD label%) in your code, but it is very dangerous.

I suspect your program is crashing because it tries to return (where?) by moving the link register value into the program counter. I'm 99% sure it should call SWI OS_Exit instead.

It looks daft to check whether the assembler overran the end of your allocated buffer (possibly crashing the BASIC interpreter or corrupting unknown data) after the event, especially as you are checking against the wrong limit. Presumably you don't want code in the memory that you reserved for the screens? You should set the assembly limit L%. See http://www.heyrick.co.uk/armwiki/BBC_BASIC_assembler#OPT

All of the above is off the top of my head, but presumably if you wanted authoritative answers, you'd consult published documentation instead of Usenet, right? ;-)

Chris Bazley

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web