World: r3wp

it sets a flag which we calls carry (like the T flag in rebcode)

I would think a pickz on a 256-byte binary would do for a lookup 
table, putting a flag value in the invalid slots. Then you could 
react to the flag afterwards.

yes but it's a little more difficult

DAA react diffenrently after an addition or a cubstraction

*substraction

256 entries for the lookup table is not enough

More than one lookup table, depending on circumstances?

4096 entries are requested to cover all possiblities

Perhaps some math to do much of the work would be preferable.

finally, 4ko, is not so huge

You are right there...

*4 kb :-)

I forget (and don't have rebcode installed on this PC), what happens 
if you pick out-of-range in rebcode?

don't konw , never occured

i test

** Script Error: Out of range or past end
** Where: f
** Near: pickz a b 10

quite good

Not for what I was thinking. I was trying a multistep process where 
the need for the next step is determined by whether the pick of the 
earlier succeeded. I suppose the same could be accomplished by math, 
but a pick would have allowed smaller lookup tables.

and using past?

How does the DAA react differently after an add or a sub? Could you 
simplify things by combining the add/sub and the daa into a larger 
logical opcode? It occured to me, looking at your code earlier, that 
you could combine strings of opcodes that didn't include writes to 
memory into larger virtual opcodes, to cut down on interpreter overhead 
when not necessary.

i see, but DAA not follows sub or add opcodes, he can act severall 
opcodes later

It would mean more branch tables or some branch index arithmetic, 
but the interpreter could be made much faster in certain cases.

Z80 just remember if the last math operation was an add or a substract

What is the effect of the add/sub that affects the DAA? Is it some 
flag?

yes a flag, but this flag is not visible

so in rebcode , i will have to manage this trick by myself, with 
seting my own DaaFlag after a sub or an add

Sorry, that answers my question. Perhaps putting the DAA implementation 
in the blocks of an either statement on that flag would lessen the 
lookup overhead.

*by setting

I'm curious as to what the effect really is. Perhaps a positive/negative 
issue?

you can sse the trick here http://www.zilog.com/docs/z80/um0080.pdf

*see

So, it looks like 3 flags, one of which may be set afterwards, and 
some ranges. Either that means some really interesting math, or a 
4096 byte lookup table :(

What's the H flag?

Half carry flag

What's that for?

set if bit 4 is set after an operation

Got it.

useless in most case (i don't manage it in my code)

It seems to matter here. Perhaps you should set it after BCD operations.

yep, i fear that

i have to handle it in all math operations

Or for that matter, you could set the reference to the lookup table 
to be the appropriate one after the initial operation. That way you 
don't need to test the flag later - the flag could be implied.

yep it's a possibility

No need to follow CPU internal execution patterns when you aren't 
a real CPU.

thats why the lookup table have 4096 entries

get the correct offset following the content of accumulator before 
math operation

then retrive the corrected BCD result using the byte AFTER the math 
operation

hum not sure about what i said, i have to think ... more

the problem with the Half carry flag is that you must compare the 
data before with the data after

you can't just test the 4th bit of the resulting data