From Newsgroup: comp.sys.acorn.programmer

On 15 Nov, Alexander Ausserstorfer wrote in message
<5c7c29dce9bavariasound@chiemgau-net.de>:

And if I use the GCC to convert the command MOV PC, R14 to machine code,
the result is not a file type of Absolute but of ELF and it has a file
size of huge blowy shit! 784 bytes for just ONE command! I don't
understand that.

Because an ELF file isn't just the code itself: it's a structured file that
can contain more data. So somewhere in there will be the 4 bytes of the MOV command, plus a header to tell the ELF loader where in memory to put that command when it loads the file. And other infrastructure needed to allow the file to do things like initialise separate blocks of memory, or load other chunks of assembled commands, linkable blocks like libraries, and so on.

We moved on from doing *Save and *Load many years ago, because it's not that flexible and forces too many assumptions about the file contents to be made.

See https://en.wikipedia.org/wiki/Executable_and_Linkable_Format for
details.
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

Steve Fryatt <news@stevefryatt.org.uk> wrote:

On 15 Nov, Alexander Ausserstorfer wrote in message
<5c7c29dce9bavariasound@chiemgau-net.de>:

And if I use the GCC to convert the command MOV PC, R14 to machine code, the result is not a file type of Absolute but of ELF and it has a file
size of huge blowy shit! 784 bytes for just ONE command! I don't
understand that.

Because an ELF file isn't just the code itself: it's a structured file that can contain more data. So somewhere in there will be the 4 bytes of the MOV command, plus a header to tell the ELF loader where in memory to put that command when it loads the file. And other infrastructure needed to allow the file to do things like initialise separate blocks of memory, or load other chunks of assembled commands, linkable blocks like libraries, and so on.

We moved on from doing *Save and *Load many years ago, because it's not that flexible and forces too many assumptions about the file contents to be made.

See https://en.wikipedia.org/wiki/Executable_and_Linkable_Format for
details.

And the Absolute file generated by Acorn/ROOL's ObjAsm is an older format
for the same idea - it's Acorn Image Format or AIF. AIF was something Acorn came up with in the 1980s, while ELF is a cross platform format devised
in 1990s.

This is a description of the format from 1993: https://www.chiark.greenend.org.uk/~theom/riscos/docs/CodeStds/AIF-1993.txt

but it's undergone many changes since then (notably for 32-bit support).
The latest version is included with the ROOL DDE tools.

Theo
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

On 15/11/2025 12:55, Alexander Ausserstorfer wrote:

Excuse me. I come from the Commodore 64 and do only know something about
the POKE and PEEK commands.

I don't understand the ! and ? commands. I found some PDFs online and
wonder because its about BBC BASIC but not for the Acorn Archimedes but
for a Z80 called Sinclair Spectrum and another for a Z88 system. So BBC
BASIC doesn't belong to RISC OS only?

? belongs to a byte ! belongs to a word.

With !(&9000) you can write into memory. But with the same command you
can read it!

I never have seen that before.

The '?' and '!' are not commands, but operators. They change the meaning
of the following constant or variable to mean the byte or word at this address.

e.g.

!&9000 means the contents of the 4 bytes at address &9000, you can
either read from it, or write to it.

The same with variables, if B%=&1234

?B%=99 set the value the byte at address &1234 to 99

There is also a syntax to write to bytes or words offset from the
address using a constant or another variable.

B%?1 the byte at location &1235
B%!4 the word at location &1238

It's all in the BBC BASIC manual

---druck
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <mpro.t5skpi00iwsze149i.news@stevefryatt.org.uk>,
Steve Fryatt <news@stevefryatt.org.uk> wrote:

On 15 Nov, Alexander Ausserstorfer wrote in message
<5c7c29dce9bavariasound@chiemgau-net.de>:

And if I use the GCC to convert the command MOV PC, R14 to machine
code, the result is not a file type of Absolute but of ELF and it has
a file size of huge blowy shit! 784 bytes for just ONE command! I
don't understand that.

Because an ELF file isn't just the code itself: it's a structured file
that can contain more data. So somewhere in there will be the 4 bytes
of the MOV command, plus a header to tell the ELF loader where in
memory to put that command when it loads the file. And other
infrastructure needed to allow the file to do things like initialise
separate blocks of memory, or load other chunks of assembled commands, linkable blocks like libraries, and so on.

