EASy68K  
It is currently Tue Dec 10, 2019 1:02 am

All times are UTC




Post new topic Reply to topic  [ 12 posts ] 
Author Message
PostPosted: Thu Mar 16, 2006 8:26 pm 
Offline

Joined: Thu Feb 23, 2006 3:25 pm
Posts: 6
Location: Connecticut
One of the assembler options of the Easy68k is to Generate Binary File.

The DataIO programmer I'm using accepts three different Binary Files: Formatted Binary, Dec Binary, Absolute Binary. Not sure how they differ.

Which one does the Easy68k generate?

Appreciate any info.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 17, 2006 4:48 am 
Offline
User avatar

Joined: Thu Dec 16, 2004 6:42 pm
Posts: 1109
I'd say the best match would be Absolute Binary. You might also be able to find a conversion program that would convert the EASy68K S-Record file into one of the supported binary formats.

_________________
Prof. Kelly


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 11, 2008 12:01 am 
Offline

Joined: Mon Nov 10, 2008 11:22 pm
Posts: 7
Location: Drummondville, Quebec
Hello Sir!

I had a question about binary generation and prior to ask it I read through your forum to see if someone else already asked and this one was the closest one.

Here is the thing. I was assuming that we choe "Generate Binary File" it would generate a binary file of data that can be stored "as is" into an EPROM and have the 68K boot from it. But visibly it cannot be the case...

The .S68 file is a valid Motorola S19 file and it is perfect. But the .BIN file created on-the-side of it is not the direct true-binary file of the result. If you look at it, you'll see that no matter what is the first line you wrote, it start with 00 01 00 00. After that, also, there is other data that change a little depending of the code. I tried to figure it but was unable to.

Let's see an example. Suppose the program is the most simple one:
START move.b #$00,d0
END START

The S19 file will have the simpliest line for a 68K program which is:
S1 07 0000 103C00 00AC

The only "binary" thing that should be in the binary output should be 103C00 which is the code for my "move.b #0,d0". BUT if we look at what EASy68K is generating for the binary file in such case it is:
00 01 00 00 00 01 00 00 00 00 00 00 00 00 28 00
00 00 00 00 00 00 00 00 00 00 00 04 10 3C 00 00

It gives these 32 bytes...

I think it's an error... Or if not, it should be called something else than "Generate Binary File" since it must implement some other custom things... But since you generate correctly the S19 file, I guess the .BIN should be generating using the same "pure" data.

If you ever consider fix that, I also suggest your to have an option to let the user select the data to use to "fill" empty holes. Because if program somewhere has a new ORG, the resulting binary file will need to have the holes filled with something. Generally I place 0xFF so it's programmed faster.

For the last 15 years I am using a good assembler for the 68K but recently I need to use the "Program Counter Indirect with Displacement Mode" address mode in a situation where my code needed to be fully relocalisable everywhere in memory including the variable and stack. Because of that, the previous person wrote the routine using opcode like " lea.l (VariableName-RAMStart,PC),a0". My old assembler I've used for fifteen years fail to code that. I tried yours and PERFECT! Not only it code it correctly but my code was fine too. So for the moment I am using your tool but it's annoying to keep having to manually convert your S19 file into a true binary file each time. Sometimes I forget this step and reupload the same old bin file and don't see my modif I just made in the .ASM and I am losing time with that...

Or maybe is there a way I could call your assembler to assemble the code directly from a command-line? I could write a batch file then to automtically process the assemble and then the conversion to binary?

Something like "EDIT68K.exe /a MyProgram.ASM >MyProgram.S19" or something like that?

Thanks.

No matter what, it's a great work! I am not using really the simulator but if I am not sure of I routine, I feel it would be a really nice thing to quickly code a minimal routine and run it into your emulator to test it... So even if you don't fix/modify what I wrote and eventually use a new assembler, I will not put aside too far your tool for it's simplicity of use.

Thanks again!

_________________
Denis Bisson
explorerworker-68k@yahoo.com


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 11, 2008 4:50 am 
Offline

Joined: Mon Dec 27, 2004 11:40 pm
Posts: 318
explorerchess wrote:
But the .BIN file created on-the-side of it is not the direct true-binary file of the result. If you look at it, you'll see that no matter what is the first line you wrote, it start with 00 01 00 00. After that, also, there is other data that change a little depending of the code. I tried to figure it but was unable to.

You need to remove the first 28 bytes from the generated .BIN file, what is left can be used in an EPROM to boot from.

Lee.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 11, 2008 2:26 pm 
Offline
User avatar

