Building assembler directives for 24-bit S/N value - Page 1
Forum section: electronics / general

author: metertech58761
author_rank: Frequent Contributor
timestamp: July 25, 2025, 12:32:55 pm
content: 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.

author: metertech58761
author_rank: Frequent Contributor
timestamp: July 26, 2025, 11:54:41 pm
content: 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.

author: Analog Kid
author_rank: Super Contributor
timestamp: July 27, 2025, 01:31:31 am
content: 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 ...

author: ledtester
author_rank: Super Contributor
timestamp: July 27, 2025, 02:39:39 am
content: Quote from: metertech58761 on July 26, 2025, 11:54:41 pmNote that on this page:http://www.hc11.demon.nl/thrsim11/infoass.htmit says:QuoteI 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:SN0 EQU 123SN1 EQU 80SNA EQU (SN1*1000+SN0)\256SNB EQU ((SN1*1000+SN0)/256)\256SNC EQU ((SN1*1000+SN0)/256)/256\256ORG $A000FCB SNA,SNB,SNCHere 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.

author: metertech58761
author_rank: Frequent Contributor
timestamp: July 27, 2025, 02:32:54 pm
content: 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.

author: metertech58761
author_rank: Frequent Contributor
timestamp: July 27, 2025, 06:13:32 pm
content: For better or worse, here's the dump as it stands.

author: Kalvin
author_rank: Super Contributor
timestamp: July 27, 2025, 06:42:13 pm
content: 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.

author: metertech58761
author_rank: Frequent Contributor
timestamp: July 28, 2025, 11:18:48 pm
content: 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:; ---------- 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 $0CdigitM EQU $57digitL EQU $57<snip>; Serial number - values are entered in configuration section at topromSnH FCB digitHromSnM FCB digitMromSnL FCB digitL

author: ledtester
author_rank: Super Contributor
timestamp: July 29, 2025, 12:55:23 am
content: 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:S105FFEDhhmmllto set the serial number.Herehh,mm, andllare the S/N bytes.

author: Analog Kid
author_rank: Super Contributor
timestamp: July 29, 2025, 02:08:02 am
content: Quote from: metertech58761 on July 25, 2025, 12:32:55 pmOK, let's take the latter example.When you sayQuote from: metertech58761 on July 26, 2025, 11:54:41 pmdoes that mean it can't handle something likeCode:SerialNum EQU 80891meaning that it can only do 16-bit arithmetic even when processing symbolic constants?

author: ledtester
author_rank: Super Contributor
timestamp: July 29, 2025, 02:22:02 am
content: 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 80891you can do:SN0 EQU 891SN1 EQU 80SNlow EQU (SN0+SN1*1000)\256SNmid EQU (SN0+SN1*1000)/256\256SNhi EQU (SN0+SN1*1000)/256/256and this computes the hi, mid and lo bytes for 80891.

author: Analog Kid
author_rank: Super Contributor
timestamp: July 29, 2025, 02:38:53 am
content: Quote from: ledtester on July 29, 2025, 02:22:02 amThat's weird.QuoteThat's what you showed before, which I think is pretty much the OP's answer here.

author: metertech58761
author_rank: Frequent Contributor
timestamp: July 29, 2025, 04:26:06 am
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: July 29, 2025, 09:46:09 am
content: What assembler are you using?

author: metertech58761
author_rank: Frequent Contributor
timestamp: July 29, 2025, 11:30:08 am
content: 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).

author: DiTBho
author_rank: Super Contributor
timestamp: July 29, 2025, 02:01:35 pm
content: Gcc / binutils, experimental for 6809

author: ledtester
author_rank: Super Contributor
timestamp: July 29, 2025, 04:57:05 pm
content: THRSim11 comes with the GNU 68HC11 assembler:http://www.hc11.demon.nl/thrsim11/thrsim11.htmInvoke 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:.globalmain.text.equ serno,12345678main:ldd#0rts.byte serno%256,(serno>8)%256,(serno>16)%256Use Tools -> Compile to invoke the assembler.To generate a listing, edit the definition of AS_OPTIONS in the makefile:AS_OPTIONS = -al=listing.txtThe listing will appear in the file listing.txt

author: westfw
author_rank: Super Contributor
timestamp: July 30, 2025, 02:58:39 am
content: QuoteQuoteI 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...

author: metertech58761
author_rank: Frequent Contributor
timestamp: August 07, 2025, 06:07:10 am
content: 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.