Building assembler directives for 24-bit S/N value

[metertech58761]

After getting a flash of insight that helped me figure out some 6800-class code I'd dumped, I have been inspired to turn my attention back to some related code I began analyzing but gave up after not understanding how part of it was structured.

Thing is, this particular code also includes a serial number that needs to be compiled into the EPROM. Its range is just wide enough to require 17 bits (so 3 bytes / 24 bits).

Instead of manually calculating the three byte values and plugging them into the source code, I want to define the S/N in the declarations portion of the source code (as there are other options that need to be set as well).

Then, in the actual source code, I would have two statements - one to define the value of the 17th bit, and one to define the value of the lower 16 bits.

How would I go about writing out the calculations? Let's use two different examples I have at hand... one would have S/N 4257, and another would have S/N 80891.

[metertech58761]

I misspoke. The actual address ranges are 101-7999 and 808000-811000 (I was a whole magnitude off - 17 bits? no, 20 bits!).

THRSim11 doesn't even like to SEE numbers higher than 65535, so that ends that. I'll use a different approach.

[Analog Kid]

Can't you just do this with 3 byte-definition statements? Split the 17-bit number up, figure out the 3 hex values and plug them in. That should work with any assembler.

Unless I'm missing something here ...

[ledtester]

THRSim11 doesn't even like to SEE numbers higher than 65535, so that ends that. I'll use a different approach.

Note that on this page:

http://www.hc11.demon.nl/thrsim11/infoass.htm

it says:

Arithmetic is carried out in signed twos-complement integer precision (32 bits).

I downloaded the simulator and played around with it. Even though symbols have to fit into 16 bits, expressions in EQU statements are calculated using 32-bits. So I tried this:

Code: [Select]

SN0     EQU     123
SN1     EQU     80

SNA     EQU     (SN1*1000+SN0)\256
SNB     EQU     ((SN1*1000+SN0)/256)\256
SNC     EQU     ((SN1*1000+SN0)/256)/256\256

        ORG     $A000
        FCB     SNA,SNB,SNC

Here SN0 contains the least significant decimal digits and SN1 contains the next three decimal digits -- i.e. the serial number is SN0+1000*SN1.

SNA, SNB and SBC are the three bytes in the binary representation of the serial number.

[metertech58761]

AnalogKid: That's how I currently have it defined - three FCB statements, one for each byte, but those statements are literally at the end of the source, just before the vector tables.

I have a section preceding the address declarations with some other options that need to be set before hitting the start button.
I thought it would be nice if I could have a space to put the S/N in that section, then down where the actual address bytes are to be written, I could just insert the formulae for the serial number. I could even have it do an FCB statement for the upper four bits then an FDB statement for the lower 16 bits...

I'm currently working on harmonizing two different versions of the source dump, then I'll post the dump.

[metertech58761]

For better or worse, here's the dump as it stands.

[Kalvin]

One option would be to use an external program (a simple Python script for example) to read the S/N and produce valid assembly definitions into a file. Then just include this generated file into your assembly source file.

[metertech58761]

That is an option, yes, but, truthfully, other than picking the code apart to figure it out, I actually don't have a need to compile the code on a regular basis.

I merely wondered if there was a more elegant solution than what I ended up doing:

Code: [Select]

; ---------- Configuration variables - ensure these are correct before compile!

; EPROM contains unit address so it must be defined before compiling
; Convert the address into hexadecimal and insert the bytes here:

digitH       EQU   $0C
digitM       EQU   $57
digitL       EQU   $57

<snip>

; Serial number - values are entered in configuration section at top

romSnH       FCB   digitH
romSnM       FCB   digitM
romSnL       FCB   digitL


[ledtester]

It seems that the serial number bytes are always located at the same addresses: $FFED-$FFEF (at least according to 45A source.)

If that's always true you can assemble the code just once and patch/edit/append to the S19 file with a line like:

S105FFEDhhmmll

to set the serial number.

Here hh, mm, and ll are the S/N bytes.

[Analog Kid]

How would I go about writing out the calculations? Let's use two different examples I have at hand... one would have S/N 4257, and another would have S/N 80891.

