I don't see where it makes much difference In general in BASIC but in this case there is a justification for MSB first ;-) It goes from MSB to LSB because the same routine does 4 or 2 digits depending on where you enter; line 5 gives the 4 digit address and it falls through to line 7 which also gives the 2 digit bytes peeked and creates the ASCII value for the text on the right hand side.
I suppose going the other way I'd always have to start at the beginning and return after two digits* 'if'* doing peeks instead of addresses; more complicated IMO. m On Thu, Oct 27, 2022 at 6:04 PM John R. Hogerhuis <jho...@pobox.com> wrote: > > > On Thu, Oct 27, 2022 at 1:10 PM MikeS <dm...@torfree.net> wrote: > >> More good tips, thanks. Yes, I have to look at defining the various >> types, especially the ones that can go above 32768. >> >> Concatenation with '+' is a habit from other languages I've worked with; >> as a matter of fact in most cases the M100 lets you print without any >> separators at all, e.g. print A$" to "B$ or a"plus"b >> >> Interesting discussion (at least for some of us ;-) ) >> >> > > One overall thing in outputting numbers in any radix, is that it is > *usually* most tractable in reverse of how you output since we generally > write/read numbers with the most significant digit first. So for generating > a number to output, It is most efficient to extract the least significant > digit, shift or otherwise divide by the radix, prepend the extracted number > onto a string/buffer, and when the value gets to zero, you're done, output > the string. > > So for the number 1235 in decimal, > > 1235 MOD 10 = 5. Prepend ASC('0') + 5 on buffer. Divide remaining value by > 10 > 123 MOD 10 = 3. Prepend ASC('0') + 3 on buffer. Divide remaining value > by 10 > 12 MOD 10 = 2. Prepend ASC('0') + 2 on buffer. Divide remaining value > by 10 > 1 MOD 10 = 1. Prepend ASC('0') + 1 on buffer. Divide remaining value by 10 > Remaining value is 0, so we're done. Buffer contains the number > > In your subroutine at 5 it is doing it MSB to LSB, I think. Overall your > way may still be faster in BASIC even with the larger divisors. > > With hex it's a question though since MOD 16 can be done with AND 15 which > is probably faster than a general integer 16 modulus. There's no bitshift > operator so you still need a integer divide by 16%. Who knows how efficient > an integer divide by 16 is in the interpreter versus 4096 (integer) > divides. > > -- John. > >>