Mode change procedure
Jeffrey Lee (213) 6048 posts |
I’m not sure if it does. There’s possibly some magic tied into the interlace settings, but it’s one of the things that I’m yet to get to the bottom of. ArcEm just looks at the ratio of the mode width & height and works out the scaling factors from there (if width <= height, apply 2x horizontal scale, if width >= height*2, apply 2x vertical scale). The OS uses similar logic when working out the default eigen values for a mode specifier – see here (note that the alternative RogerEXEY code isn’t used). But of course the eigen values only affect the aspect ratio the OS uses, not any scaling done by the hardware; apart from on the Pi, the hardware just outputs the signal without any scaling whatsoever and leaves it to the monitor to work out what to do with it.
There’s a compatibility mode in the OS for applying horizontal pixel doubling to certain modes (BBC modes 2 and 5, and mode 10 which seems to be the 256 colour version of the modes). So the physical buffer is 320 pixels wide, but all the OS rendering routines (or at least the ones which aren’t broken – I found a few issues with sprites when I was working on the new sprite formats in SpriteExtend) treat it as 160 pixels wide and just write out double pixels rendering. There are a couple of notes about the feature which I added to the mode variables page. |
Jon Abbott (1421) 2651 posts |
Independently, I came to the same conclusion but used HCR/VCR instead of the mode width/height so overscan modes scaled correctly. |
Jon Abbott (1421) 2651 posts |
Jeffrey, I don’t suppose you could provide the flowchart as a PDF, so it can be searched? Is the diagram complete? I can’t see where Service_ModeChanging is issued. Also, are either Service_ModeChanging or Service_ModeChange issued as part of the Mode Extension process? If I’m reading the diagram correctly, the key points of the process when Service_ModeExtension is claimed are: ModeChangeSub And at which point is GraphicsV_SetMode issued in this process? |
Jeffrey Lee (213) 6048 posts |
Possibly; I’ll check when I get home.
I think I skipped that (and GraphicsV_SetMode) because those parts aren’t involved in deciding which mode is used. The “Final VIDC list produced; proceed with mode change” node at the end of ModeChangeSub actually does the following operations:
I’m not quite sure what happens to cursor/palette/mouse updates during the mode change procedure – I thought there was some code somewhere which disabled them, but I can’t immediately see it.
They’re only issued during the “Final VIDC list produced; proceed with mode change” bit
Yeah, I think that’s correct (OfferModeExtension may also be called from the PushModeInfoAnyMonitor call from FindSubstitute from FindOKMode, but I think the combination of parameters going into PushModeInfoAnyMonitor means that it won’t actually call OfferModeExtension and will use one of the kernel’s internal VIDC lists instead) |
Jeffrey Lee (213) 6048 posts |
PDF version: http://www.phlamethrower.co.uk/misc2/ModeChangeSub.pdf |
Andrew Rawnsley (492) 1445 posts |
Since someone brought up non-square pixel modes, it is probably worth mentioning that there are quite a few displays now available with >2:1 aspect ratios (eg. resolutions of 2560×1080 or 3440×1440). RISC OS deems anything > 2:1 to be a rectangular pixel mode. I’ve written an app which we supply with such monitors to auto-correct, but if this is being looked at, it could probably do with refining the logic. I’d imagine this would also apply to multi-monitor stuff (I actually wrote the app when developing support for multi-display on RISCubes/VA). |
David Feugey (2125) 2709 posts |
Yep. I have also the problem with semi-fullscreen modes under RPCEmu (for example 1280×600). Will your software help here? |
Jeffrey Lee (213) 6048 posts |
New flowchart reflecting the recent changes (to the Kernel and ScreenModes): http://www.phlamethrower.co.uk/misc2/ModeChangeSub3.png Compared to the version in this post:
The new diagram’s arranged things into three logical groups so it should be easier to see how things fit together (core kernel/VDU driver code, kernel service call handlers, and ScreenModes service call handlers). The “fallback_resolutions” list alluded to in ScreenModes Service_ModeTranslation is here |
André Timmermans (100) 655 posts |
Thanks, for the graphs, it makes it easier to compare the kernel versus ScreenModes and reflect on the services. Examining Service_ModeExtension: |
Chris Evans (457) 1614 posts |
I may be talking rubbish but there don’t appear in the “fallback_resolutions” list any 15KHz type resolutions! |
Rick Murray (539) 13850 posts |
What about most (all?) of the ARM boards when using CVBS/S-Video? I know the Pi is clever and can rescale anything, what about the likes of the Beagle? Are they fixed at the output resolution (what is it? proper PAL D1 or 640×480?) or is there any control over the output? Could a Pi (under RISC OS control) or the Beagle be programmed to output the old TV style (15kHz) modes directly? And, as a throwaway comment – does the current implementation have a way of determining the output in question? Pi magic aside, what can be supported via analogue output and what can be supported via HDMI are going to be quite different. Can a mode providing module tell that? |
Rick Murray (539) 13850 posts |
<offtopic>
While I’m here – I recorded JESC off S4C last weekend. Watched it in Welsh (which I understand exactly none of) without subtitles as the satellite receiver doesn’t do fancy stuff while recording. And my question: it is the SD broadcast, not the HD, so it is MPEG 2 at 15MB/s, but at a resolution of 1024×576. What the heck is that? I expected MPEG 2 SD video to be 720×576. </offtopic> |
Clive Semmens (2335) 3276 posts |
I am in awe of this discussion, and thanking my lucky stars that I’ve got a working set-up without having to worry my little head about these issues. My Pi happily produces a RISCOS desktop at a huge variety of resolutions up to 3840×2160 and down as low as I care to go (1024 × 768 and probably lower) although really they’re all scaled to 3840×2160 which is what the monitor sees. Would my MDF still work if I updated my RISCOS? I’m actually pretty happy running 5.23… |
Dave Higton (1515) 3534 posts |
PAL 16:9 according to Wikipedia. |
Jeffrey Lee (213) 6048 posts |
Correct. Previously they were applied to all modes, but that’s a bit silly since MDFs offer better ways of tweaking picture position / format, and EDID in theory doesn’t need tweaking. https://www.riscosopen.org/forum/forums/3/topics/12137
Possibly. At the moment it makes sense to include it because we’re also expecting third-party modules to make sure the mode has been vetted with the GraphicsV driver (and the vet call will indicate what ExtraBytes value should be used). A better way of structuring things might be to have the kernel (or whatever invokes the service call) pass a mode vet function pointer into Service_ModeExtension / Service_ModeTranslation. That way it should be less often that the different implementations need to be changed in order to deal with changes to the mode vet process.
One of my motivations for making the changes was to make it so that the kernel’s built-in VIDC lists are inspectable by other software. So although the kernel might not require the kernel’s Service_ModeExtension implementation to support numbered modes directly, it could be useful for external software to be able to quickly get at the VIDC lists by providing a mode number. I may be talking rubbish but there don’t appear in the “fallback_resolutions” list any 15KHz type resolutions! They probably aren’t needed.
But, I can easily add them in if the lack of them causes problems (plus code to translate mode selector blocks back to mode numbers, which is something the kernel’s Service_ModeTranslation does but ScreenModes doesn’t)
https://www.yworks.com/products/yed
I believe the OMAP TV-out is sufficiently flexible that we can program arbitrary mode timings. But it’ll need a bit of a debugging session to work out what some of the relationships are between the different registers (the TRM doesn’t make it entirely clear). Also since I don’t own a CRT TV, or any known-good systems to compare against, I’m always a bit unsure over whether things are being programmed correctly or not. |
Steffen Huber (91) 1953 posts |
Usually, CVBS-HDMI converters are extremely picky, so that might be a good way to check! |
André Timmermans (100) 655 posts |
Ok, I am starting to see what you are trying to do, and I am now looking at the two Service_ModeTranslation handlers. I am assuming that in the kernel version “Double pixel mode?” is incorrect and should be read “Original BPP supported?” and so the center of thet graph is basically a “Try all BPP for resolution”. The kernel version is thus basically: Compared to that the ScreenMode version basically also try an hardcoded fallback list of resolutions and the EDID prefered mode (oabtainable via Service_MonitorLeadTranslation ?). Looking at revision 2 of the graphs, the old service handler did just translate a mode number in a mode block so maybe it is best to let Service_ModeTranslation handlers do just that and centralize the rest of the processing in FindOkMode. That would also make it easier for a third party module trying to provide support for old non-Acorn mode numbers: translating the mode number in a mode block and let the system do the hard stuff. |
Jeffrey Lee (213) 6048 posts |
Yes, the loop is effectively “try all BPP for resolution”. However the original BPP can be skipped, under the assumption that the caller of Service_ModeTranslation will have already tried it (via Service_ModeExtension). The exception to the above is double-pixel modes (2x horizontal upscaling by the OS). A double-pixel mode with a physical framebuffer size of 640×256 can be replaced with a non- double-pixel mode with a physical framebuffer size of 320×256. They will be different modes (several of the mode variables will change), so Service_ModeExtension can’t perform this substitution. But Service_ModeTranslation can. So if it’s a double-pixel mode, it will check the current BPP, so that it can check to see if a non-double pixel version of the mode is available.
Correct. |
Jeffrey Lee (213) 6048 posts |
Code for having ScreenModes return mode numbers from Service_ModeTranslation has now been added (+ diagram updated as appropriate). |