GB3US Mk2 EPROM change callsign,

GB3US Mk2 EPROM change callsign,

I recently helped the repeater keeper of GB3TC (Three Counties) configure his GB3US EPROM firmware (originally written by G3RKL) with the correct callsign.
The firmware is used to send the CW ident after a certain duration. It has two idents (referred to as “bcs” – beacon callsign) one long and one short.

The default firmware has (as previously mentioned) two bcs. What the information does not make clear is that both of them are the same string, with the short bcs being the first part of the long bcs:
“DE GB3US SHEFFIELD” is the long bcs
“DE GB3US” is the short bcs (the first part of the long bcs)
The length of the long bcs gets stored, as does the length of the short bcs.

The issue I needed to resolve was that the two bcs messages needed to be completely different. This was not a trivial task and in doing so I had to give myself a crash course in 1802 assembly language which was quite interesting – the 1802 CPU has a strange but very economical way of handling memory reads and writes.

To get to the meat of the solution I will first provide the information given in the RADCOM November 1983 magazine, and reproduced in the QEX June 1984 magazine:

Te program is written in 1802 machine code, as shown in the listing . By copying this exactly, with the appropriate changes to the message store and length parameters, an eprom can be “blown” for a unit to work to the above specifications. The bcs message stored (start address 666h) as a series of 2-bit characters (dibits):
00 interletter gap
01 interword gap
10 a dot
11 a dash
The dot and dash characters automatically containing the one dot space.
Thus the sequence “DE” will be coded as:
interword gap, dash, dot, dot, dot, interletter gap, dot
which equals 01 11 10 10 10 00 10.
At this point count the number of dibits, in this case 7. This is our bcs length.
The message length parameters, as a (two bit) character count are located as follows:
short bcs (and all other callsigns) at 0120h, 019Eh and 0449h
long bcs at 0128h
The talkthrough timer is set at:
high byte 03E1h
low byte 03E4h
as the number of 9.14285ms interrupts required, eg 4 min = 26,250 (668Ah).
Location 04A should be 01 for a logical squelch (1 for carrier) or 00 for a relay squelch (0 for carrier).

To try and clarify this somewhat (which is doubtless why you are here):
You can have 2 beacon messages: a short bcs and a long bcs.
They currently can’t be different messages but the short bcs is a cropped part of the long bcs:
long bcs:
short bcs:
As you can see the short bcs is the first part of the long message. This took me quite some time to figure out as it is not made clear in the text.

I was asked to come up with a way to allow completely different messages for long and short bcs. I achieved this by first teaching myself 1802 assembly language, disassembling the hex dump and then finding the pointers to the long and short bcs.

As it stands there are 3 separate bcs allowed which are called in order short1, short1, short2, long then back to short1. As standard these all point to the same place in the EPROM (0666h).
Only one is called per beacon message, at the next beacon time the next message is used and so on in a round-robin system.
For those playing along at home (note I have moved the long bcs pointer from 012Bh and 012Eh to 0443h and 0446h respectively, and also the length):
the long bcs pointer high byte is at 0443h, length at 0449h
the long bcs pointer low byte is at 0446h
the short bcs(1) pointer high byte is at 012Bh, length at 0120h and 0128h
the short bcs(1) pointer low byte is at 012Eh
the short bcs(2) pointer high byte is at 0198h, length at 019Eh
the short bcs(2) pointer low byte is at 019Bh
These all currently point to the same address 0666h, if we change one (or more) pointers we can move the message elsewhere in the EPROM.
I chose:
the long bcs pointer to 0700
the short bcs(1) pointer to 0710
the short bcs(2) pointer to 0720
This is in an unused area of the EPROM and gives plenty of room for our bcs messages.
To do this, set the following:
long bcs pointer high byte (0443h) to 07h (originally was 06h)
long bcs pointer low byte (446h) to 00h (originally was 66h)
long bcs length pointer (0449h) to long bcs length (in dibits)
short bcs(1) pointer high byte (012Bh) to 07h (originally was 06h)
short bcs(1) pointer low byte (012Eh) to 20h (originally was 66h)
short bcs(1) length pointer (0120h and 0128h) to short bcs(1) length (in dibits)
short bcs(2) pointer high byte (0198h) to 07h (originally was 06h)
short bcs(2) pointer low byte (019Bh) to 40h (originally was 66h)
short bcs(2) length pointer (19Eh) to short bcs(2) length (in dibits)

Now we need to generate our messages:
long bcs “DE GB3TC IO92JX AR”
short bcs(1) “GB3TC B”
short bcs(2) “GB3TC B”
Converting them to Morse:
long bcs: -.. . / –. -… …– – -.-. / .. — —-. ..— .— -..- / .- .-.
short bcs(1): “–. -… …– – -.-. / -…”
short bcs(2): “–. -… …– – -.-. / -…”
In the Morse above a slash (“/”) represents the interword gap and a space (” “) represents an interletter gap.
We always start with an interword gap (I don’t know if this is strictly necessary but it will not do any harm)
Breaking down the short bcs(1) (because it is the short one!) we get:
01 11 11 10 00 11 10 10 10 00 10 10 10 11 11 00 11 00 11 10 11 10 00 11 10 10 10
Which has a length of 54 bits (27 dibits – 1Ch). We would need to pad the message as it is not a multiple of 8 bits long. The nearest would be 56 bits so we can just add 2 zeroes on the end:
01 11 11 10 00 11 10 10 10 00 10 10 10 11 11 00 11 00 11 10 11 10 00 11 10 10 10 00
The message itself is still the same length – we did not add any extra characters on so the 27 dibits (1Ch) figure above is still valid.
Convert this to hex:
0111 1110 7E
0011 1010 3A
1000 1010 8A
1011 1100 BC
1100 1110 BD
1110 0011 E3
1010 1000 A8
As this is the short bcs(1) we need to write this hex (7E 3A 8A BC BD E3 A8) to the address 0720h.
short bcs(1) length needs to be written to 0120h and 0128h
short bcs(2) hex needs to be written to 0740h
short bcs(1) length needs to be written to 019Eh
long bcs hex needs to be written to 0700h
long bcs length needs to be written to 0449h

If the dibits are confusing, look at it this way:
11 or 10 are characters (– and .)
01 or 00 are gaps
-.. . / — —– — -.. –.. / –. .-. . –.
01 11 10 10 <iw> D
00 10 <il> E
10 11 11 <iw> M
00 11 11 11 11 11 <il> 0
00 11 11 11 <il> O
00 11 10 10 <il> D
00 11 11 10 10 <il> Z
01 11 11 10 <iw> G
00 10 11 10 <il> R
00 10 <il> E
00 11 11 10 <il> G
Giving us the message DE M0ODZ GREG
Typing out the dibits can be done manually, or do a quick search and replace on your Morse string:
replace ‘/’ with 01
replace ‘ ‘ with 00
replace ‘-‘ with 11
replace ‘.’ with 10

The first and second bcs messages are pointing to the same location as the original author was trying to save a few bytes. More power to him, but this is the reason that you need to set the length byte twice for the first short bcs (0120 and 0128). To get around this I have given you 2 short and one long bcs. The first short bcs – bcs(1) – will be played twice, once at the first delay and once at the second delay, then bcs(2) at the third delay and finally the long bcs at the 4th delay.

If you are following along at home and get stuck, feel free to contact me. I will be glad to help.

Related posts

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.