Not sure where to place this question but this seems as good a place as any...

So,.. how Can I add a version number that auto increments each time I run the assembler.

I am using the tass64 assembler, and I was hoping to be able to add a number that increments each time I run the assembler to create a binary file, and automatically add the newly incremented number into the binary at a defined place..

I guess the number has to have a range to 0-9999,.. thinking outside the box and further what about stamping the code with date and time,.. or is that a stretch too far,...

Has anyone else played with this concept with the TASS assembler.

Many thanks for any feedback
kind regards

Don't know tass64, but other assemblers. I would create a batch/script file as a frontend to the assembler. The batch would then echo a .db "Version" into a file called version.inc and execute the assembler afterwards. The assembler source in turn must have an .include version.inc.

The "Version" string can then be an increment to the existing version.inc or even better a string with the file date and time of the assembler source.

note: .db = .text = .byte - whatever tass64 takes as a string directive

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Actually, what most folks do is not increment for every compile, but rather increment for every "release", for whatever reading of "release" you want. In practice this tends to be facilitated by the Version Control system.

In many VC systems, you can place special tokens in your code. Then, when the code is checked out, the VC system replaces that token with version information (and you can do what you like with that number, notably stick it in a string or whatever).

So, mechanically, what happens is that your code version is incremented every time the code is changed and actually checked in to the VC system. Since the VC version of the code is the "source of truth", this tends to work well in practice. When someone has an issue with their code, you can have them report the version information, and (ideally) pull out that exact source code (and build instructions, etc.) from your VC and try to duplicate the problem.

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

Don't know about other assemblers, but HXA has a time$() function that returns the system date and time as a string (which can then be chopped up as desired). It's basically just a wrapper for the TAWK ctime() function (which in turn is probably just a wrapper for the 'C' standard library's ctime() function).

But notice that in essence what happens is that a value is being retrieved that is (a) stored outside the assembler itself and (b) is maintained by "something" outside the assembler as well. Those mechanisms already exist, and accessing them is trivial.

An "assembly number" that increases with each run is like time and date in that it has to be stored and maintained outside the assembler itself. BDD does it with hand-coded macros in the source code, for instance. In any case it's something you'll have to implement yourself. The idea of doing with a batch file or other script language that writes (or reads, slightly alters and then re-writes) an "include" file and then executes the assembler seems a reasonable alternative approach.

Even if an assembler was capable of incrementing a run number by itself, there still would have to be some kind of external persistent storage to let the assembler know what the next value should be. And you'd probably want it to increment each different source file with its own sequence, so if you assembled file "a" and then file "b" and then file "a" again, "a"'s run number would go up by only two instead of three. So there would have to be a way of associating file names and run numbers.

I suppose there could exist something like a getrun$() function that looked for a particular file name (most likely the file name that contains the getrun$() call with a different extension), read it, returned the value and then re-wrote the file with an incremented value. If the file didn't exist, return 1 and write the file with a value of 2. In the source code it would look something like:



and one of BDD's macros would look like:



That expression just concatenates the run number onto a string of "0" characters and then chops off everything but the last two characters, so runs 1-9 come out "01" to "09". Unless they were written that way in the first place, but is a fixed format the best approach?

I dunno. I can see its use, but it's sort of a specialized thing.

I was going to suggest the idea of using a date function (though I didn't know of any assemblers that happened to have one), but the problem with something like that possibly becomes that there is no way to determine that the source you are working with is the source code in the ROM. You could compare the assembler listing (which would have the correct information), but, not the source itself. This sort of defeats the purpose I think.

Version Control is so cheap and ubiquitous, that I think it would be better to simply commit every build to a branch and use the VC mechanism. When you're done with a chunk of work, you can merge the branch work up in to the main development branch. Have to play with the workflow though.

The 2500AD 6502/65c02 assembler I used in the late 80's and early 90's does have it. I just looked at the manual for C32 which I now use and it does not seem to have that kind of thing. I think I would just increment the version manually in the source code.

_________________
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?

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

Thanks for the feedback guys,.. just catching up with the final comments posted.
Clearly TASS64 does not do these things, as I suspected,.. but I think I will explore the options of doing some external scripts and doing and import of some description.

Many thanks to all
Mark

64tass has the -D command line option to assign a value to a label name. I spend a little time today playing with Windows 7 batch files. I have developed a way to provide the incremented number as label value. You could place that value in the object file as you see fit. It works with two batch files. One simply contains a "SET vers=1" command. This is used to initialize and keep the count. The other batch file calls the first, increments the count, erases and replaces th first with the new count. It then calls the 64tass assember with the -D command line parameter. You will need to modify that line to suite your particular 64tass needs.

1.bat looks like this:

The %1 at the end of call 64tass... line could contain the source file. i.e.,
"1.bat mycode.asm" would call 64tass to assemble mycode.asm Alternatively, you can just hard code the command line as you need (my preferred method).

2.bat looks like this initially:


This will probably work with older windows too, but you will have to experiment. Try it by placing the two batch files in an empty folder and clicking on the 1.bat file 3 or 4 times. Then edit the 2.bat file. It should have the incremented count if all works correctly.

I have attached the files too. Be sure to rename to 1.bat and 2.bat (drop the .txt)

Enjoy!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

I use the assembler built into BBC BASIC, so my code starts along the lines of:
ver$="1.00 ("+MID$(TIME$,5,11)+")"

which then later goes in as:
EQUS "name":EQUB 0
EQUS ver$:EQUB 0
etc.

_________________
--
JGH - http://mdfs.net

As way of completeness,.. I will add my final entry to this post,....

Bottom line success!!!,.. with thanks to all for their input.

I eventually adapted the above scripts from "8Bit" to end up with a compile script that looks as follows:-

echo %time%
call 2.bat
del 2.bat
del vers.inc
set /A vers += 1
echo set Vers=%vers% > 2.bat
echo vers .word %vers% > vers.inc
@ECHO OFF
FOR /F "tokens=*" %%A IN ('TIME/T') DO SET Now=%%A
ECHO It's %Now% now
echo TM %now% > tim_date.txt
@ECHO OFF
FOR /F "tokens=*" %%A IN ('DATE/T') DO FOR %%B IN (%%~A) DO SET Today=%%B
ECHO It's %Today% today
echo DT %today% >> tim_date.txt

64tass light.asm -L lights.lst -o a-lights.obj -b -l labels.txt
echo %time%

and a file Vers.inc which looks as follows;-
vers .word 3893

This uses 64tass directives to include a number with a range up to 65000, ( so should keep me going on versions for a while

and 2.bat which looks as follows:-
vers .word 3893

So for a simple explanation,.. c.bat runs calls some other batch files which create a new vers.inc file, this is then included in the compiled files as well as one called tim_date.txt which contains the current date and time..
So with some nimble settings in memory of where things load,.. I now have a new compile versions as well as the date and time the compile was run included into the binary object code....

many thanks once again

Regards