Font_read_defn

Tony van der Hoff tony at mk-net.demon.co.uk
Mon Feb 19 10:51:41 GMT 2001


In message <4a4ed8f0d3chris at bulldog.u-net.com>
          Chris Johnson <chris at bulldog.u-net.com> wrote:

> I have been converting my old BASIC apps to C/oslib. I have hit a problem
> with the routine to deal with fonts at a mode change. I have isolated the
> problem to the oslib function
> 
>         font_read_defn
> 
> Every time it is called (whether an actual mode change or not) it causes a
> fatal exit due to a "no stack for trap handler" error.

[snip]
> 
> In the original BASIC program I simply called SYS "Font_ReadDefn", but
> that requires a pointer to a buffer (for font identifier) to be passed in
> R1. There is no evidence of this in the oslib version.
> 
Yes, that is correct. The OSLib call font_read_defn() does not return the
font identifier; you need font_read_identifier() for that.

> The other odd thing is that if I use DDT and single step through the
> program, the error is not raised.
> 
Well, your code snippet looks OK, but OSLib's implementation of that SWI
looks fine too; this probably means you need to be looking at your runtime
environment when the call is made. Basic and DDT isolate you from some of the
problems here by setting up their own environment. 

How are you calling that function? If it's as a result of a service call
(which you shouldn't intercept in an absolute application in any case), the
processor may be in SVC mode, and you may not have a SVC stack.

You could try using the x-version of the SWI, and handling any error return
yourself, thus avoiding the trap handler.

-- 
Tony van der Hoff         | MailTo:tony at mk-net.demon.co.uk
                          | MailTo:avanderhoff at iee.org
Buckinghamshire, England  | http:mk-net.demon.co.uk



More information about the oslib-user mailing list