home .. forth .. colorforth mail list archive ..

Re: [colorforth] bug in bit32?


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