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.

I used to program the motorola 68hc11 if that helps

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?

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 )

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?

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:

---

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.

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.

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.

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++ ).

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...

Quote:

---

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?

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)

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.

>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 :)