Cleaning up a bit of 6800 assembly code

[metertech58761]

When going through a bit of 6800 assembly code (actually 6801 / HC11), I came across this section and I know it can be rearranged better, but I cannot get it to work properly. I would like to see if anyone can point out how to properly rearrange these instructions, especially given that the RTS is smack dab in the middle and that a BRA is needed to continue the loop. Now, this is after I already cleaned the 'spaghetti' out of the first half and replaced a loop counter with CPX.

What this does is convert a 7-digit BCD value (readout+7 is MSB, readout+1 is LSB, readout+0 is used as a checksum digit elsewhere) into a 3-byte binary value.


addrCalc   CLC   
   CLR   temp6
   CLR   addrL
   CLR   addrM
   CLR   addrH
   LDX   readout+7
func01_1   LDAA   addrM
   LDAB   addrL
   ADDB   $00,X
   STAB   addrL
   BCC   func01_2
   ADDA   #$01
   STAA   temp6
   STAA   addrM
   BCC   func01_2
   LDAA   addrH
   ADDA   #$01
   STAA   addrH
   LDAA   temp6
func01_2   CPX   readout
   BNE   func01_5
   RTS   
func01_5   ASLD   
   STAB   addrL
   STAA   temp6
   STAA   addrM
   ROL   addrH
   LDAA   addrH
   STAA   temp7
   LDAA   temp6
   ASLD   
   ROL   temp7
   ASLD   
   ROL   temp7
   ADDB   addrL
   STAB   addrL
   ADCA   addrM
   STAA   addrM
   BCC   func01_6
   INC   addrH
func01_6   LDAA   temp7
   ADDA   addrH
   STAA   addrH
   DEX   
   BRA   func01_1

[Nominal Animal]

Friends don't just throw 68HC11 assembly at friends and ask what's wrong, friends describe the idea of what the code tries to implement (you mostly did, but not fully), and how. 

Is this packed (two decimal digits per byte) or unpacked BCD (each byte being 0..9 only)?
Or is the problem that you use an unpacked algorithm, but the data is really packed?

If it is packed BCD, I guess that your input is something like
   Byte   Bits    Description
    B0    0..7    Checksum digit, ignored
    B0    4..7    D0, least significant BCD digit we're interested in
    B1    0..3    D1
    B1    4..7    D2
    B2    0..3    D3
    B2    4..7    D4
    B3    0..3    D5
    B3    4..7    D6, most significant BCD digit we're interested in
but your description kinda implies unpacked BCD.  Which is it?

In any case, output is bytes O0, O1, O2, such that
    O0 + 256*(O1 + 256*O2) = D0 + 10*(D1 + 10*(D2 + 10*(D3 + 10*(D4 + 10*(D5 + 10*D6)))))
i.e.
    O0 + 256*O1 + 65536*O2 = D0 + 10*D1 + 100*D2 + 1000*D3 + 10000*D4 + 100000*D5 + 1000000*D6
right?  (If you use MSB, just swap O0 and O2 above, they're just labels anyway.  I like to use arithmetic numbering, which starts at zero, and increases as the significance increases, because that matches the math: value = sum digit[n]*radix^n.  I'm not a "little-endian zealot".)

The core operation here, if I were to implement this from scratch, would be
    A ← A*10+B = (A << 3) + (A << 1) + B
where A is the three-byte register, initialized to zero.  For 68HC11, we of course can only shift/rotate one bit at a time, so we need a temporary three-byte area for the shifting, since we need to do that sum.  We can do with A, B, D accumulators, if we do it before we extract the new digit B, though.

Can I use the NXP M68HC11E manual for reference, or does your architecture have a different instruction set?

[metertech58761]

In this instance, yes, it is unpacked BCD, entered from a keypad before being passed to this routine.

The HC11 instruction set will be just fine.

If you have a better algorithm in mind, I'd be all ears. If you say you need a third temporary byte, use the mnemonic temp5.

Whoever wrote the original code did not know the first thing about 68xx assembly - what I started with was atrocious!

