Motorala Hex

[James_Parsons]

could someone translate this into Motorola hex for me. I have done some research, but I don't know what the record types should be

Code:

Code: Select all

A2 0A CA D0 FD 60

sorry I might be spamming again

[GARTHWILSON]

James_Parsons wrote:

could someone translate this into Motorola hex for me. I have done some research, but I don't know what the record types should be

Code:

Code: Select all

A2 0A CA D0 FD 60

I haven't used Mot S-record hex files, only Intel Hex; but the wikipedia article at http://en.wikipedia.org/wiki/S-record should help. You will need the address too though to make an S-record line.

[James_Parsons]

I just can figure out what the S-records are

[whartung]

Untested

Code: Select all

S0030000FC  // Header record with vendor specific information -- there is 0 bytes of that here
S1090200A20ACAD0FD6054FD // Your program, loaded at 0x0200. Repeat these as necessary
S5030001FB   // How many S1 records were there.
S9030200FA  //  What address does the program start at (0x0200)

[GARTHWILSON]

This page http://srecord.sourceforge.net/ is about S-record software. I mentioned it in my Large Look-up Tables for Hyperfast, Accurate, 16-Bit Fixed-Point/Scaled-Integer Math page of my website. The software lets you test and transform EPROM file types, concatenate, split, etc.. Version 1.52 is in the Ubuntu (Linux) software center for one-click download and installation. Enter "EPROM" for a search term and it comes right up. SRecord is command-line-only, which initially made it confusing because I didn't see any new icons and couldn't find it under "Applications". The voluminous .pdf manual could stand to have better command-line examples, but you'll figure it out. Much of the manual is spent on telling about multitudes of file types you will never use, so there's not really that much that you really have to read.

In your signature line,

Code: Select all

:01030000A20AF4
:0103020000CA32
:01030300D0FD2F
:01030500006049
:00000001FF

what it says is, starting from address 0300, A2 0A 00 CA D0 FD 00 60, with the underlined 00's being unwanted extras. The 01 at the beginning of each line means there's one byte of data, when you actually have two; so an error condition would probably be flagged. I didn't check the checksum bytes. To make it say A2 0A CA D0 FD 60 starting at address 0300 with such short lines, you need:

Code: Select all

:02030000A20A4F
:02030200CAD05F
:02030400FD609A
:00000001FF

It's easy to make a mistake when doing it by hand. Hopefully I got it all correct. The description of Intel Hex is on my website at http://wilsonminesco.com/16bitMathTables/IntelHex.html .

A2 0A CA D0 FD 60 would translate to:

Code: Select all

        LDX  #$0A
        DEX
        BNE  label

or, with the structure macros ,

Code: Select all

        FOR_X   10, DOWN_TO, 0
        NEXT_X

an empty FOR...NEXT loop.

Intel Hex lines are normally made to be quite a bit longer, typically holding 16 or 32 data bytes, although the lines of a file don't have to be all the same length. Putting this all on one line would be:

Code: Select all

:06030000A20ACAD0FD6054
:00000001FF

[barrym95838]

A quick question, Garth.

From my BASIC experience, I would read your FOR_X ... NEXT_X empty loop to mean 11 iterations, when the original is only 10!

Maybe that's why I would avoid structure macros in my (admittedly simple) hobby projects ... they shorten the source, but don't aid my understanding of what is really going on. Given the choice, I would comment the structure in, and leave the raw instructions alone. Am I missing something?

Mike

[GARTHWILSON]

The DOWN_TO, 0 tells NEX_X to assemble the DEX, BNE; so the last time DEX is executed, X becomes 0 so the program counter drops through and does not branch back up to execute the loop for X=0. You always have control of the macros to modify as you wish though, so you can make them however you like.

FOR_X 8 DOWN_TO, 0 ... NEXT_X will give the same thing you would do with LDX #8, ... DEX, BNE top_of_loop, which will execute the loop for 8, 7, 6, 5, 4, 3, 2, and 1, but not 0, making it just the ticket when you want to execute something 8 times.

There are so many ways FOR_X...NEXT_X and FOR_Y...NEXT_Y could be used, which made me initially think they would not be feasible to do, and I did not initially tackle them for my structure-macros page. Later I got to thinking about it more and decided on a method. The ton of options makes those particular macros quite large for the little they assemble; but in the end you'll get the same machine code you would have gotten without them, just more clear and without the labels. The structure macros become more valuable in cases where you would otherwise have a spaghetti mess of branches going everywhere in a piece of code even a couple of pages long. I previously used to print those out on fanfold paper for checking, stretch the paper out on the livingroom floor, and use a pencil to draw a bazillion arrows showing where all the branches go, and it still left my head spinning. I don't need to do that anymore.

[BigEd]

Which record types you need depends on your loader, or generally on what you want to do with your srecord file. The S10 records are sufficient to load code.
Here are some example srec_cat conversions on the linux command line:

Code: Select all

$ echo A2 0A CA D0 FD 60 | xxd -p -r - | srec_cat - -binary -offset 0x0300 -o - -intel -esa 0x0300
:020000040000FA
:06030000A20ACAD0FD6054
:0400000500000300F4
:00000001FF

Code: Select all

$ echo A2 0A CA D0 FD 60 | xxd -p -r - | srec_cat - -binary -offset 0x0300 -o - -esa 0x0300
S0220000687474703A2F2F737265636F72642E736F75726365666F7267652E6E65742F1D
S1090300A20ACAD0FD6050
S5030001FB
S9030300F9

I've included the '-esa' which adds an execution start address: if your loader understands those records then it will jump to that address after loading. I imagine it's normal to jump to the first address written: certainly my trivial loader does that. But then my trivial loader only accepts S10 records.

I'm not entirely convinced that the intel code given in the .sig is correct - it's certainly unconventional. According to srec_cat it has bad checksums. All the lines claim to give just one byte but it looks like your intention was to have a mix of 1-byte and 2-byte records. I suppose it was encoded by hand?

Cheers
Ed

[James_Parsons]

Sorry the checksums were hard for me a hate math and really couldn't understand 2's compliment

[BigDumbDinosaur]

James_Parsons wrote:

could someone translate this into Motorola hex for me. I have done some research...

Try http://en.wikipedia.org/wiki/S-record