Mail Archives: djgpp/1996/11/06/17:53:18
> eli, i don't understand your attitude ... and roger, did you actually
> run any of the tests or the demo programs to see if those programs
> worked after making the change?
Hey, settle... :)
> here is my "ridiculous" problem: i thought everyone around here knew
> that successful compilation does not mean you have a working program.
> obviously everything compiles fine once you change the lines from
> incl %ah to incb %ah. however, the same is true if you change them to
> incw %ax or incl %eax. the catch is, no matter which one of the changes
> i make, both the demo program and the test program crash (usually with a
> blank screen but sometimes with a narrow band of garbage pixels on the
> screen. i even got a SIGSEV once after i built the whole thing using
> incl %eax.) all the programs seem to run without problems under the vbe
> 2.0 emulator from ati.
> i could not try this out yesterday because i did not have a machine with
> a mach64 around. but i posed the same question then, too: which one of
> these is correct? and the correctness does not depend on matching the
> opcode and operand, it depends on what is correct for the given video
> hardware.
I don't use Allegro, and its in an archive somewhere, but if I knew
where
the problem is supposed to be in respect to which subroutine, I could
probably tell you whether it should be an 8/16/32 bit register. BUT,
going
on your saying that the program runs fine under the VBE 2.0 emulator, I
would think it should be incb %ah as the graphics library is based
around
an 8 bit per pixel setup, and the incb could just be an increment to
the window pointer to the graphics card... no?
> so, it seems to me, however retarded i may sound, there is another bug
> in the mach64 routines. but, i just do not know what.
Post the subroutine... :)
Leathal.
- Raw text -