That is probably old news here but I didn't know and found it clever use of BCD mode.

https://twitter.com/adumont/status/1381 ... 02785?s=19



The code is brilliant. For 0-9 the first step gets $90 to $99, which are the uppermost values BCD can represent in a byte.
For 10-15 this gets, through the overflow, then $00 to $05, plus carry.

Adding $40 in the second step results in $30-$39 and $41-$46 (due to the carry).

There is no branch but sed and cld add cycles. Still have to compare with a classic conversion.
But nevertheless clever code.

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That technique is as old as dirt. This was used in at least two places within the DDT debugger of CP/M-80:



The 6502 version:



The brute force version:



The "clever" method is one cycle faster for 0..9 and two bytes smaller.

The fastest way on the 6502 at the expense of more bytes is:



The 8080 and 6800 cannot do that...

Ooh, that is good. I have never seen that before...

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

From https://twitter.com/LIV2/status/1381885385085755392

who got it from http://www.6502.org/tutorials/decimal_mode.html#6

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Or we could be happy that people are discovering and sharing knowledge about programming the 6502.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I like reading these sorts of threads - mostly because it highlights my old saying of ask 10 programmers, get 11 answers...

It also demonstrates just how varied our world is with different people coming up with different ideas and styles - for different reasons....

My own coding style is often somewhat verbose and easy to read - and that's intentional. Until I'm really pressed for space I tend to not code for space efficiency (or even speed - until I really need it) so my preferred hex print code looks like:



It's easy to read and follow, but yes, is a bit longer and has some extra guards in it to preserve Y - which in a more tighter system may be eliminated, but, for me, its easy to read now and re-read years later and easy to understand.

(and interesting choice of me using Y here - vs the use of X above - no difference in this instance, but just an interesting thing I note)

When I (re) started my 6502 love, I write my own 'wozmon' - it was much bigger than the Woz original, even bigger than the 2K one in the Apple II, but back then what were the constraints? RAM and ROM were very expensive, so Woz had to save every byte he could. I don't have that restriction, so is that making me lazy? Who knows.

I'd actually suggest I'm more lazy because I've never bothered with decimal mode on the 6502 - I've never, ever had a use for it in it's intended use-case, but it's very interesting to see little hacks like this.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Haha, I knew it would be old news here

But interestingly for a while here I still thought it would be the shortest one, but then came the BCD version here with 8 bytes http://www.6502.org/tutorials/decimal_mode.html#6
I'm interested what the comment on that page relates to regarding "relying on undocumented behaviour"? The decimal mode is well documented, so why should this be undocumented?

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

I think decimal mode is documented when the hex digits are in the range 0-9, but when they are A-F, the machine does whatever it does - and that's the sort of thing where different implementations can differ.

Ha, I see BDD has edited out the max 10 cycles in the original post that I tripped over here
Because if branch is taken the ADC does not count, so it's 8 max.

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

So, let's compare the different versions

1. BCD version

• size: 6
• NMOS: 8 cycles
• CMOS: 9 cycles (ADC in decimal mode is once add. cycle)

Note: behaviour in decimal mode for values 10-15 typically work, but are actually not defined.

2. Branch version

• size: 8
• NMOS: 7 cycles for digits 0-9, +1 if page is crossed on branch. 8 cycles for digits A-F
• CMOS: 7 cycles for digits 0-9, +1 if page is crossed on branch. 8 cycles for digits A-F

Note: different versions exist where e.g. the EOR is replaced with ADC (and values adapted) but they have the same properties.

3. Table version

• size: 22 (assuming HTAB is not in zeropage, in which it would be 21, but 16 of them ZP)
• NMOS: 8 cycles (+1 if index crosses page boundary)
• CMOS: 8 cycles (+1 if index crosses page boundary)

Note: additional code and cycles are needed to protect YR (typically easier per byte, not nibble)

Summary

1. The BCD version is the shortest one with 6 bytes, with the additional benefit of using constant time (per CPU type) of 8 or 9 cycles, but relying on potentially undocumented behaviour
2. The Branch version is the fastest one with 7-8 cycles, with variable execution time, with 8 byte size.
3. The table version is the largest, but has constant time of 8 (+1 if page crossing, which can be controlled by placing code) without BCD mode

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Don't the other methods also need to do the "AND $0F"?

Also, if we do both nybbles in a byte, the cost of the table is only an additional 8 bytes per instance.