| |
RO3.5-3.7x L1PT / L2PT |
| |
sirbod (06:32 4/9/2013)
Phlamethrower (13:10 4/9/2013)
sirbod (19:31 4/9/2013)
Phlamethrower (20:09 4/9/2013)
sirbod (21:06 4/9/2013)
MEmerton (09:47 5/9/2013)
flibble (15:43 5/9/2013)
sirbod (16:04 5/9/2013)
CJE (10:13 6/9/2013)
arawnsley (13:19 6/9/2013)
flibble (14:07 6/9/2013)
MEmerton (07:31 7/9/2013)
arawnsley (10:32 7/9/2013)
MEmerton (12:52 9/9/2013)
arawnsley (22:00 12/9/2013)
flibble (09:18 13/9/2013)
flibble (09:21 13/9/2013)
MEmerton (18:37 14/9/2013)
trevj (10:04 13/9/2013)
flibble (10:18 13/9/2013)
trevj (11:56 13/9/2013)
flibble (13:40 13/9/2013)
MEmerton (07:29 7/9/2013)
swirlythingy (02:15 5/9/2013)
sirbod (05:47 5/9/2013)
|
| |
|
Jon Abbott |
Message #122625, posted by sirbod at 06:32, 4/9/2013 |
Member
Posts: 563
|
Is there a legal way to get the address of L1PT / L2PT on RO3.5 thru RO3.71?
If not, what are the addresses for them?
From my work on getting ADFFS working on RO4/SA, I've realised things get drastically simpler if I modify L1PT / L2PT directly instead of using OS_SetMemMapEntries / OS_Memory - it avoids all the issues with flag corruption and double mapping introduced with the legal OS SWI's. |
| |
 [ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #122628, posted by Phlamethrower at 13:10, 4/9/2013, in reply to message #122625 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
There's no legal way of getting the addresses prior to RISC OS 3.8. But, I believe L1PT was fixed at &2c0c000 - that's the address the softload tool uses for 3.6 & 3.7. Unfortunately the softload tool isn't 3.5 compatible, but it should be easy enough to test on 3.5 to see if the same address works. For L2PT you should always be using L1PT to find the physical address of the L2PT entry, and then use OS_Memory 0 to map to a logical address. This is because (IIRC) L2PT isn't allocated in any pre-defined order (although, I think it may actually be indexed by physical page number? it's been a while since I've looked at that code) |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122631, posted by sirbod at 19:31, 4/9/2013, in reply to message #122628 |
Member
Posts: 563
|
Thanks, works wonderfully.
L2PT appears to be indexed by logical address. To work out the L2PT entry, I'm simply adding logicaladdress>>10 to the L2PT table address 2C00000
So for 1FD8000 its:
2C00000 + (1FD8000 >> 10) = 2C07F60
It's working, so it's obviously the correct L2PT entry. I tried using the method detailed in the ARM710/SA-110 PRM (working out the L2PT address via L1PT) but it just resulted in the wrong L2PT entry address.
If there's a correct way to work out the L2PT entry from the logical address via L1PT, you'll have to detail how it's done. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #122632, posted by Phlamethrower at 20:09, 4/9/2013, in reply to message #122631 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
L2PT appears to be indexed by logical address. Yes, I think that's correct. It was the page allocation that I was getting confused with (the physical pages used for L2PT aren't allocated in any fixed order).
For working out the L2PT address from just L1PT, take a look at the log2phys function in the softload tool. Specifically the call to svcpeek at line 464 - that calculates the L2PT entry logical address and reads from it. As far as I know that code works correctly, although I'm not sure how much actual use it's seen.
[Edited by Phlamethrower at 21:10, 4/9/2013] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122633, posted by sirbod at 21:06, 4/9/2013, in reply to message #122632 |
Member
Posts: 563
|
For working out the L2PT address from just L1PT... I've implemented it using OS_ReadSysInfo 6 for RO4+ and hardcoded it for RO3.5-3.71.
I've done no testing on RO3.8 as it wasn't an official OS release, however, I suspect RO4 rules probably apply.
Thanks for all your help Jeffrey, its greatly simplified the abort handler. I've managed to drop over 1K of assembler by switching to direct L1/2PT manipulation and it's resolved all the RO4/SA issues I was seeing. |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #122634, posted by swirlythingy at 02:15, 5/9/2013, in reply to message #122625 |
Posts: 460
|
So, are the legal OS SWIs not working as intended, then? Is that a fault in the OS, or just a deficiency in the specification? |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122635, posted by sirbod at 05:47, 5/9/2013, in reply to message #122634 |
Member
Posts: 563
|
It's a combination of deficiency and not working as intended.
OS_ScreenMode 4 simpy doesn't work on RO4/SA, it should 1. change the memory domain of the screen in L1PT and 2. clear the cacheability flag in L2PT. The former doesn't work and the later is simply missing in the OS source..
OS_Memory doesn't alter the cacheability flag on RO4/SA when asked to do so.
OS_SetMemMapEntries corrupts flags on all OS versions up to RO5, doesn't allow you to set the offset for doubly mapped pages on any OS version and on RO5 it doesn't mask out flags it can't handle, so corrupts the CAM in the case of doubly mapped pages. I raised the later as a bug last year, so it may be fixed by now.
What ADFFS does, to get legacy games working on RO3.5+ is tertiary and quad map the screen memory to the RO3.1 address space below and above 2000000, in the currently released version this works using legal OS calls, but is rather convoluted as it has to repair the corrupt cacheability flag and work around the issues with double mapped DA's.
There was no work around for the RO4/SA issues, other than directly altering the L1 and L2 page tables directly. It made sense the back port that to RO3.5-3.71, as it allowed me to drop the bulk of the abort handler, which now only handles VIDC, IOC and CursorData writes.
I've yet to look at RO5, I'm hoping I can get away with using a doubly mapped DA at the logical address 2000000 - when single tasking. |
| |
[ Log in to reply ] |
| |
|
Michael Emerton |
Message #122636, posted by MEmerton at 09:47, 5/9/2013, in reply to message #122633 |
Member
Posts: 75
|
I would love to know how my School manage to get a whole bunch of NCs with RO 3.8 on them! |
| |
[ Log in to reply ] |
| |
|
Peter Howkins |
Message #122637, posted by flibble at 15:43, 5/9/2013, in reply to message #122636 |
Posts: 892
|
I would love to know how my School manage to get a whole bunch of NCs with RO 3.8 on them! If you still have access I'd love to snaffle a rom image off one! That, and a poke around the insides to see if they differ from regular NCs.
NCOS naming/numbering is rather random  RISC OS 3.61, NCOS 1.06, RISC OS NC-5.13 etc. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122638, posted by sirbod at 16:04, 5/9/2013, in reply to message #122636 |
Member
Posts: 563
|
I tested RO3.8 last night, it has the same issues as RO4 with screen caching so I've added support for it.
I didn't realise there were any machines out there with it on though, up until now I've ignored it as being development only.
[Edited by sirbod at 22:33, 5/9/2013] |
| |
[ Log in to reply ] |
| |
|
Chris Evans |
Message #122639, posted by CJE at 10:13, 6/9/2013, in reply to message #122638 |
CJE Micros chap
Posts: 228
|
Very very few. I've never seen one except at Acorn in Cambridge. |
| |
[ Log in to reply ] |
| |
|
Andrew Rawnsley |
Message #122640, posted by arawnsley at 13:19, 6/9/2013, in reply to message #122639 |
R-Comp chap
Posts: 600
|
3.80 was only made available through Acorn's "Registered Developer" scheme (paid service), and presumably internally at Acorn.
The Reg Dev versions were nerfed to only work on ARM610/710, which led to a popular belief that it didn't work on StrongARM, and that it was therefore a dead end.
In fact one or two developers were given SA-safe builds, but only for good reason. I know we (R-Comp) were given one as we were supplying SA-optimised software for Phoebe. I assume others were given such builds, but in reality, I never saw anyone else with the SA build.
It was this SA build that led me to champion the development of RISC OS 3.80+ because I knew there was a decent product there (watch out for the filecore bug though) when others dismissed it. This is what ultimately led to RISCOS Ltd / RISC OS 4.
As I said, I never saw 3.80 SA edition outside of R-Comp / RISCOS Ltd, but obviously it'd have been around Acorn too, and I guess it may have leaked afterwards.
Bottom line - definately don't go out of your way to support it, and it shouldn't be live on any systems because of its nature (it can, and will, knacker hard drives). It will, however, be 95% identical to RISC OS 4, as RISC OS 4 was in essence 3.80 with the bugs fixed, and enhanced user interface elements. (Much of the new !Boot/!Configure was only partially implemented). |
| |
[ Log in to reply ] |
| |
|
Peter Howkins |
Message #122641, posted by flibble at 14:07, 6/9/2013, in reply to message #122640 |
Posts: 892
|
A full description of 3.80 and files for trying it can be found here.
http://www.4corn.co.uk/articles/regdev/
However the reason I'm interested in Michael's 3.80 NCs is that I've not seen 3.80 on that kind of hardware before. I'm wondering if it's a different build.
I'm currently aware of/own 3 separate 3.80 builds.
1) Registered developer, a7k/rpc (but not SA)
2) Registered developer, a7k/rpc (including SA)
3) Phoebe/RPC2 |
| |
[ Log in to reply ] |
| |
|
Michael Emerton |
Message #122642, posted by MEmerton at 07:29, 7/9/2013, in reply to message #122640 |
Member
Posts: 75
|
Bottom line - definately don't go out of your way to support it, and it shouldn't be live on any systems because of its nature (it can, and will, knacker hard drives). It will, however, be 95% identical to RISC OS 4, as RISC OS 4 was in essence 3.80 with the bugs fixed, and enhanced user interface elements. (Much of the new !Boot/!Configure was only partially implemented).
Maybe that's the reason it's in the NCs... They all booted from a Windows Share? |
| |
[ Log in to reply ] |
| |
|
Michael Emerton |
Message #122643, posted by MEmerton at 07:31, 7/9/2013, in reply to message #122641 |
Member
Posts: 75
|
However the reason I'm interested in Michael's 3.80 NCs is that I've not seen 3.80 on that kind of hardware before. I'm wondering if it's a different build.
I will have to see if I can nab one of them... Last time I went there (2 years ago) they were still using them over Citrix as an IT suit for office.
I would hate for a unique model not to go to a collection / the computer museum. |
| |
[ Log in to reply ] |
| |
|
Andrew Rawnsley |
Message #122644, posted by arawnsley at 10:32, 7/9/2013, in reply to message #122643 |
R-Comp chap
Posts: 600
|
Are we sure the ROMs were 3.80? My hazy recollection is that NCs boot from NCOS ROMs which are just enough to get going, then softload the rest from the server if needed. I seem to recall having to set up a Linux box with convoluted NFS setup to get ours to boot to anything useful.
This would make sense if the school had 3.80 softload, as the NCs would be ARM7500 which was supported by the general developer release of 3.80 if memory serves (I think it was only StrongArm that wasn't supported without the "special edition").
I could imagine an enterprising IT guy treating 3.80 as "the best" available for softload (ie. RO4 not an option) at the time? |
| |
[ Log in to reply ] |
| |
|
Michael Emerton |
Message #122647, posted by MEmerton at 12:52, 9/9/2013, in reply to message #122644 |
Member
Posts: 75
|
Are we sure the ROMs were 3.80? This would make sense if the school had 3.80 softload, as the NCs would be ARM7500 which was supported by the general developer release of 3.80 if memory serves (I think it was only StrongArm that wasn't supported without the "special edition").
I could imagine an enterprising IT guy treating 3.80 as "the best" available for softload (ie. RO4 not an option) at the time?
You may be right there...
I can recall them doing nothing if the server wasn't available.
I know the technician at the time knew nothing about the system, other than it worked, and he maintained the citrix side. |
| |
[ Log in to reply ] |
| |
|
Andrew Rawnsley |
Message #122658, posted by arawnsley at 22:00, 12/9/2013, in reply to message #122647 |
R-Comp chap
Posts: 600
|
Thinking even further, since NCs would boot from NFS or LanManFS or whatever, the bugs in filecore wouldn't even matter in to NC systems, making 3.80 perfectly viable, give or take... |
| |
[ Log in to reply ] |
| |
|
Peter Howkins |
Message #122659, posted by flibble at 09:18, 13/9/2013, in reply to message #122658 |
Posts: 892
|
Thinking even further, since NCs would boot from NFS or LanManFS or whatever, the bugs in filecore wouldn't even matter in to NC systems, making 3.80 perfectly viable, give or take... That's true, and true about NCs needing to softload things. But to get a risc os desktop you didn't load a whole rom image, just softloaded the extra desktop modules you needed.
Well at least that was my experience with NCs, the *FX0 would still say NCOS 1.06 but you'd have loaded the desktop/wimp/other bits saved out from a 3.6/3.7/3.8? machine.
All this talk is making me think I need to get my two NCs working again |
| |
[ Log in to reply ] |
| |
|
Peter Howkins |
Message #122660, posted by flibble at 09:21, 13/9/2013, in reply to message #122659 |
Posts: 892
|
Well at least that was my experience with NCs, the *FX0 would still say NCOS 1.06 but you'd have loaded the desktop/wimp/other bits saved out from a 3.6/3.7/3.8? machine. Oh another thing is that NCOS versions have Window Managers in the 3.8x range. Which might confuse things |
| |
[ Log in to reply ] |
| |
|
Trevor Johnson |
Message #122661, posted by trevj at 10:04, 13/9/2013, in reply to message #122659 |
Member
Posts: 660
|
All this talk is making me think I need to get my two NCs working again Do you also fancy having a go getting RISC OS working on the Netwinder? |
| |
[ Log in to reply ] |
| |
|
Peter Howkins |
Message #122662, posted by flibble at 10:18, 13/9/2013, in reply to message #122661 |
Posts: 892
|
Do you also fancy having a go getting RISC OS working on the Netwinder? No. |
| |
[ Log in to reply ] |
| |
|
Trevor Johnson |
Message #122663, posted by trevj at 11:56, 13/9/2013, in reply to message #122662 |
Member
Posts: 660
|
Why don't you say it like you mean it!  |
| |
[ Log in to reply ] |
| |
|
Peter Howkins |
Message #122664, posted by flibble at 13:40, 13/9/2013, in reply to message #122663 |
Posts: 892
|
Why don't you say it like you mean it! No I will not spend the months of time porting a non-open-source operating system to a development board that's over a decade old, that offers less performance than a 25 quid computer, for the board's three remaining users. I have no interest in doing it for personal development and there is certainly not the multiple tens of thousands around to fund me doing it for employment. The skills I would learn in doing the port would transfer no practical benefit to me personally or raise my value to potential employers.
These are the edited highlights, if this is not 'mean it' enough I can go fully rantomatic in a future post. |
| |
[ Log in to reply ] |
| |
|
Michael Emerton |
Message #122666, posted by MEmerton at 18:37, 14/9/2013, in reply to message #122660 |
Member
Posts: 75
|
Well all I can recall is the RISC OS 3 Initialising screen stating 3.8, and info from the switcher was 3.8.
On Monday I will give the school a call to see if they still have the admin guy I worked with. |
| |
[ Log in to reply ] |
| |
|
