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

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

Code or SWI to read word of logical memory?

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

Contents

  Code or SWI to read word of logical memory? "neil f" <news@anf.nildram.co.uk> - 2011-05-27 09:34 +0100
    Re: Code or SWI to read word of logical memory? Theo Markettos <theom+news@chiark.greenend.org.uk> - 2011-05-27 11:42 +0100
      Re: Code or SWI to read word of logical memory? "neil f" <news@anf.nildram.co.uk> - 2011-05-27 13:29 +0100
        Re: Code or SWI to read word of logical memory? "neil f" <news@anf.nildram.co.uk> - 2011-05-27 13:47 +0100
          Re: Code or SWI to read word of logical memory? "neil f" <news@anf.nildram.co.uk> - 2011-05-27 14:36 +0100
            Re: Code or SWI to read word of logical memory? Theo Markettos <theom+news@chiark.greenend.org.uk> - 2011-05-28 00:20 +0100
              Re: Code or SWI to read word of logical memory? "neil f" <news@anf.nildram.co.uk> - 2011-05-29 21:31 +0100
                Re: Code or SWI to read word of logical memory? Theo Markettos <theom+news@chiark.greenend.org.uk> - 2011-05-29 23:40 +0100
              Re: Code or SWI to read word of logical memory? Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2011-06-01 02:07 +0100
                Re: Code or SWI to read word of logical memory? Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-06-01 04:24 +0200
            Re: Code or SWI to read word of logical memory? Tank <webmaster@tankstage.co.uk> - 2011-05-28 06:54 +0100
              Re: Code or SWI to read word of logical memory? "neil f" <news@anf.nildram.co.uk> - 2011-05-28 22:36 +0100
                Re: Code or SWI to read word of logical memory? Tank <webmaster@tankstage.co.uk> - 2011-05-29 08:38 +0100

#350 — Code or SWI to read word of logical memory?

I need to read and write a word or two of memory during execution of a 
program. Is it possible to do this via a snippet of assembler from Basic? 
Alternatively, is there a SWI that I can call when necessary for the 
read/write operation? I've mapped in the memory locations I'm interested in 
using OS_Memory 13, so I can supply a logical address to a routine.

All needs to be 32-bit compliant of course.

[toc] | [next] | [standalone]

#351

neil f <news@anf.nildram.co.uk> wrote:
> I need to read and write a word or two of memory during execution of a 
> program. Is it possible to do this via a snippet of assembler from Basic? 
> Alternatively, is there a SWI that I can call when necessary for the 
> read/write operation? I've mapped in the memory locations I'm interested in 
> using OS_Memory 13, so I can supply a logical address to a routine.

Do you mean physical memory?

Logical memory = what the programmer sees (aka virtual memory on systems
with page files)
Physical memory = how the memory chips are actually connected

If you really mean logical memory, you can either just read it normally
(PRINT !address%) or else drop into supervisor mode to access memory that
user mode doesn't have read permissions for (see OS_EnterOS).

Note that on RISC OS applications share logical address space (they all
think they start at &8000) so you have to be sure that the right application
is paged in.

Theo

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

#352

"Theo Markettos" <theom+news@chiark.greenend.org.uk> wrote in message 
news:8Oh*fa+Dt@news.chiark.greenend.org.uk...
> neil f <news@anf.nildram.co.uk> wrote:
>> I need to read and write a word or two of memory during execution of a
>> program. Is it possible to do this via a snippet of assembler from Basic?
>> Alternatively, is there a SWI that I can call when necessary for the
>> read/write operation? I've mapped in the memory locations I'm interested 
>> in
>> using OS_Memory 13, so I can supply a logical address to a routine.
>
> Do you mean physical memory?
>
> Logical memory = what the programmer sees (aka virtual memory on systems
> with page files)
> Physical memory = how the memory chips are actually connected
>
> If you really mean logical memory, you can either just read it normally
> (PRINT !address%) or else drop into supervisor mode to access memory that
> user mode doesn't have read permissions for (see OS_EnterOS).
>
> Note that on RISC OS applications share logical address space (they all
> think they start at &8000) so you have to be sure that the right 
> application
> is paged in.
>
> Theo

Hi Theo. I'm messing around with a Beagle XM. I started out looking at just 
GPIO access but after a few days absorbing the TRM etc I'm finding all sorts 
of memory mapped registers I'd like prod and play with.

Peter xxx and Tank have been knocking up some useful module code, but it's 
limited to specific register ranges and all very well behaved. It won't let 
me stray 'off piste', which is what I'd like to do to really get to know 
what the various interfaces can provide. All I need for that is to map in 
some physical address ranges to logical ones (which OS_Memory 13 seems to be 
designed for) and then have a read routine and a write routine that can 
access any register in the mapped in range.

So I'd like to map register X physical to logical address, then supply that 
logical address to a read or write routine to monitor and manipulate various 
XM I/O processes.

I've got as far as mapping physical registers to logical addresses, which 
seems to work fine. But any moves to read from those addresses just produce 
data aborts at the moment. Even just using plain SYS"OS_EnterOS" followed 
straight away with SYS"OS_LeaveOS" gives a data abort. I would have thought 
that was practically a NOP but it still throws up an error.

-Neil. 

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

#353

"neil f" <news@anf.nildram.co.uk> wrote in message 
news:iro5et$3t2$1@speranza.aioe.org...
>
> "Theo Markettos" <theom+news@chiark.greenend.org.uk> wrote in message 
> news:8Oh*fa+Dt@news.chiark.greenend.org.uk...
>> neil f <news@anf.nildram.co.uk> wrote:
>>> I need to read and write a word or two of memory during execution of a
>>> program. Is it possible to do this via a snippet of assembler from 
>>> Basic?
>>> Alternatively, is there a SWI that I can call when necessary for the
>>> read/write operation? I've mapped in the memory locations I'm interested 
>>> in
>>> using OS_Memory 13, so I can supply a logical address to a routine.
>>
>> Do you mean physical memory?
>>
>> Logical memory = what the programmer sees (aka virtual memory on systems
>> with page files)
>> Physical memory = how the memory chips are actually connected
>>
>> If you really mean logical memory, you can either just read it normally
>> (PRINT !address%) or else drop into supervisor mode to access memory that
>> user mode doesn't have read permissions for (see OS_EnterOS).
>>
>> Note that on RISC OS applications share logical address space (they all
>> think they start at &8000) so you have to be sure that the right 
>> application
>> is paged in.
>>
>> Theo
>
> Hi Theo. I'm messing around with a Beagle XM. I started out looking at 
> just GPIO access but after a few days absorbing the TRM etc I'm finding 
> all sorts of memory mapped registers I'd like prod and play with.
>
> Peter xxx and Tank have been knocking up some useful module code, but it's 
> limited to specific register ranges and all very well behaved. It won't 
> let me stray 'off piste', which is what I'd like to do to really get to 
> know what the various interfaces can provide. All I need for that is to 
> map in some physical address ranges to logical ones (which OS_Memory 13 
> seems to be designed for) and then have a read routine and a write routine 
> that can access any register in the mapped in range.
>
> So I'd like to map register X physical to logical address, then supply 
> that logical address to a read or write routine to monitor and manipulate 
> various XM I/O processes.
>
> I've got as far as mapping physical registers to logical addresses, which 
> seems to work fine. But any moves to read from those addresses just 
> produce data aborts at the moment. Even just using plain SYS"OS_EnterOS" 
> followed straight away with SYS"OS_LeaveOS" gives a data abort. I would 
> have thought that was practically a NOP but it still throws up an error.
>
> -Neil.

Sorry, I meant SWI "OS_EnterOS" in the above of course.

E.g the following gives a data abort when run:

DIM code% 100
FOR pass%=0 TO 3 STEP 3
P%=code%
[
OPT pass%
SWI "OS_EnterOS"
SWI "OS_LeaveOS"
]
NEXT pass%
CALL code%

Shouldn't it just do nothing?

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

#354

