The Icon Bar: Programming: RO4 / OS_ScreenMode 4
|
RO4 / OS_ScreenMode 4 |
|
sirbod (14:10 31/8/2013) sirbod (17:45 1/9/2013) swirlythingy (20:42 2/9/2013) sirbod (18:22 3/9/2013) Phlamethrower (18:40 3/9/2013) richw (20:11 3/9/2013) sirbod (21:43 3/9/2013)
|
|
Jon Abbott |
Message #122609, posted by sirbod at 14:10, 31/8/2013 |
Member
Posts: 563
|
When running on RO4.x with a StrongARM on a RiscPC, OS_ScreenMode 4 doesn't appear to disable caching when asked too via OS_ScreenMode 4, 1, -1
From the documentation, this should turn caching off on the screen until the next mode change.
Presuming the code does actually get called (Screen_makevanilla in ChangeDyn,v), the comment above it says it should "make lower screen mapping vanilla flavour by suspending screen cleaning, then setting page mapped, uncacheable and domain 0".
From my tests, it would appear to do none of this. The memory is still in domain 1 (as can be seen by domain 1 faults), screen cleaning remains active and the memory pages are still being cached.
Also on a similar note, OS_Memory on RO4.x doesn't turn caching off when a StrongARM is present. On RO3.71/SA OS_Memory works correctly when asked to turn caching off, so it seems to be broken in RO4.x+.
Is this a known bug / feature? |
|
[ Log in to reply ] |
|
Jon Abbott |
Message #122611, posted by sirbod at 17:45, 1/9/2013, in reply to message #122609 |
Member
Posts: 563
|
OS_ScreenMode 4, 1/3, -1 definitely doesn't call Screen_makevanilla, I've confirmed that much.
Using the Screen_makevanillla code works in that it switches the pages to domain 0 and turns off the screen cleaning, however it doesn't alter the catchable flag for the pages. Shouldn't it clear the C and possibly B flags in L2PT?
Having never touched L1/2PT how do I work out where the relevant entries are to clear the C / B bits?
;action: make lower screen mapping vanilla flavour by suspending screen cleaning, then setting page mapped, ; uncacheable and domain 0 ; Screen_makevanilla ROUT Push "r0-r8,LR" [ ARMSASupport MOV r0,#6 SWI XOS_ScreenMode ;force screen to be clean MOV r0,pc ORR r1,r0,#I_bit TEQP r1,#0 ;disable IRQs MOV r1,#0 LDR r2,[r1,#ARMA_Cleaner_status] ORR r2,r2,#ACS_SCsuspend BIC r2,r2,#ACS_VSCpending_MASK BIC r2,r2,#ACS_Scacheflag STR r2,[r1,#ARMA_Cleaner_status] TEQP r0,#0 ;restore IRQs TST r2,#&80000000 BNE %FT99 ;assume already vanilla if SC disabled MOV r0,#2 MOV r1,#ChangeDyn_Screen SWI XOS_DynamicArea BVS %FT99 SUB r0,r3,r2 ;base of lower of the two mappings MOVS r1,r2 ;size BEQ %FT99 MOV r3,#L2PT ADD r4,r3,r0,LSR #10 ;L2PT of base (L2PT stuff will still be set up, though unused) ADD r5,r3,r4,LSR #10 AND r4,r5,#3 ;remember 1k offset into L2PT page itself, for later BIC r5,r5,#&3 ;L2PT of L2PT of base LDR r6,[r5] MOV r6,r6,LSR #12 MOV r6,r6,LSL #12 ;physical address of L2PT of base, except for offset ORR r6,r6,r4,LSL #10 ;and now including offset ORR r6,r6,#&11 ;for vanilla L1PT entry - is domain 0, page LDR r7,=L1PT ADD r7,r7,r0,LSR #18 ;r7 -> 1st L1PT entry for screen 01 STR r6,[r7],#4 ADD r6,r6,#&400 ;next L2PT physical address (1k per 1Mb of mapping) SUBS r1,r1,#&100000 BGT %BT01 99 ] ;ARMSASupport Pull "r0-r8,PC"
[Edited by sirbod at 20:24, 1/9/2013] |
|
[ Log in to reply ] |
|
Martin Bazley |
Message #122612, posted by swirlythingy at 20:42, 2/9/2013, in reply to message #122611 |
Posts: 460
|
I tried to disable screen caching on RO4 once. Read the same docs you did. Eventually gave up. |
|
[ Log in to reply ] |
|
Jon Abbott |
Message #122617, posted by sirbod at 18:22, 3/9/2013, in reply to message #122612 |
Member
Posts: 563
|
I've reimplemented Screen_makevanilla with additional code to turn caching off in L2PT, this has worked around the issue.
Ignoring the fact OS_ScreenMode 4 doesn't call Screen_makevanilla, it would never have worked anyway, as it doesn't actually disable caching and only changes the memory domain from 1 to 0 which turns off the screen scrubbing.
I'm surprised RO4 got to 4.39 without it being noticed. I've seen lots of people mentioning games flickering on the net, but nothing around any bug in OS_ScreenMode 4.
Hopefully RO5 doesn't contain the Chocolate screen code, so it shouldn't suffer the same problem on IOMD. I'm not it a position to check yet, as 32bit gaming support is the next thing on my list once RO4/SA is working - although I've got games running, there's still a few issues to resolve. |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #122619, posted by Phlamethrower at 18:40, 3/9/2013, in reply to message #122617 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Hopefully RO5 doesn't contain the Chocolate screen code It doesn't. And when/if we do add support for screen caching, we'll hopefully remember to make sure it works properly! |
|
[ Log in to reply ] |
|
Richard Walker |
Message #122622, posted by richw at 20:11, 3/9/2013, in reply to message #122617 |
Member
Posts: 73
|
32bit gaming support is the next thing on my list once RO4/SA is working - although I've got games running, there's still a few issues to resolve. Hi Jon,
Is that your general aim re. compatibility? Games to work on a StrongARM Risc PC with RISC OS 4.02?
I've been meaning to comment on JASPP for some time. I am tracking the progress excitedly, and continue to be impressed. Some years ago, I started trying to collect games in Arculator. I was frustrated by the lack of compatibility, key disks, missing manuals etc. It sounds like you have got all of these licked!
I sincerely hope that the few remaining publishers follow R-Comp's lead and realise that spreading around the old titles freely will encourage use of the platform (perhaps even leading to purchases of more recent titles?).
I am super impressed with the whole thing, and cannot wait to see the web site and the first disk images etc. I wish I had time to contribute in some way, but having two under 4s makes it hard!
Cheers, Richard. |
|
[ Log in to reply ] |
|
Jon Abbott |
Message #122623, posted by sirbod at 21:43, 3/9/2013, in reply to message #122622 |
Member
Posts: 563
|
Is that your general aim re. compatibility? Games to work on a StrongARM Risc PC with RISC OS 4.02? The ultimate aim is to get all original Arc games working on current Risc OS machines, the Pi being the prime goal as its cheap. That should also get them working in the Iyonix and most if not all machines that can run RO5.
The past nine months have been spent getting VIDC1 to VIDC20 translation working, so that 1. we have a good understanding of both VIDC1 and VIDC20 and 2. have a stable base to build a generic translator for non-Acorn GPU's.
That release (2.17) has been ready for a few weeks, but unfortunately I still can't log into the FTP site to upload it and release, hopefully Jason will get that resolved soon.
2.17 however doesn't work on RO4 with a StrongARM, due to the lazy task swapping and screen caching. I've been working on that and have it pretty close to working. Magic Pockets and Zarch certainly both work without flickering (which is what this thread is about). I still have some issues when returning to the desktop, which I need to resolve though.
Once that's all working, 32bit support is the next goal. Steve has already done a lot of work on shims for the various SoundTracker modules used over the years, I need to sort out 26bit module support, video translation, sound translation, self modifying code support and 26bit PC emulation.
I would have liked to have released game images by now, we have permission for about 90, although without a web site that's hosted at The Centre for Computing History, that's not been possible.
However, that's not stopped development or archiving. We have around 1/2 of all games either fully archived or in progress. They include scans of the boxes, PDF manuals, protection sheets, screenshots, floppy images and where available passwords, level maps, hints/tips etc. Most also have boot scripts to run the game, which fix bugs and compatibility issues.
If anyone wants to help with any if this, by all means contact me. |
|
[ Log in to reply ] |
|
|
The Icon Bar: Programming: RO4 / OS_ScreenMode 4 |