GraphicsV questions
Pages: 1 2
Jeffrey Lee (213) 6046 posts |
My preferred choice for tidying up the code would be to fix the known issues with OS_UpCall 6 / RT_Yield, and then change VCHIQ to use synclib’s synchronisation primitives (extending synclib where relevant, e.g. semaphore support). But for a quick fix, maybe changing mutex_lock to behave like down_interruptible (enabling IRQs around the RT_Yield call) would be enough. |
Jon Abbott (1421) 2597 posts |
I wouldn’t implement a quick fix, there may be a knock on effect. Extending a suitable library to provide semaphore support would be the preferred route to take. As a workaround to the locking, I’ve changed my RTSupport based VSync generator so it no longer directly raises GraphicsV 1, but instead uses a semaphore, so the next GPU VSync is passed through as my driver. It’s altered VSync timings slightly, but I can compensate for that by reducing the IOC Timer flyback period. If/when VCHIQ is tidied up, I’ll switch it back to generating the VSync. |
Jeffrey Lee (213) 6046 posts |
you’ll have to wait until I’ve had a chance to add GraphicsV 19 calls to the kernel Just letting you know that I’m still working on this! I’ve made some good progress this week, but that progress revealed that there’s more work to be done to make everything work properly. What I’m aiming for is the following:
The above has hit on some undefined/undocumented areas of the OS, relating to if/how you can specify non-standard modes (double vertical, double pixel, gap modes, etc.) via mode selector blocks & mode strings, how much of a mode selector block a Service_ModeExtension implementation needs to look at, etc. So I’ve been researching that today, and will try and write up my findings on the wiki over the next day or two. And of course at some point I’ll be making sure all the VIDC lists get vetted via GraphicsV 19, both to add support for the ExtraBytes control list item, and so framebuffer switching can be supported. |
Colin Ferris (399) 1735 posts |
Getting a numbered MODE for 1024×768 256C was interesting. Config. MODE seems to be set ok – but RO with no Boot running doesn’t pick it up on startup. |
Jeffrey Lee (213) 6046 posts |
I think 16/32bpp numbered modes will only work properly with RISC OS 5, and only after July 14th. Other OS versions will be using the wrong palette/gamma data.
If you aren’t running Boot, how are you loading the mode? If you’re loading it via a podule (or podule ROM in an emulator), chances are the kernel will have done its initial mode change before your module has been initialised (especially on RISC OS 3/4). So you’ll probably have to modify your module so that during initialisation it registers a callback which performs a mode change (to the desired mode). Trying to replace an os mode – came up with a jumbled screen. The kernel isn’t designed to allow you to replace the builtin modes – there are numerous short-cut paths in the kernel which will look up values directly in the builtin table of mode variables. |
Colin Ferris (399) 1735 posts |
The Modes module is loading from ‘Chunks’ dir in Windows. {have a HardDisc_C on the Icon Bar – and just drop files directly into ’Chunks’} The ro3.1 Modes module is picked and used in startup -RedSq Just tried 14 Aug 2018 version – and indeed – both the 16bit & 32bit colour modes work ok – The Apple shows well. Just will have to try and see what is upsetting !Zap. |
Jeffrey Lee (213) 6046 posts |
you’ll have to wait until I’ve had a chance to add GraphicsV 19 calls to the kernel Still going! For assorted reasons I didn’t get much done the past few weeks, but this weekend I managed to get things to the point where all the major functional stuff is done. So hopefully I’ll be able to get it tidied up, tested, and checked in sometime this week. I still need to add support for the “min screen banks” mode variable – that’ll probably be my next task once this current batch of changes is checked in. |
Jon Abbott (1421) 2597 posts |
Once it’s in I’ll unpick the many workarounds and see which issues are resolved. The key issues I think were:
I suppose I should also look at coding a separate driver that does software scaling for the EDID/MDF crowd that want legacy modes. |
Jeffrey Lee (213) 6046 posts |
I haven’t tackled that issue yet – when I get home I’ll have to double-check where it is on my todo list.
That should be fixed; a test driver of mine which does the GraphicsV 19-based framebuffer switching seems to work OK.
Yes please! |
André Timmermans (100) 618 posts |
Somewhat reminds me of how OS_ReadVduVariables 148 (and/or 149 ?) is always reset to the start of the first screen bank when you switch output back from a sprite to the screen. |
Jon Abbott (1421) 2597 posts |
I believe I’ve found another instance of VCHIQ locking the machine. I’ve been doing some digging into why Hero Quest locks when it calls OS_File after you select the language, and found the PC is stuck in a VCHIQ wait loop in BCMSound.
Is it wise to have such loops in the OS? Should they not either timeout/recover or be handled via a callback if its waiting for a result to become available? How many other instances of this type of loop are there in the OS? |
Pages: 1 2