Hi George.

Thanks for the replay.

Your comment are very pertinent but I did not describe all the job as I thought was not important ( I thing ).

<<<Interestingly, I had used the same AT89C2051 with the same clock. But my manchester decoding took 40 bytes only.>>>

Yes, you are right; it is even smaller then 40 bytes but, as I mentioned I decoded all the information in the tag ( the matrix reading )and I toke some extra measures for avoid false reading ( a majority decision function ), and specially for improve the read distance ( yes, is incredible but is a matter of software too, not only of emitter power or receiver sensitivity )

<<<<What are you talking about? What is phase incertitude?>>>>

Simply XOR-ing signal and clock ( as for coding ) implies a 180 deg phase incertitude in output signal.. Analysing the pulses durations remouve it easy.

<<<Well, with due respect to the old good fellow 8051 I cannot believe that ATmega doubles the program space. My 8051-program size was about 1KB, and I reckon that ATmega code will be smaller. The ATmega parity calculation for one byte takes 3.6us at 11MHz clock and code size is 8 bytes.>>>

In this case is possible you be right too but I do some mentions. The at89c2051 do not have I2C, SPI s.a hardware found in atmega8 so I took in to consideration only software without this peripherals witch was emulated in 8051.
I confess I simultaneously work with several types of controllers ( a bad approach but indispensable for me for extra technical reasons ) and in this condition it is difficult to be master of all ( special in assembler ). I tried to do the job in C but the results was not to much satisfactory.
As you mention Atmega8 “eats” 8 bytes only for parity; 8051 needs nothing ; also direct bit manipulation of ports pins reduces the code in this kind of jobs.

Best regards.

Cristian Ceausescu