We moved on from doing *Save and *Load many years ago, because it's
not that flexible and forces too many assumptions about the file
contents to be made.

My idea was (or is) that an Assembler just converts the source code with mnemonics 1 : 1 into machine code - and nothing else! If you have a need
for additional data and structures, you should be able to add it to your
source code by your own.

It shouldn't be added automatically by the Assembler because this is a
bit of spoon-feeding (the German word here would be 'Bevormundung', I
don't know the correct English expression). You are hide here something
from the programmer. This is not a good way to learn! He should be able
to know what he's doing!

Unix, ugh!

A.
--
http://home.chiemgau-net.de/ausserstorfer/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <050c4e7c5c.harriet@bazleyfamily.co.uk>,
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

[part snipped]

So
[OPT pass%
FNmessage("Harriet")
MOV R15, R14 ;exit routine
]

will generate a scrap of code that simply prints the string "Harriet".

Thank you! However, you can do this much easier. Just write the hex
values

01 00 00 EF 48 61 72 72 69 65 74 00 0E F0 A0 E1

into the memory and run it. It does the same as your example programme.

If you want to have it word aligned type

EF000001 72726148 00746569 E1A0F0E0

This is the representation in the dump mode of !StrongED, for example.

The most significant byte of a word is always on the left! That's may be
the point here.

A.
--
http://home.chiemgau-net.de/ausserstorfer/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <5c87099f9bbavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

However, you can do this much easier. Just write the hex
values

01 00 00 EF 48 61 72 72 69 65 74 00 0E F0 A0 E1

That to my mind is MUCH harder, and would give you maintenance
nightmares, as it is impossible to read easily. The computer is MUCH
better translating plain text into hex and binary then we are.

I strongly suggest that is not the way to program these days.
It was bad enough 50 years ago, when that was the only option, but
certainly not now.
--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

On 6 Dec 2025 as I do recall,
Alexander Ausserstorfer wrote:

In article <050c4e7c5c.harriet@bazleyfamily.co.uk>,
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

[part snipped]

So
[OPT pass%
FNmessage("Harriet")
MOV R15, R14 ;exit routine
]

will generate a scrap of code that simply prints the string "Harriet".

Thank you! However, you can do this much easier. Just write the hex
values

01 00 00 EF 48 61 72 72 69 65 74 00 0E F0 A0 E1

into the memory and run it.

I don't know aboput you, but most people find assembler op codes "much
easier" than poking raw hexadecimal bytes into memory, even if not quite
so easy to read as high-level languages!

The point of that example was to demonstrate the use of the BASIC
assembler, which allows you to use features like BASIC's string
variables and functions while assembling your machine code, while still producing 'pure' machine code without the headers you were objecting to.

Unfortunately it is not at all simple to use or set up (for example the requirement to do two passes with a different options value each time),
which is why for all practical purposes I keep a file with an empty
'shell' assembly routine in it and then copy that as a starting template
any time I want to create a scrap of machine code to call from within
BASIC.
--
Harriet Bazley == Loyaulte me lie ==

Let a fool hold his tongue and he will pass for a sage.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

On 6 Dec, Alexander Ausserstorfer wrote in message
<5c870ac95abavariasound@chiemgau-net.de>:

It shouldn't be added automatically by the Assembler because this is a bit
of spoon-feeding (the German word here would be 'Bevormundung', I don't
know the correct English expression). You are hide here something from the programmer.

That's not a good thing? As a programmer, the building of code is a
repetitive, boring task that I want as automated as possible. Knowing what
is happening is useful, agreed, but doing it by hand every time is
definitely not useful!

This is not a good way to learn! He should be able to know what he's
doing!

That's a different thing, though. And just because a 1:1 relationship is
useful for learning, it doesn't follow that it's the way that development
tools should do things.

Unix, ugh!

We may have to agree to differ!
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <5c87163b82News04@avisoft.f9.co.uk>,
Martin <News04@avisoft.f9.co.uk> wrote:

In article <5c87099f9bbavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

However, you can do this much easier. Just write the hex
values

01 00 00 EF 48 61 72 72 69 65 74 00 0E F0 A0 E1

That to my mind is MUCH harder, and would give you maintenance
nightmares, as it is impossible to read easily. The computer is MUCH
better translating plain text into hex and binary then we are.

I strongly suggest that is not the way to program these days.
It was bad enough 50 years ago, when that was the only option, but
certainly not now.

I don't understand that. The values are much more clear to me. Without I couldn't understand how computers are working.

A.
--
http://home.chiemgau-net.de/ausserstorfer/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <5c87850775bavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

In article <5c87163b82News04@avisoft.f9.co.uk>,
Martin <News04@avisoft.f9.co.uk> wrote:

In article <5c87099f9bbavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

However, you can do this much easier. Just write the hex
values

01 00 00 EF 48 61 72 72 69 65 74 00 0E F0 A0 E1

That to my mind is MUCH harder, and would give you maintenance
nightmares, as it is impossible to read easily. The computer is
MUCH better translating plain text into hex and binary then we
are.

I strongly suggest that is not the way to program these days. It
was bad enough 50 years ago, when that was the only option, but
certainly not now.

I don't understand that. The values are much more clear to me.
Without I couldn't understand how computers are working.

Good luck in understanding it in a year ... or two ...or many more.
Hex code I would not even try, stopping and improvment or development.

As Steve said, we may have to agree to differ!
--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In message <5c87163b82News04@avisoft.f9.co.uk>
Martin <News04@avisoft.f9.co.uk> wrote:

In article <5c87099f9bbavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

However, you can do this much easier. Just write the hex
values

01 00 00 EF 48 61 72 72 69 65 74 00 0E F0 A0 E1

That to my mind is MUCH harder, and would give you maintenance
nightmares, as it is impossible to read easily. The computer is MUCH
better translating plain text into hex and binary then we are.

I strongly suggest that is not the way to program these days.
It was bad enough 50 years ago, when that was the only option, but
certainly not now.

50 years ago we entered codes with switches then punched cards. The
assembler was a big step forward
--
Jean-Michel
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

On 06/12/2025 15:57, Alexander Ausserstorfer wrote:

Thank you! However, you can do this much easier. Just write the hex
values

01 00 00 EF 48 61 72 72 69 65 74 00 0E F0 A0 E1

into the memory and run it. It does the same as your example programme.

I'm surprised you haven't gone for the even easier option of toggling it
in on the front panel switches, like a real programmer.

---druck
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <10h8m65$mhgq$1@druck.eternal-september.org>,
druck <news@druck.org.uk> wrote:

On 06/12/2025 15:57, Alexander Ausserstorfer wrote:

Thank you! However, you can do this much easier. Just write the
hex values

01 00 00 EF 48 61 72 72 69 65 74 00 0E F0 A0 E1

into the memory and run it. It does the same as your example
programme.

I'm surprised you haven't gone for the even easier option of
toggling it in on the front panel switches, like a real programmer.

I certainly remember a real programmer setting lots of switches on the
front of an enormous mainframe so it did what he wanted.

But a real old programmer needed a pair of pliers to extract and
insert hundreds of tangled patch leads in a patch board over a meter
square!
--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <10h8m65$mhgq$1@druck.eternal-september.org>, druck <news@druck.org.uk> wrote:

On 06/12/2025 15:57, Alexander Ausserstorfer wrote:

Thank you! However, you can do this much easier. Just write the
hex values

01 00 00 EF 48 61 72 72 69 65 74 00 0E F0 A0 E1

into the memory and run it. It does the same as your example
programme.

I'm surprised you haven't gone for the even easier option of
toggling it in on the front panel switches, like a real programmer.

LOL

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <5c878d77feNews04@avisoft.f9.co.uk>,
Martin <News04@avisoft.f9.co.uk> wrote:

In article <5c87850775bavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

In article <5c87163b82News04@avisoft.f9.co.uk>,
Martin <News04@avisoft.f9.co.uk> wrote:

In article <5c87099f9bbavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

However, you can do this much easier. Just write the hex
values

01 00 00 EF 48 61 72 72 69 65 74 00 0E F0 A0 E1

That to my mind is MUCH harder, and would give you maintenance
nightmares, as it is impossible to read easily. The computer is
MUCH better translating plain text into hex and binary then we
are.

I strongly suggest that is not the way to program these days. It
was bad enough 50 years ago, when that was the only option, but
certainly not now.

I don't understand that. The values are much more clear to me.
Without I couldn't understand how computers are working.

Good luck in understanding it in a year ... or two ...or many more.
Hex code I would not even try, stopping and improvment or development.

As Steve said, we may have to agree to differ!

May it be. For me, machine code is much more easy to understand. Because
you don't need a compiler it means that there is nothing between you and
the machine.

You have to know something like a command of ARM (here 32 bit) is 32 bit
wide (or 4 bytes what means 8 places in hex). The command beginns with
the most significant byte why all four bytes has to be read reversed in
byte oder. This makes thinks a bit more complicate because in memory you
start with byte four and go back to byte one for each command.

The example was:

EF000001 72726148 00746569 E1A0F0E0

In memory this is written in byte order, however:

(Order counted here in decimal):

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.

01 00 00 EF 48 61 72 72 69 65 74 00 0E F0 A0 E1

EF is the command for jumping to a routine of the OS. You're calling
this SWI. Learning SWI or EF doesn't matter. Both sais nothing so you
have to learn and to know in any way what it means.

000001 is the number of the routine (or SWI). EF is shorter as SWI and
1 is much shorter as this long string "OS_WriteS". With the number, you
will get more easy the idea of the table of routines EF links to.

When you read the Programmers Reference Manuals about subroutine 1
(or OS_WriteS) you'll learn that this routine uses the next bytes to
print them as ASCII characters on the screen. The bytes have to be ASCII encoded and the routine ends by zero, so the bytes 5 up to 11 have to be interpreted as ASCII code.

5. 48 = "H"

6. 61 = "a"

7. 72 = "r"

8. 72 = "r"

9. 69 = "i"

10. 65 = "e"

11. 74 = "t"

Byte 12. has the value 00. It stops the subroutine 1.

E1 A0 F0 0E writes the value from register &E (LR or fourteen) back to
register &F (PC or fiveteen) what means that it gives the controll back
to the OS. Because &F is the Programm Counter. It says to the CPU which
command from which position in memory it should take next.

We had one and a half year of programming C in the school but this way
we learnt nothing. It is too abstract. You won't understand how
computers are working and you don't understand what you are doing.
Everything is hidden before you. You are stuck to the compilers. This is
why I started learning ARM machine code.

A.
--
http://home.chiemgau-net.de/ausserstorfer/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

On 21/12/2025 15:13, Alexander Ausserstorfer wrote:

May it be. For me, machine code is much more easy to understand. Because
you don't need a compiler it means that there is nothing between you and
the machine.

This topic was nothing to do with compilers, you responded to an ARM
assembler example with idiotic comments that it was easier to program
machine code in hex.

You either need to switch to sniffing lead free solder, or require a
quick tap to the temple with a wire wrap tool.

Now stop wasting everyone's time with this nonsense.

---druck
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <10ic84f$3on78$1@druck.eternal-september.org>,
druck <news@druck.org.uk> wrote:

Now stop wasting everyone's time with this nonsense.

Now, now... Alex didn't waste my time. Although I will never touch machine code, it was pretty amusing to read that someone is so familiar with it.

Paul
--
https://riscos.sprie.nl
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <5c8f6b2891Paul@sprie.nl>,
Paul Sprangers <Paul@sprie.nl> wrote:

In article <10ic84f$3on78$1@druck.eternal-september.org>,
druck <news@druck.org.uk> wrote:

Now stop wasting everyone's time with this nonsense.

Now, now... Alex didn't waste my time. Although I will never touch machine code, it was pretty amusing to read that someone is so familiar with it.

I just try to understand and to learn. How can I do or learn coding when
I even don't understand any of the machine code, means _both_ sides of a compiler (or assembler)? I don't know what the program (compiler) is
doing. I don't say you should do it always like that. But you should be
able to do it! Without this knowledge, you aren't good. When you compare
the code (source) before the compiler and behind the compiler (machine
code), you'll learn and uncover a lot!

A.
--
http://home.chiemgau-net.de/ausserstorfer/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

On Tue, 06 Jan 2026 14:42:37 +0200, Alexander Ausserstorfer wrote:

In article <5c8f6b2891Paul@sprie.nl>,
Paul Sprangers <Paul@sprie.nl> wrote:

In article <10ic84f$3on78$1@druck.eternal-september.org>,
druck <news@druck.org.uk> wrote:

Now stop wasting everyone's time with this nonsense.

Now, now... Alex didn't waste my time. Although I will never touch
machine code, it was pretty amusing to read that someone is so familiar
with it.

I just try to understand and to learn. How can I do or learn coding when
I even don't understand any of the machine code, means _both_ sides of a compiler (or assembler)? I don't know what the program (compiler) is
doing. I don't say you should do it always like that. But you should be
able to do it! Without this knowledge, you aren't good. When you compare
the code (source) before the compiler and behind the compiler (machine
code), you'll learn and uncover a lot!

A.

Have a free book:

https://archive.org/details/arm-archimedes-assembly-language-the-complete- programming-course-se-covers-risc-os
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In the book 'Raspberry Pi Assembly Language RISC OS Beginners' von Bruce
Smith I'M missing the links to the ARM machine code. I want to see the
commands in hex or binary values and want to be able to calculate it by
myself.

Is there another book or anything else you can recommend?

Thanks,

A.
--
http://home.chiemgau-net.de/ausserstorfer/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

On 12 Apr 2025 as I do recall,
Alexander Ausserstorfer wrote:

In the book 'Raspberry Pi Assembly Language RISC OS Beginners' von Bruce Smith I'M missing the links to the ARM machine code. I want to see the commands in hex or binary values and want to be able to calculate it by myself.

Is there another book or anything else you can recommend?

StrongED can disassemble ARM code instructions for you in Dump mode, so technically speaking you can use the BBC BASIC built-in assembler (I
assume the Bruce Smith book gives instructions for that?), save out the
area of memory into which you have assembled your code, and inspect it
in StrongED in order to see the hex values.

If you look inside !Textseek.Resources you will find the file 'detoken',
for example, which is just raw machine code that gets loaded and
executed by the BASIC !RunImage. It doesn't have any kind of executable
header or anything, so you can load that directly into Dump mode and
select the ASM button to ask StrongED to interpret it as assembly
language, which will display the assembler instructions in one column
and the raw hex values (and ASCII equivalents) in another. The 0101
button will do the same, but displaying the raw values as binary rather
than hex.

e.g.
0000001C : E92D5FFE : ____ : STMDB R13!,{R1-R12,R14}
00000020 : E24FC024 : ____ : ADR R12,&00000004 ; ADR -> &00000004 00000024 : E28E704C : ____ : ADD R7,R14,#&4C ; ="L"
00000028 : E58C7010 : ____ : STR R7,[R12,#16]
0000002C : E1A0E00C : ____ : MOV R14,R12
00000030 : E59E0004 : ____ : LDR R0,[R14,#4]
00000034 : E5900000 : ____ : LDR R0,[R0,#0]
00000038 : E280C001 : ____ : ADD R12,R0,#1
0000003C : E08CA002 : ____ : ADD R10,R12,R2
00000040 : E59E0014 : ____ : LDR R0,[R14,#20]
00000044 : E590B000 : ____ : LDR R11,[R0,#0]
00000048 : E28BB001 : ____ : ADD R11,R11,#1
0000004C : E1A0600B : ____ : MOV R6,R11

(upper-bit-set characters in the third column blanked out in case it
messes up the formatting)
--
Harriet Bazley == Loyaulte me lie ==

The attacker must vanquish; the defender need only survive.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In message <56b9040d5c.harriet@bazleyfamily.co.uk>
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

On 12 Apr 2025 as I do recall,
Alexander Ausserstorfer wrote:

In the book 'Raspberry Pi Assembly Language RISC OS Beginners' von Bruce
Smith I'M missing the links to the ARM machine code. I want to see the
commands in hex or binary values and want to be able to calculate it by
myself.

Is there another book or anything else you can recommend?

StrongED can disassemble ARM code instructions for you in Dump mode, so technically speaking you can use the BBC BASIC built-in assembler (I
assume the Bruce Smith book gives instructions for that?), save out the
area of memory into which you have assembled your code, and inspect it
in StrongED in order to see the hex values.

If you look inside !Textseek.Resources you will find the file 'detoken',
for example, which is just raw machine code that gets loaded and
executed by the BASIC !RunImage. It doesn't have any kind of executable header or anything, so you can load that directly into Dump mode and
select the ASM button to ask StrongED to interpret it as assembly
language, which will display the assembler instructions in one column
and the raw hex values (and ASCII equivalents) in another. The 0101
button will do the same, but displaying the raw values as binary rather
than hex.

e.g.
0000001C : E92D5FFE : ____ : STMDB R13!,{R1-R12,R14}
00000020 : E24FC024 : ____ : ADR R12,&00000004 ; ADR -> &00000004 00000024 : E28E704C : ____ : ADD R7,R14,#&4C ; ="L"
00000028 : E58C7010 : ____ : STR R7,[R12,#16]
0000002C : E1A0E00C : ____ : MOV R14,R12
00000030 : E59E0004 : ____ : LDR R0,[R14,#4]
00000034 : E5900000 : ____ : LDR R0,[R0,#0]
00000038 : E280C001 : ____ : ADD R12,R0,#1
0000003C : E08CA002 : ____ : ADD R10,R12,R2
00000040 : E59E0014 : ____ : LDR R0,[R14,#20]
00000044 : E590B000 : ____ : LDR R11,[R0,#0]
00000048 : E28BB001 : ____ : ADD R11,R11,#1
0000004C : E1A0600B : ____ : MOV R6,R11

(upper-bit-set characters in the third column blanked out in case it
messes up the formatting)

It's a good method!
I have :
Mike Ginns Archimedes Assembly Language (Dab Press) 1988.
and Alex & Nic VAN SOMEREN Archimdes Operating System (Dab Press) 1991.

If you use the BBC Basic Built-in assembly as mentioned above, you add
lines to your program to see the content of the memory and using the
Memory command obtain a code in assembler.
For example after NEXT pass
PRINT
PRINT "PGM words content"
size% = 40
FOR i%= 0 TO size% STEP 4
PRINT "adress% ";~(code% + i%) SPC(5)"content: " ~code%!i%
NEXT
PRINT
PRINT "PGM words content an disassembled code"
comd$ = "memoryi " + STR$~code% + " " + STR$~(code% + size%)
OSCLI comd$
To test...
--
Jean-Michel
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

In the book 'Raspberry Pi Assembly Language RISC OS Beginners' von Bruce Smith I'M missing the links to the ARM machine code. I want to see the commands in hex or binary values and want to be able to calculate it by myself.

Is there another book or anything else you can recommend?

Arm has documentation of the A32 instruction encoding, starting from the
most significant bits and drilling your way down: https://developer.arm.com/documentation/ddi0597/2025-03/A32-Instructions-by-Encoding

Going the other way, if you start at the top level of that manual and work
down by instruction type: https://developer.arm.com/documentation/ddi0597/2025-03?lang=en

each instruction shows its encoding. eg there are three entries for MOV, depending on what's on the right hand side:

https://developer.arm.com/documentation/ddi0597/2025-03/Base-Instructions/MOV--MOVS--immediate---Move--immediate--?lang=en
https://developer.arm.com/documentation/ddi0597/2025-03/Base-Instructions/MOV--MOVS--register---Move--register--?lang=en
https://developer.arm.com/documentation/ddi0597/2025-03/Base-Instructions/MOV--MOVS--register-shifted-register---Move--register-shifted-register--?lang=en

Not all instructions are available on all CPUs, of course.

Theo
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <buh*s+0-z@news.chiark.greenend.org.uk>,
Theo <theom+news@chiark.greenend.org.uk> wrote:

Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

In the book 'Raspberry Pi Assembly Language RISC OS Beginners' von Bruce
Smith I'M missing the links to the ARM machine code. I want to see the
commands in hex or binary values and want to be able to calculate it by
myself.

Is there another book or anything else you can recommend?

Arm has documentation of the A32 instruction encoding, starting from
the most significant bits and drilling your way down:

...

Not all instructions are available on all CPUs, of course.

Many thanks! I was not able to see the pages at home, however. I
downloaded a PDF (8 MB) now elsewhere.

I begun to write an introduction

http://home.chiemgau-net.de/ausserstorfer/Temp/2022-05-26/Skript.pdf (5
kB)

in German for me to learn and teach myself. May be that I include the
new 8 bit home computer Mega65 from Trentz Elektronik there later as
well.

A.
--
http://home.chiemgau-net.de/ausserstorfer/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

An einem Sat, 07 Jun 2025 17:08:01 +0200 schrieb der Meister Alexander Ausserstorfer:

In article <buh*s+0-z@news.chiark.greenend.org.uk>,
Theo <theom+news@chiark.greenend.org.uk> wrote:

Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

In the book 'Raspberry Pi Assembly Language RISC OS Beginners' von
Bruce Smith I'M missing the links to the ARM machine code. I want to
see the commands in hex or binary values and want to be able to
calculate it by myself.

Is there another book or anything else you can recommend?

Arm has documentation of the A32 instruction encoding, starting from
the most significant bits and drilling your way down:

...

Not all instructions are available on all CPUs, of course.

Many thanks! I was not able to see the pages at home, however. I
downloaded a PDF (8 MB) now elsewhere.

I begun to write an introduction

http://home.chiemgau-net.de/ausserstorfer/Temp/2022-05-26/Skript.pdf (5
kB)

in German for me to learn and teach myself. May be that I include the
new 8 bit home computer Mega65 from Trentz Elektronik there later as
well.

A.

The link doesn't work.
--
holy miau is a snake
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

Sebastian Barthel <naitsabes@freenet.de> wrote:

An einem Sat, 07 Jun 2025 17:08:01 +0200 schrieb der Meister Alexander Ausserstorfer:

I begun to write an introduction

http://home.chiemgau-net.de/ausserstorfer/Temp/2022-05-26/Skript.pdf (5
kB)

in German for me to learn and teach myself. May be that I include the
new 8 bit home computer Mega65 from Trentz Elektronik there later as
well.

A.

The link doesn't work.

It's 2025 already. This works for me: http://home.chiemgau-net.de/ausserstorfer/Temp/2025-05-26/Skript.pdf
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <iKm*CnCeA@news.chiark.greenend.org.uk>,
Theo <theom+news@chiark.greenend.org.uk> wrote:

Sebastian Barthel <naitsabes@freenet.de> wrote:

The link doesn't work.

It's 2025 already. This works for me:

http://home.chiemgau-net.de/ausserstorfer/Temp/2025-05-26/Skript.pdf

Thanks, Theo. I will give it later another place on my web site.

It is to understand, that this is a working process. This means that it
may and may not include mistakes and errors. It is written down by
something who wants to know the stuff in an logical order what he was also missing in the past.

The first I will explore will be the PC (R15). I want to know the
structures of programs at the beginning. So the first command will be
MOV here. (On Mega65 it would be JMP I think).

It may be that I will include the Mega65 besides the ARM, too, because
you can learn a lot by comparing things.

A.
--
http://home.chiemgau-net.de/ausserstorfer/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

An einem Mon, 09 Jun 2025 17:36:00 +0100 schrieb der Meister Theo:

Sebastian Barthel <naitsabes@freenet.de> wrote:

An einem Sat, 07 Jun 2025 17:08:01 +0200 schrieb der Meister Alexander
Ausserstorfer:

I begun to write an introduction

http://home.chiemgau-net.de/ausserstorfer/Temp/2022-05-26/Skript.pdf
(5 kB)

in German for me to learn and teach myself. May be that I include the
new 8 bit home computer Mega65 from Trentz Elektronik there later as
well.

A.

The link doesn't work.

It's 2025 already. This works for me: http://home.chiemgau-net.de/ausserstorfer/Temp/2025-05-26/Skript.pdf

OK - Thanks.
With the corrected year it was a full success.
--
holy miau is a snake
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <5c2adc4465bavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

In article <iKm*CnCeA@news.chiark.greenend.org.uk>,
Theo <theom+news@chiark.greenend.org.uk> wrote:

Sebastian Barthel <naitsabes@freenet.de> wrote:

The link doesn't work.

It's 2025 already. This works for me:

http://home.chiemgau-net.de/ausserstorfer/Temp/2025-05-26/Skript.pdf

Thanks, Theo. I will give it later another place on my web site.

I put it now here:

http://home.chiemgau-net.de/ausserstorfer/Computer/Kurs.pdf (27 kB)

It is to understand, that this is a working process. This means that it
may and may not include mistakes and errors. It is written down by
something who wants to know the stuff in an logical order what he was also missing in the past.

The first I will explore will be the PC (R15). I want to know the
structures of programs at the beginning. So the first command will be
MOV here. (On Mega65 it would be JMP I think).

No, before all I begin now with the memory. This will become a huge
part.

It is a living process. It should be logical and not an enumeration of
commands like I found in many books.

I found something of the memory in the Programmer's Reference Manuals.
Are there other sources as well? Is there a program with which I can see
the memory of any RISC OS machine? StrongEd can only display files,
can't it?

A.
--
http://home.chiemgau-net.de/ausserstorfer/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <5c2cea6fccbavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

Is there a program with which I can see the memory of any RISC OS
machine?

There are commands *Memory, *MemoryA, and *MemoryI to display (and
even modify) memory in different formats.

StrongEd can only display files, can't it?

No - it can also display memory.
See Menu -> Create File -> Grab memory.
Different named areas, and in different formats.
--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <5c2cef85bdNews03@avisoft.f9.co.uk>,
Martin <News03@avisoft.f9.co.uk> wrote:

In article <5c2cea6fccbavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

Is there a program with which I can see the memory of any RISC OS
machine?

There are commands *Memory, *MemoryA, and *MemoryI to display (and
even modify) memory in different formats.

Thanks.

StrongEd can only display files, can't it?

No - it can also display memory.
See Menu -> Create File -> Grab memory.
Different named areas, and in different formats.

I couldn't find the menu entry. When I click on iconbar -> !StrongEd ->
Menu -> Create -> Dump StrongEd offers me a window with name Grab in the
window title bar. Did you mean that?

In !Zap I can grab a are of memory as I wish.

A.
--
http://home.chiemgau-net.de/ausserstorfer/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <5c2f3eb0a5bavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

In article <5c2cef85bdNews03@avisoft.f9.co.uk>,
Martin <News03@avisoft.f9.co.uk> wrote:

In article <5c2cea6fccbavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

Is there a program with which I can see the memory of any RISC OS
machine?

There are commands *Memory, *MemoryA, and *MemoryI to display (and
even modify) memory in different formats.

Thanks.

StrongEd can only display files, can't it?

No - it can also display memory.
See Menu -> Create File -> Grab memory.
Different named areas, and in different formats.

I couldn't find the menu entry.

Which version of StrongEd are you using?
Here I am using v4.70a17 (31 May 2025)

When I click on iconbar ->
!StrongEd -> Menu -> Create -> Dump StrongEd offers me a window
with name Grab in the window title bar. Did you mean that?

If the Grab Memory window shows menu icons for ROM Module, RAM Module, Application, ROM Workspace, RAM Workspace and Dynamic Area, then
buttons for Zero Page, Empty Text, CMOS RAM, Close, then yes. If you
are using another version of SE it may be slightly different.

In !Zap I can grab a are of memory as I wish.

I don't think there is an equivalent of !Zap -> Create -> Read Memory
to specify addresses to dump, but that only reads from the specified
task - which is what selecting an application in SE does for the whole application slot.
--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In message <5c2f581e37News03@avisoft.f9.co.uk>
Martin <News03@avisoft.f9.co.uk> wrote:

In article <5c2f3eb0a5bavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

In article <5c2cef85bdNews03@avisoft.f9.co.uk>,
Martin <News03@avisoft.f9.co.uk> wrote:

In article <5c2cea6fccbavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:

Is there a program with which I can see the memory of any RISC OS
machine?

There are commands *Memory, *MemoryA, and *MemoryI to display (and
even modify) memory in different formats.

Thanks.

StrongEd can only display files, can't it?

No - it can also display memory.
See Menu -> Create File -> Grab memory.
Different named areas, and in different formats.

I couldn't find the menu entry.

Which version of StrongEd are you using?
Here I am using v4.70a17 (31 May 2025)

When I click on iconbar ->
!StrongEd -> Menu -> Create -> Dump StrongEd offers me a window
with name Grab in the window title bar. Did you mean that?

If the Grab Memory window shows menu icons for ROM Module, RAM Module, Application, ROM Workspace, RAM Workspace and Dynamic Area, then
buttons for Zero Page, Empty Text, CMOS RAM, Close, then yes. If you
are using another version of SE it may be slightly different.

In !Zap I can grab a are of memory as I wish.

I don't think there is an equivalent of !Zap -> Create -> Read Memory
to specify addresses to dump, but that only reads from the specified
task - which is what selecting an application in SE does for the whole application slot.

FIY, Stronged GrabMemory: Application drop -down menu, allows you to see
that all applications start at 0x8000
--
Jean-Michel
--- Synchronet 3.21d-Linux NewsLink 1.2