Thanx for pointing out my errors. I intend to look into this further. For some time I've wondered if there were a faster way to convert binary to ASCII coded hex. I even played with some BCD numbers before I understood the Decimal mode. If you can code an algorithm with the lowest possible cycle count to process in 1-byte chunks, please do :-) If you still think its a good idea to code with SED as the program's default condition, I would like to see a routine to plot pixels on the high-res screen in Decimal mode!!! ;-) --- Spiro Trikaliotis <Trikemail@example.com> wrote: > Hi, > > > The routines are not out of context because they > are > > not part of a larger program. I typed them in > exactly > > as they are presented in the book, except the > comments > > are mine. The only command I left out of each code > > snippet was the BRK at the end of each. > > I know, I'm an owner of this book, too. ;-) > > > Besides, its ABSURD to assume that SED is the > default > > condition for the entire program. NO-ONE programs > this > > way. Even Leventhal recommends keeping D clear > outside > > of subroutines! For that reason I say its QUITE > FAIR > > to include SED and CLD in the cycle count. > > I'm not so sure for this. For example, in a program > dealing with monetary > values, it might be the "normal" thing to have > decimal mode. Think: That we > are not used with the decimal mode not mean that it > is not reasonable to use > this. With mainframes (of these times), most of the > times, you were working > with the decimal mode. > > Processors before the 6502 mostly didn't have a > decimal flag, they had extra > commands to do decimal arithmetic, which corrected > the value afterward the > calculation. I believe MOS thought that it would be > very handy to have this > mode, because you would not always be forced to > correct the value after it > is calculated. So, I would say that MOS indeed > thought it would be a big > advantage to be able to write most parts of a > program in decimal mode - > else, they would not have included this mode, which, > as for as I know, no > other processor (except the 65xx series) has! > > > Here're two sample routines I cooked up to test > your > > second statement: > [...] > > > ; TRY DECIMAL MODE ALGORITHM > [...] > > You know your error? > > [...] > > JSR MAKEDIG ; 6 CYCLES > > STA $FB ; 3 CYCLES > > TXA ; 2 CYCLES > > AND #$0F ; 2 CYCLES > > > ; 2 ITERATIONS FOLLOWING CODE > > MAKEDIG CLC ; 2x2=4 CYCLES > > ADC #$90 ; 2x2=4 CYCLES > > ADC #$40 ; 2x2=4 CYCLES > > CLD ; 2x2=4 CYCLES > ^^^ > Here, you're leaving decimal mode. In the second > iteration, you don't have > it anymore! > > > STA $FC ; 3x2=6 CYCLES > > RTS ; 6x2=12 CYCLES > > ; 59 CYCLES TOTAL > > > Looks like you were correct Spiro! > > Not any more with the error! > > > Now, I suppose I can further optimise it by > removing > > the subroutine calls and using straight-line code: > > [...] > > > AND #$0F ; *Can this be omitted? > > CLC ; **IS THIS EVEN NECESSARY? > > ADC #$90 > > ADC #$40 > > STA $FC > > CLD > > ; 36 cycles. BLAZING FAST! > > > * I dont' think its really necessary to mask out > the > > high nybble here. Since there is no CoMParison to > do, > > the extra nybble should just overflow thru the > Carry > > and out into the binary ether, right??? > > I don't think so! The ADC #$90 is for generating an > additional carry in case > we have a value from A - F, but not generate in in > case we have a value from > 0 to 9. Additionally, both additions want to add > $90+$40 = $(1)30 to your > value, so you end up in the range $30-$39 OR > $41-$45. > > Think of the following case: > > You have $28 to convert. The first ADC #$90 now > generates a carry, since > $28+$90 = $118 (in decimal mode). So, the second ADC > #$40 generates > $18+$40+C = $59. Observe that our result is not only > out of range, even it's > lowest nibble is not right because the carry was set > wrong! > > > ** I'm pretty damn sure that the first instance of > ADC > > #$40 will eat any carry. Thus, C is already clear > for > > the low nybble. > > NO! If your initial value was in the range 0-9, the > ADC #$40 will surely > GENERATE a carry, because the first ADC generated a > value in the range > $90-$99. If your initial value was in the range A-F, > the ADC #$40 will not > generate a carry, because the first ADC #$90 > generated a value in the range > $100 to $104. > > > ASIDE - I'm inexperienced with 6502 decimal mode > > operations. I was SHOCKED to discover that in > decimal > > mode $0A is treated as 10 'ones' units! :-O > > Well, simplified speaking, think of the decimal mode > as adding another ADD: > If a nibble of the result from the first ("real") > addition is in the range > "A"-"F", then add 6 to that nibble (that goes for > both nibbles). Because of > this strategie, the processor cannot determine of on > $0A, for example, was > generated by the first ("real") addition, or was > there as input. > > Spiro. > > - > This message was sent through the cbm-hackers > mailing list. > To unsubscribe: echo unsubscribe | mail firstname.lastname@example.org. ===== Get a FREE 6Mb webmail box from go6502! - http://www.geocities.com/profdredd As low as 2.99% Intro APR from NextCard! - http://www.nextcard.com/index6.html?ref=aff0074521 PayPal is the FAST FREE and SECURE way to send money! - https://secure.paypal.x.com/refer/pal=profdredd%40yahoo.com __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - This message was sent through the cbm-hackers mailing list. To unsubscribe: echo unsubscribe | mail email@example.com.
Archive generated by hypermail 2.1.1.