After staring at it for a bit I can tell that it's dreadfully clever, and that the hex constants loaded into the Y register (and subsequently stored in .B) serve two purposes, at least for OUTDEC8Z. The high bit is iteration control for the inner loop which runs two or four times per digit (depending on which routine and which digit), and the lower bits form part of an ASCII character.

After staring at it for a bit I can tell that it's dreadfully clever, and that the hex constants loaded into the Y register (and subsequently stored in .B) serve two purposes, at least for OUTDEC8Z. The high bit is iteration control for the inner loop which runs two or four times per digit (depending on which routine and which digit), and the lower bits form part of an ASCII character.

I agree, and I would like to place my bet for authorship on dclxvi (Bruce).
Mike

... [snip] ... BUT! I do not understand WHY this all is working!

You may be wondering about base conversions for when you want decimal input and output even though the computer internally uses hexadecimal. After all, we're also talking about handling things like decimal points and signs for input and output. It's not particularly difficult; and you can use the same routines to convert to and from any base, changing only the number in variable BASE. It does require multiplication and division, but you only do it when it's time for human I/O, and otherwise let the computer do its business efficiently in hex. The processor does not even need any decimal-mode arithmetic instructions like the 6502 & '816 have.

Here's an explanation of how, simplified not quite to the point of lying. It should give the basic understanding so you can write suitable routines. For inputting numbers from a text string (e.g. typed in from a keyboard), initialize a number as 0 to build on, then take the first digit in the string and add its value to the hex number you're building. Continue until you're out of digits, each time multiplying the build by the number in variable BASE and then adding the new digit's value to the build. If you encounter a decimal point, keep track of how many digits were after it. In Forth, the decimal point automatically makes the result double-precision; but you can convert back to single if you want to. If there was a minus sign, record that too.

For converting hex numbers to other bases for output (which will normally be a string), initialize a blank string. You will build it from right to left. Divide your number by what's in variable BASE, and use the remainder to add a text digit to the build, even if it's a 0. Keep doing that until there's 0 in the number. You can add a decimal point or other characters between digits, e.g. 12.345 or 12:36:40 (actually you might want to change BASE from 10 to 6 and back for the time readout, if you started with a number of seconds!)

The way Forth does this output number formatting is somewhat explained starting at about the middle of the page of chapter 5 of Leo Brodie's "Starting Forth" (with ANS updates here, and they're mostly calling single-precision 32-bit, like I want for the 65Org32 with all 32-bit registers).

I have tried to expand it to 16 bits.

The .B constants would be for

1 shift : 10011000=$98
2 shifts: 01001100=$4C
3 shifts: 00100110=$26
4 shifts: 00010011=$13

all this constants fit in 1 byte. Unfortunately the second loop (4. decimal digit) needs 5 shifts. Can anybody confirm this?

Wolfgang