sorry correction, wrong cut/paste.

this works in 80c85
var_fix:
LDA 0FB65H
CPI 08H
JC var_carry
sui 03d
ora a
RET
var_carry:
sui 03d
ora a
STC
RET


this does NOT work
var_fix:
LDA 0FB65H      ; Type of last variable used
sui 3d
CPI 05d
JNC var_no_carry
ora a
STC
ret
var_no_carry:
ora a
ret


It's odd, I can't immediately see the difference but it is real.
the 2nd version crashes the standard M100 implementation with 80C85, and
also crashes the NSC800 implementation.

The first version works in 80C85, and I have also verified on NSC800.

strange.  will have to figure this one out!



On Sat, Dec 21, 2024 at 9:41 AM Stephen Adolph <[email protected]> wrote:

> George, update
>
> This patch works:
> var_fix:
> LDA 0FB65H
> CPI 08H
> DCR A
> DCR A
> DCR A
> JC var_carry
> ORA A
> RET
> var_carry:
> ORA A
> STC
> RET
>
> but this patch does not:
> LD A,($40AF) SUB 3 CP 8-3 JR NC,_25E5 OR A SCF RET _25E5: OR A RET
>
> have not yet figured out why!
>
> On Thu, Dec 19, 2024 at 3:13 AM George Phillips <[email protected]> wrote:
>
>> As Stephen Adolf discovered the Z-80 will compute overflow instead of
>> parity when doing arithmetic operations.  Thus BASIC's 8085 RST 5
>> subroutine won't work on the Z-80 as the 8085 computes parity on DCR A
>> while the Z-80 computes overflow.
>>
>> Note here that the routine gets Carry from the CPI and Sign, Zero and
>> Parity from the last DCR A.
>>
>> LDA FB65H
>> CPI 08H
>> DCR A
>> DCR A
>> DCR A
>> RET
>>
>> Adding a "OR A" will almost fix it as that will compute parity and
>> recompute S and Z.  But that will clear the carry.  A little branching
>> will handle this correctly:
>>
>> LDA FB65H
>> CPI 08H
>> DCR A
>> DCR A
>> DCR A
>> JR C,has_carry
>> OR A
>> RET
>> has_carry:
>> OR A
>> SCF
>> RET
>>
>> It the occurred to me that, rather like the old "replacing the step
>> stone" joke, Microsoft had to solve this problem before.  Indeed, in the
>> TRS-80 Model 1 ROM we see:
>>
>> LD A,($40AF)
>> CP $08
>> JR NC,_25E5
>> SUB $3
>> OR A
>> SCF
>> RET
>> _25E5:
>> SUB $03
>> OR A
>> RET
>>
>> I feel confident my solution will work and is even a byte shorter than
>> what Bill or Paul (or some other Microsoft employee) came up with.
>>
>> Before learning the purpose I did go into the weeds a bit looking at
>> compact subroutines to compute parity.  I'll save that for a separate
>> message.
>>
>>                          -- George
>>
>>

Reply via email to