[Nominal Animal]

I would implement the following pseudocode:
    Set addr to 0
    Set X to address of first digit
    Optional: jump to First
  Loop:
    Multiply addr by 2
    Copy addr to temp
    Multiply addr by 2
    Multiply addr by 2
    Add temp to addr

  First:
    Load next decimal digit,
      and add it to addr

    Increment X
    If we are not past the digit buffer yet,
      jump to Loop
      otherwise return from subroutine

noting that temp=addr*2; addr=temp*2*2+temp is equivalent to addr=10*addr.


I have a nagging feeling we could use the Y register for our advantage here, perhaps via XGDY, which exchanges D and Y, to avoid using temp5, and speed things up.. but me brain isn't working well enough now, captain!

I do not have an emulator handy (and can't recall where I could get one quickly for Linux), so consider the following implementation suspect, probably buggy, in need of checking:

The conversion starts with clearing addrH:addrM:addrL, and I do assume addrH has the lowest address and addrL the highest address:
        CLR   addrL             ; addrL = 0
        CLR   addrM             ; addrM = 0
        CLR   addrH             ; addrH = 0

Use X for the address of incoming digits, in increasing order of importance.
        LDX   readout+1         ; address of least significant digit
        JMP   first

Next, we have a subroutine that multiplies addr by 10, using temp5 as a scratchpad.
  loop  LDD   addrM             ; A=addrM, B=addrL
        LSLD
        STD   addrM
        LDAA  addrH
        ROLA
        STAA  addrH             ; addr now multiplied by 2,
        STAA  temp5             ; and temp5=addrH
        LDAA  addrM             ; We didn't mangle B above, so reloading addrM suffices
        LSLD
        ROL   temp5             ; second doubling done
        LSLD
        ROL   temp5             ; third doubling done
        ADDD  addrM             ; A=A+addrM, B=B+addrL, carry set if necessary
        STD   addrM             ; addrL and addrM updated
        LDAA  temp5
        ADCA  addrH
        STAA  addrH             ; addrH updated

We then want to load the next digit to B,
  first LDAB  $00,X

and add it to the 24-bit addr:
        CLRA
        ADDD  addrM             ; A=addrM, B=addrL+digit
        STD   addrM             ; addrL and addrM updated
        LDAA  #$0
        ADCA  addrH
        STAA  addrH             ; addrH updated

Advance to next digit, if any left.
        INX
        CPX   readout+8         ; past the incoming data?
        BLO   loop
        RET

Can you follow the logic above?  Could you test if it works?

If it is not fast enough, I'm pretty sure it can be sped up somewhat.  I never write fast code on the first run, I strive for correctness.

(In fact, if you think about it, it might be useful to call something like this directly from the keypad, using an extra byte to count the number of digits already pressed.  Would also save about seven bytes of RAM.  Even if the 68HC11 is running off a 32kHz clock or something, the above is faster than even the fastest human pressing digits.)

[metertech58761]

Just want to confirm a few details - the 24-bit address, it is stored as high / mid / low.

Given the atrocious code I began with, I don't think speed is terribly important (the clock speed of the MPU was a mere 1.0MHz - about the same as a Commodore 64)

Also, there's plenty of space in the ROM - especially after my cleanup / optimization of the overall code, so as long as the code is readable, we should be fine.

[DiTBho]

I think you can study this kind of routines from the old Motorola BUFALO/11 source.
The assembly source is opensource.

[Nominal Animal]

Do you know of any emulation environments for 68HC11?  They have existed for sure, but are there any that haven't bit-rotted too much?

The instruction set is small enough that a simulator for the symbolic assembly would be easy enough to write, so that functions like the above could be simulated and checked for correctness.  Binary simulators are much more work.

[DiTBho]

I have a few good emulators and debuggers for Windows XP(1)
None for Linux. Tried a few, all toyish.
I prefer real hardware, with "noICE" support.
(noICE is a commercial tool, again, for Windows).

This stuff is useful for the HC-timers and misc rather than for the HC11 ISA.

For GNU/Linux I wrote a downloader tool.
Kind of avr-dude for hc11. Nothing special.
It supports both bufalo and evb/evbu boards.


(1) I specifically bought a second hand laptop for those Windows XP dev tools.
There is a nice "talker" written in hc11 assembly, the host control program is written in Delphi Pascal.
I'd like to re-write it in C-xmotif. One day 

[DiTBho]

• THRSim11 v5.30
• Proteus v8.0 (comes with an hc11 simulator)

[Nominal Animal]

Would a symbolic ASM simulator (running on human-readable assembly source, not modeling any peripherals, only the instruction set) be of any use?

[ozcar]

   LDX   readout+7

In 680x assembly, that would have to be

Code: [Select]

  LDX   #readout+7

to make any sense.

Given the whole thing, including sample 'readout', I could probably assemble that for 6809 and see how it behaves.

[DiTBho]

Would a symbolic ASM simulator (running on human-readable assembly source, not modeling any peripherals, only the instruction set) be of any use?

limited use, hc11 makes sense for its peripherals 

ummm, there should be sim support in gdb.
or, repo like this (hc11-sim). Never tried.

[srb1954]

Do you know of any emulation environments for 68HC11?  They have existed for sure, but are there any that haven't bit-rotted too much?

The instruction set is small enough that a simulator for the symbolic assembly would be easy enough to write, so that functions like the above could be simulated and checked for correctness.  Binary simulators are much more work.

You could look around for a 68HC11 evaluation board. Motorola made several different models using the BUFFALO monitor S/W. There were also some third party evaluation boards providing similar features.

An evaluation board will generally have a fairly reasonable debugger built into it and should prove adequate for most program testing purposes. An evaluation board is also useful when you come to add extra peripheral devices your system and it allows you to debug on the actual hardware rather than trying to simulate those peripheral devices in a S/W emulator.

[ozcar]

You could look around for a 68HC11 evaluation board. Motorola made several different models using the BUFFALO monitor S/W. There were also some third party evaluation boards providing similar features.

I had one made by Axiom, something like 25 years ago!

[Circlotron]

you have

Code: [Select]

BCC   func01_2

and then

func01_2   CPX   readout
   BNE   func01_5
   RTS   

Won't exiting the latter with a RTS after initially branching there and consequently not pushing the stack eventually cause a stack underflow?

[MIS42N]

You say 'readout+0 is used as a checksum digit elsewhere', but it will get added in because your final comparison to exit is with readout, not readout+1

Also I don't know how you distinguish between an address as a literal (usually expressed as #address) and an address as a source/destination.

I would have thought you'd be using LDX   #readout+7 and CPX #readout+1 but I don't know what assembler you are using.

The code is a bit messy, possibly could use D register (A+B) to advantage in places and I would not call it addrL/M/H as addr implies address, maybe BinRsL/M/H (Binary result) but that's cosmetic. Some documentation would be good. 'here we multiply by 10' 'here we add in the next digit' etc. It may not help you but it will help the next poor sod that has to look at it. I'd just get it going and walk away - too many people fall into the "if it ain't broke, fix it until it is" mindset. Microsoft updates, I'm looking at you.

[edavid]

Do you know of any emulation environments for 68HC11?  They have existed for sure, but are there any that haven't bit-rotted too much?

There is one here: http://www.hvrsoftware.com/6800emu.htm

[ozcar]

Also I don't know how you distinguish between an address as a literal (usually expressed as #address) and an address as a source/destination.

I would have thought you'd be using LDX   #readout+7 and CPX #readout+1 but I don't know what assembler you are using.

I already mentioned that. For the 680x assemblers I encountered, # was used to indicate immediate addressing, where the byte or bytes following the opcode is the information being accessed. So, "LDX readout" would load the contents of readout into the index register. "LDX #readout" would assemble to have the two byte address of readout in the instruction, and it is that value that the instruction puts into the index register.

Using a vintage assembler of the era (which allows only UPPERCASE symbols of maximum length 6!):

Code: [Select]

    1  0000                   ORG    0
    2  0000 31        READO   FCC    '1234'    directly addressable (one byte address)
    3  0100                   ORG    $100
    4  0100 35        READI   FCC    '5678'    extended addressing required (two byte address)
    5                 
    6  0104 DE 00             LDX    READO     loads contents (first two bytes) of READO into X
    7  0106 FE 01 00          LDX    READI     loads contents (first two bytes) of READI into X
    8                 
    9  0109 CE 00 00          LDX    #READO    loads two byte address of READO into x
   10  010C CE 01 00          LDX    #READI    loads two byte address of READI into x
   11                 
   12                         END   

If the assembler used here is different, how do you load the contents of readout into the register?

[Nominal Animal]

This compiles using m68hc11-as, the GNU assembler for MC68HC11 from package binutils-m68hc1x version 2.18:

Code: [Select]

; compile using
;       m68hc11-as example.s -o example.o

.data

    temp5:
        .byte 0

    addr:
        .byte 0                 ; Most significant byte
        .byte 0
        .byte 0                 ; Least significant byte

    readout:
        .byte 0                 ; Checksum byte
        .byte 0                 ; Least significant digit (0-9)
        .byte 0
        .byte 0
        .byte 0
        .byte 0
        .byte 0
        .byte 0                 ; Most significant digit (0-9)
    endreadout:

.text

    convert:
        clr   addr+0
        clr   addr+1
        clr   addr+2

        ldx   #readout+1        ; address of least significant digit
        jmp   .first

    loop:
        ldd   addr+1            ; Least significant 16 bits of addr
        lsld
        std   addr+1
        ldaa  addr+1
        rola
        staa  addr+0            ; addr now multiplied by 2,
        staa  temp5             ; and temp5=most significant 8 bits of addr
        ldaa  addr+1            ; We only mangled A above, so reloading addr+1 suffices
        lsld
        rol   temp5             ; second doubling done
        lsld
        rol   temp5             ; third doubling done
        addd  addr+1            ; (A:B) = (A:B)+(addr+1:addr+2)
        std   addr+1
        ldaa  temp5
        adca  addr+0
        staa  addr+0            ; addr fully updated

    first:
        ldab  0,x               ; New digit
        clra
        addd  addr+1            ; Add to least significant 16 bits of addr
        std   addr+1            ; addrL and addrM updated
        ldaa  #0                ; Does not affect carry (clra would)
        adca  addr+0            ; Add carry and most significant 8 bits of addr to A
        staa  addr+0            ; and addr now fully updated

        inx
        cpx   #endreadout       ; past the incoming data?
        blo   .loop
        rts
The operand syntax is
  #value for immediates (8 and 16 bit, stored in the instruction)
  *zero for value read from a zero page address
  .label for relative jumps within -128..+127 bytes of the beginning of the next instruction

In other words,
    addd  addr    ; adds the contents of [addr:addr+1] to the D register (A:B)
    addd *addr    ; adds the contents of [addr:addr+1] to the D register (A:B), addr being in the zero page
    addd #addr    ; adds the constant addr:addr+1 to the D register (A:B)
which the MC68HC11 calls extended (EXT), direct (DIR), and immediate (IMM), respectively.

The most complex instructions are brclr and brset,
    brclr *addr   #mask .label
    brclr  addr,x #mask .label
    brclr  addr,y #mask .label
that branch to label if bits specified in byte mask are all clear (brclr) or all set (brset).

I'm using Linux, so I don't have an emulator to check if the above code works.  I guess I have to write my own, dammit.  Fortunately, the opcode coding is extremely straightforward; no bit extraction or such, as it is just a simple bytecode.

[DiTBho]

GAS syntax is not compatible with Motorola ssrmbly syntax.

[DiTBho]

You cannot recompile BUFFALO with GAS.
You need to adjust the code.

Edit:
Just checked, BUFFALO has interesting routines, bcd conversation etc

[metertech58761]

As far as testing environments, I have a small W7 box I picked up after finding that neither Parallels or VMWare Fusion would work on a M1 Mac.

(things may have changed since then, but this small PC was VERY reasonable in price and was probably a better choice for my remaining Windows needs in the end)

I have both THRSim11 and 6811IDE (former for full compile, latter for quick routine testing)

MIS42N, ozcar: Yes, well spotted. That was a typo - yes, the LDX and CPX opcodes should be immediate-mode (in other words, #readout+7 and #readout)

Circlotron: I'm not sure, but that code is as fragile as it is atrocious. Any attempts to make it flow better visually causes the code to fall apart in a multitude of brainfarts, hence my question to see if it could be rewritten a bit better.
Oh, and there are other parts of the code that are even worse, but that's another thread.

The reason I use 'addr' for the 24-bit binary result is that is exactly what it is - the address of the unit to be tested (this is part of some code for a piece of test equipment I reverse engineered a while back)

And regarding the arrangement of the readout bytes - that was dictated by the requirements of the Intel 8279 display / keyboard controller IC.
If I ever finish optimizing the code, I can probably redo it to work on something juuuust a bit more modern.

Anyway, the data readout portion of the display is 8 digits, the MSB being on the left (readout+7), going right towards readout+1, then the LSB (readout+0) contains the checksum digit (for example - if 64738 is entered as the address, the sum of the digits is 28, which is lopped off to leave just the 8. When the enter key is pressed, the code checks to ensure 8 was entered as the checksum before passing the data down to this routine).

Nominal Animal: Your code didn't work.  The X register address just kept drifting upwards and never exited.

[Nominal Animal]

Nominal Animal: Your code didn't work.  The X register address just kept drifting upwards and never exited.

Dammit.  The INX ; CPX #endreadout ; BLO .loop should have worked.  The loop order is correct, it progresses from least significant digit to most significant digit.

Oh well, time to create a simulator –– in Python, I think, for maximal OS portability and user modifiability without a toolchain –– to lick this.

[MIS42N]

Can't resist trying this.

I downloaded what is supposed to be a 6811IDE emulator from http://www.hvrsoftware.com/download.htm. Unpack the program is SDK6811.exe and run it - doesn't need installing.

When I used the ADDD instruction, it did not seem to deal with the C carry flag properly, setting it when it shouldn't. So I replaced it with ADDB and ADCA. I'm assuming this is a bug in the emulator and ADDD will work properly in firmware. LDD and STD seemed to work OK.

This code appears to work OK in the emulator - just save it as a text file, load it into the emulator with the LOAD button and RUN. The value 7654321 is hard coded, and converts to 0x74CBB1 (location 0003-5)

Code: [Select]

        bra convert

temp5 .byte 0

binV0 .byte 0       ; big endian
binV1 .byte 0
binV2 .byte 0

read0   .byte 0       ; Checksum byte
        .byte 1       ; Little endian value
        .byte 2       ; 7,654,321
        .byte 3
        .byte 4
        .byte 5
        .byte 6
read7   .byte 7       ; first digit

convert clr   binV0   ; result = 0
        clr   binV1
        clr   binV2
        ldx   #read7  ; point to first digit
        jmp   first

loop    ldaa  binV0   ; Multiply binary value by 10
        staa  temp5
        ldd   binV1   ; 2 shifts = multiply by 4
        aslb
        rola
        rol   temp5
        aslb
        rola
        rol   temp5
        addb  binV2   ; add the original = multiply by 5
        adca  binV1
        std   binV1
        ldaa  temp5
        adca  binV0
        staa  binV0
        asl   binV2   ; 1 shift = multiply by 10
        rol   binV1
        rol   binV0

first   ldaa  0,x     ; add in next digit
        adda  binV2
        staa  binV2
        bcc   next
        inc   binV1
        bne   next
        inc   binV0
next    dex
        cpx   #read0   ; all done?
        bne   loop
        rts





[metertech58761]

I have that downloaded and it is a handy app to test 68xx code fragments once you understand how it expects the code to be formatted.

Just tried it and seems to work like a champ. Thank you!