"neil f" <news@anf.nildram.co.uk> wrote in message 
news:iro6gm$6s0$1@speranza.aioe.org...
>
> "neil f" <news@anf.nildram.co.uk> wrote in message 
> news:iro5et$3t2$1@speranza.aioe.org...
>>
>> "Theo Markettos" <theom+news@chiark.greenend.org.uk> wrote in message 
>> news:8Oh*fa+Dt@news.chiark.greenend.org.uk...
>>> neil f <news@anf.nildram.co.uk> wrote:
>>>> I need to read and write a word or two of memory during execution of a
>>>> program. Is it possible to do this via a snippet of assembler from 
>>>> Basic?
>>>> Alternatively, is there a SWI that I can call when necessary for the
>>>> read/write operation? I've mapped in the memory locations I'm 
>>>> interested in
>>>> using OS_Memory 13, so I can supply a logical address to a routine.
>>>
>>> Do you mean physical memory?
>>>
>>> Logical memory = what the programmer sees (aka virtual memory on systems
>>> with page files)
>>> Physical memory = how the memory chips are actually connected
>>>
>>> If you really mean logical memory, you can either just read it normally
>>> (PRINT !address%) or else drop into supervisor mode to access memory 
>>> that
>>> user mode doesn't have read permissions for (see OS_EnterOS).
>>>
>>> Note that on RISC OS applications share logical address space (they all
>>> think they start at &8000) so you have to be sure that the right 
>>> application
>>> is paged in.
>>>
>>> Theo
>>
>> Hi Theo. I'm messing around with a Beagle XM. I started out looking at 
>> just GPIO access but after a few days absorbing the TRM etc I'm finding 
>> all sorts of memory mapped registers I'd like prod and play with.
>>
>> Peter xxx and Tank have been knocking up some useful module code, but 
>> it's limited to specific register ranges and all very well behaved. It 
>> won't let me stray 'off piste', which is what I'd like to do to really 
>> get to know what the various interfaces can provide. All I need for that 
>> is to map in some physical address ranges to logical ones (which 
>> OS_Memory 13 seems to be designed for) and then have a read routine and a 
>> write routine that can access any register in the mapped in range.
>>
>> So I'd like to map register X physical to logical address, then supply 
>> that logical address to a read or write routine to monitor and manipulate 
>> various XM I/O processes.
>>
>> I've got as far as mapping physical registers to logical addresses, which 
>> seems to work fine. But any moves to read from those addresses just 
>> produce data aborts at the moment. Even just using plain SYS"OS_EnterOS" 
>> followed straight away with SYS"OS_LeaveOS" gives a data abort. I would 
>> have thought that was practically a NOP but it still throws up an error.
>>
>> -Neil.
>
> Sorry, I meant SWI "OS_EnterOS" in the above of course.
>
> E.g the following gives a data abort when run:
>
> DIM code% 100
> FOR pass%=0 TO 3 STEP 3
> P%=code%
> [
> OPT pass%
> SWI "OS_EnterOS"
> SWI "OS_LeaveOS"
> ]
> NEXT pass%
> CALL code%
>
> Shouldn't it just do nothing?
>
Whoops. Just noticed I'd left the MOV PC, R14 off the end. Now it does what 
I'd expect - i.e. nothing.

Peter van der Vos kindly wrote and posted a very simple memory access module 
in response to my request for GPIO access routines on the ROOL forum. 
Unfortunately that module doesn't allow wide-ranging access of the kind I 
need now, so I thought I'd try to write something simple myself.

Now all I need to do is work out what to put between those two SWIs :-) 

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

#357

neil f <news@anf.nildram.co.uk> wrote:
> Whoops. Just noticed I'd left the MOV PC, R14 off the end. Now it does what 
> I'd expect - i.e. nothing.
> 
> Peter van der Vos kindly wrote and posted a very simple memory access
> module in response to my request for GPIO access routines on the ROOL
> forum.  Unfortunately that module doesn't allow wide-ranging access of the
> kind I need now, so I thought I'd try to write something simple myself.