Joined: Thu Dec 16, 2004 6:42 pm
Posts: 1109
The binary output file adds a 28 byte header to make it compatible with the Teeside assembler. It would be a simple matter to remove the extra bytes. I don't think keeping Teeside compatibility is important. Any opinions?

_________________
Prof. Kelly


Top
 Profile  
 
 Post subject: Well...
PostPosted: Tue Nov 11, 2008 3:02 pm 
Offline

Joined: Mon Nov 10, 2008 11:22 pm
Posts: 7
Location: Drummondville, Quebec
Hello Sir!

Well... Two things...

First, I have to zap the file each time, it does not help really. I mean, it does not solve the annoying thing, I would still have to manually do something after the compilation (or assemble).

Second, it's only a partial solution. It does not fill the holes for situation like this:
...
org $100
dc.l $12345678
org $200
dc.l $12345678
org $300
dc.l $12345678
...

The binary resulting file for this is not a binary image of the normal expected output. It create in the file something like this:
...
12 34 56 78 00 00 02 00 00 00 00 04 12 34 56 78 00 00 03 00 00 00 etc...

I admit that THIS example is simply to make it simple to explain. In my case, the situation of having "hole" is because the whole thing fit in a 32K relocalisable in RAM memory. It start with the code, then with the variable at the middle and the stack at the end going downward. Between the end of the program and the start of the variable, there is empty room. I cannot include "dc.l xxxxx" to fill these hole each time. I am assembling and retrying hundred of times per session, the code grow and decrease each time, the empty hole would be different each time, etc... And I do not want to refrence my variable by constant. Firs tbecause the whole thing is already done and second because it's very nice to have things like "lea.l (MyVariable-RAMStart,PC),a0". It makes the whole thing that could move eveywhere easily.

So, if it's not possible that fine... I've my own S3 to BIN convert and there dozens on the web two. The things is that it is annoying to have to do something AFTER I've assemble it. Sometimes I forget it and keep retry the same thing. If I could at least call the assembler via a batchfile, it would solve the thing also you know...

Dennis.

_________________
Denis Bisson
explorerworker-68k@yahoo.com


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 11, 2008 3:22 pm 
Offline

Joined: Mon Dec 27, 2004 11:40 pm
Posts: 318
Quote:
Between the end of the program and the start of the variable, there is empty room. I cannot include "dc.l xxxxx" to fill these hole each time. I am assembling and retrying hundred of times per session, the code grow and decrease each time, the empty hole would be different each time, etc...

Then let the assembler fill the holes for you, first define the limit of the ROM in your system.

Code:

end_of_rom  EQU   $8000       * the address is the next byte after the ROM end,
                              * the last ROM address is $7FFF. set as needed

Then, at the end of your code, get the assembler to work out how much space is left and fill it with $FF (or whatever byte an erased device is filled with).

Code:
      * end of code
end_of_code
      dcb.b       end_of_rom-end_of_code,$FF


You should be doing this anyway as filling the unused space with $FF saves wear and tear on your EPROM/flash ROM/whatever.

Lee.


Top
 Profile  
 
 Post subject: Almost...
PostPosted: Tue Nov 11, 2008 5:22 pm 
Offline

Joined: Mon Nov 10, 2008 11:22 pm
Posts: 7
Location: Drummondville, Quebec
Good. It almost make the tool usable "as is".

One thing I did not realise looking at your example and realize when I tried it is the fact that the "dcb.b" directive does support forward reference. I tried to write something like " dcb.b VarArea-EndOfCode" but it did not work. Certainly I can write somewhere earlier something like "ConstantVarAre = $7000" but I did not like that because it means in two years I might change the ORG of the variable but forget to change the constant defined earlier... After time, you "forget" these things tricky to make a tool work...

BUT, your assembler is nice and turnaround is elegant. I can write "VarArea = $7000" and later in the code write "Org VarArea"! Ha! Ha! That's good.


BUT UNFORTUNATELY, what about the infamous first byte in the resulting output bin file... They are not remove...

Between you and I, the suggestion you made is nice and I am happy to learn somethign new but it does not correct the fact that the conversion made from the S3 to bin is not really standard. We've seen many format and needed to convert many time but never we got the kind of binary that your tool is outputing. With humility, I am not complaining but commenting, you should have a big huge warnign next to the bin output option mentionning that it could create a true-bin output if:
-there is no holes and you mange to write the dcb.b stuff to fill the holes
-is aware that some anoying 28 bytes are present at the beginning... I would be very curious to see how this bin file could be helpful.

Normal S3 to bin converter does not do that. Many have limitations and will say something like "cannot create file bigger than 16M" for example, that's normal.

