[Coco] [Color Computer] OS-9 Editor and NitrOS-9 Download

[David]

On Thu, Dec 11, 2003 at 11:53:37AM -0500, KnudsenMJ at aol.com wrote:
> In a message dated 12/10/03 6:09:37 PM Eastern Standard Time, 
> dbree at duo-county.com writes:
> 
> > It probably was.  It was probably just defined as a "char", since there
> >  is no unsigned char in Coco C, and it was never changed.  Of course, it
> >  was a bug to not mask off the MSB in the first place.
> 
> Right, but there's a catch here.  The usual way to fake "unsigned char" on 
> the Coco is, given a char variable ch, is
>     (ch & 127)      /* I have dozens of these in UME source code */
> but in the Scred case you want the full 8 bits, so you have to first extend 
> it to a 16-bit int and then mask out the upper byte, so you need something like

In looking at the code, it seems that the ALT-keys are ignored, so the
upper bit can be ignored.  However, what I did was to change the branch
instructions.

FWIW, here's the snippet of code in the section I changed:

Note that this assembly source is just a raw disassembly with no attempt
to make a "real" source.  I'm sure most of you can see what is going on.
----------- cut --------------
L05b9 ldd   #2
 lbra  L0655
L05bf lbsr  L4dd0
 lbra  L064e
L05c5 lbsr  L2aed
 lbra  L064e
L05cb lbsr  L29b3
 lbra  L064e
L05d1 lbsr  L0753
 lbra  L064e

* check for control character
L05d7 cmpu  #$0020
 bge   L05ed        changed to bcc L05ed
* This area processes control-key combinations, but with "bge", a signed
* comparison, CTRL-A would also be processed here.
 tfr   u,d
 lslb        These two lsl/rol's would handle offset x 2
 rola  
 leax  >239,y  Point to CTRL-function table
 leax  d,x
* Oops!  in orig, suppose you'd hit ALT-<something> to give $ff, This
* unsigned character would have been sign extended to $ffff before
* calling this function, and then would have been rotated to $fffe,
* thus, x would now be pointing two bytes IN FRONT OF (or BEFORE) the
* table's actual begin !!!  The bcc I changed it to, however, caused
* a jump in the instruction following L05d7 above.

 ldd   ,x
 std   ,s
 bra   L060e

L05ed cmpu  #$007f  ALT-KEY
 bgt   L064e        changed to bhi
 cmpu  #$0060
 ble   L064e        changed to bls
 pshs  u
 ldd   #$ff9f
 addd  ,s++
 lslb  
 rola  
 leax  303,y
 leax  d,x
 ldd   ,x
 std   ,s
 bra   L060e
L060e ldd   ,s
 beq   L0616
 jsr   [,s]
 bra   L064e
L0616 bsr   L0659
 bra   L064e
L061a cmpx  #$001b
 lbeq  L0579
 cmpx  #$000d
 lbeq  L0592
 cmpx  #$000a
 lbeq  L05aa
 cmpx  #$003f
 lbeq  L05bf
 cmpx  #$003b
 lbeq  L05c5
 cmpx  #$002e
 lbeq  L05cb
 cmpx  #$002c
 lbeq  L05d1
 lbra  L05d7
L064e clra  
 clrb  
L0650 std   D0049
 lbra  L0525
L0655 leas  4,s
 puls  u,pc
----------- cut --------------

In the code above, If we could have masked off the the high bit in  one
single instruction, for the value held in the U register, then we could
have corrected the whole thing, but I didn't want to add any
code bytes so simply changed the relative branching modes, and it seems
that this corrected the problem.

>     (((int) ch) & 255)
> to get the offset you will be adding to index the table.
> 
> In assembly, you just LDB ch and then CLRA before doing the coupled left 
> shift by one to double the offsets --Mike K.

Yes, in assembly, you have more control over how it works.