Hi Group,
I've added a new page to the github Wiki to consolidate our research
here
. I think I've set it up so it can be edited by anyone (you will need
awi github account). The Groups WIKI is just too painful to use
frequently. Additionally the github wiki is backed by a git repo so
history is easily available.
I spent a lot of time with the disassembler over the weekend and made
a couple of happy discoveries! For one, memory access for the X900
does NOT use the address encryption feature of SB9600 that is used by
the Spectra RSS. This makes life MUCH easier!
I'm writing a script to dump the contents of a code plug image or .RDB
file to test our findings. Currently it doesn't do much other than
verify the checksum of the code plug and dump the number of active
modes. I'm currently adding code to dump the Tx and Rx frequencies
from the synthesizer programming bits that Dennis has already
identified. You can find the script in the Xcat NG firmware repo
()
My goal is to write a simple script to program code plugs from .RDB
files on a modern computer without screwing around with trying to slow
down the computer.
I went to the local Ham radio swap meet this weekend in search of
X9000 cables and heads ... I came home empty handed. X9000s aren't
very plentiful on ebay at the moment either and they haven't gotten
any lighter with age! I'm keeping my eyes open.
73's Skip WB6YMH
toggle quoted message
Show quoted text
On Sun, Aug 28, 2022 at 8:37 PM Dennis Boone <drb@...> wrote:
> I'm still not out of ideas for work arounds, but if the codeplug is
> to be extracted to be modified and re-inserted in the Pico, then
> using the RSS will destroy the work around structure...so far.
If RSS doesn't deal with cheating the number of entries higher, then
there's serious doubt that the radio will do it reliably either. I'm
not convinced it makes sense to try to force it.
In the X, the primary PL/DPL setup is in the mode data, not elsewhere.
The MPL setup does put stuff in other slots beyond the normal end of the
mode data. Does the X9000 do this similarly? It has half again as much
space devoted to the mode line.
> I really think the future of codeplug editing is going to be via a
> Java or VB runtime that can export a format that can be
> (re)integrated into the Pico possibly as a secondary step. I can
> provide structure/format information but writing such an application
> is beyond my skillset.
Language doesn't really matter. Generating proper bit patterns, and
making the thing feasible for mortals to fly, is what matters.
I'm sure a number of us are capable of generating software once we have
the details of the bit patterns in hand. You seem to have worked out
more of the layout than is written down anywhere. Any chance you could
write that out in text form and share that? Anything you've already
identified is something we don't have to reinvent.
De
|
Hi Group, Here's another update to review. Changes: 1. Added pullup resistors on DH interface, thanks Dave! 2. Connected PlugRd and BufDirIn to processor, thanks swguest ! I've also updated the Wiki () and committed the changes. 73's Skip WB6YMH On Sun, Aug 28, 2022 at 6:36 PM swguest via groups.io <swguest@...> wrote:
@ Skip,
Well I couldnt resolve the 2 different labels so I "connected" them myself to try to make it make sense...lol
IIRC Eagle will complain if you have unconnected lines/labels.
I *think* it will allow cross-connected labels but will issue an "Are you sure?" warning. It's been several years (a couple 'o three computers/HDDs ago) since I messed with it.
I am familiar with the effort hence my "Labor of Love" comment.
I always got a kick out of watching it do the PCB/Vias layout variants ...smart lil bugger...lol
Yeah, I dont see any easy way to do any muxing with the Pico not knowing when to latch the requested address. If you slowed it down *some amount* and did something like "n samples = the same values then latch that addr value" but that would be some ugly/quirky code. Plus, it would still have to be faster than the read window so the 244's could swap and settle...just to save one lousy pin?..naaa
I agree, use a GPIO to generate an IRQ, then let the state machine do it's thing is a much simpler method.
|
I retired my WINXP about a week ago and so, new to Win10 and getting sorted out what legacy stuff will work. The new GUI makes my eyes and brain bleed so I am not at 100% to try much at the time.
I do have a DOS setup with RIB and the untested RSS and cable for X9000. However I had Andy Brinkley program my codeplugs and firmware for which I am forever grateful.
toggle quoted message
Show quoted text
On Sun, Aug 28, 2022 at 11:59 PM, swguest wrote:
@ Joe,
Do you have a means to connect you X9000 to a Windoze computer via serial port and RIB?
It might work with a USB---> serial adapter too, I've never tried it. I've run the Mototools proggy on 32b XP and 64b Win7 w/o issues (both w/real serial ports)
I cant speak for Win10/11/68 and owe ya one/or whatever.
I have a computer with it on it but I abhor 10 and all the BS/bloat that comes with it...but what do I know. A few hundred million Koolaid drinking sheeple cant be wrong, right?
snip
|
Re: I got an EEPROM reader/writer
Oh, on a side note, I was able to program my X9000 with a Panasonic > CF-18 toughbook using a DOS boot USB stick and a slowdown program > called throttle. It was a nice discovery after I wasted several hours > going through a pile of old 386/486 laptops that all ended up having > some issue like bad hdd or floppy drives. Nice, and if you're having trouble getting the radio to release from the mounting plate, you can use the Toughbook as a blithwapper to get it started moving! De
|
Re: I got an EEPROM reader/writer
It's the Chinese so who knows. It probably emits gamma radiation.? :)
I'll probably pick up one of the little eraser drawers off Amazon. They are cheap enough.
Oh,? on a side note,? I was able to program my X9000 with a Panasonic CF-18 toughbook using a DOS boot USB stick and a slowdown program called throttle. It was a nice discovery after I wasted several hours going through a pile of old 386/486 laptops that all ended up having some issue like bad hdd or floppy drives.?
On Sun, Aug 28, 2022, 23:11 Dennis Boone < drb@...> wrote: ?> I had a little cell phone sterilization box thing I got as a
?> Christmas stocking stuffer item. I wonder if it would be the proper
?> UV to erase them.
They're selling those things to mortals, so I suspect they're not all
that powerful. :)
De
|
Re: I got an EEPROM reader/writer
I had a little cell phone sterilization box thing I got as a > Christmas stocking stuffer item. I wonder if it would be the proper > UV to erase them. They're selling those things to mortals, so I suspect they're not all that powerful. :) De
|
FAIL ERROR is in the firmware along with programming and other system messages as well as the alpha character sets with the? / -? _? characters.? The head is of course programmed via SB9600 but it seems the only thing it can do is react to a mode slot and then look up what mode alpha name corresponds to it.
Perhaps a spectra systems 9000 head could be used since,? if I'm correct, it actually displays data from the radio via SB9600 and is not separately programmed. There are FW updates to convert syntor heads to spectra heads if I remember right. That should mean that the rest of the design is the same.?
On Sun, Aug 28, 2022, 20:53 Dennis Boone < drb@...> wrote: ?> Can the X9000 VFD display be written to externally via the SB9600
?> bus? If so the XCAT9K could push channel labels to the control head
?> and multiple pages of channel labels displayed. Of course that begs
?> the question as to whether that traffic can write to the head without
?> bogging down the resto of the system. Has anyone tried this? The
?> radio apparently can write certain things to the display like BITE
?> errors and scratchpad memory for DTMF dialing.
SB9600 does provide a mechanism for writing labels and such to a control
head over the bus, but it's not clear to me whether that's ever used by
the radio.? Since you have to also program the control head, and its
code plug is supposed to match the radios plug, I suspect it mostly
doesn't.? Interestingly, the string FAIL isn't apparently in the ROM.
De
|
@ Joe,
Do you have a means to connect you X9000 to a Windoze computer via serial port and RIB?
It might work with a USB---> serial adapter too, I've never tried it. I've run the Mototools proggy on 32b XP and 64b Win7 w/o issues (both w/real serial ports)
I cant speak for Win10/11/68 and owe ya one/or whatever.
I have a computer with it on it but I abhor 10 and all the BS/bloat that comes with it...but what do I know. A few hundred million Koolaid drinking sheeple cant be wrong, right?
If you can get the HW set up, the program is in the files section.? It has a tab that will let you compose ASCII? and send the text to the display via SB9600. No functional use really, except to see it work as POC and see the packets created and sent to make it happen. Practically speaking, the head and it's codeplug is another animal alltogether. I doubt any display data sent by the Xcat would be retained the next time the CH needed to perform a function,
There *may* be? a means to manipulate the CH codeplug to allow for > 211? or 214? (I dont recall the name limit) possibly at the expense of some other feature, if at all.
Do you need more that the limit of mode names? 200+ modes with built in TA/simplex/direct option in each mode should cover a lot of real estate.
The multi codeplug image is an intriguing idea but a hotswap might bite you if the radio needed to recalc the checksum for some reason.
Still definately something worth validating if plausable or not, once we are out of the nest.
|
I'm still not out of ideas for work arounds, but if the codeplug is > to be extracted to be modified and re-inserted in the Pico, then > using the RSS will destroy the work around structure...so far. If RSS doesn't deal with cheating the number of entries higher, then there's serious doubt that the radio will do it reliably either. I'm not convinced it makes sense to try to force it. In the X, the primary PL/DPL setup is in the mode data, not elsewhere. The MPL setup does put stuff in other slots beyond the normal end of the mode data. Does the X9000 do this similarly? It has half again as much space devoted to the mode line. > I really think the future of codeplug editing is going to be via a > Java or VB runtime that can export a format that can be > (re)integrated into the Pico possibly as a secondary step. I can > provide structure/format information but writing such an application > is beyond my skillset. Language doesn't really matter. Generating proper bit patterns, and making the thing feasible for mortals to fly, is what matters. I'm sure a number of us are capable of generating software once we have the details of the bit patterns in hand. You seem to have worked out more of the layout than is written down anywhere. Any chance you could write that out in text form and share that? Anything you've already identified is something we don't have to reinvent. De
|
I got an EEPROM reader/writer
I picked up a TL866II Plus reader/writer. It's a pretty neat little kit for about $70. So far I have been able to read and backup the codeplug and FW chips in the X9000 and also my old T3011DX keyloader. I believe the chips are UV erasable type since they have windows so I was unable to try programming them yet. I had a little cell phone sterilization box thing I got as a Christmas stocking stuffer item. I wonder if it would be the proper UV to erase them. If I can find it I'll try it. I don't know if the capability will be of any use here but figured I'd mention it.
|
@ Dennis,
Yeah, it's squirrelly.
For a 2k codeplug, the beginninf of the MPL data storage offset is 0700h, and goes for 64 bytes, ala 4 bytes (2 for RX,2 for TX) per MPL unit X 16 MPL units.
That is where the RSS begins to assign offset values for mode slaved PL data (in byte 7 of a mode's 24 byte set), referenced to the BEGINNING of the MPL storage location, ala 0700h.
This beginning addr is set on zero page and can be changed, but the stock RSS ALWAYS puts the 1st mode slaved PL values 17 MPL sets above the MPL data start (0700h default for a 2k EEPROM).
So... the OEM calculated offset for the 1st mode slaved PL is 11h (17d, 17th PL set). This doesnt have to be mode one. If the 1st mode slaved PL created is say, mode five, mode five will have 11h in byte 7 and reference the 4 bytes beginning 11h above 0700h.
Each PL set is two sets of two byte values, even if either is carrier squelch. Any mode(s) that use the same mode slaved PL data, get the same offset value in byte 7.
Each PL offset counts in two, two byte steps. so 11h references data in offset positions (bytes) 1,2(RX) and 3,4(TX). The 2nd created mode slaved PL will have an offset value in byte 7 of 12h and will reference data in offsets positions (bytes) 5,6,7 and 8.
There is another value on zero page that tells the RSS how many MPLs you have. Stock RSS allows it to be set to 10h(16d) max by default. Changing that to 20h (32d) forces the RSS to allow 32 MPL units to be entered and makes the 1st mode slaved PL offset to be 21h (33d),
....BUT each mode slaved PL created after that gets an offset value that is less by one...20h,1Fh,1Eh, etc until it gets back down to 11h.
If you have any MPL data in MPL units in MPLs 17-32, they are overwritten.
Edit or delete a mode slaved PL an it gets really interesting...Unique PL data values are copied/shufled down toward the expected beginning offset, if shuffled/moved, all byte 7 offsets are re-calculated and re-referenced, and as for the data that is copied, the original values are de-referenced and abandonded as clutter. That makes it really difficult to sort out what belongs and what is clutter.
I'm still not out of ideas for work arounds, but if the codeplug is to be extracted to be modified and re-inserted in the Pico, then using the RSS will destroy the work around structure...so far.
I really think the future of codeplug editing is going to be via a Java or VB runtime that can export a format that can be (re)integrated into the Pico possibly as a secondary step. I can provide structure/format information but writing such an application is beyond my skillset.
|
Can the X9000 VFD display be written to externally via the SB9600 > bus? If so the XCAT9K could push channel labels to the control head > and multiple pages of channel labels displayed. Of course that begs > the question as to whether that traffic can write to the head without > bogging down the resto of the system. Has anyone tried this? The > radio apparently can write certain things to the display like BITE > errors and scratchpad memory for DTMF dialing. SB9600 does provide a mechanism for writing labels and such to a control head over the bus, but it's not clear to me whether that's ever used by the radio. Since you have to also program the control head, and its code plug is supposed to match the radios plug, I suspect it mostly doesn't. Interestingly, the string FAIL isn't apparently in the ROM. De
|
@ Skip,
Well I couldnt resolve the 2 different labels so I "connected" them myself to try to make it make sense...lol
IIRC Eagle will complain if you have unconnected lines/labels.
I *think* it will allow cross-connected labels but will issue an "Are you sure?" warning. It's been several years (a couple 'o three computers/HDDs ago) since I messed with it.
I am familiar with the effort hence my "Labor of Love" comment.
I always got a kick out of watching it do the PCB/Vias layout variants ...smart lil bugger...lol
Yeah, I dont see any easy way to do any muxing with the Pico not knowing when to latch the requested address. If you slowed it down *some amount* and did something like "n samples = the same values then latch that addr value" but that would be some ugly/quirky code. Plus, it would still have to be faster than the read window so the 244's could swap and settle...just to save one lousy pin?..naaa
I agree, use a GPIO to generate an IRQ, then let the state machine do it's thing is a much simpler method.
|
I've made a bit more discovery on the codeplug PL data > management...it is going to be a task to say the least to edit the PL > data outside the RSS and maintain RSS compatibility. Hex editing > codeplugs made by RSS is doable but not a straight forward/valid > option for many. I'm hoping the ROM will provide us with some clues about how the PL data is laid out. I've already seen it calculate a couple of offsets. De
|
Can the X9000 VFD display be written to externally via the SB9600 bus? If so the XCAT9K could push channel labels to the control head and multiple pages of channel labels displayed. Of course that begs the question as to whether that traffic can write to the head without bogging down the resto of the system. Has anyone tried this? The radio apparently can write certain things to the display like BITE errors and scratchpad memory for DTMF dialing.
|
It looks like while either of the 2816's /CE or /OE lines are high, the U4a gate output is low and the /OE for U3 (d0-d7) is enabled, and when the 2816's /CE AND /OE go low (read EEPROM) the U4a gate output goes high, releasing U3's /OE, and drives the U4b gate output low, selecting the U1 (a01-a7) /OE pin until the read cycle is finished.
If that is right and those need swapping, might still have to give the Pico the actual read cycle req. so it can latch that addr before the 244's swap, otherwise it will look at what it considers the addr inputs "many times" during a single read event..and possibly retreive/present the wrong data?...... A second set of eyes certainly helps, thanks for reviewing it! Actually the output from U4a goes ... NOWHERE! That thing that looks like a wire is a BUS and PlugRd is just one signal in the bus, but it's not connected anywhere. The same thing for U4b's inputs BufDirIn comes from the bus, but it is not driven from ANYWHERE! The intent is that U3A generates a read request to the processor which causes an interrupt. The processor sets BufDirIn low, disabling U1 (the address buffer) and enabling U3 (the data buffer). Once it has done that it changes GPIO8-GPIO15 from input mode to output mode. I'll fix it and post a new schematic. 73's Skip WB6YMH
|
@ Skip
Just had a bit of time to take a look at your schematic. That's a lot of work and a colossal effort to maitain legacy functions...a labor of love for sure.
I've made a bit more discovery on the codeplug PL data management...it is going to be a task to say the least to edit the PL data outside the RSS and maintain RSS compatibility. Hex editing codeplugs made by RSS? is doable but not a straight forward/valid option for many.
........More investigation needed.
Anyway, to the schematic. Am I seeing it right? It looks like U3 and U4 /OE lines should be swapped?
First, this is? presuming PlugRd = BufDirIn
If not, then disregard the following and color me lost...lol
It looks like while either of the 2816's /CE or /OE lines are high, the U4a gate output is low and the /OE for U3 (d0-d7) is enabled, and when the 2816's /CE AND /OE go low (read EEPROM) the U4a gate output goes high, releasing U3's /OE, and drives the U4b gate output low, selecting the U1 (a01-a7) /OE pin until the read cycle is finished.
If that is right and those need swapping, might still have to give the Pico the actual read cycle req. so it can latch that addr before the 244's swap, otherwise it will look at what it considers the addr inputs "many times" during a single read event..and possibly retreive/present the wrong data?......
I'm thinking all the addr lines 244s should be enabled at the same time for a valid addr read by the Pico, then swap out the lower addrs lines and swap in the data lines for the final step of the read cycle.
Also, I'm presuming that there is enough propagation delay in U4 to allow for the Hitachi's addr lines "settling time" so the Pico can get a valid addr read before the 244s swap to present the correct data on the data out port. I guess one could put the extra gate inline to add a bit more delay if needed and if so it would be enough.
I have just perused the schematic, and this is all "mental/virtual/theoretical logic".
I have not looked up settling time, propagation delay(s), or breadboarded anything with a logic analyzer.
Those SMT are going to be the death of me...lol
?If I read the .pdf right, the pitch is right at 2:1 for SOIC and 4:1 for SSOP over thru hole.
I'm going to have to get me a stack of BoBs and some cheap SOIC/TSOP/SSOP's to practice on.
The new chip tech aint making it easy for us old farts with diminished vision to play anymore.? Sign of the times....
|
If I understand correctly from a hardware viewpoint that could be
done. The Pico has 2 megabytes of flash, I'd be shocked if the
firmware took more than 128k so there's plenty of space to save
multiple 8K code plugs.
Note that as currently designed the Xcat can't be written to by the
radio, only read. So RSS won't be able to program the multiple images
directly. Once we learn enough it should be possible to create the
images independently of RSS.
It is an outstanding question is if the EEPROM is ever written by the
radio independently of RSS. If it is then we'll need to change the
design.
73's Skip WB6YMH
toggle quoted message
Show quoted text
On Fri, Aug 26, 2022 at 4:24 PM RFI-EMI-GUY <rhyolite@...> wrote:
Would it be possible, and this coming from my exceedingly vast ignorance, while treating the XCAT9K as multiple code plugs and (for present) use the RSS to write to each codeplug image as a separate session and have XCAT9K control which codeplug image is presented to the radio?
Then use SB9600 from the control head to step through the images as "zones"? The codes for the siren features could be hijacked for this purpose.
Can some memory in the XCAT9K be reserved for future control head alphanumeric tags in the event some future control head project can make use of that data somehow?
On Fri, Aug 26, 2022 at 04:33 PM, Skip Hansen wrote:
We're doing everything out in the open in this group. There are no
side discussions. Personally I'm not interested in a control head at
the moment, but I'm happy to support anyone who is.
Other than interest the other key ingredient is understanding the low
level details of the code plug layout. Dennis, swguest and others
have made some great progress but we're not there yet.
I've tried sniffing the SB9600 bus, but RSS apparently uses address
encryption while reading and writing the EEPROM so that's a dead end
(for now).
I've dumped my EPROM and I'm starting to try to figure out the code
(more details in my github repo
).
73's Skip WB6YMH
On Fri, Aug 26, 2022 at 12:32 PM RFI-EMI-GUY <rhyolite@...> wrote:
Mux Genius!
I am very interested in X9000. Has there been further discussion about how to interface data with outside world (outside the Personality Board RF can and radio itself)? Also a general sense of the development path to either a new control head or extension of X9000 control head to the new memory capabilities? or both?
On Fri, Aug 26, 2022 at 02:33 PM, Skip Hansen wrote:
X9000
|
Would it be possible, and this coming from my exceedingly vast ignorance, while treating the XCAT9K as multiple code plugs and (for present) use the RSS to write to each codeplug image as a separate session and have XCAT9K control which codeplug image is presented to the radio?
Then use SB9600 from the control head to step through the images as "zones"? The codes for the siren features could be hijacked for this purpose.
Can some memory in the XCAT9K be reserved for future control head alphanumeric tags in the event some future control head project can make use of that data somehow?
toggle quoted message
Show quoted text
On Fri, Aug 26, 2022 at 04:33 PM, Skip Hansen wrote:
We're doing everything out in the open in this group. There are no
side discussions. Personally I'm not interested in a control head at
the moment, but I'm happy to support anyone who is.
Other than interest the other key ingredient is understanding the low
level details of the code plug layout. Dennis, swguest and others
have made some great progress but we're not there yet.
I've tried sniffing the SB9600 bus, but RSS apparently uses address
encryption while reading and writing the EEPROM so that's a dead end
(for now).
I've dumped my EPROM and I'm starting to try to figure out the code
(more details in my github repo
).
73's Skip WB6YMH
On Fri, Aug 26, 2022 at 12:32 PM RFI-EMI-GUY <rhyolite@...> wrote:
Mux Genius!
I am very interested in X9000. Has there been further discussion about how to interface data with outside world (outside the Personality Board RF can and radio itself)? Also a general sense of the development path to either a new control head or extension of X9000 control head to the new memory capabilities? or both?
On Fri, Aug 26, 2022 at 02:33 PM, Skip Hansen wrote:
X9000
|
We're doing everything out in the open in this group. There are no
side discussions. Personally I'm not interested in a control head at
the moment, but I'm happy to support anyone who is.
Other than interest the other key ingredient is understanding the low
level details of the code plug layout. Dennis, swguest and others
have made some great progress but we're not there yet.
I've tried sniffing the SB9600 bus, but RSS apparently uses address
encryption while reading and writing the EEPROM so that's a dead end
(for now).
I've dumped my EPROM and I'm starting to try to figure out the code
(more details in my github repo
).
73's Skip WB6YMH
toggle quoted message
Show quoted text
On Fri, Aug 26, 2022 at 12:32 PM RFI-EMI-GUY <rhyolite@...> wrote:
Mux Genius!
I am very interested in X9000. Has there been further discussion about how to interface data with outside world (outside the Personality Board RF can and radio itself)? Also a general sense of the development path to either a new control head or extension of X9000 control head to the new memory capabilities? or both?
On Fri, Aug 26, 2022 at 02:33 PM, Skip Hansen wrote:
X9000
|
RFI-EMI-GUY