| |
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 |
Posts: 187
|
&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 |
Posts: 187
|
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 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
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 |
Posts: 892
|
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 
[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 |
Posts: 187
|
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 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
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 |
Posts: 187
|
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 |
Posts: 187
|
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 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
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 ] |
| |
|
