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:


sorry I might be spamming again

_________________
JMP $FFD2

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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I just can figure out what the S-records are

_________________
JMP $FFD2

Untested

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:

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

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

        LDX  #$0A
        DEX
        BNE  label

or, with the structure macros ,

Code:

        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:

:06030000A20ACAD0FD6054
:00000001FF

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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:



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

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

_________________
JMP $FFD2

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!