stability of OS 5.25 05-Aug-18
18 posts, 6 voices
André Timmermans (100)
655 posts
|
I just gave a quick try of the 5.25 on mi PI3 and it was so instable that I reverted to 5.24 in less than 5 minutes. - KinoAmp showed no image when used in full screen mode (1920×1080 16M) |
|
André Timmermans (100)
655 posts
|
Here is the dump for SparkFS: Error block: 80000002 Internal error: abort on data transfer at &204D9CA4 R15 = 204d9ca4 = SparkFS +c670 SVC stack: R14_usr = 00000001 is system workspace USR stack: End of dump |
David Pitt (3386)
1248 posts
|
Using the RPi3B+ OS5.25 (14-Jul-18) with the (only) test file I have, which is 4×3, did play in full screen 1920×1080 16M pillarboxed but the desktop backdrop was flickering badly on both sides. A proper black pillarbox appears with OS5.24 and OS5.25 (22-Jun-18) the fault appearing with OS5.25 (02-Jun-18). Gamma is disabled in
Haven’t seen that. Otherwise OS5.25 (05-Aug-18) doesn’t look like an instant disaster here. |
Jeffrey Lee (213)
6048 posts
|
Make sure that you have both entries on the same line (separated by spaces). Multiple lines won’t work (I think the GPU only reads the first line of the file). |
Andrew Rawnsley (492)
1445 posts
|
It probably isn’t related, but a number of people reported issues in 5.25 with a variety of programs which ultimately stemmed from the HidePtr module supplied in versions of !Zap. Rick Murray’s latest Zap builds disable the module so that it can’t cause problems. |
|
André Timmermans (100)
655 posts
|
That seems to have solved the SparkFS issue. It reminds me that I had a similar issue with RISC OS 6 were HidePtr makes a complete mess of the Desktop. I have also corrected my CMDLINE/TXT file so the only remaining issue at the moment seems to be KinoAmp’s black screen in 16M full screen mode except when using the “System” scaler. In other words it plotting through OS_SpriteOp is fine but directly accessing the screen memory leaves the screen black. |
Jon Abbott (1421)
2651 posts
|
I wonder if that’s related to the OS_ReadVDUVariables bug I came across a few weeks back? How is KinoAmp getting the screen address? It’s worth confirming that the address is correct. If it’s the issue I highlighted, then OS_ReadVDUVariables will be returning the wrong address. The workaround is to issue OS_Byte 112,1 before calling OS_ReadVDUVariables. |
|
Jeffrey Lee (213)
6048 posts
|
I expect that bug is related to switching between DA 2 and GraphicsV 9 during mode changes, and so isn’t likely to get hit during normal use. While testing the overlay support I did discover that KinoAmp was writing 0 to the alpha channel, but I haven’t had a chance to check if that’s the problem here (new versions of BCMVideo should use alpha-blending in alpha-channel screen modes) |
|
André Timmermans (100)
655 posts
|
I have been doing some debugging on KinoAmp by changing the backgound color and playing a 4:3 video on my 16:9, and I see a black rectangle in the middle of the screen. YUV to RGB conversion is ok (saving that converted output as a sprite or plotting it with OS_SpriteOp works fine) but using any of the three 32bpp scalers that directly accesses the screen (internal, linear and bilinear) produces a black output while the same scalers work fine in the desktop.The bug is likely in KinoAmp itself but I haven’t figured it out yet. |
|
André Timmermans (100)
655 posts
|
I have no tested in the desktop using the LAGBR option and I know also get a black image. I guess that for maximum compatibility, if mode variable 0 (flags) is not specified to OS_ScreenMode 0, the TGBR variant should be returned. |
|
Jeffrey Lee (213)
6048 posts
|
That’s exactly how things currently work. |
|
André Timmermans (100)
655 posts
|
No I get an ABGR32 mode, that’s why KinoAmp full-sceen remained black (till I added support for alpha modes today). |
|
André Timmermans (100)
655 posts
|
I think it would be helpful to have 2 Sticky posts in the Bugs forum to centralise. The first one should concern debugging info/tools (the Excdump which I didn’t know about till a few days ago, ZeroPain, …), the other Known OS stability issues/solutions and major behaviour changes that occur in the OS (like high vector builds, the “disable_mode_changes” and “disable_gamma” options for PI3, Zap’s HidePtr causing major instability on OS 5.25, …). All such info appears at one point or another on the forums and you can perform search on the forums but you can’t search for what you have no clue about. |
Rick Murray (539)
13850 posts
|
[…]
Arguably these really belong in the wiki, not in the forum. But, again, it requires you to read and know what you’re looking for. Exception dumps, etc: https://www.riscosopen.org/wiki/documentation/show/Debugging%20guide <fx: reads> Hmm, I wonder if I could use HangWatch to work out why DigitalCD freezes the machine when playing streaming radio? Jeffrey – if you’re there – is there a pre-built version of HangWatch? Shouldn’t these things perhaps be in BonusBinDev? |
|
Jeffrey Lee (213)
6048 posts
|
That’s exactly how things currently work. That sounds like a bug then. DIM B% 64 B%!0=1 B%!4=640 B%!8=480 B%!12=5 B%!16=-1 B%!20=-1 FOR A=0 TO 1 SYS "OS_ScreenMode",0,B% PRINT "Mode flags ";STR$~((VDU 0) AND NOT 64) SYS "OS_SetColour",0,&FF0000FF RECTANGLE FILL 100,100,100,100 SYS "OS_SetColour",0,&FF RECTANGLE FILL 300,100,100,100 A$=GET$ B%!20=0 B%!24=&8000 B%!28=-1 NEXT A For the first mode you should see “mode flags 0” and two red rectangles. For the second mode you should see “mode flags 8000” and one red rectangle. If you see anything else, then something must be wrong (do you have anything else running like AnyMode? How old are the firmware files you’re using? What settings are in config.txt?) |
|
Jeffrey Lee (213)
6048 posts
|
You should be able to, although it’s less than ideal on the Pi because the FIQ vector is used for USB by default (so allowing HangWatch to use it might affect things. And although recent versions of HangWatch can run off the IRQ vector, that’ll obviously decrease its detection ability).
No. As you’ve no doubt noted from the wiki page, you’ll need a ROM which has HAL_DebugTX enabled (and probably ‘DualSerial’ removed so that the OS won’t also try using the serial port). If you’re building a customised ROM then working out how to download and build HangWatch should be trivial. And when you’re dealing with the really nasty bugs, often you need to hack things into the OS or the debug modules in order to help you track it down.
Perhaps. n.b. I’ve also been on-and-off attempting to track down a total lockup that DigitalCD can trigger while playing music (on iMX6). Trouble is, the HangWatch watchdog doesn’t fire, so I’ve had to resort to other means to try and locate the problem (getting a trace of HAL IRQ calls to make sure nothing is disabling important IRQs (which can also be used to check it’s not in an IRQ handler when the hang occurs), adding tracing to the kernel to determine whether it’s inside a callback when the hang occurs, etc.) |
|
André Timmermans (100)
655 posts
|
Just in case, in DigitalCD’s Choices window section Drivers → DiskSample there is an option “Enable interrupts”. Normally DiskSample (and TimPlayer) leave interrupts disabled while filling the soundmda/sharedsound buffers but you can change that with this option.
Your text program works fine but KinoAmp still gets an ABGR32 mode. Puzzling!. I wonder if all that OS_ScreenMode stuff in display_init() to build a list of available resoultions and colors could be somehow influemcing ths mode change call. I only load AnyMode manually when required for testing. Frimare is from 15 Apr 2018 and config/txt contains: note that when I tried to use framebuffer_ignore_alpha to 1 in order avoid alpha modes, KinoAmp could not start in 16M full-screen mode with an error which was something like “Mode not supported”. |
|
Jeffrey Lee (213)
6048 posts
|
Yes. KinoAmp is using GraphicsV 17 to get a list of all the pixel formats the driver supports. For each colour depth, it overwrites the corresponding col_flags entry with the mode flags. So if the list returned by GraphicsV has the alpha formats after the non-alpha formats, when display_setup switches to a fullscreen mode it’ll be selecting an alpha mode because that’s what col_flags contains the flags for.
Yes, BCMVideo will still list the alpha pixel formats in the GraphicsV 17 output, so KinoAmp will still get confused and try using them. (GraphicsV 17 lists the combined set of pixel formats supported by both the desktop and the overlays – so although you can’t use alpha in the desktop with framebuffer_ignore_alpha=1, you can still use alpha in overlays) |
