Re: [colorforth] bug in bit32?

[Mark Slicker <maslicke@xxxxxxxxxxx>]

On Thu, 5 May 2005, Albert van der Horst wrote:

> On Wed, May 04, 2005 at 04:54:26PM -0400, Mark Slicker wrote:
> > Here is bit16 and bit32 from ftp://ftp.ultratechnology.com/GEN.ASM:
> <SNIP>
>
> > Notice above by the lablel 'b32', 'shl  EAX, 1'. I think this should be
> > 'shl  AX, 1' like in 'bit16'. I think bit32 apears to work because the
> > previous row in the bitmap will be shifted into the upper 16 bits of EAX,
> > and will be displayed on the next call to bit32.
>
> As far as I understand it, this keeping of 16 bits for the next call of
> bit32 is intended. Why would you call it bit32 if it only handles
> 16 bits? It does handle 32 bits, in two calls.

I did not name it, but the name does not necesarilly imply what should be 
the correct logic for this function. bit16 is used to write a row of the 
icon bitmap. A row is 16 bits, bit16 is called 24 times by emit. This 
displays the 16x24 icons we are familer with. bit32 is also called 24 
times but instead by emit2 (2emit). The difference between bit16 and bit32 
is that bit32 writes four pixels (2x2 square) for each bit in the bitmap 
row. The effect of bit32 being defined the way it is, is that magnified 
characters (2emit), when displayed, will be shifted down by one pixel and 
the last row of the bitmap will be cut off. Maybe this behavior is 
intended, but from my view it looks clearly like a bug.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com