You can write a very simple module like this yourself.  Just have a
barebones module with a few SWIs.  I once wrote a module called SVCUtils
with the following SWIs:

SVC_LDR
SVC_LDRB
SVC_STR
SVC_STRB

Each SWI handler just calls the appropriate instruction then returns, eg:
.SVC_STR
STR r0,[r1]
MOV pc,r14

Then you can call it thus:
SYS "SVC_STR",&45,&03010FE0
equivalent to !&03010FE0=&45

It isn't 32 bit and I don't have the source to hand, but it shouldn't take
long to write something similar, or modify Peter's version.

Theo

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

#365

"Theo Markettos" <theom+news@chiark.greenend.org.uk> wrote in message 
news:8Oh*WXaEt@news.chiark.greenend.org.uk...
> neil f <news@anf.nildram.co.uk> wrote:
>> Whoops. Just noticed I'd left the MOV PC, R14 off the end. Now it does 
>> what
>> I'd expect - i.e. nothing.
>>
>> Peter van der Vos kindly wrote and posted a very simple memory access
>> module in response to my request for GPIO access routines on the ROOL
>> forum.  Unfortunately that module doesn't allow wide-ranging access of 
>> the
>> kind I need now, so I thought I'd try to write something simple myself.
>
> You can write a very simple module like this yourself.  Just have a
> barebones module with a few SWIs.  I once wrote a module called SVCUtils
> with the following SWIs:
>
> SVC_LDR
> SVC_LDRB
> SVC_STR
> SVC_STRB
>
> Each SWI handler just calls the appropriate instruction then returns, eg:
> .SVC_STR
> STR r0,[r1]
> MOV pc,r14
>
> Then you can call it thus:
> SYS "SVC_STR",&45,&03010FE0
> equivalent to !&03010FE0=&45
>
> It isn't 32 bit and I don't have the source to hand, but it shouldn't take
> long to write something similar, or modify Peter's version.
>
> Theo

I downloaded SVCUtils module from your website, Theo, and it seems to run OK 
on the XM. I've loaded and saved a few sample GPIO registers without 
problems showing up. Are you sure it isn't 32-bit compatible? It seems to 
have the 32-bit flags word present. 

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

#366

neil f <news@anf.nildram.co.uk> wrote:
> I downloaded SVCUtils module from your website, Theo, and it seems to run
> OK on the XM. I've loaded and saved a few sample GPIO registers without
> problems showing up. Are you sure it isn't 32-bit compatible? It seems to
> have the 32-bit flags word present.

Umm... OK!  I'd completely forgotten it was ever on my website let alone
that I'd 32 bitted it (not that it does anything remotely clever that might
make a 26/32 difference).  Looks like I did it when the Iyonix came out -
which must have been keen as I've never actually seen one.

Ah well, glad it was useful :)

Theo

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

#383

Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:

> Then you can call it thus:
> SYS "SVC_STR",&45,&03010FE0
> equivalent to !&03010FE0=&45

What then is the point of using the SYS call?

-- 
Jeremy C B Nicoll - my opinions are my own.

Email sent to my from-address will be deleted. Instead, please reply
to newsreplyaaa@wingsandbeaks.org.uk replacing "aaa" by "284".  

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

#384

On 01/06/2011 03:07, Jeremy Nicoll - news posts wrote:

>> Then you can call it thus:
>> SYS "SVC_STR",&45,&03010FE0
>> equivalent to !&03010FE0=&45
> What then is the point of using the SYS call?

I'd imagine it sticks you in SVC mode so you can read/write bits of 
memory where BASIC would normally choke (due to being in USR mode).


Best wishes,

Rick.

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

#359

In message <iro9d1$eio$1@speranza.aioe.org>
          "neil f" <news@anf.nildram.co.uk> wrote:



> Peter van der Vos kindly wrote and posted a very simple memory access module
> in response to my request for GPIO access routines on the ROOL forum.
> Unfortunately that module doesn't allow wide-ranging access of the kind I
> need now, so I thought I'd try to write something simple myself.

> Now all I need to do is work out what to put between those two SWIs :-)

Neil,
Is there a specific set of registers you need to access ?
The hybrid Peter/Tank module lets you access all the control registers 
in the physical range 0x48002030-0x48002264 and 0x480025A0-0x480025A0 
and if the IO pin you need to access doesn't have a GPIO in mode 4, I 
can add them to the "safe" range for you. I have added all the pins 
that go to the Expansion and the Auxiliary connectors, so the pin you 
are trying to access will have no "exit" from the board, unless you 
wish to use the LCD connector outputs as well!!
Tank


-- 
webmaster@tankstage.co.uk   Iyonix PC

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

#360

"Tank" <webmaster@tankstage.co.uk> wrote in message 
news:f1df50da51.tank@tankstage.co.uk...
> In message <iro9d1$eio$1@speranza.aioe.org>
>          "neil f" <news@anf.nildram.co.uk> wrote:
>
>
>
>> Peter van der Vos kindly wrote and posted a very simple memory access 
>> module
>> in response to my request for GPIO access routines on the ROOL forum.
>> Unfortunately that module doesn't allow wide-ranging access of the kind I
>> need now, so I thought I'd try to write something simple myself.
>
>> Now all I need to do is work out what to put between those two SWIs :-)
>
> Neil,
> Is there a specific set of registers you need to access ?
> The hybrid Peter/Tank module lets you access all the control registers
> in the physical range 0x48002030-0x48002264 and 0x480025A0-0x480025A0
> and if the IO pin you need to access doesn't have a GPIO in mode 4, I
> can add them to the "safe" range for you. I have added all the pins
> that go to the Expansion and the Auxiliary connectors, so the pin you
> are trying to access will have no "exit" from the board, unless you
> wish to use the LCD connector outputs as well!!
> Tank

Hi Tank. It would be good to be able to experiment with the level, edge and 
debounce registers, for example.

And the GPIO lines on the LCD ports are probably of more interest to 
computer control enthusiasts than the Aux interface. Between them the two 
LCD interfaces offer enough lines for a couple of clean 8-bit I/O ports, 
with little likelihood of contention with other signals. And if you're going 
to go to the trouble of dealing with those micro-sized aux socket pins, you 
might as well wrestle with the LCD pins instead and get twice the outputs 
for your effort.

Actually, in my case I'll probably wrestle with them all as I fancy seeing 
eight separate 8-bit I/O ports all running gadgets at once!

So would I like you to include the LCD registers - the answer is yes please 
;-)

BTW, on reading through the GPIO module source I notice that the Expansion 
pin table (table 1) is missing GPIO 157. Don't know whether that's important 
or not, but GPIO 157 is available on pin 22 of the main expansion connector. 

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

#361

In message <irrpsg$mp9$1@speranza.aioe.org>
          "neil f" <news@anf.nildram.co.uk> wrote:


> Hi Tank. It would be good to be able to experiment with the level, edge and
> debounce registers, for example.

You know these are only relevant to control the generation of an 
interrupt signal ?
To mess with these, you will need to set up an interrupt handler.
I can help here, as when I was messing with the ethernet interface on 
the Devkit, I setup an interrupt handler then, as it uses a GPIO line 
as an interrupt.

> And the GPIO lines on the LCD ports are probably of more interest to
> computer control enthusiasts than the Aux interface. Between them the two
> LCD interfaces offer enough lines for a couple of clean 8-bit I/O ports,
> with little likelihood of contention with other signals. And if you're going
> to go to the trouble of dealing with those micro-sized aux socket pins, you
> might as well wrestle with the LCD pins instead and get twice the outputs
> for your effort.

Don't forget the Camera port !!


> BTW, on reading through the GPIO module source I notice that the Expansion
> pin table (table 1) is missing GPIO 157. Don't know whether that's important
> or not, but GPIO 157 is available on pin 22 of the main expansion connector.

If it was missing in the earlier versions, its not in the later/latest 
ones...


-- 
webmaster@tankstage.co.uk   Iyonix PC

[toc] | [prev] | [standalone]

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

csiph-web