The Crossroads of personal computing (it goes on and on).

Well it had to happen, four episodes and all I get is fan mail, I had to go and blow it on the fifth now didn’t I. Yet, strange, only two letters and one phone call to tell me. Either no one out there is reading this rubbish, or no one out there understands it, or you are all so poor (having taken out a second mortgage to buy the darned thing in the first place), you can’t afford a stamp. Well, having been caught by the way B2HEX worked half way through writing the last episode, I wasn’t thorough enough in checking the thing myself. When making use of tricks to do useful things in programs, I said you needed to know exactly how an instruction worked, and then proceeded to waffle on about how the DAA instruction went about its ‘doings’. Got it wrong didn’t I?. Made it up from what I thought it did, didn’t I? Didn’t look in the Zilog bible, did I? Oh what the heck, I made a dogs’ breakfast of it and now I’ve proved what I said in the first episode, that I’m not qualified to write this stuff anyway. Call that an excuse? Yeah!! Want to make something of it?

So it’s sackcloth and ashes time, I consulted the Zilog bible (not the little one in the Nascom manual, the big fat ‘Zilog Programming Manual’), and intoned one hundred times as a penance, “The DAA instruction works as follows ......”. Now I must impart the truth and explain exactly how it does work. Fortunately (for me) the remainder of my description of the B2HEX routine is correct, even down to the introduction of the ADC 40H as a ‘fiddle factor’. It was only the way the DAA dealt with it which was wrong.

So here goes. Firstly, the invisible ‘Half Carry’ flag is not affected by the DAA instruction itself, in fact, it is the preceding arithmetic instruction which sets the H flag for the DAA instruction to use. The instructions which affect the H flag are ADD, ADC, INC, SUB, SBC, DEC and NEG. The DAA instruction works conditionally in the following manner: