Products > Programming

Another bit of 68xx code

(1/4) > >>

metertech58761:
I recently posted a bit of HC11 assembly code for converting unpacked BCD to binary, and I thank those that took time to look at it and for the replacement code that someone offered.

I figure the code that does the opposite is probably just as inefficient, so here we go.

;      Convert binary data to BCD values
bin2BCD      LDX   f2BCD
      LDAB  f2bytes
      LDAA  #$00
func02_1   STAA  $00,X
      DEX
      DECB
      BNE   func02_1
      INX
      STX   f2BCD
      LDAA  #$80
      STAA  f2bitpos
func02_2   LDX   f2binary
      LDAA  $00,X
      PSHA
      DEX
      STX   f2binary
func02_3   PULA
      PSHA
      ANDA  f2bitpos
      BEQ   func02_5
      LDX   f2BCD
      LDAB  f2bytes
      LDAA  $00,X
      ADDA  #$01
func02_4   DAA
      STAA  $00,X
      DECB
      BEQ   func02_5
      INX
      LDAA  $00,X
      ADCA  #$00
      BRA   func02_4
func02_5   LDAA  f2bits
      CMPA  #$01
      BEQ   func02_7
      LDX   f2BCD
      LDAB  f2bytes
      LDAA  $00,X
      ADDA  $00,X
func02_6   DAA
      STAA  $00,X
      DECB
      BEQ   func02_7
      INX
      LDAA  $00,X
      ADCA  $00,X
      BRA   func02_6
func02_7   DEC   f2bits
      BEQ   func02_8
      LSR   f2bitpos
      BNE   func02_3
      PULA
      LDAA  #$80
      STAA  f2bitpos
      BRA   func02_2
func02_8   PULA
      RTS

As I mentioned in the other thread, this routine has a few prerequisites before being called:

f2binary - 16-bit address of the source binary data
f2BCD - 16-bit address of the packed BCD output (these are stored in the same sequence as the readout as mentioned in the other thread; 7/6, 5/4, 3/2, 1/0)
f2bytes - I assume this is a byte counter (only 2 values are used: 2 or 4)
f2bits - I assume this is a bit counter (only 2 values are used: 8 or 24 - corresponding to above values)

metertech58761:
I'm now actively working to figure out this bit of code... my interest is trying to figure out why it pushes and pulls values on and off the stack versus using an actual variable in RAM.

It seems 6811IDE doesn't work well with PSHA / PULA, and I'm having fits trying to get THR6811 to accept ORG - no matter how I try and format the address, it gets rejected every time.  :wtf:

brucehoult:

--- Quote from: metertech58761 on January 06, 2023, 07:59:12 pm ---I'm now actively working to figure out this bit of code... my interest is trying to figure out why it pushes and pulls values on and off the stack versus using an actual variable in RAM.

--- End quote ---

It's only one thing -- the current byte from f2binary.

Push and pull are normally used for code compactness, at the expense of speed, because they are only 1 byte, vs 2 bytes each for store to direct page and load from direct page. But that is negated when you do "PULA;PSHA" when it could have been just a load, and have to add not one but two gratuitous "PULA" in func02_7 / func02_8 to clean up. You're ending up with 5 bytes of code in total when it could have been just 4 with storing the result of "LDAA  $00,X" to DP and then loading it at the start of func02_3 and that's it.

I suspect the code was hacked on a lot after it was initially "designed".

The whole 68xx "LDX ptr;LDAA $00,X;DEX;STX ptr" dance kind of pisses me off every time I see it. Sooo much easier and faster on 6502 to just do "LDA (ptr),Y;DEY", especially when you know the buffers are no more than 256 bytes, as here ("f2bytes" fits into B). When the size can be greater than 256 on 6502 then you need a little bit of fiddling in an outer loop which more or less equalises the code size. but there's still a fast inner loop.

Or 6809, of course, where you have X, Y, and if you need it U.

metertech58761:
So I could just add a dedicated variable (or even use one of the existing 'scratchpad' variables) and just do away with PSHA / PULA?

The code I started with could easily be described as "And it still works?! Really?!" Some sections only needed minor cleanup but two major sections still had to be torn to bits and reassembled in a more logical order (and the result is ALSO a few dozen bytes shorter!)

The bit about the index registers on the 68xx vs. the 6502 IS a pain indeed! It's almost like they flipped the index and base around.

MIS42N:
I already wrote the bin->dec for you https://www.eevblog.com/forum/programming/cleaning-up-a-bit-of-6800-assembly-code/msg4569265/#msg4569265

I don't have the hardware to test it using the DAA instruction so it was emulated. Not exactly what you asked for as I didn't have the requirements. I'll look later at your code and resolve any differences.

Navigation

[0] Message Index

[#] Next page