It's really annoying because I would buy this product. I'm really excited to discover such a tool after 16 years working with the 68K. The similation thing is something very nice and I cannot wait to have a problem to solve that I could simulate with that and to isolate a small routine to test. With our boards, with breakpoints, it works but it's a little a pain in the ass, it modify the code, etc... But with your tool, I'll be able to copy and paste one section run it and view the evotion of registers inside loops, etc...

I am just sorry I cannot call it in a make file or batch file (so a true S3 converter would follow) OR that it does not generate a normal binary file...

:oops:

_________________
Denis Bisson
explorerworker-68k@yahoo.com


Top
 Profile  
 
PostPosted: Tue Nov 11, 2008 6:20 pm 
Offline

Joined: Mon Nov 10, 2008 11:22 pm
Posts: 7
Location: Drummondville, Quebec
profkelly wrote:
The binary output file adds a 28 byte header to make it compatible with the Teeside assembler. It would be a simple matter to remove the extra bytes. I don't think keeping Teeside compatibility is important. Any opinions?


Hello Sirs

I am sorry. I haven't see that post earlier. I've never heard or seen that assembler. Well... If it has to be there to accomodate someone somwhere, I don't want you to change just for me...

Finally, I now have access to the source of the program that upload my firmware so I will simply modify it to seek at offset 0x1C in it and I'll be fine.

But if you modify it to create a true binary image, and also be able to fill the holes, I won't hate that. Ha! Ha! ;-)

_________________
Denis Bisson
explorerworker-68k@yahoo.com


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 11, 2008 6:45 pm 
Offline

Joined: Mon Dec 27, 2004 11:40 pm
Posts: 318
Quote:
I don't think keeping Teeside compatibility is important. Any opinions?

I see no need either. While I don't have any problem using the output .bin files as they are, my programmer software can be set to skip the header, raw binary output, padded as needed by a user defined byte, would also be usefull.

Lee.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 11, 2008 6:53 pm 
Offline

Joined: Mon Dec 27, 2004 11:40 pm
Posts: 318
Quote:
Certainly I can write somewhere earlier something like "ConstantVarAre = $7000" but I did not like that because it means in two years I might change the ORG of the variable but forget to change the constant defined earlier... After time, you "forget" these things tricky to make a tool work...

That's what comments can be used for, to remind you of why you wrote what you wrote.

Quote:
It's really annoying because I would buy this product.

I would say EASy68K is easily worth twice what Professor Kelly charges for it, if not more. 8^)=

Lee.


Top
 Profile  
 
 Post subject: Good thing
PostPosted: Tue Nov 11, 2008 8:15 pm 
Offline

Joined: Mon Nov 10, 2008 11:22 pm
Posts: 7
Location: Drummondville, Quebec
lee wrote:
I would say EASy68K is easily worth twice what Professor Kelly charges for it, if not more. 8^)=Lee.


You are right sir. It's very nice.

Concerning what you wrote about the fact that with your programmer it's easy to remove the first 28 bytes it might be. Certainly. But in a context of development, learning, etc... having to keep do that, to DON'T FORGET to do it prior to upload, when you do it dozen and dozen if times, it's normal to try to avoid that and find a solution.

Conccerning the "comment" about the "comment", you are right if you meant that including comment is essential, especially in assembly, beleive me. BUT, when you have to define TWO things that means the same thing to make something works, even if you comment it, I feel it's also normal to find a better way to do things. The fact that the compiler let me type something like " ORG VariableAreaStart" having an equate earlier of "VariableAreaStart Equ $7000" is a very nice and I like that. If I change my equate, ONE thing, it will change the calculation for the empty space to fill with 0xFF as the trick you gave me, AND it will also effectively change my block of variable location.

One alreay said that "Comment are not useful, code should talk by itself". I always though that it was a big joke. But at some point, when I am looking at my colleague sometimes, I feel they should spend a little more time to optimize the number of lines that means the same thing even if they have tons of comment. Ha! Ha!

This aftertoon I modified the tool who sent the firmware generated by Easy68K so it seek ot position 28th in the binary output file of Easy68K and I am now almost able to work as good as before. I am doing F9 to compile, ATL-TAB to the uploader, F9 to upload, and I'm ready to try. No third-middle-task that was not present before. Thanks for the trick of the dcb.b. I still beleive the "normal" solution would have been to generate a true binary image when doing the conversion but I appreciate that your idea make me abl to use EASy68K.

Bye.

_________________
Denis Bisson
explorerworker-68k@yahoo.com


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group