Pointer moves out of resize icon when dragging beyond maximum window size in Paint [Open]
If I enlarge a Paint sprite (edit) window by dragging the adjust size (resize) icon in the bottom right corner, the pointer moves out of the icon if I continue to drag beyond the maximum window size.
Usually, the pointer is bound to the icon as long as you keep dragging. The Paint sprite file window or any Filer window work this way.
This can best be reproduced with a smaller window.
System: RISC OS 5.28 (16-Dec-29) with Paint 2.37 (10-Aug-20)
cc 5.89: _Generic breaks when used with pointers
[Fixed]
If _Generic is used to identify pointers to types, then (a) the compiler will access zero page when compiling the code, and (b) the compiled code will fail to identify the type of value (it'll take the default case in the _Generic statement, if there is one).
cc 5.88: __return_address() can be broken by tail-call optimisation or -APCS /nofp
[Fixed]
In some situations the __return_address() intrinsic will read from a nonsense stack offset.
When compiling the sample code with "cc -S test.c" and examining the output, the "tailcall" function is broken, suggesting a problem with tail-call optimised functions.
When compiling with "cc -S -APCS /nofp test.c", both "tailcall" and "normal" are broken, suggesting a problem with functions which have a stack frame but no frame pointer register.
Wimp title bar validation crash
[Fixed]
I discovered that development versions of PrivateEye were crashing specific other tasks, including Maestro, when they were loaded to adjacent positions on the icon bar.
After a lot of hunting I found that ccres (the Template/Res<->Text tool) outputs Templates which include a title bar definition which points to an empty string. Normally this would be encoded as a validation string pointer of 0 or -1 in the window definition. It's unusual, but not wrong per-se.
It turns out that this causes Wimp_CreateWindow to call checkextent > minwindowx > seticonptrs which in the "check for line spacing" chunk calls pageiniconbartask. This seems to page out the active task and we end up with (in my tests) Maestro running while the validation string pointer from one of PrivateEye's windows is used... seticonptrs then instructs findcommand to hunt for an 'L' validation string using PrivateEye's title bar validation string pointer, but using Maestro's RAM. If Maestro's not got enough RAM, then bang, it crashes and then PrivateEye explodes too.
I've observed the same behaviour on various Wimps back to 3.7. I've not tried earlier.
CM4 mouse doesn't move without PCIe peripheral
[Fixed]
On three start ups out of 4 the mouse pointer appears frozen in mid screen, making it very difficult to click over the right item.
WindowManager can abort on data transfer when auto-scrolling
[Fixed]
If a wimp task uses Wimp_AutoScroll to start scrolling a window then a data abort occurs in the window manager under the following conditions:
# Wimp_AutoScroll is used to start scrolling a window with no wimp icons.
# The auto-scrolling window has scrolled as far as it can given the position of the pointer.
# After the scrolling has reached it limit, but still active the pointer is over an icon in different window.
This was originally noticed in Avalanche and after some investigation, it appears that the WindowManager is using the ID of the icon under the pointer with the data structures for the auto-scrolled window. If there have never been any icons in that window then this results in an invalid pointer dereference.
See https://www.riscosopen.org/forum/forums/11/topics/16312?page=3#posts-120698
This isn't limited to Avalanche, the following BASIC application can be used to reproduce the problem as follows:
# Open a window containing some icons, e.g. the disc Free Space display.
# Run the test application below
# Position the test application's window just above the first window opened.
# Move the pointer into the test application's window and perform a SELECT drag. This should initiate auto-scrolling and the pointer will change accordingly.
# Move the pointer over one of the icons in the first window opened
# Wait for the auto-scroll to reach the limit of the window.
This triggers a data abort at exactly the same location in the WindowManager as in the VNC Client discussion referenced above.
bc.. ON ERROR ON ERROR OFF:ERROR ERR, REPORT$ + " at line " + STR$(ERL):END
SYS "Wimp_Initialise",310,&4B534154,"AutoScroll Test",0
DIM blk% 256
b% = blk% + 4
b%!0 = 300
b%!4 = 300
b%!8 = 500
b%!12 = 500
b%!16 = 0
b%!20 = 0
b%!24 = -1
b%!28 = &FF000052
b%!32 = &01070207
b%!36 = &00010301
b%!40 = 0
b%!44 = -300
b%!48 = 300
b%!52 = 0
b%!56 = &90000091
b%!60 = 10<<12
b%!64 = 1
b%!68 = &0000800080
$(b%+72) = "AutoScroll" + CHR$0
b%!84 = 0
SYS "Wimp_CreateWindow",,b% TO window%
!blk%=window%
SYS "Wimp_OpenWindow",,blk%
quit%=FALSE
REPEAT
SYS "Wimp_Poll",&3933,blk% TO event%
CASE event% OF
WHEN 2: SYS "Wimp_OpenWindow",,blk%
WHEN 3: quit%=TRUE
WHEN 6: PROCclick(blk%)
WHEN 17: IF blk%!16=0 quit%=TRUE
ENDCASE
UNTIL quit%
SYS "Wimp_CloseDown"
END
DEF PROCclick(blk%)
IF blk%!8 = 64 THEN
blk%!0 = window%
blk%!4 = 80
blk%!8 = 80
blk%!12 = 80
blk%!16 = 80
blk%!20 = 0
blk%!24 = 1
blk%!28 = 0
SYS "Wimp_AutoScroll",3,blk%
ENDIF
ENDPROC
p. RISC OS 5.28 (16 Dec 2020) on a RPi 2B
cc 5.79, 5.80, 5.82: LDRSB is sometimes broken
[Fixed]
When targetting an ARMv4+ CPU, compiler versions 5.79 and newer generate incorrect code when using LDRSB to access an int8_t and convert to int32_t. 5.78 and older appear to be fine.
Although the LDRSB instruction targets the correct memory address, the loaded value is then "ASR #24"'d before it gets used.
This only seems to affect situations where the compiler knows the value is on the stack or has static storage. int8_t's accessed via arbitrary pointers appear to work correctly.
The attached test case shows a few different situations which either succeed or fail (just compile with '-cpu 4' or higher)
cc 5.72 and older: Inlined memset can result in pointer drift
[Fixed]
"As described in this thread":https://www.riscosopen.org/forum/forums/4/topics/9010, if the compiler replaces a call to memset(ptr,value,size) with an inline version then there's a chance that the variable 'ptr' will be left pointing at the end of the block instead of the start. This seems to happen whenever 'size' becomes too large for the SUB to be able to represent it as an immediate constant.
This bug seems to affect compiler versions from 5.72 to at least as far back as 5.65.
Minimal test case below, textile gods permitting.
#include
#include
typedef struct {
int stuff[0x104c0/4];
} player_t;
player_t *new_player(void)
{
player_t *player = (player_t *) malloc(sizeof(player_t));
memset(player, 0, sizeof(*player));
player->stuff[123] = 1;
return player;
}
Random freezing of Iyonix during hard disk activity [WorksForMe]
Since installing 5.20 on an Iyonix, the system has been completely freezing at random times during intense IDE disk write activity. Typical activities include copying files, downloading or processing videos and other large files, and compiling software from sources. Installing 5.22 appears to have made the problem even more frequent. (Although I have also turned off buffering and minimised caching in an attempt to ward off filesystem corruption, and this has caused disk access to increase.)
Freezes seem to occur when the system is multitasking. I had thought it was related to disk-intensive activity running in a taskwindow, but freezes have also occurred when downloading files by web browser or processing downloaded emails. Fortunately, the machine has never frozen while running DiskKnight to repair damage to the filesystem.
The freeze is total. The hard disk light stays brightly lit and steady; the mouse pointer neither moves nor changes; the keyboard does not respond; and a complete power-off at the wall socket is necessary to reboot. As far as I can tell, despite the disk light being lit, there is no further disk activity once the freeze occurs.
Being unable to edit and rebuild software without the machine freezing, I have restored 5.18 on the machine and (fingers crossed) it has not frozen since.
Through the forum topic
NVidia driver mouse pointer comes out red
[Fixed]
Verbal report via Wakefield show, so unfortunately no detail on which graphics card was in use.
Was running in 32k colours mode (again, verbal report, was a little unsure).
Desktop colours all correct, however the blue mouse pointer was red.
Memory leaks on longjmp [Open]
The C runtime leaks memory when longjmp is performed. Ben Avison quotes from the compiler release notes:
VLAs use new library functions "__rt_allocauto" and "__rt_freeauto". In
the future these could be improved to make sure VLAs are freed
correctly in longjmp-type situations, by associating blocks with stack
chunk and stack pointer values.
To quote Ben's approach to fixing the problem (communicated via email):
In principle, it's just a matter of over-allocating memory within
__rt_allocauto and using the extra space to construct a wrapper which
includes a linked list pointer so it can be located from the stack chunk
header, plus the stack pointer that was pertinent at allocation time;
then when you longjmp back up the stack, iterate over stack chunks and
auto-alloced blocks that belonged to skipped stack frames, and free them.
I discovered this when trying to compile & link C code using OSLibSupport (http://sourceforge.net/projects/ro-oslib/files/OSLibSupport/), when linking fails with:
ARM Linker: (Error) Undefined symbol(s).
ARM Linker: ___arm_alloca_longjmp, referred to from OSLibSupport:o.OSLibSupport32(o).
ARM Linker: Errors in link, no output generated.
ARM Linker: finished, 2 informational, 0 warning and 1 error messages.
AMU: *** exit (1) ***
I+S+T icons that are faded/inverted abort on redraw
[Fixed]
Window Manager 5.30.
Icons with I+S+T set abort when being redrawn, simplest way to recreate is open a template editor, add a label icon, set I+S+T (such that the box behind it should be minimised to the size of the text) and bang!
If faded, seems to be in Go_CreateRemovePalette in SpriteExtend.
If inverted, seems to be in ValidateModeSelector in the Kernel.
In both cases the sprite pointer looks dodgy.
Spotted by Druck, whose DiscKnight main window had a faded box+label around some icons
Icon invert to co_cpu icon fails as it is 16M colours
[Fixed]
I have submitted a set of patches to Configure. Included in them is a patch to make Configure behave in a 'filer-like' fashion (ie. instead of having all plugins listed in a submenu, the plugin under the pointer is displayed as 'plugin 'X'' with an info submenu.
Part of that patch (which I think at the time of reporting has not been added) inverts the icon under the pointer in the same fashion as Filer.
co_cpu (from !CPUSetup) doesn't invert as it is 16M colours.
I think the root problem here is that 16M colour icons need to be able to invert if we're going to use them. That may be a bug (I thought work was being done on that) or it may be an absent feature.
Solution is either to update the sprite with a 256 colour 'safe' version of co_cpu (easy), or correct the inversion of 16M colour sprites (hard).
I can run it through ColourTrans and submit the changed icon if need be - but it will take just as long for someone to sort the email as it would to run it through CFSI themself!
Norcroft (possibly) incorrectly decorates pointer/array typedef as readonly
[Fixed]
bc..#include
typedef unsigned char byte;
typedef byte Charset[123];
void test(const Charset follow)
{
follow = NULL;
}
*cc -strict -c99 -fah -Wh -Otime SSEx4nim.c
Norcroft RISC OS ARM C vsn 5.69 [20 Oct 2010]
"c.SSEx4nim", line 7: Warning: extern 'test' not declared in header
"c.SSEx4nim", line 8: Error: assignment to 'const' object 'follow'
c.SSEx4nim: 1 warning, 1 error, 0 serious errors
p.
This code compiles warning-free on gcc, clang, and EDG-based compilers. It appears to be misidentifying which part of the type expression should be read-only. This might be an ambiguity in the spec, but if so it would be nice if it interpreted it the same way as all the other popular compilers.
(I have no idea if this is fixed in a later version, I do not have Norcroft and this has been diagnosed using remote-hands)
inlined memset() of variable on stack could lead to corruption with events (cc 5.69)
[Fixed]
While debugging PipeDream I had reason to trace into vsnprintf() and was somewhat surprised to see the following code (DecAOF output of fpprintf.o):
0x001028: 706e7376 vsnp : RSBVC r7,r14,r6,ROR r3
0x00102c: 746e6972 rint : STRVCBT r6,[r14],#-0x972
0x001030: 00000066 f... : ANDEQ r0,r0,r6,RRX
0x001034: ff00000c .... : DCI 0xff00000c ; Undefined instruction
0x001038: e1a0c00d .... : MOV r12,r13
0x00103c: e92dd8ef ..-. : STMDB r13!,{r0-r3,r5-r7,r11,r12,r14,pc}
0x001040: e24cb004 ..L. : SUB r11,r12,#4
0x001044: e15d000a ..]. : CMP r13,r10
0x001048: 4bfffbec ...K : BLMI __rt_stkovf_split_small
0x00104c: e1b05001 .P.. : MOVS r5,r1
0x001050: e1a06002 .`.. : MOV r6,r2
0x001054: e1a07003 .p.. : MOV r7,r3
0x001058: e24dd028 (.M. : SUB r13,r13,#0x28
0x00105c: e3a01000 .... : MOV r1,#0
0x001060: e3a02000 . .. : MOV r2,#0
0x001064: e3a03000 .0.. : MOV r3,#0
0x001068: e3a0c000 .... : MOV r12,#0
0x00106c: e3a0e000 .... : MOV r14,#0
0x001070: e8ad500e .P.. : STMIA r13!,{r1-r3,r12,r14}
0x001074: e88d500e .P.. : STMIA r13,{r1-r3,r12,r14}
0x001078: e24dd014 ..M. : SUB r13,r13,#0x14
0x00107c: e58d0000 .... : STR r0,[r13]
0x001080: e3a0200a . .. : MOV r2,#0xa
0x001084: 12450001 ..E. : SUBNE r0,r5,#1
0x001088: 03a00000 .... : MOVEQ r0,#0
0x00108c: e58d200c . .. : STR r2,[r13,#0xc]
0x001090: e3a03000 .0.. : MOV r3,#0
0x001094: e58d0008 .... : STR r0,[r13,#8]
0x001098: e52d3004 .0-. : STR r3,[r13,#-4]!
0x00109c: e51f3378 x3.. : LDR r3,0xd2c
0x0010a0: e1a02007 . .. : MOV r2,r7
0x0010a4: e1a01006 .... : MOV r1,r6
0x0010a8: e28d0004 .... : ADD r0,r13,#4
0x0010ac: ebfffbd3 .... : BL __vfprintf
vsnprintf() uses memset() to zero-initialise a FILE structure before filling in some members then calling __vfprintf()
What gives me cause for concern is the method used to zero-initialise:
SUB r13,r13,#0x28 ; FILE structure size
...
STMIA r13!,{r1-r3,r12,r14}
STMIA r13,{r1-r3,r12,r14}
SUB r13,r13,#0x14
This zero-initialises the lower five words, then retracts the stack pointer back over them before zero-initialising the upper five words.
Consider an event being dispatched by the SCL kernel as the STMIA completes and before the stack pointer is advanced back down over the lower five words - they will have been trashed.
I rebuilt the IOMD ROM from today's source with cc 5.69 and sure enough that's what fpprintf.c currently compiles to.
This can also be reproduced with the trivial example:
#include
#include
int main(int argc, char * argv[])
{
FILE hack;
memset(&hack, 0, sizeof(hack));
fprintf(&hack, "argc is %d\n", argc);
return(0);
}
VProtect 4.04 null pointer bug
[Fixed]
While trying to get the boot sequence to work with my zero page relocation, I've found what looks like a pretty serious bug in VProtect. Starting a offset &1D30 is a function that gets called during initialisation that looks like it's meant to enumerate all the modules and examine them (presumably checking for known viruses). However the R0 parameter to OS_Module isn't being preserved/restored properly, so the second time round the loop OS_Module will get called with R0=1, R1=1, causing it to try loading a module with a filename pointer of 0x1. This seems to silently fail on current OS versions (presumably generating an error and prematurely terminating the module enumeration), but on my zero page relocated kernel I get a nice data abort deep inside FileSwitch.
Changing the code at &1DBC and &1DC0 to load R0 instead of R4 makes the crash go away, although I haven't stepped through the code to make sure that the value it loads is still correct (i.e. &C, as stored by the code at &1D38)
Ticket search results don't display ticket status
[Fixed]
# ""toolbox"":https://riscosopen.org/tracker/search?q=toolbox
# ""pointer"":https://riscosopen.org/tracker/search?q=pointer
* Obviously not a major issue in cases giving only a handful of results.
* Displaying the part and severity might also be helpful, particularly for someone wanting to kill two birds when about to investigate an unreported issue.
** (An enhanced enhancement could be to build the results into a searchable table "like the full list":https://riscosopen.org/tracker/ (including filters?) but this would mean the details not being shown.)
If the outcome is a WontFix because time could be better used elsewhere, that will make sense - but I thought I'd just note it for consideration.
Text area gadgets left with stale pointers after expanding RMA block containing handles for sliding heap
[Fixed]
The TextGadgets module maintains a dynamic array in an RMA block, where each element gives the base address and size of a block within its sliding heap (also the number of bytes free at the end of each block). Such elements are typed as 'Handle'.
If every element of this array is in use then the RMA block containing it will be extended using OS_Module 13. That will change the base address of the block and thus invalidate all the 'Handle' pointers previously output by the 'create_block' function. Data aborts are likely to ensue because every pre-existing TextArea gadget will have been left with a stale pointer to part of the RMA that is liable to be overwritten by other data.
TextGadgets claims MORE from RMA when a gadget is removed andothers of the same type remain.
[Fixed]
When a Scrollbar, ScrollList or TextArea gadget is removed, the TextGadgets module makes a hamfisted attempt to shrink the RMA block containing its array of pointers to the internal data structures for that type of gadget. The only exception is when removing the final gadget, when the RMA block is instead freed.
Unfortunately, the RMA block is expanded to a silly size instead of being shrunk, because the wrong type specifier is used with the 'sizeof' operator (e.g. 'PrivateScrollbar' instead of 'PrivateScrollbar *'):
// No need to generate an error if the realloc fails, 'cos
// it'll just realloc next time, hopefully
new_list = realloc(scrollbar_list, sizeof(PrivateScrollbar) * (j+1));
Tragically this isn't the only thing wrong with the calculation: The comments saying "j points to last entry" are a lie; j is actually the index of the NULL terminator (i.e. the number of gadgets). Therefore 'j+1' should be the current number of array elements, which isn't appropriate as the new number of array elements.
TextGadgets post-filter's handling of Toolbox_ObjectDeleted is dangerously broken.
[Fixed]
The first time that a Scrollbar, ScrollList or TextArea gadget is created for a client task, the TextGadgets module uses Toolbox_RegisterPostFilter to register SWI TextGadgets_Filter to be called before delivering events of type Toolbox_ObjectDeleted for Toolbox objects of Window class. Unfortunately, the code for handling Toolbox_ObjectDeleted events is horribly broken.
It searches the internal arrays of gadgets of each type for any which have a parent object ID which matches the Window that was just deleted. Upon finding such a TextArea or Scrollbar, it copies all the pointers above downwards, but does so in a very stupid and dangerous way ([n] := [2n], [n + 1] := [2n + 1], [n + 2] := [2n + 2], etc.) In fact, this corrupts the array contents from the orphaned gadget upwards:
// Found one!
int j;
for (j = i; text_area_list[j] != NULL; j++)
{
// Copy down following gadgets
text_area_list[j] = text_area_list[j+i];
}
After having corrupted the contents of the array of pointers, the memory block containing it is expanded to a silly size instead of being shrunk, because the wrong type specifier is used with the 'sizeof' operator:
new_list = realloc(text_area_list,
sizeof(PrivateTextArea) * (remaining + 1));
(The actual type of 'text_area_list' is 'PrivateTextArea **' and not 'PrivateTextArea *'.)
I believe that SWI TextGadgets_Filter is never called for Toolbox_ObjectDeleted events because Toolbox module's post-filter dispatcher is unable to determine the class of an object referenced in a Toolbox event if that object ID is no longer valid (as in this case). Therefore it uses 0 as the class ID, which mismatches the class ID specified in the TextGadgets module's array of event interests.
ScrollList_SetFont and TextArea_SetFont don't accept a font handle (only an identifier).
[Fixed]
The TextGadgets module provides two methods ScrollList_SetFont and TextArea_SetFont, which are analogous to the (undocumented) methods that the Window module provides to set the text font for displaying gadgets of type ActionButton, RadioButton, DisplayField, WritableField, StringSet or Button.
Unlike the methods provided by the Window module, the TextGadgets module does not interpret values of R4 less than 256 as raw font handles. Instead, it will pass such values directly to SWI Font_FindFont, which treats them as a pointer to a font identifier string and reads garbage from zero page until encountering a control character.
Although the ScrollList_SetFont and TextArea_SetFont methods are not broken in this respect, it seems reasonable to expect them to behave like the equivalent methods provided for inbuilt gadget types. We should attempt to harmonise behaviour of the TextGadgets and Window modules as far as possible.
ScrollList_SetFont and TextArea_SetFont don't interpret identifier "" like a NULL pointer.
[Fixed]
The TextGadgets module provides two methods ScrollList_SetFont and TextArea_SetFont, which are analogous to the (undocumented) methods that the Window module provides to set the text font for dis`playing gadgets of type ActionButton, RadioButton, DisplayField, WritableField, StringSet or Button.
Unlike the methods provided by the Window module, the TextGadgets module does not interpret an empty string (R4 points to a control character) as equivalent to a NULL string pointer (i.e. the value of R4 is 0). Instead, it passes an empty string straight through to SWI Font_FindFont, which returns a slightly puzzling error " font not found".
This lack of flexibility makes calling these methods via a veneer awkward in languages such as BASIC where there is no representation of a NULL string that is distinct from an empty string. Hence, it is necessary to use a different SYS statement when trying to unset a gadget's custom font (i.e. revert to using the desktop font).
TextGadgets module returns pointers to OS error blocks allocated on the SVC stack
[Fixed]
Many functions in the TextGadgets module return pointers to OS error blocks automatically allocated on the run-time stack within the body of the function. This is very bad practice because any pointers to automatic variables become invalid as soon as they go out of scope, and the effect of using them afterwards is undefined. This is the kind of mistake that a novice C programmer might make!
On RISC OS, the consequence is that the error block may be overwritten by garbage if anything uses that part of the SVC mode stack between the error block being created and the error being handled.
The errors affected are:
"Not enough memory" when adding a redraw handler for a text area, scroll list, or scrollbar gadget. Luckily, this error is ignored by the calling code.
"Not enough memory to add item" in method ScrollList_AddItem. Potentially fatal.
"Not enough memory" in method ScrollList_SetItemText. Potentially fatal.
"No such scrollbar" when removing a redraw handler for a scroll bar. Luckily, this error is ignored by the calling code.
"No such scrolling list" when removing a redraw handler for a scroll list. Luckily, this error is ignored by the calling code.
"No such text area" when removing a redraw handler for a text area. Luckily, this error is ignored by the calling code.
"Invalid desktop colour" in method ScrollList_SetColour or TextArea_SetColour. Potentially fatal.
Filecore stores flags in top bit of pointers.
[WontFix]
Filecore stores a flag in the top bit of some internal pointers, with the result that it doesn't work if the memory is above 2GB.
The flag in question is HandleBlkBit, and I see no reason why it cannot be in bit 0 as all pointers are word aligned.
Batch 3 build issues
[Fixed]
Here's a summary of the build issues relating to the Batch 3 code release:
Component: Issue(s):
---------- ---------
Desktop.Free Missing Hdr:PCCardFS
Internat.Territory.Module COMPONENT=Japan Use of EXITS without EntryS
(s.DateTime line 340)
Internat.Territory.{Japan,UK,USA} Empty directory trees -- no files
HWSupport.ARM Missing Hdr:MEMM.ARM600
HWSupport.PCI Missing Hdr:MEMM.ARM600
No ErrorBase_PCI defined in Hdr:NewErrors
HWSupport.Podule Missing Hdr:PoduleReg
HWSupport.SCSI.SCSISoftUSB No ErrorBase_USBDriver defined in
Hdr:NewErrors (Global/NewErrors.h)
HWSupport.SerMouse Missing Hdr:Pointer
HWSupport.USB Entire NetBSD.dev tree missing
Missing "callx" library
Video.Render.Hourglass2 No source files
Draw: resizing objects using the drag box is dodgy
[Fixed]
When an object is selected, it has a highlight box drawn around it with a couple of control points to allow resizing and rotation.
There's a bug in the resize box stuff where when you start the drag operation, Draw assumes that the mouse pointer is already at the exact bottom-left corner of the object. This isn't usually the case; you're usually a few pixels away from the corner - somewhere in the little control box. Thus, the object instantly gets resized to be a few pixels larger.
Draw should make a note of the X and Y offset of the mouse pointer from the bottom-left corner of the object and preserve that offset throughout the lifetime of the drag operation on the resize control box.
Paint: delete rows/columns is a pain to use
[Fixed]
When you want to delete rows or columns of pixels in a sprite using Paint, it's usually very tricky to select the ones you are interested in. There are a couple of reasons for this:
# Moving the mouse pointer off the edge of the sprite usually skips the last row/column leaving it unselected
# When your mouse step is greater than one pixel, you can't easily select rows/columns without zooming in
# The menu entry doesn't have 'bump' arrow icons allowing you to increment/decrement the number of rows/columns
I'd suggest that the extent of the selected rows/columns should be set to the nearest edge of a pixel row/column to where the mouse pointer is. This also applies if you've gone off the edge of the sprite.
The menu structure should have a small dialogue box for the delete rows/columns (and add) which is a bit like the zoom box - with arrow icons to adjust the number up and down.
Ticket #541 comment by Sprow (202)
[Fixed]
Could you try the attached? This DrawFile module copies the error away at the point it is raised so that at the end of the render you get the true error not some stale pointer.
Ticket #541 comment by Chris Hall (132)
[Fixed]
I have a repeatable set up that produces the error each time a particular page is turned, in a version of the !RingBind programme before I included error trapping for skewed JPEGs.
DrawFile_Render produces this error (System variable 'SCSI$Path' not found at line 2760) when it renders a draw file that includes a JPEG where the transformation matrix in R3 is skewed (i.e. b<>0). It renders the image correctly skewed (so long as the error box does not overlap the affected page) but with the JPEG concerned missing. !RingBind then continues to work if the error is accepted and the page widens to the next image, then the error comes again. Once the page is fully turned, the JPEG is no longer skewed and renders with no error.
While !RingBind is running, if I press f12, set SCSI$Path to SCSI::$ then press ENTER (redrawing the desktop), I either get a bad error pointer from SWI 400xx (didn't manage to note it down) or an error SCSI$Path refers to itself (not unexpected) or a strange error '(Number)' in each case from the line that first invokes DrawFile_Render as a (non skewed) image is rendered. So it seems that when DrawFile_Render invokes SpriteExtend to render a skewed JPEG, the error buffer returned is unpredictable.
Ticket #476 comment by Stuart Swales (1481)
[Fixed]
I suppose that example looks rather artificial, but it does fail on real-world constructs such as when accessing a double member of a structure via a pointer-to-const
Ticket #383 comment by Sprow (202)
[Fixed]
> Please confirm if you get the chance!
Yup, all colours and pointers now the right colour with simply "-auto".
I've added the missing new line after the configure text for you too!
Ticket #383 comment by Steve Revill (20)
[Fixed]
Reopened. Here's what happened when I tried this on an Iyonix running RISC OS 5.21 (20th Sep):
*Help nvidia
NVidia 0.46 (06 Aug 2014)
*Status nvidia
NVidia -device 2 -auto
*Configure nvidia -manual -alt16bpp
Buffer overflow
*Configure nvidia -device 2 -manual -alt16bpp
Buffer overflow
*Configure nvidia -device 2 -auto
*Configure nvidia -device 2 -manual -alt16bpp
*Status nvidia
NVidia -device 2 -manual -alt16bpp
Note: after doing all of this and rebooting, I'm still left with a red mouse pointer that has a yellow border.
Ticket #383 comment by Jeffrey Lee (213)
[Fixed]
I'm thinking this might be possible if Geminus (or something else) is performing red/blue swapping.
Prior to NVidia 0.40, on an FX-series card 32K colour modes would have had the desktop appear red/blue swapped but the mouse pointer correct. In NVidia 0.40 things were switched over to using the new red/blue swapped screen modes where appropriate, so that in 32K colour modes the desktop and pointer should match. Then in NVidia 0.43 the *Configure NVidia option was added to allow manual control over the red/blue swapping - but if you use those options to disable the use of the new screen modes, then it will also disable red/blue swapping of the mouse pointer. So in a 32K colour mode both the desktop and the pointer will be incorrect. And if Geminus (or any other software which does manual red/blue swapping, e.g. ArcEm) is expecting that only the desktop needs red/blue swapping then that will give the end result of the desktop appearing correct but the pointer being red/blue swapped. The gamma tables in 32K colour modes will have also been affected in a similar way.
So I guess the correct fix would be a new config flag to allow red/blue swapping of the mouse + gamma table to be controlled independently of whether a red/blue swapped screen mode is in use (in 16bpp modes). 32bpp modes and 8bpp modes should be fine, as all three parts (desktop, gamma, mouse) always had consistent colour channels.
Ticket #375 comment by Jeffrey Lee (213)
[Fixed]
99% certain this was fixed with the translation table caching code that was introduced in Wimp 5.36.
After deciphering a stack dump, it looks like the following was happening:
* !Alarm asks the wimp to redraw its icon (which is held in !Alarm's application space)
* The wimp caches information for that sprite, including the parameters needed for calling ColourTrans_GenerateTable
* The wimp plots the sprite and everything is OK
* The user clicks the I+S+T icon to select it, and a redraw of that icon is triggered
* The icon doesn't have a sprite, and so caching of the sprite information fails. However the icon redraw code tries to redraw the sprite regardless.
* The redraw code thinks "hmm, this icon is selected, I need to regenerate the translation table" and calls calcinverse
* Because the previous sprite which was cached successfully was <8bpp, calcinverse thinks "hmm, cachespritedata will have already been called, and so the colourtrans parameters will be up to date", and so skips the calling cachespritedata (and exiting out if there was an error)
* It then issues ColourTrans_GenerateTable using the stale parameters, leading to a crash somewhere nasty due to the sprite pointer pointing at whatever random garbage the template editor has in its memory at the address !Alarm's sprite was
Wimp 5.36 fixes this by moving the ColourTrans_GenerateTable call out of calcinverse and into the new cachespritepixtable routine, which will always make a call to cachespriteaddress and safely exit out if there was an error.
Ticket #375 comment by Sprow (202)
[Fixed]
Having turned off lazy task swapping, it still fails, so it's not that.
But the dodgy sprite pointers look like the corresponding bit of memory from !Alarm, so it looks like !Alarm was left paged in somehow?
Ticket #347 comment by Chris Hall (132)
[Fixed]
A work around is as follows:
snd%=TRUE
ON ERROR snd%=FALSE
IF snd% THEN SYS "Sound_Configure",0,0,0,0,0 TO ,r1%,r2%
IF snd% THEN fsrf=9968/r1%/r2%:REM Fast sample rate fudge
ON ERROR OFF
...
replace
SOUND a%,b%,c%,d%,e% with SOUND a%,b%,c%,d%*fsrf,e%*fsrf
to get duration and delay timing right
In voice handlers:
PRM 4-74 add after SWI "XSound_Configure"
MOV R2,R2,ASL #8
STR R2,ssrate
For envelope control where tremelo and/or envelope control is applied
once each sample period (previously based on 48us) use actual sample
period, adding each time until 48us is reached:
.GateOn
add after LDMIA R9,{R1-R8}
LDR R8,ssrate
...
B FillGate
.Fill
LDMIA R9,{R1-R8}
.FillGate
ADD R8,R8,R8,LSL #16
CMP R8,#&300000
SUBGE R0,R0,#&300000 ; reset R8 to zero and flag tremelo/env
LDRB R0,[R7],#1 ;faster sample rates - only do tremelo
ADDGE R2,R2,R0,ASR #24 ; when was donbe before every 1cs
...
LDRB R0,[R3] ;get amp envelop but only increment pointer
LDRGEB R0,[R3],#1 ;to table every 1cs not every sample period
Hope this helps.
Ticket #346 comment by Sprow (202)
[Fixed]
Fixed in Wimp-5_32.
As an aside, another workaround is to make sure that there are no duplicates of the window title sprites in the RAM copy, that way the Wimp wont end up with a stale pointer when the RAM and ROM sprites are intersected (as they are when the WimpSpritePrecedence is changed).
Ticket #263 comment by Trevor Johnson (329)
[Fixed]
A few more notes on this one:
* It may be useful to sneakily move the pointer away from the *Try* button after clicking on it (in the split second you have before the display is actually blanked), in order that the subsequent swipe doesn't try to click on it.
* Note that the cyclic shimmering can remain for an extended period on 'almost black' although banding is visible - the coloured screen cycling returns after waiting long enough.
* With DPMS blanking configured with a timer, it can be invoked when an Edit window has the input focus. Again using the merest touchpad swipe to get the shimmer, keypresses are then visibly passed to Edit (although delayed), which displays them. The shimmer isn't stopped by the keypresses, so RISC OS obviously thinks the display is functioning correctly.
* Ctrl-Shift-F12 shuts down the system as normal during a shimmer, although the message isn't visibly rendered on the screen (both complete shutdown and
* In attempting the above, I somehow executed the 'Exit Desktop' command via keypresses (dunno what the key combination was). The @*@ Supervisor prompt appeared at the top of a black screen as normal (display correctly restored).
*
Ticket #176 comment by Theo Markettos (89)
[Invalid]
The 32 bit OS_ReadLine doc (http://www.iyonix.com/32bit/APIchanges.shtml) says:
"In a 32-bit OS, OS_ReadLine now interprets R0 as a 32-bit address, and acts as though the flags are both clear. This reflects the most common usage, and allows applications not wanting to use the flags to remain unaltered."
BASIC only uses OS_ReadLine in one routine I can find, where the code is this:
INLINE ADD R0,ARGP,#STRACC
MOV R1,#238
MOV R2,#" "
MOV R3,#255
SWI READLINE
(in castle/RiscOS/Sources/Programmer/BASIC/s/Basic)
ARGP is BASIC's workspace pointer, and thus won't have any flag bits set. STRACC=256. Thus this code is 32 bit safe because of the new definition of OS_ReadLine.
Ticket #163 comment by John-Mark Bell (94)
[Fixed]
Ok, let's see if textile will build us a table, as that's probably more use :)
|_.Component:|_.Issue(s):|
|Desktop.Free|Missing Hdr:PCCardFS|
|Internat.Territory.Module COMPONENT=Japan|Use of EXITS without EntryS (s.DateTime line 340)|
|Internat.Territory.{Japan,UK,USA}|Empty directory trees -- no files|
|HWSupport.ARM|Missing Hdr:MEMM.ARM600|
|/2.HWSupport.PCI|Missing Hdr:MEMM.ARM600|
|No ErrorBase_PCI defined in Hdr:NewErrors|
|HWSupport.Podule|Missing Hdr:PoduleReg|
|HWSupport.SCSI.SCSISoftUSB|No ErrorBase_USBDriver defined in Global/NewErrors.h|
|HWSupport.SerMouse|Missing Hdr:Pointer|
|/2.HWSupport.USB|Entire NetBSD.dev tree missing|
|Missing "callx" library|
|Video.Render.Hourglass2|No source files|