Help, need help with an old 68hc11 assembler !!

Howdy,

Hope somebody can help.......

I'm working on a project with an old American Automation Inc 68HC11 assembler and linker, dating back to 1988. AS68HC11.EXE and AALINK.EXE

I tracked down the company, now American Arium, but they stopped supporting the product and 'threw out all the documentation', about four years ago. Arrgghhhh

At any rate, I need the command line options for the Linker..... as I'm trying to generate a symbol table.

Can anybody help me on this ??

Thanks

DennisB

Reply to
DennisB
Loading thread data ...

When run with no params, any well designed .EXE should give options, sometimes full help needs -H or ? the command line.

Failing that, you can look at the .EXE in an editor, and look for the param string area, and that will give more clues.

-jg

Reply to
Jim Granville

Jim Granville wrote in news:428bdf6f$ snipped-for-privacy@clear.net.nz:

Thanks for the suggestions Jim, but I tried them all.... and spent another hour trying 'dummy' command line options.

DennisB

Reply to
DennisB

You could try using the "strings" command (available under Cygwin) to see what text messages are in the executable.

Andrew

Reply to
Andrew Jackson

Thanks

I've tried that and even did a quick disassemble with IDA.

The program was written in assembler, using MASM 6 or 7.

The options are single letter and are combined with + - @ and possibly with * and &. ie /ru-s @3200 -test.h

I've tried MANY combinations, but still no symbol table..... which makes debugging a 10000 line file, a challange.

At any rate, I was hoping somebody had an old manual, with the command line options hanging around.

Thanks for the help !!!

DennisB

Reply to
DennisB
[...]

You could ask on the mailing list of the group in my sig below. While the group is dedicated to the 6800 and 6809 FLEX OS, there are many oldtime 68hc users in the group. Some of them have even ported FLEX to hc11.

--
http://www.flexusergroup.com/
Reply to
Bjarne Bäckström

The OP said that it was a 10000 line program. It is likely that porting such a program to a different compiler is not likely to be trivial.

-Robert Scott Ypsilanti, Michigan

Reply to
Robert Scott

6811 Assemblers can't be rare. If you're not supported, sounds like time to move to another assembler. You are simply going to relive this pain over and over again until you move.

I did quick search on "68hc11 assembler", it lit up like a Chrismas tree. Including free ones.

Reply to
Scott Moore

Indeed not. Gnu binutils supports the 6811/6812 architecture. It's free (libre and gratis), and it's better supported than anything other assembler I've ever used. Gcc supports the architecture as well, and does a far better job of code generation that the (admittedly old) commercial compiler I used to use.

Yup. It'll always be "just one more small change before we EOL the project."

--
Grant Edwards                   grante             Yow!  I've got to get
                                  at               these SNACK CAKES to NEWARK
                               visi.com            by DAWN!!
Reply to
Grant Edwards

You could also search for .MAP ( or whatever the HC11 convention is for link symbol/map output - do you know if this SW is able to do this. Also, if you have full archived project directories, you might find an example symbol file, and if lucky, the linker command line will be reported in the top... Failing that, another pathway would to be find a HC11 simulator that can read the absolute files, and report the symbols.

-jg

Reply to
Jim Granville

snipped-for-privacy@dont-mail-me.com (Robert Scott) wrote in news: snipped-for-privacy@news.provide.net:

Howdy,

Well, I ended up spending a few more hours with IDA (the disassembler) and I'm on track to cracking the secerts of the linker.

I was hoping to not have to spend the time (and customers money), but that's the way it goes. We are going to port the whole mess over to new hardware/processor later this year, but some fast fixes need to be incorporated.

BTW, the 68HC11 project is hugh, poorly written, maintained by many and loaded with pot holes that I hope to not re-visit. The idea of switching compiler is totally out of the question.

Some of the early coders had misconceptions about the use of DB and DS so varaibles sit on top of each other. Later coders found ways to work around these issues, without fixing the root cause...

Multiple ring buffers that don't check for space avaliable before dropping data into it..... and the list goes on.....

And, it's all stuffed into a medical product that's been around for a long time...... so don't get sick !!!

Thanks for the help and suggestions....

DennisB

Reply to
DennisB

"assembler", in case that addresses your concern. In case it does not, yes, I have moved that much assembler code from one assembler to another. The only thing that should be different is the pseudo-ops, and those can be searched-replaced by a decent editor.

Reply to
Scott Moore

Is it assembler, or a compiler ? Please don't call an assembler a compiler. I have created several of both, and I assure you, there is a big difference.

I'll assume you are talking about an assembler. These are easy to move. Since you must eventually end up with a binary load file, you can move it to a new assembler, then compare the two files for equality, old and new assembler. The only difference should be the pseudo-ops, which can be changed easily with a decent editor that has search and replace, and preferably RE.

Thats nothing. I once worked at a place where they decided that the "call" instruction took too much execution time, so forbade all subroutines in the code.

Reply to
Scott Moore

Sometimes (perhaps often) you get lucky like that, but I don't remeber the 'easy' conversions. I was once given 6805 source code (maybe only 2k lines, horrible code but the company made money selling the product) and the assembler for it that ran on an older Macintosh. I was able to run a Mac simulator in Windows and assemble it, but that was a lot to go through. I converted it to 2500AD assembler, which required substantial movement of things from the single-source-file Mac version. I made separate sections of zero-page variables (neccesary, else 2500AD would create code with two-byte addressing), other ram variables, and code, as opposed to wherever they were in the original. It's been a few years, I forgot doing this until reading this thread. It took maybe a few days, including reading all the sections about 'sections' or whatever they were in the 2500AD manual, but I did get it to assemble to a binary that verified with the original binary. It's not always trivial.

-----

formatting link

Reply to
Ben Bradley

... snip ...

I have seen commercial equipment with hidden hard and software replace the thoroughly characterized homegrown systems I built in the 70s and 80s. My software generally ran with all run-time checks enabled, including such things as arithmetic overflow, index ranges, etc. The replacements also had the advantage of requiring expensive reagent packages from the vendors.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
Reply to
CBFalconer

I'll believe that someone can write an assembly program so bad that it cannot be ported.

Reply to
Scott Moore

If you have both the original source and the binary, to prepare to modify and assemble on another assembler, simply disassemble with a suitable disassembler and edit the result. Most of the editing will be replacing identifiers, such as "L0123" -> "foofaw". My id2id-20 package will be very useful for this. You have an absolute check by comparing the original binary with the regenerated binary.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
Reply to
CBFalconer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.