Thread: Anyone familiar with 68xx assembly AND C?

  1. #1
    Registered User
    Join Date
    Apr 2021
    Posts
    20

    Anyone familiar with 68xx assembly AND C?

    First time posting here, be gentle.

    So I've got this little electronics project I've been working on because this ongoing 'human malware' situation has pretty much cut off my other hobbies for the duration.

    I eventually come to find that the custom (and unobtainium) microprocessor at the core of the project (an MC6800 derivative) is basically dead in the water. If I want to get this project working, I have to look at a newer platform, so I pretty much need to get 8K of somewhat densely written assembly translated into a more commonly used programming language, something like C.

    I have the disassembly of this code about 2/3 translated into approximate statements that should be fairly straightforward to rewrite into proper, functional C (which dialect, I am not sure yet, but I AM looking at Arduino as a possible destination platform).

    So, tl;dr - I want to know if there is anyone who understands 68xx assembly AND C and can help me with the remaining third of this code. I'm no stranger to programming in general, but I do not yet know enough to be competent with C.

  2. #2
    TEIAM - problem solved
    Join Date
    Apr 2012
    Location
    Melbourne Australia
    Posts
    1,896
    I used to program the motorola 68hc11 if that helps

  3. #3
    Registered User
    Join Date
    Apr 2021
    Posts
    20
    That does, actually!

    Software-wise, omit the HC11's Y register and you have the equivalent of the CPU in question.

    Let's start off with the BPL / BMI conditionals and handling of signed numbers... suggestions for how to rewrite these?

  4. #4
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    38,568
    Do you have an instruction set reference?
    6800 instruction set

    BMI - Branch if minus
    if ( my_signed_number < 0 )

    BPL - Branch if plus
    if ( my_signed_number >= 0 )
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  5. #5
    Registered User
    Join Date
    Apr 2021
    Posts
    20
    Here are a couple examples of BMI branches in my code:

    Code:
    LDA A msg23
    CMP A # 0x41
    BMI LB_FC23
    Code:
    LDA B keyNum
    BMI LB_EAB5
    So, for the second example, I would just write (for now - proper formatting comes later):

    Code:
    if ( keyNum < 0x00 ) goto LB_EAB5
    right?

  6. #6
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    38,568
    In C
    Code:
    if ( foo != 0 ) {
        // then code
    } else {
        // else code
    }
    In assembler,
    Code:
    LDA B foo
    BEQ else_part  // the inverse of foo != 0
    // then code
    BRA endif
    else_part:
    // else code
    endif:
    Or
    Code:
    LDA B foo
    BNE then_part
    // else code
    BRA endif
    then_part:
    // then code
    endif:
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  7. #7
    TEIAM - problem solved
    Join Date
    Apr 2012
    Location
    Melbourne Australia
    Posts
    1,896
    You're right in that the branching commands in the 68s are like a goto statement, as it is a shorter version of the jump statement (unlike the branching statements on a PIC that only skip the next statement, which you'd usually put a jump statement anyway).

    What Salem is saying is that using gotos make very bad C code, so you want to be trying to be finding different ways, like putting the code in the if statement.

    All that being said, if you are just trying to decipher what it's doing and then doing a full rewrite, goto is what you're after.

  8. #8
    Registered User
    Join Date
    Apr 2021
    Posts
    20
    I've got the BRA conditionals changed to goto statements, the BNE statements changed to !=, BEQ to ==, most of the BLE to <=...

    The BCC and BCS (and accompanying ASL / LSR statements) branches have been changed to a two-stage conditional: doing an AND on the bit needed, then doing a corresponding != or == statement.

    Let me make a PDF printout of the code as it lies and i'll put it up.

  9. #9
    Registered User
    Join Date
    Apr 2021
    Posts
    20
    Here's a couple samples of the code as it stands now.

    Please keep in mind that I KNOW it is nowhere near proper formatting OR structure for C.

    My goal right now is transliteration: converting the assembly statements into phrases that can later be rewritten into proper C.

    This is just to give an idea of what I have done and samples of some of the remaining code I need to work out.
    Attached Images Attached Images

  10. #10
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    38,568
    What's the end goal here?

    a) Actual readable C code you can maintain and enhance in the future.
    b) The ugliest hack that will just get past a C compiler to allow you to put the same functionality on another processor.

    There are a couple of things I would suggest you do.
    1. Leave all the assembler in place.
    As you learn more, you might revise your opinion on what some code is actually for and come up with a better C representation for it.
    If you delete it, you're stuck with your first guess.

    2. In the actual assembler, rename all the labels which are the targets of backward jumps, such as BNE LB_E21D as BNE LOOP_E21D
    These will almost certainly be some kind of for / while loop.

    Assembler
    Code:
    label:
      // opcodes
      BR? label
    This will be a do ... while ( condition ) loop.

    Assembler
    Code:
    label1:
      // opcodes1
      BR? label2
      // opcodes2
      BRA label1
    label2:
    A branch inside a loop is likely to be a for loop or a while loop.
    Both of these evaluate the condition at the start of the loop, so there is a branch out of the loop when some condition is satisfied.
    Use a for loop if there is some obvious counter increment at the end of opcodes2, as typically this would be your i++ in for ( i = 0 ; i < 10 ; i++ ).
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  11. #11
    Registered User
    Join Date
    Apr 2021
    Posts
    20
    My end goal? A proper C program, of course.

    I don't want something that needed to be brute-forced through a compiler, no! The end goal is a program that reads well and flows well. If I have to stop where I am and just start over from scratch, I may well end up having to do so.

    I wanted to see how much I can transliterate and in doing so, make it easier to understand what the code is doing. I've already identified a few significant program sections (and renamed them in my transliteration). I've already identified some key variables.

    I know the code - both the original assembler and my work in progress - is stone cold ugly. Again, a mere basis for a full rewrite.

    I've already plucked out a fair number of shortcuts that make more sense in assembler than they do in C, and have even rewritten a few small sections, and identified an entire section that is ripe for a full rewrite once I am further along.

    I'm no dummy as far as the code goes either. I made sure to keep an unaltered copy of the original disassembly, and it has come in handy several times already.

    So - do I push forward with my current effort, or do I stop and start over from scratch? There is still a fair bit that needs to be discerned, including identifying and removing some code I know I will not need or want in the final product...

  12. #12
    Registered User
    Join Date
    May 2010
    Posts
    4,585
    So - do I push forward with my current effort, or do I stop and start over from scratch?
    No matter what it will probably be a combination of pushing forward and starting over. Most of your initialization functionality will probably require total rewrite because of the new processor, also any timing routines will probably need severe tweaking as well.

    Since you're dealing with obsolescence of the processor what other key hardware is also going to need to be updated?

    Also since you mention a "custom microprocessor", what made it custom? How will this "custom" affect the hardware going forward?

    Also what changes in operation will be desirable going forward? How will your company want to improve the produce during this major redesign?

  13. #13
    TEIAM - problem solved
    Join Date
    Apr 2012
    Location
    Melbourne Australia
    Posts
    1,896
    Sorry, I haven't been able to download the pdf, as I've only been on my mobile phone.

    If were me and my work place, I'd never be able to justify the amount of hours needed to go through and translate 8k of assembly to C and then rewrite it again. You are double handling the code.

    I'd instead say, here is the inputs, here are the outputs, and then write everything in between - fresh - only looking at the assembly code when I wasn't sure about the expected behaviour, or I needed to save time developing algorithms.

    You can now get massive amounts of onboard memory compared to the 90s, so a lot of those clever tricks to save memory are just not helpful, just a pain in the arse to anyone trying to maintain the code later...

    The 68HC11 I used in uni, and that had 256 bytes (not kilobytes) of non-volitile memory to write your program. (Although the Mororola assembly language is quite good at making small programs, and you only had to work with linear memory, so you could do quite a lot)

  14. #14
    Registered User
    Join Date
    Apr 2021
    Posts
    20
    jimblumberg: The other major ICs in this:

    8279 keyboard / display driver: I've already identified all the code pertaining to the calls to this IC, so it "shouldn't" be that difficult to replace the keyboard routines - I want one with a more standard layout anyway, and I've also identified everything relating to the display, and want to transfer that into an LCD instead.

    MC6840 Programmable timer: All three channels are used, but two are used strictly for internal timing; one is for a variable-length delay timer, and the other is also an internal timer I haven't quite identified yet. Those will likely get replaced by some kind of a delay routine. The one with a physical output is a "set and forget" deal, generating a low-frequency clock. That one is going to be replaced by a 555 with external reset.

    MC6821 PIA: This is like the main output - I have a list of all the calls to the two ports, I just need to work out what happens when the registers are written to. Port B has almost nothing external, so it may be providing some kind of internal timing. Port A has at least 5 of the port bits in use, and the control register I believe runs the watchdog.

    RAM: There's not even 256 bytes devoted to variables in this, so I don't see any issue on that front. There will undoubtedly be a few introduced as "scratchpad" variables.

    The 'custom' microprocessor was apparently a MC6800 derivative that was mainly developed for automotive applications. It had the 6801 instruction set and hard-wired address / data pins (as opposed to the Port A, Port B, etc. pin arrangement). The only impact it has on the design is that its being long-obsolete is forcing me to rewrite the code.

    OK - so what I'll do at this point is try and figure out the calls made to the timer chip and the PIA, then start a separate project from scratch.
    Last edited by etech58761; 3 Weeks Ago at 09:28 PM.

  15. #15
    TEIAM - problem solved
    Join Date
    Apr 2012
    Location
    Melbourne Australia
    Posts
    1,896
    >OK - so what I'll do at this point is try and figure out the calls made to the timer chip and the PIA, then start a separate project from scratch.

    Sounds good - You'd have to do that anyway

    That being said: if you need to check something in tye assembly and don't understand, we're here to help

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Anyone familiar with Qt?
    By Al3 in forum C++ Programming
    Replies: 4
    Last Post: 03-04-2015, 10:34 AM
  2. Need someone familiar with DLLs
    By Kurisu33 in forum Windows Programming
    Replies: 9
    Last Post: 09-14-2006, 02:01 AM
  3. Anyone here familiar with FIRST?
    By KingDubya in forum A Brief History of Cprogramming.com
    Replies: 6
    Last Post: 12-02-2005, 02:37 PM
  4. Familiar with AnsiString??
    By tegwin in forum C++ Programming
    Replies: 3
    Last Post: 02-28-2002, 01:20 PM
  5. Anybody Familiar with A.L.I.C.E. bot?
    By blackwyvern in forum C++ Programming
    Replies: 6
    Last Post: 01-23-2002, 10:53 PM

Tags for this Thread