Re: A86: Re: _vputs strikes again... again???
[Prev][Next][Index][Thread]
Re: A86: Re: _vputs strikes again... again???
> Without seeing your code, I would guess that your interrupt handler is
> trashing some memory/register/flag while _vputs is running (though you'd be
> very lucky to have the interrupt run at the exact time _vputs ran). Did you
> try setting the flag that forces alpha lock? You could do that or use
> _get_key and not worry about key state.
Unfortunately, my code is too large to put in an email without getting
alot of people mad, and the routines at fault would make no sense if I
took them out of context.
xor a
ld (IY+shiftFlags), a
ret
the above code is all that I install for my temporary int handler.
Before installing, I copy the _alt_int_exec code (200 bytes) to a safe
location and preserve the original states of the checksum and the
control flag. After I am done with key entry, I replace the original
code and checksum and flag state, totally erasing the int handler I
installed, and preserving any handler that was already there.
Well, I used _getkey because I'm so used to using it, I guess. Does
_get_key return codes that actually reflect the key that was pressed, or
the different things on each key? (i.e., '3', or '3', 'MEM', or whatever
letter is above the 3 key) What really matters is, does _get_key
monitor keys for special combinations like 2nd+ON or 2nd+up/down?
Afterall, the whole reason I used the interrupt handler in the first
place was to ensure that the calculator could not be turned off while
entering a series of keypresses. Turning ALPHA off was even better, as
that made it impossible for the user to enter both a letter and a number
for the same key. Can I detect the ALPHA and 2ND keys in _get_key?
That would be nice. (I can't test it right now, I'm on the wrong comp)
Thanks,
Cassady Roop
>
> > I'm having some problems, and they are nasty, and I'm quite surprised to
> > find that they stem from _vputs. For some reason _vputs crashes in the
> > middle of a string. I was attempting to print the string 'SUCCESSFUL',
> > which is a part of my program that has worked for a long time until I
> > began fiddling with it again tonight. It gets to the second 'S', but
> > only prints the upper half of the character, and then it dies. The
> > emulator says that at this point it is running an endless loop in a
> > memory area that is supposed to be nonexecutable system data. I find
> > this very strange. The modifications I made to the program do not seem
> > to include anything that could possibly affect _vputs... One
> > modification is the addition of a temporary interrupt handler routine
> > that constantly loads $00 to (IY+shiftFlags) to cancel out the 2nd and
> > ALPHA keys for a key input routine (I did this to make it impossible to
> > turn it off while inputting a password). This routine does not seem to
> > be possibly detrimental to _vputs, but it is the only explanation I can
> > think of. Also, this only happens after I run the program several
> > times, which further confounds me...
> >
> > What external conditions does _vputs require to run properly?
> > (variables, obscure memory areas, ... I wonder if I could be overwriting
> > the character bitmaps or something??? where are those?... I'm at a loss
> > here...)
> >
> > Cassady Roop
> >
> >
References: