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

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

Learning ARM machine code

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

Contents

  Learning ARM machine code Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-04-12 15:11 +0200
    Re: Learning ARM machine code Harriet Bazley <harriet@bazleyfamily.co.uk> - 2025-04-13 18:27 +0100
      Re: Learning ARM machine code Jean-Michel <jmc.bruck@orange.fr> - 2025-04-14 11:40 +0200
    Re: Learning ARM machine code Theo <theom+news@chiark.greenend.org.uk> - 2025-04-14 17:56 +0100
      Re: Learning ARM machine code Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-06-07 17:08 +0200
        Re: Learning ARM machine code Sebastian Barthel <naitsabes@freenet.de> - 2025-06-09 13:04 +0000
          Re: Learning ARM machine code Theo <theom+news@chiark.greenend.org.uk> - 2025-06-09 17:36 +0100
            Re: Learning ARM machine code Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-06-10 18:11 +0200
              Re: Learning ARM machine code Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-06-14 17:58 +0200
                Re: Learning ARM machine code Martin <News03@avisoft.f9.co.uk> - 2025-06-14 17:54 +0100
                  Re: Learning ARM machine code Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-06-19 06:31 +0200
                    Re: Learning ARM machine code Martin <News03@avisoft.f9.co.uk> - 2025-06-19 10:09 +0100
                      Re: Learning ARM machine code Jean-Michel <jmc.bruck@orange.fr> - 2025-06-19 11:32 +0200
                Re: Learning ARM machine code Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-11-02 16:42 +0200
                  Re: Learning ARM machine code Martin <News03@avisoft.f9.co.uk> - 2025-11-02 17:01 +0000
                    Re: Learning ARM machine code Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-11-15 14:55 +0200
                      Re: Learning ARM machine code druck <news@druck.org.uk> - 2025-11-17 19:08 +0000
                  Re: Learning ARM machine code Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-11-15 15:11 +0200
                    Re: Learning ARM machine code Harriet Bazley <harriet@bazleyfamily.co.uk> - 2025-11-15 19:46 +0000
                      Re: Learning ARM machine code Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-12-06 17:57 +0200
                        Re: Learning ARM machine code Martin <News04@avisoft.f9.co.uk> - 2025-12-06 18:15 +0000
                          Re: Learning ARM machine code Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-12-07 16:25 +0200
                            Re: Learning ARM machine code Martin <News04@avisoft.f9.co.uk> - 2025-12-07 15:57 +0000
                              Re: Learning ARM machine code Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-12-21 17:13 +0200
                                Re: Learning ARM machine code druck <news@druck.org.uk> - 2025-12-22 20:02 +0000
                                  Re: Learning ARM machine code Paul Sprangers <Paul@sprie.nl> - 2025-12-22 23:32 +0100
                                    Re: Learning ARM machine code Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2026-01-06 14:42 +0200
                                      Re: Learning ARM machine code anonymouse <na@ignoreme.com> - 2026-01-06 15:02 +0000
                          Re: Learning ARM machine code Jean-Michel <jmc.bruck@orange.fr> - 2025-12-08 10:23 +0100
                        Re: Learning ARM machine code Harriet Bazley <harriet@bazleyfamily.co.uk> - 2025-12-06 20:06 +0000
                        Re: Learning ARM machine code druck <news@druck.org.uk> - 2025-12-09 08:21 +0000
                          Re: Learning ARM machine code Martin <News04@avisoft.f9.co.uk> - 2025-12-09 09:48 +0000
                          Re: Learning ARM machine code Richard Ashbery <basura@invalid.addr.uk> - 2025-12-09 10:54 +0000
                    Re: Learning ARM machine code Steve Fryatt <news@stevefryatt.org.uk> - 2025-11-15 23:46 +0000
                      Re: Learning ARM machine code Theo <theom+news@chiark.greenend.org.uk> - 2025-11-16 11:59 +0000
                      Re: Learning ARM machine code Alexander Ausserstorfer <bavariasound@chiemgau-net.de> - 2025-12-06 18:10 +0200
                        Re: Learning ARM machine code Steve Fryatt <news@stevefryatt.org.uk> - 2025-12-07 12:18 +0000
            Re: Learning ARM machine code Sebastian Barthel <naitsabes@freenet.de> - 2025-06-10 18:37 +0000

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

#6565

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. 

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

#6568

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/

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

#6569

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. 

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

#6575

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/

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

#6578

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

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

#6579

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

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

#6586

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/

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

#6587

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

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

#6570

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

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

#6566

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.

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

#6571

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

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

#6572

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. 

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

#6573

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

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

#6560

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/

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

#6561

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

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

#6564

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/

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

#6567

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/

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

#6516

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

[toc] | [prev] | [standalone]

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

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

csiph-web