What is the file type of machine code? In Bruce Smith book
"Raspberry Pi Assembly Language" he saves a block of memory with
the command *save <filename> <startaddr>+<length>. The saved file
has no file type. By a double click the code is running from the
desktop in single mode, though.
What is the file type of machine code? In Bruce Smith book "Raspberry Pi Assembly Language" he saves a block of memory with the command *save <filename> <startaddr>+<length>. The saved file has no file type. By a
double click the code is running from the desktop in single mode, though.
Where do I find the starting point of such a code? What is the address
where the machine code is starting?
On the Commodore 64 (or Mega65) you will type
SYS <address> to start machine code at address.
When I examine an absolute file in StrongEd (dump mode), the first line always at address 8000. Is this also the starting point of the code?
In article <5c294dfd2cbavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
What is the file type of machine code? In Bruce Smith book
"Raspberry Pi Assembly Language" he saves a block of memory with
the command *save <filename> <startaddr>+<length>. The saved file
has no file type. By a double click the code is running from the
desktop in single mode, though.
Saved like that it will have no filetype (and no date) - instead it
has a load and exec address, which default to <startaddr>
Use *Help Start for more details.
Display the file in the Filer with full info and it will show the load
& start addresses.
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
What is the file type of machine code? In Bruce Smith book "Raspberry Pi
Assembly Language" he saves a block of memory with the command *save
<filename> <startaddr>+<length>. The saved file has no file type. By a
double click the code is running from the desktop in single mode, though.
Where do I find the starting point of such a code? What is the address
where the machine code is starting?
This is the territory of executable formats.
In article <lKm*MFveA@news.chiark.greenend.org.uk>,
Theo <theom+news@chiark.greenend.org.uk> wrote:
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
Where do I find the starting point of such a code? What is the address
where the machine code is starting?
This is the territory of executable formats.
[...]
Many thanks! I found the Appendix D: Code file formats in RISC OS 3 Programmer's Reference Manual Volume 4. I'm not sure if I will
understand that all. It's a shame that I never read about that in the GAG-News or any other publication in a clear understandable way.
In article <5c29d67fbebavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
In article <lKm*MFveA@news.chiark.greenend.org.uk>,
Theo <theom+news@chiark.greenend.org.uk> wrote:
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
Where do I find the starting point of such a code? What is the address >>>> where the machine code is starting?
This is the territory of executable formats.
[...]
Many thanks! I found the Appendix D: Code file formats in RISC OS 3
Programmer's Reference Manual Volume 4. I'm not sure if I will
understand that all. It's a shame that I never read about that in the
GAG-News or any other publication in a clear understandable way.
I created a new file in !StrongEd and saved it with file type
"application". You can change the file type while saving the file to anywhere. Then opened the file again. It may be required to chance the
mode to 'dump'. Clicked on 'byte'. Now you can write the commands like
you wish. The last command should always be E0 F0 A0 E1. Then saved the
file and started it by a double click. You can add the command 00 00 A0
E1 (what is doing nothing of course) before. And so on.
I have no idea, why 'word' and 'byte' are reversed. When you click on
word, you have to write
E1 A0 00 00
E1 A0 F0 E0
of course. This is the format it is descripted in the manual of the ARM
(Arm A32/T32 Instrution Set for A-profile architecture) I have here.
Thank you very much for all your help here.
A.
A.
I created a new file in !StrongEd and saved it with file type
"application".
An application will always be loaded and started by RISC OS on
address &08000. This is a bit strange because RISC OS can hold
different applications at the same time in the RAM. Normally, the
programs would be overwritten when all are loaded at the same
location of memory. But between the ARM and the RAM you have the
MEMC (this I grab from the PRMs 3 - is that still the case today?).
The MEMC maps the memory for the applications and moves it to
elsewhere, to a place where is free memory.
It seems to me that there are existing much
different ARM chips today. What are the differences? Which ones are
relevant for RISC OS today? I'm have some Raspberry Pi's and an
Elesar's Titanium. Never read about this issue.
I'm also a bit confused about the documentation. I have the
Programmer's Reference Manuals here. But they are for RISC OS 3.
What was chanced in meantime, what is still valid from them today?
I have replied to some of your points...
In article <5c2f4363e6bavariasound@chiemgau-net.de>,
Alexander Ausserstorfer <bavariasound@chiemgau-net.de> wrote:
I created a new file in !StrongEd and saved it with file type
"application".
There is no filetype for 'Application', so not sure what you mean
here. Application is a special name given to a directory (not a file)
that starts with a ! (an exclamation mark, commonly referred to as a
pling in this context)
[Snip]
An application will always be loaded and started by RISC OS on
address &08000. This is a bit strange because RISC OS can hold
different applications at the same time in the RAM. Normally, the
programs would be overwritten when all are loaded at the same
location of memory. But between the ARM and the RAM you have the
MEMC (this I grab from the PRMs 3 - is that still the case today?).
The MEMC maps the memory for the applications and moves it to
elsewhere, to a place where is free memory.
Applications do always appear to start at &8000, but this is just a
'virtual' address. It will actually be at a physical real address, and
the translation is done for you by RISC OS so you always deal with the virtual addresses. There is no longer a MEMC chip involved.
[Snip]
It seems to me that there are existing much
different ARM chips today. What are the differences? Which ones are
relevant for RISC OS today? I'm have some Raspberry Pi's and an
Elesar's Titanium. Never read about this issue.
There is lots on the web, but probably best place to start is https://www.riscosopen.org
Click on Library, go down to Programmer Documentation and click on the Programmer Documentation link, then click on ARMV6+ compatibility
primer. You should end up at https://www.riscosopen.org/wiki/documentation/show/ARMv7%20compatibility%20primer
but it gives you an idea of other things available on this one site.
I'm also a bit confused about the documentation. I have the
Programmer's Reference Manuals here. But they are for RISC OS 3.
What was chanced in meantime, what is still valid from them today?
Most of it is still valid with RO5, apart from the 26bit to 32bit
changes. An updated version of the PRMs is being worked on ... but it
is a mammoth project. If you click on Bounties at the top of the ROOL
page, you will see details of the work for Revide PRMs step 1.
Some updates since RO3 are available in the ROOL Library, and the
Style Guide, BASIC and DDE manuals have all been updated.
I created a new file in !StrongEd and saved it with file type
"application". You can change the file type while saving the file to anywhere. Then opened the file again. It may be required to chance the
mode to 'dump'. Clicked on 'byte'. Now you can write the commands like
you wish. The last command should always be E0 F0 A0 E1. Then saved the
file and started it by a double click. You can add the command 00 00 A0
E1 (what is doing nothing of course) before. And so on.
I have no idea, why 'word' and 'byte' are reversed. When you click on
word, you have to write
E1 A0 00 00
E1 A0 F0 E0
of course. This is the format it is descripted in the manual of the ARM
(Arm A32/T32 Instrution Set for A-profile architecture) I have here.
An application will always be loaded and started by RISC OS on address &08000. This is a bit strange because RISC OS can hold different
applications at the same time in the RAM. Normally, the programs would
be overwritten when all are loaded at the same location of memory. But between the ARM and the RAM you have the MEMC (this I grab from the PRMs 3
- is that still the case today?). The MEMC maps the memory for the applications and moves it to elsewhere, to a place where is free
memory.
With the instruction A1 A0 F0 E0 at the end you will give the controll
back to RISC OS. It moves the address which was stored in register &E
before calling the programm, back to register &F, which is the programm counter of the ARM.
For this part I was looking long. It seems to me that there is no direct introduction to that issue. But it is so fundamental. And it is very
easy to understand. You can examine an application that way, too!
It may look a bit strange to other people to instruct the computer in
such a - I'll call it - 'hard' way. It is the direct way. It is machine
code. The problem is if you are not learning it this 'hard' way and if
you are using all the helpers (assemblers, compilers) from the beginning
on you won't learn real coding nor create an understanding in this issue.
They created the Raspberry Pi to give the people cheap computers to
learn. This alone won't work, of course. You have to give the people the information to learn, too. And I think this isn't happen. There is a lot
of publication around but nothing what may help people to understand
what's going on. It would be so helpful to have such an publication.
I'm a bit confused by the huge amount of documentation I found about the
ARM. It seems to me that there are existing much different ARM chips
today. What are the differences? Which ones are relevant for RISC OS
today? I'm have some Raspberry Pi's and an Elesar's Titanium. Never read about this issue.
I'm also a bit confused about the documentation. I have the Programmer's Reference Manuals here. But they are for RISC OS 3. What was chanced in meantime, what is still valid from them today? Never read about that issue.
An application will always be loaded and started by RISC OS on
address &08000. This is a bit strange because RISC OS can hold
different applications at the same time in the RAM. Normally, the
programs would be overwritten when all are loaded at the same
location of memory. But between the ARM and the RAM you have the
MEMC (this I grab from the PRMs 3 - is that still the case today?).
The MEMC maps the memory for the applications and moves it to
elsewhere, to a place where is free memory.
Applications do always appear to start at &8000, but this is just a
'virtual' address. It will actually be at a physical real address, and
the translation is done for you by RISC OS so you always deal with the
virtual addresses. There is no longer a MEMC chip involved.
Thanks. Let do that task RISC OS means doing it by software. Isn't that
a brake for the performance?
What about the program counter? Was there any changes to it since the
release of the PRMs for RISC OS 3?
From DDE.Codestds.AOF
There are two sorts of AOF: <little-endian> and <big-endian>.
In little-endian AOF, the least significant byte of a word or half-word
has the lowest address of any byte in the (half-)word. This <byte sex> is used by DEC,Intel and Acorn, amongst others.
In big-endian AOF, the most significant byte of a (half-)word has the lowest.address. This byte sex is used by IBM, Motorola and Apple, amongst others.
On 19/06/2025 10:23, Jean-Michel wrote:
From DDE.Codestds.AOF
There are two sorts of AOF: <little-endian> and <big-endian>.
In little-endian AOF, the least significant byte of a word or
half-word has the lowest address of any byte in the (half-)word.
This <byte sex> is used by DEC,Intel and Acorn, amongst others.
In big-endian AOF, the most significant byte of a (half-)word has
the lowest.address. This byte sex is used by IBM, Motorola and
Apple, amongst others.
Never seen a big endian AOF in the wild, and suspect no-one else
has either.
I can only guess it was specified as a result of Sam Wauchope's
crazed ideas about running a successor to RISC OS on Power PC or
something.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 29:39:47 |
| Calls: | 10,391 |
| Calls today: | 2 |
| Files: | 14,064 |
| Messages: | 6,417,089 |
