On Fri, Aug 05, 2005 at 01:29:46PM +0200, Frode Tenneboe wrote: > On Fri, 5 Aug 2005 12:23:39 +0100 Stuart Brady <[EMAIL PROTECTED]> wrote: > > On Fri, Aug 05, 2005 at 10:10:00AM +0200, Frode Tenneboe wrote: > > > Strange..... I have no idea what that could be. It used to work.... > > > > I start by disabling the printing code, see what happens. > > Try with a simple basic program > > 10 do > 20 pause 1 > 30 loop > > Then add dos, drivers, etc.
Good idea... That test passes with and without DOS. It also passes with DOS and the serial driver loaded. In the keyboard relaying program, ESCAPE breaks with or without the serial driver loaded, though. I have a feeling it's the serial driver itself that's doing this... I've also tested with: 10 CLOSE #6: OPEN #6;"b" 20 DO 30 PRINT #6;"Testing" 40 LOOP This seems to give the same results, I.e. ESCAPE breaks (or traps) even when BREAKDI is set. Interestingly, if I run "POKE &5B41,1" (BREAKDI), I can trap ESCAPE using ON ERROR... but I still can't respond to ESCAPE in the way that I want to. If I don't set BREAKDI, ON ERROR doesn't work. I'm wondering if there's a way that I can provide my own error handling routine to work around this. It'd be a shame to have to resort to programming the hardware directly. Thanks, -- Stuart Brady
