log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- Drag'N'Drop Autumn edition now available (News:)
- !DualHead puts 2 screens in one (News:)
- RISC OS London Show 2017 - Notes from the talks (News:6)
- November News (News:)
- !Organizer 2.28 reviewed (News:2)
- !OBrowse reviewed (News:10)
- Aemulor (Gen:16)
- DDE reaches release 28 and above (News:)
- Elesar quicks dispels stormy clouds (News:2)
- RISC OS London Show 2017 (News:)
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
Site Search
 
Article archives
The Icon Bar: Programming: Detailed memory map of RISC OS 3.1 required
 
  Detailed memory map of RISC OS 3.1 required
  sirbod (12:41 2/12/2012)
  msww (16:05 2/12/2012)
    sirbod (17:35 2/12/2012)
      qUE (00:10 4/12/2012)
        Phlamethrower (00:48 4/12/2012)
          sirbod (08:24 4/12/2012)
            flibble (19:04 4/12/2012)
              qUE (22:44 4/12/2012)
                sirbod (23:24 3/1/2013)
              sirbod (12:48 29/12/2012)
                TomWalker (10:52 30/12/2012)
      sirbod (20:31 16/1/2013)
        Phlamethrower (21:03 16/1/2013)
          sirbod (20:44 17/1/2013)
        qUE (15:28 17/1/2013)
          qUE (17:53 17/1/2013)
          Phlamethrower (18:49 17/1/2013)
  qUE (00:01 4/12/2012)
 
Jon Abbott Message #121585, posted by sirbod at 12:41, 2/12/2012
Member
Posts: 563
I'm making a start on updating all the Krisalis titles to work on the Pi / Iyonix as part of JASPP. However, to do so, I need a detailed memory map of page zero and the upper memory ranges under RISC OS 3.1.

For example, two hardcoded entries I've found in Lemmings read/write to &100 and an address in the &3200000 range. The latter is one of the chipset, I've no idea on the former. It's an offset in page zero to some code is about all I know.

[Edited by sirbod at 12:42, 2/12/2012]
  ^[ Log in to reply ]
 
Matthew Wightman Message #121586, posted by msww at 16:05, 2/12/2012, in reply to message #121585
Member
Posts: 4
Googling "RISC OS 3.1 zero page locations" reveals the document at http://www.drobe.co.uk/archives//freenet.barnet.ac.uk/Acorn/programming/docs/zeropage.txt , which may be of use?
  ^[ Log in to reply ]
 
Jon Abbott Message #121587, posted by sirbod at 17:35, 2/12/2012, in reply to message #121586
Member
Posts: 563
Just what I needed, thank you.

Now just need to find the map above &1000000, I have a rough one (below), but need more detail on the chipset areas. I have the original VLSI ARM chipset manual, but it only covers the first chipset, so only gets me so far.

http://www.poppyfields.net/acorn/docs/armdocs/pocket.shtml

1F03800 - Mouse cursor data

[Edited by sirbod at 21:05, 30/6/2013]
  ^[ Log in to reply ]
 
qUE Message #121590, posted by qUE at 00:01, 4/12/2012, in reply to message #121585
qUE

Posts: 168
&3200000 is the IOC.

the page zero varies from OS version to OS version.


[Edited by qUE at 00:04, 4/12/2012]
  ^[ Log in to reply ]
 
qUE Message #121591, posted by qUE at 00:10, 4/12/2012, in reply to message #121587
qUE

Posts: 168
You mean what ROS has setup as default map with MEMC in 1Fxxxxx?

on a ROS 3 machine;

FOR page=0 TO 255:PRINT ~!(&164+(page<<2));",";:NEXT

(very top two bits are permissions)


again, this varies depending on how much memory is allocated to the video, heap, etc. in CMOS


[Edited by qUE at 00:25, 4/12/2012]
  ^[ Log in to reply ]
 
Jeffrey Lee Message #121592, posted by Phlamethrower at 00:48, 4/12/2012, in reply to message #121591
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15057
Luckily, Acorn decided to archive some copies of the kernel/OS memory map seperately to the live copies that are used to build the kernel. So you can still find them in ROOL's CVS, although they aren't the easiest files to decipher:

http://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Kernel/hdr/Old/?hideattic=0

Despite there being a folder called 'Arthur', it actually contains a copy of the RISC OS 2 memory map. 'NewSpace' and 'VickySpace' appear to be from during RiscPC development, so might not be all that useful.

For I/O memory, you've got four sources:

* The RISC OS 2/3 PRMs
* The IOC, IOEB, MEMC, VIDC, etc. datasheets (if you've got them! Most are available here)
* The register definitions in HdrSrc
* Any other unofficial docs you come across (docs like the ones on poppyfields.net, source code to emulators, etc.)


[Edited by Phlamethrower at 00:55, 4/12/2012]
  ^[ Log in to reply ]
 
Jon Abbott Message #121593, posted by sirbod at 08:24, 4/12/2012, in reply to message #121592
Member
Posts: 563
Thank you, I think that between this, Matthew's post and the VIDC manuals, I have most of the info I need.

I'm sure it's common knowledge, but where we're the four chips mapped too on RO3.1 machines? qUE mentioned IOC being at &3200000
  ^[ Log in to reply ]
 
Peter Howkins Message #121595, posted by flibble at 19:04, 4/12/2012, in reply to message #121593
flibble

Posts: 864
Thank you, I think that between this, Matthew's post and the VIDC manuals, I have most of the info I need.

I'm sure it's common knowledge, but where we're the four chips mapped too on RO3.1 machines? qUE mentioned IOC being at &3200000
From a bit of arcem remembering.

0x03800000 - MEMC (write only, read is rom high)
0x03400000 - VIDC

Note these are not 'mapped', but the set positions of the hardware, physical, not logical addresses, wired into these lines on the ARM address bus smile


[Edited by flibble at 19:06, 4/12/2012]
  ^[ Log in to reply ]
 
qUE Message #121598, posted by qUE at 22:44, 4/12/2012, in reply to message #121595
qUE

Posts: 168
Just to add to the chaos of memory offsets, MEMC also uses &36xxxxx for the offsets of the VIDC buffers and various MEMC modes. &33xxxxx are devices. And reading from &34xxxxx is lo-ROM.

Afaik Acorn were going for;
&1xxxxxx - logical space
&2xxxxxx - physical memory
&3xxxxxx - i/o space

This idea became shot on newer architectures afaik :/
  ^[ Log in to reply ]
 
Jon Abbott Message #121718, posted by sirbod at 12:48, 29/12/2012, in reply to message #121595
Member
Posts: 563
0x03400000 - VIDC
Does VIDC2 map elsewhere? I've come across a few games that are generating a Data Abort writing to &3400000

[Edited by sirbod at 12:48, 29/12/2012]
  ^[ Log in to reply ]
 
Tom Walker Message #121719, posted by TomWalker at 10:52, 30/12/2012, in reply to message #121718
Member
Posts: 25
VIDC2 is mapped at 0x03500000 - presumably to aid old VIDC emulation.
  ^[ Log in to reply ]
 
Jon Abbott Message #121727, posted by sirbod at 23:24, 3/1/2013, in reply to message #121598
Member
Posts: 563
&2xxxxxx - physical memory
If a game tries to write to &2xxxxxx, where is it actually writing? Is it simply a case of doing a reverse lookup in the logical memory table and redirecting the write?

Looking at No Excuses as an example, it does an "SWI Sound_Configure" and immediately after starts writing to &2020000 with what looks like sound buffer data.

Rick Dangerous is another example, which tries writing to &200A028. As the amount is &14000 and all zero's, its obviously trying to clear the screen, which is what I'd expect at that range in physical.

VIDC2 is mapped at 0x03500000 - presumably to aid old VIDC emulation.
Thanks Tom, I now have the VIDC1 > VIDC20 translation code up and running which has made at least 30 more games RO3.7 compatible.

[Edited by sirbod at 20:29, 16/1/2013]
  ^[ Log in to reply ]
 
Jon Abbott Message #121755, posted by sirbod at 20:31, 16/1/2013, in reply to message #121587
Member
Posts: 563
Anyone know what's at &1F08000
  ^[ Log in to reply ]
 
Jeffrey Lee Message #121756, posted by Phlamethrower at 21:03, 16/1/2013, in reply to message #121755
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15057
Anyone know what's at &1F08000
That's "Nowhere". It's the logical address which (Arc-era) RISC OS maps pages to in order to get rid of them. Based on my own experiences with ArcEm, I think this does actually result in multiple pages being mapped to the same place in MEMC - but I may be misremembering (or it may be a bug). Certainly I just got an abort on data transfer when trying to *memory the address in ArcEm, suggesting there wasn't anything (currently) mapped there.

Of course it's also possible you're seeing that address because something has overrun the sound buffers (&1F06000-&1F07FFF)
  ^[ Log in to reply ]
 
qUE Message #121762, posted by qUE at 15:28, 17/1/2013, in reply to message #121755
qUE

Posts: 168
Anyone know what's at &1F08000
Pretty sure it's &1FF8000

Like Jeffery said, it's a dummy logical value for the MEMC pages. To clarify, it's set like that because when the machine first boots R13 aka the stack pointer is set to 0. If you then go and store to the stack in decending order it'll wrap in memory and cause an abort vector call because the page isn't set. So you have to set the MEMC to have a valid page at the end of logical to avoid the abort.

[Edited by qUE at 15:33, 17/1/2013]
  ^[ Log in to reply ]
 
qUE Message #121763, posted by qUE at 17:53, 17/1/2013, in reply to message #121762
qUE

Posts: 168
Other addresses at end of logical are listed in the RISC OS source code. They're normally named <something>chunkaddress and are intially setup in newreset, referring to the iyonix since I haven't looked at the later source.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #121764, posted by Phlamethrower at 18:49, 17/1/2013, in reply to message #121762
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15057
Anyone know what's at &1F08000
Pretty sure it's &1FF8000
&1FF8000 would be the last 32K of the logical mapping of screen memory (with the physical mapping of screen memory immediately afterwards, from &2000000)

[Edited by Phlamethrower at 18:50, 17/1/2013]
  ^[ Log in to reply ]
 
Jon Abbott Message #121766, posted by sirbod at 20:44, 17/1/2013, in reply to message #121756
Member
Posts: 563
Of course it's also possible you're seeing that address because something has overrun the sound buffers (&1F06000-&1F07FFF)
Could be a sound buffer overrun. It's Gribbly's Day Out that's trying to write to it.

If I trap the write, it crashes elsewhere as it seems to be writing to all sorts of addresses in the 1F00000 > 1F0FFFF range.

There's a few others I've yet to decode:

Aliped Aborts writing to &4DBC43D
No Excuses Aborts writing to &2020000
Manchester United Pre-fetch Aborts at &1CE24EC
  ^[ Log in to reply ]
 

The Icon Bar: Programming: Detailed memory map of RISC OS 3.1 required