This screen mode is not suitable for displaying the desktop
109 posts, 18 voices
Martin Avison (27)
1494 posts
|
@David: Yes, I raised the ‘Memory cannot be moved’ message in that thread last October, and I still have the problem – though I have not changed anything that might fix it. @Chris E: You just asked on the other thread to post here if I have an RTC fitted: yes I do. |
Chris Hall (132)
3554 posts
|
AFAIK the only way to get the actual GPU output resolution is to query it via the VCHIQ display service (e.g. vc_dispmanx_display_get_info) Yes. Message 40003 doesn’t seem to read the GPU frame buffer at all, it seems to read the RISC OS frame buffer. |
Chris Mahoney (1684)
2165 posts
|
I believe that VCHIQ is more-or-less a direct port across from Raspbian so I suspect that you’ll need to dig out the Linux documentation. I have no idea where to find it :) The stuff from the C wrapper may also be slightly helpful, if only to indicate what goes in each register:
static inline _kernel_oserror *vchi_service_open(VCHI_INSTANCE_T instance,
SERVICE_CREATION_T *setup,
VCHI_SERVICE_HANDLE_T *handle)
{
return _swix(VCHIQ_ServiceOpen,_INR(0,1)|_OUT(0),instance,setup,handle);
}
static inline _kernel_oserror *vchi_service_use(VCHI_SERVICE_HANDLE_T handle)
{
return _swix(VCHIQ_ServiceUse,_IN(0),handle);
}
|
|
Chris Hall (132)
3554 posts
|
I believe that VCHIQ is more-or-less a direct port across from Raspbian so I suspect that you’ll need to dig out the Linux documentation. Many thanks. That may take some time so I’ve released a utility for the Raspberry Pi that shows RISC OS resolution, GPU resolution (unknown) and Monitor capabilities as well as Pi board revision. Once I work out how to interrogate the GPU properly, it’ll show GPU output resolution. Screenshot of it running on a Raspberry Pi model 3 using RC14 plus update 4 (image below updated to version 0.04 05-Sep-2016):
Download from !Store or from here |
|
Chris Hall (132)
3554 posts
|
The monitor information is obtained via EDID. It will be blank if there is no EDID information received by the GPU. In the case where there is no EDID information (e.g. VGA adapter) then the GPU is told by config/txt what to use and at present I cannot find the right syntax to ask the GPU what it is sending to the monitor. The GPU cannot know the monitor’s capabilities other than via EDID. Lower resolutions, up to 1024×768, from EDID now included in version 0.02. Where there are many EDID entries, not sure how to identify the one that specifies the native resolution. |
Raik (463)
2061 posts
|
I have try with the portabel solution e.g. PiTop, Lapdock + Zero, Lapdock + Mod. A… all the same. With !ScrHelp: With *ReadEDID": With *CreateModeFile I get this MDF witch not works correctly. |
|
Raik (463)
2061 posts
|
Have you try *ReadEDID and *CreateModeFile |
|
Chris Hall (132)
3554 posts
|
Version 0.02 of !ScrHelp now includes 640×480 60Hz, 720×480 60Hz, 800×600 60Hz, 1024×768 60Hz – these are expressed in a bit field (sixteen of the ‘commonest’ modes in 16 bits) which version 0.01 didn’t bother with. I haven’t been able to test it yet as my monitors are mostly modern ones… Am starting to get to grips with vc_dispmanx_display_get_info. Starting with: SYS “VCHIQ_ServiceOpen”,buf%,instance%,setup%,handle% TO ,instance%,setup%,handle% but having some trouble working out what to put in memory before the call… It’s a bit like writing multi-tasking applications before the PRMs were produced and making guesses at what does what (in that case from desktop apps written in BASIC in Resources). |
Rick Murray (539)
13840 posts
|
Is there any way to use ReadEDID or CreateModeFile without having RISC OS take action upon it? In the few times I can get a stable picture out of the Beagle xM, using either of them kills video completely. I suspect it is trying to do 1280×1024-60 which is the native resolution of the monitor but is not something the OMAP is capable of in a manner that my VGA dongle recognises as a valid video signal. I’d like to get the timings for a lower res mode like 800×600 to see if I can get any of that to stick… |
|
Chris Hall (132)
3554 posts
|
Use a Raspberry Pi connected to the monitor in question and then run the following to get the EDID block (lines 1610 to 2050 are just examples of displaying info, see the EDID spec for what the data mean, b% is the block number: |
Jeffrey Lee (213)
6048 posts
|
Am starting to get to grips with vc_dispmanx_display_get_info. Starting with: If you want an example to go by, take a look at the hardware pointer code in BCMVideo since it uses the display service to read the GPU output resolution (HWPDisplayWidth, HWPDisplayHeight). The basic sequence of events is:
CreateModeFile will read the EDID and write out the MDF without affecting the current configuration. |
|
Raik (463)
2061 posts
|
*ReadEDID writes nothing out but you get changed setting behind the display Icon on the Iconbar… *CreateModeFile If nothing is detected… |
|
Chris Hall (132)
3554 posts
|
Many thanks for the help. Am slowly getting there. There are a few assembler commands that BASIC does not recognise, such as Entry, EXIT, ASSERT, ROUT. I have replaced EXIT by MOV PC,R14 but don’t know whether ROUT is important. Edit: I also need to find the magic number for VCHI_CALLBACK_MSG_AVAILABLE. I think I have worked out that ASSERT is simply an assignment (for the result) and EXIT is a macro that returns to the calling programme (here BASIC so MOV PC,R14 should be OK). Entry and ROUT still seem inpenetrable though. Can’t remember the significance of R12 but do recall that it has a special value in BASIC so is hopefully OK. There is a similar sequence in the ROM so I’ll try checking against that… Here’s where I’ve got to so far (at least BASIC assembles it OK): |
David Pitt (102)
743 posts
|
The minimalist example is a bit too minimalist, it is taken from
1995 PRINT a3$ |
|
Chris Hall (132)
3554 posts
|
The minimalist example is a bit too minimalist, i Yes, sorry. It does get the EDID blocks into memory though… |
|
Chris Hall (132)
3554 posts
|
Now almost working but I get an abort on data transfer at the PC address corresponding to (without thinking about pipelining) code at line 1470 (just after the first ‘FT90’ label, strange there is more than one) where it does STR r7, [sp]. Puzzled. Commenting out the line The ARM code in HWP_WaitFor looks rather exotic, especially LDR PC,IRQTrigger where IRQTrigger doesn’t seem to be defined… |
Fred Graute (114)
645 posts
|
You can’t have 2 labels with the same name in the BASIC assembler. If you do then the latter one will determine its value. You’re using |
Steve Drain (222)
1620 posts
|
A good warning, but it can be done with what is called 2½-pass assembly instead of 2-pass. In the second of the usual 2-passes, each routine is assembled again with errors off before being assembled with errors on. I use that for all my source. |
Colin Ferris (399)
1814 posts
|
Could we have a little example of 2-1/2 assembly? I think ObjAsm used to give an error if two ALIGN’s were in the left hand margin – and didn’t inform you they were in the wrong place! |
jan de boer (472)
78 posts
|
Re. the TestVC program: could it be that Basic assembles the EQUW’s into two-byte entities, while four-byte is meant? E.g. line 510 is a four-byte word. With EQUW’s, you might get alignment errors and undesired overwrites. What happens if EQUD’s are used? |
|
Fred Graute (114)
645 posts
|
Ah, yes, thanks for the reminder. The late Martyn Fox used this too. I suppose having homonymous labels would also work with 1 pass assuming you only have backward references. |
|
Chris Hall (132)
3554 posts
|
I know two labels with the same name are wrong, but the example used two labels with the same name but was more complicated because the branch was to %FTnn and the label was just nn. EQUW should be EQUD (silly me) of course. And BL (now I remember) doesn’t stack properly on its own (but the example code used in the rom presumably works OK though). At least it runs now with no errors, just doesn’t return to BASIC. Will have another look tonight. I still have to find the magic number for VCHI_CALLBACK_MSG_AVAILABLE (which I have guessed as zero for the moment) and puzzle out the meaning of IRQTrigger which is not defined. Also add some stack pushing and pulling around BL so it can return to BASIC OK. |
|
Jeffrey Lee (213)
6048 posts
|
Entry and EXIT are macros used for creating stack frames, e.g. Entry "r0-r7", VCHIQ_Service_Size is equivalent to STMFD sp!,{r0-r7,r14}
SUB sp,sp,#VCHIQ_Service_Size
EXIT is context-sensitive – it will pop the stack frame corresponding to the preceding Entry (in program listing order), e.g. ADD sp,sp,#VCHIQ_Service_Size
LDMFD sp!,{r0-r7,pc}
EXIT can also be used conditionally, e.g. the EXIT VS to only exit if the V flag is set. ASSERT is used to check values, not for assignment. It will cause the assembly to fail if the expression evaluates to false. The numbered labels are local labels. %FTnn will reference the following label with number nn, while %BTnn will reference the preceding label with the number nn. The labels can be multiply defined (it just uses the first one it finds when scanning forwards/backwards). To avoid accidentally referencing labels from unrelated routines the ROUT directive is used to limit how far the assembler will search (i.e. it will stop and throw a “label not found” error if it hits a ROUT while looking for a local label). There are also a couple of other variants of local label but they’re rarely used in the RISC OS sources (the armasm docs are a reasonable reference – I think objasm has the same capabilities)
In BCMVideo R12 would be being used for the module workspace pointer. VCHIQ_Initialise is given the R12 value so that when it provide it to any of the callbacks it calls (e.g. HWP_ClientCallback). This makes VCHIQ easier to use from modules (especially C modules, where CMHG-generated veneers require the private word to be provided in R12) I think BASIC allows assembler routines to trash everything except R13; variables only have significance if you’re planning on calling back into BASIC.
The main module sources initialise that. But since you’re only sending a couple of messages it shouldn’t hurt to simplify HWP_WaitFor so that it just sits in a loop and waits until LDR r0,[r1] is non-zero. (Plus you’re in user mode, so the PSR manipulation to enable/disable interrupts won’t work) |
|
Steve Drain (222)
1620 posts
|
My pleasure. Here is a simple example where |
|
Steve Drain (222)
1620 posts
|
I should add that I have used |
