Re: A86: _vputs strikes again... again???
[Prev][Next][Index][Thread]
Re: A86: _vputs strikes again... again???
In a message dated 11/23/99 15:30:59 Eastern Standard Time,
croop@oregontrail.net writes:
> > shiftflags does nothing to _vputs, but why don't you use shiftKeepAlph to
> > keep alpha lock on?
>
> Because I want it to stay off, not on. And I especially want the 2nd
> shift to stay off.
You really should just use _getcsc (_getky, _get_key, whatever...). It
treats 2nd and alpha the same as any other char.
>
> > have you tried setting a breakpoint on the line after returning from
> > _vputs to make sure it's actually crashing there?
>
> Yes. It never makes it out of _vputs. It dies in the middle of a
> character.
>
> > _vputs will never execute any code in ram, here's a list of flags and ram
> > addresses it uses:
>
> Then something is REALLY wrong, because it is definitely executing RAM
> system data, thinking it is executable code.
It's most likely that your interrupt is either messing up a register,
corrupting memory, or changing SOMETHING it shouldn't be. You could try
testing it with that interrupt disabled.
>
> > 0,(iy+$1d) - cleared in _vputmap,_vputs, tells it to ignore screen
> > limits?
> > _penCol, _penRow
> > 3,(iy+$1b) - tells it to use _STATED_CUT_COL
> > _CXCURAPP
> > _STATED_CUT_COL
> > 6,(iy+$18) - textwrite,(iy+new_grf_flgs)
> > 1,(iy+$05) - textEraseBelow,(iy+textFlags)
> > _winBtm
> > 1,(iy+$23) - alt_vfont,(iy+exceptionFlg)
> > _altsfontptr
>
> Question: if it thought there was an alternative font, and there really
> wasn't one, could that cause what is happening? Maybe the vfont flag is
> getting turned on somehow...
>
Nah, it has a verification byte. And besides, it would just go and display
the alternate fonts, not crash.
----
Jonah Cohen
<ComAsYuAre@aol.com>
http://linux.hypnotic.org/~jonah/