OK, let's take the latter example.
When you say

THRSim11 doesn't even like to SEE numbers higher than 65535

does that mean it can't handle something like

Code: [Select]

SerialNum       EQU 80891
meaning that it can only do 16-bit arithmetic even when processing symbolic constants?

[ledtester]

You can't EQU something that's more than 16 bits. But intermediate calculations are carried out to 32-bits.

So while you can't set:

SerialNum   EQU 80891

you can do:

SN0    EQU 891
SN1    EQU 80

SNlow EQU (SN0+SN1*1000)\256
SNmid EQU (SN0+SN1*1000)/256\256
SNhi  EQU (SN0+SN1*1000)/256/256

and this computes the hi, mid and lo bytes for 80891.

[Analog Kid]

You can't EQU something that's more than 16 bits. But intermediate calculations are carried out to 32-bits.

That's weird.

So while you can't set:

SerialNum   EQU 80891

you can do:

SN0    EQU 891
SN1    EQU 80

SNlow EQU (SN0+SN1*1000)\256
SNmid EQU (SN0+SN1*1000)/256\256
SNhi  EQU (SN0+SN1*1000)/256/256

and this computes the hi, mid and lo bytes for 80891.

That's what you showed before, which I think is pretty much the OP's answer here.

[metertech58761]

AK: Yeah, that was a bit of a surprise to see the compiler choke on large numbers like that.

ledtester: Hmm. I'll file that idea for future reference. Thanks! Of the various code dumps I have at hand, this one (36D) is the ONLY one with the S/N burned in ROM.

The -45A is for 1-way receivers, the "serial number" being set by a removable comb that can have its teeth cut away to program 2 levels of addresses (Gold 1-4, Silver 1-60)
The -36D is for 2-way receivers, with the unique address in ROM. I suspect it CAN have two lower level addresses (bronze 1-256 and lead 1-4096) programmed into NVRAM through commands.
Figuring out the command interpreter in 45A may well be the Rosetta stone I needed for 36D, but before I do that, I need to extract some sample messages out of a third code dump I have at hand.

[westfw]

What assembler are you using?

[metertech58761]

THRSim11 - most of the code I have at hand is for 6801-style or HC11-style MPUs, so it fits the bill.

I do need to find a compiler that handles 6809 code (I think I have A09, but I haven't set that up yet).

[DiTBho]

Gcc / binutils, experimental for 6809

[ledtester]

THRSim11 comes with the GNU 68HC11 assembler:

http://www.hc11.demon.nl/thrsim11/thrsim11.htm

Invoke it by the File menu -> New GNU cc or as source.

The syntax is different but GNU as supports 32-bit ints for symbols.

Example code:

Code: [Select]

.global main
.text
.equ serno,12345678
main:
ldd #0
rts
.byte serno%256,(serno>8)%256,(serno>16)%256

Use Tools -> Compile to invoke the assembler.

To generate a listing, edit the definition of AS_OPTIONS in the makefile:

AS_OPTIONS  = -al=listing.txt

The listing will appear in the file listing.txt

[westfw]

>> What assembler are you using?
THRSim11

GNU as supports 32-bit ints for symbols.

I was going to check whether the assembler might have other features (like macros) that could be coerced into handling your large numbers, but it looks like the THRSim11 assembler is a pretty bare-bones one, aimed at just supporting the simulator.

Since the simulator is also compatible with the Gnu Assembler, and there IS a 6811 Gnu Assembler, I think your best course of action would be to use that...

[metertech58761]

Perhaps it may help if I rewind to the beginning and explain what I'm after -

I have dumps or binary files for various EPROMs relating to some equipment for which I've been accumulating information.
I wanted to generate assembly code dumps for these files, and f9dasm has been my go-to for the files based on the 6801 / HC11 / 6809 MPUs.
(I have a few HC05-C9A files and I eventually found a tool for those, but its name escapes me at the moment)
I've been taking those raw dumps and gradually translating them into proper source code as I begin to understand what each of section of code does.
The assembler helps me validate that the source code is capable of generating object files identical to the original dumps / programming files.