Ticket #431 (Open)Sat Nov 26 12:32:25 UTC 2016
VDU text window/cursor position (and gfx window/origin) functionality is limited for large screen modes/sprites
| Reported by: | Jeffrey Lee (213) | Severity: | Normal |
| Part: | RISC OS: Module | Release: | |
| Milestone: | Status | Open |
Details by Jeffrey Lee (213):
There are a few VDU sequences for dealing with the text window and text cursor which use bytes to specify row & column positions. This causes problems with large screen modes (dimensions greater than 2048, assuming 8×8 font) due to there being over 256 text rows/columns available.
Interfaces known to be limited by this include:
- VDU 28, for defining custom text window coordinates.
- VDU 31, for setting the text cursor position.
Internally the OS seems to use 32bit values for storing the above, and there are 32bit APIs for reading the values, it’s only the ability to set the values which is affected. For VDU 31 you could use the workaround of navigating to the closest position and then using horizontal & vertical tabs to move the cursor one character at a time, but for VDU 28 there’s no workaround available if a large-coordinate text window is required.
Changelog:
Modified by nemo (145) Tue, January 23 2018 - 21:04:26 GMT
I have a module that provides SWI versions of VDUs 24, 28, 29 and 31 – they’re called VDU_24, VDU_28… you get the picture.
However, I think it may be better to have a single OS_VDU SWI which could (in time) accumulate or expose other functionalities as well.
Note that OS_Byte,134 already returns word-sized coordinates for the text cursor position, and OS_ReadVduVariables allows the others to be read in full, so it is only writing of large values that must be implemented.
For the proof-of-concept this involves reusing existing code from immediately after the byte parameters have been loaded from the VDU queue. Existing VDU24 implementations are not amenable to that approach, but VDU24 is so trivial that reimplementation is simple (it has no side effects).
Modified by nemo (145) Wed, January 31 2018 - 12:23:24 GMT
- Summary changed from VDU text window functionality is limited for large screen modes to VDU text window/cursor position (and gfx window/origin) functionality is limited for large screen modes/sprites
I also should have said that providing such a module is not a complete solution, as printer drivers will not notice the new API being used.
So there’s a lot of ramifications. Even wheezes such as switching to a sprite with a save area, modifying the VDU state in the save area and then switching back won’t get picked up. Drivers intercept Wrch and act directly. New interfaces required everywhere, sadly.
The API issue also affects plotting into sprites (graphics window and origin) and that isn’t dependent on large displays, just the desire to create a large bitimage. I’ve modified the summary accordingly.
