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
- 10 RISC OS gift ideas for Christmas (News:)
- 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)
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: 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
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15057
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: 32
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! big smile

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