Time to time people in comp.sys.psion.* ask questions which have no answers in the official documentation. With this page I try to answer them. Of course, I don't claim to be true. I you find a mistake or have other good questions just drop me a line.
It starts immediately after so called Interrupt Vector Table (IVT), i.e. from segment $0040. It has 19200 bytes in size (2x9600 for black and gray planes).
You can examine that OS data segment has a value $04B0, i.e. offset 19200 (decimal) from memory start. Thus OS data segment overlaps upper $400 bytes of video memory.
Of course, on other SIBO computers this address may vary, and so with emulator too.
Yes. SIBO computers have only (limited) hardware write memory protection. Usually a process can't write outside its data segment, but has read-only access to all memory.
You even don't need to use assembler -- just use far pointers from C program. But you should disable interrupts before this access and enable them as soon as possible, but only after all segment registers are restored to default values.
This technique is used by HexView.
Yes, but it is not so easy. Usually, if a process writes outside its data segment, hardware interrupt is generated and the process is paniced. But if your code is called by OS, protection is switched off and all memory is accessible. Generally speaking, it is usually safe (in sense of protection) to write to any address inside interrupt handler.
To execute your code at interrupt time you need one of the following:
I just deleted all stuff about compatibility and multitasking. I'm sure you know all these problems.
Why you need direct screen access? I'm not sure you can write bitmap transfer or line draw significantly faster. The only application I see is fast text output, e.g. for terminal emulators.
You should take care about dialogs and menus to not overdraw them. If your program is HWIM-based (you fight for speed, don't you?), you never could predict this -- ATS allows to display a dialog or a message over your application. All in all you couldn't predict system messages like "Replace main batteries" or "Batteries too low for digital audio" (other application beeps!) over your window. And yes, your application must be foreground!
The only documented way is ATS (Automated test system). See SIBO C SDK (ver. 2.10) for details. It works only if the destination process supports ATS. Just run an example from SDK and test.
For ATS-compatible applications use ATS. For all other...
Well, it is possible. If you really need it, mail me for details. You should have SIBO C SDK and Turbo assembler, be familiar with LDD and assembler, understand terms like "ROM scan", "ROM patch" and "ROM breakpoints". Anyway I couldn't guarantee that it will be compatible with all ROM versions. But it is possible !
Return to my home page
Last updated June 10, 1996