Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Has anyone fully decoded the X9000 memory mapping?
|
On Tue, Aug 9, 2022 at 01:04 PM, Casey Crane wrote:
Intronics Pocket RomulatorLet me see what I've got. I had some misc for testing, but if you've got RSS running you can roll your own w/whatever you want in it. You will have to trim to 2048. The RSS file is? bit bigger w/ comments area at the end. RSS write to radio ignores all that's above 2 or 8 k. |
|
I now have an Intronics Pocket Romulator model 1 in hand. As luck had it, the company was local so I drove over and got one on lunch. The problem is I need a ROM reader and I don't yet have one. Do you are anyone have a binary or hex image of one of the 2k X9000 EEPROMS? I'm continuing to read up on it and my understanding is I would load the file into it then it will allow live editing of the EEPROM image byte by byte. Probably a dumb purchase but whatever.... On Mon, Aug 8, 2022 at 2:21 PM Dennis Boone <drb@...> wrote: ?> I assumed for whatever reason, the radio just iterated over the mode |
I assumed for whatever reason, the radio just iterated over the mode> data again and again refreshing itself to make sure nothing was > inadvertently corrupted along the way. I guess I got this mental > picture from the synth refresh description and likely incorrectly > applied it to everything else. Remember that the 9000 radio has only 256 bytes of RAM (minus microcontroller control registers which are memory mapped), into which it has to stuff the currently needed mode data, software stack, counters and control and status values for loops and whatever, etc. The X has _64_ bytes. It's pulling in the data for the mode it needs now, and keeping whatever bits it'll reuse in RAM -- maybe the whole mode, maybe just some of it. Without disassembling the ROMs, we don't know if it stores two whole modes for scan, or just one and a "go back to" mode number. In the X, the processor generates the tx PL/DPL data, and counts the rx. I can't speak to whether it repeatedly reprograms the prescaler / divider setup. > So, how do you suspect scan works? You are saying the radio reads the > modes into the uP from the EEPROM all at once along with the PL data > then executes operations using that data stored internally? This is a pretty good description of the scan concepts for the X: Since the scan data is encoded in the mode data (primary and secondary priority scan as numbers, and non-priority scan list as a bit map), the radio must be reading each mode as the list calls for it, and remembering somehow how to get back to whence it came. The X _could_ just be reading the Mode Select lines from the control head each cycle, or it could store the mode number. Either way, with such a small RAM, I rather doubt it'd keeping more than one mode worth of data in RAM. Note that on the X, for some scan modes, scan mode data is held *in modes other than the currently selected receive mode*. I rather expect the cycle looks something like: - fetch scan target mode data (pri1, then pri2, then scan list) - change frequency to there - check for signal, maybe stay around for a bit - maybe switch back to the selected mode by - fetch selected mode data - change frequency to there - repeat De |
|
Good points. We really need to figure out how to get something usable from this LA data. I assumed for whatever reason, the radio just iterated over the mode data again and again refreshing itself to make sure nothing was inadvertently corrupted along the way. I guess I got this mental picture?from the synth refresh description and likely incorrectly applied it to everything else. So, how do you suspect scan works? You are saying the radio reads the modes into the uP from the EEPROM all at once along with the PL data then executes operations using that data stored internally? I assumed it read in some codeplug structure info, determined what size of chip was on board, how many modes there are and then made the decision as to what EEPROM data locations to go and grab the freq an PL data, obtaining it on the fly based on scan flags in the codeplug and ultimately doing operations with it in a just in time manner by manipulation of the PL output lines, synth divider lines and other associated?functions. We really have to map out the order of operation before we can do anything else or it's all just speculation.? On Mon, Aug 8, 2022 at 1:28 PM swguest via <swguest=[email protected]> wrote: @ Casey, |
To emulate the EEPROM in mode based operation the uC will have to be> commanded to re-read the EEPROM (ie:via a mode increment cmd) and it > is multiple memory locations so it will step thru at least 16 > (probably all 24) addresses to get the data it wants for a complete > byteset. The Xcat does this with a fly-lead from the xcat to a point inside the radio, since the switching on the X is all mechanical. Note that the radio may or may not just read addresses n through n+23 (for the 9000, +15 for the X) locations in order. Inquiring minds want to ... ooh, shiny! > I dont know of a single SB9600 or other cmd that will initiate a > re-read of the EEPROM for the same mode. There is a "switch mode" command, iirc. The question is whether, when the radio is sitting on Mode 1, sending it a "Switch Mode To 1" command will induce the required heartburn, or if the radio thinks its smarter than that. But even if the radio tries to filter out such "duplicate" or "repetitive" commands, there's a simple workaround: alternate between two modes for VFO type control. De |
|
@ Casey,
Unless your LA tests determined otherwise, I imagine the refresh is from data stored in the uC for that mode to the divider. Infact, that might explain a lot of the buss activity you were seeing since the divider FF/register is fed from the addr and data lines ?To emulate the EEPROM in mode based operation the uC will have to be commanded to re-read the EEPROM (ie:via a mode increment cmd) and it is multiple memory locations so it will step thru at least 16 (probably all 24) addresses to get the data it wants for a complete byteset. You have to decode the addr lines to know what it is asking for, so you might as well associate all that data to that address request in memory anyway. VFO mode is something that needs to be evaluated. I dont know of a single SB9600 or other cmd that will initiate a re-read of the EEPROM for the same mode. It would still be a 16 or 24 byte read regardless. Maybe a macro of the SB9600 commands that perfoms the random access to mode selection function....sel/keypad1/sel or whatever the actual sequence is...I dont recall ATM Repeating that macro should force the uC to re-read of the same place(es) in the EEPROM's memory, until a COS (in the case of a search feature, another input needed for non OEM scan function) or an end routine command is received. You would have to inc/dec or encode FPP input and write that data to the address of the 3 bytes used for rx VCO frequency in the Pico (or whatever is used) memory of the mode you are re-reading before each execution of the SB9600 macro. Likely doable, but could get complex. |
Speaking of CTCSS, provisions for a non-standard user-settable tone> would be great, too. (user-settable meaning preprogrammed, but if it > can be set on the fly that is fine too) Since the programming for this is a computed divisor, you can set any frequency you want within the range. On the X, the ranges are different for tx vs rx, or at least, since it uses different scaling factors the bit field holds different ranges. Syntorxgen lets you do custom tones. De |
|
OK. I didn't know if the COS was in software or hardware.
toggle quoted message
Show quoted text
A limit search would be a great feature. I wish the scan could be made fast enough to emulate a GE MVS scan. It has Priority sampling so fast you could never hear the sampling unless a constant tone were transmitted on the non-priority channel (then you could hear the very small sampling gap). No other radio had that. Something else it did was sampled for COS first, then if active it sampled only long enough to determine matching tone/code. Speaking of CTCSS, provisions for a non-standard user-settable tone would be great, too. (user-settable meaning preprogrammed, but if it can be set on the fly that is fine too) Joe M. On 8/8/2022 2:06 PM, Casey Crane wrote:
I'll have to check my code again but I was able to drive the synthesizer |
|
I'll have to check my code again but I was able to drive the synthesizer very quickly across the band. Definitely fast enough for a good limit search function.? The channel activity input to the processor would be the stop flag.? On Mon, Aug 8, 2022, 13:02 Joe M. <mch@...> wrote: If scan is external you would also need a squelch |
|
If scan is external you would also need a squelch
toggle quoted message
Show quoted text
indication in order to stop scan (for active channels). I would check to see how fast the synth can lock at maximum change (and lowest decode rate (67.0 Hz or DPL - I forget which is slower), then double that to set the scan speed. If you are rewriting the scan, dual-priority should be a minimum. Two scan lists (or more) would be a bonus. Those could be mode-slaved. Joe M. On 8/8/2022 1:37 PM, Casey Crane wrote:
As for the synthesizer the radio updates it every 20 milliseconds |
|
As for the synthesizer the radio updates it every 20 milliseconds regardless of mode change to maintain stability in the event some transient voltage or whatever corrupted something. My thought was a mode change would occur by way of changed emulated eeprom data representing mode 1 of only a 1 mode codeplug. I'm not seeing any reason for more than one mode of data since we are changing it dynamically and there would be no reason to chase data all over the memory map when we can just point it to one spot and change that.? Scanning is something I've been mulling over. Can you? build a 1 mode codeplug and have a 1 mode scanlist? If so I would assume in scan mode the radio accesses and updates the synthesizer faster than the 20 milliseconds refresh static rate (how fast do they scan?). If so, then presenting emulated mode 1 data at a faster changing rate might work out as long as the radio is polling faster since it's thinking it's scanning. Of course we would have to keep it all in perfect time with what the processer wants but I assume that would be all part of the emulation process and dictated by the CE activity. On Mon, Aug 8, 2022 at 12:08 PM Skip Hansen <skip@...> wrote: Good points!? I had forgotten about needing to get the radio to |
|
Good points! I had forgotten about needing to get the radio to
toggle quoted message
Show quoted text
re-read the mode info, ugh. In reality it might be worth taking this approach just to solve the refresh problem. An EXTERNAL to the radio ESP32 could provide CI-V to SB9600 translation plus be the basis for an Bluetooth or WiFi interface to phone/tablet or head using app. And ... ESP32 boads with RS485 support exist already for $21.57 (). It just so happens I have two sitting on my self from a work project ... Damn them squirrels ! 73's Skip WB6YMH 73's Skip WB6YMH On Mon, Aug 8, 2022 at 9:50 AM Dennis Boone <drb@...> wrote:
|
Yea, but then you have to conform to the SB9600 protocol, yuck! For> computer control you'd also need a SB9600 "gateway" or a rib and a > serial port, again yuck. Going back to Skip's comment, a couple of thoughts, devil's advocate: 1. But you don't have to find a hack/slash way to get your control path out of the radio, because it's already there, and it's compatible with the whole existing system. 2. One way to get the radio to notice new mode data set by the external frequency agile control setup would be for the x9000cat-2022 to spoof a mode change onto the sb9600 channel. FWIW. De |
|
On Sun, Aug 7, 2022 at 06:21 PM, Skip Hansen wrote:
Yea, but then you have to conform to the SB9600 protocol, yuck! For@ Skip, True. Hand assembling a few basic commands like volume and mode select inc/dec, scan on/off etc might not be a major undertaking. I'd like to see a macro of commands that get you control of the squelch parameters too. Although forcing a mode increment cmd to the uC might be needed to force an EEPROM read to create a scan function that can be controlled in a PH II design. Doesnt the Xcat do something similar on one of the CH lines to X's uC to implement scan? Since the X9000 OEM head is intelligent too, mode information is a function of the radio commanding the head to "display the data you have stored for mode nn. Building that array could get complex. Likely OTF edits could get cumbersome too. Using/hijacking the SB9600 protocol to program the EEPROM via the host uC is unlikely. I doubt Motorola supports single byte writes in the FW, which is necessary for the goal. ? That's when we will need that wedge into the FW loop and a single byte write subroutine written......got 'er done yet? With a lot of research and dedication, some form of SB9600 based UI isnt unrealistic, but is probably Ph III or beyond. |
|
After re-reading the txt a few additional thoughts....
The CE for the data line 245 must be an undefined (in the information presented) outboard connection to the host, probably an expansion window enable line of some sort. This appears to present a n Kbyte block into the memory map of the host, via an expansion window. That said, not absolute addressing, no zero page conflicts. I didnt see an example shown of using Arduino IDE to load the memory array, or mention of where. Comments show the 7FFF mask references the PCjr's memory not the Teensy's. I have never used it but have seen examples of how to load an array into the Arduino family's memory via the IDE. That method wont work for our goal. Running full tilt like it does assures data will alway be present, but it's not likely to win any power consevation awards...lol |
|
I think the CPU *could* do it, but why bother? Plus playing with the
state machine will be the fun part of the project for me. The "page zero" ram stuff really doesn't apply to the Teensy, it's a 32 bit processor with a megabyte of RAM on chip. My take on the posted code was that you just defined the values of the RAM buffer in the C source, recompiled and reloaded using the Arduino IDE. 245's might not mind 3v3 on the data lines, but powering them from 3v3?? My data books are in the garage and I'm too lazy to go look... 73's Skip WB6YMH On Mon, Aug 8, 2022 at 8:17 AM swguest via groups.io <swguest@...> wrote:
|
|
Yeah, they are feature packed for sure. Kinda pricy and supply chain hobbled last I looked.
How to load to memory is probably Teensy 101 for the Teensy camp. I havent looked at the other projects yet. The 245's on the addr lines with 3v3 VCC on them would likely be ok. I think the one for the data bus would likely be better served with the dual voltage 245 you mentioned a few posts back. ?Given enough real estate, I'd opt for the dual voltage version for all lines. It looks like the thing reads and presents data every time the loop is executed whether the address lines have changed or not. He does show a CE for the data line's 245 but no reference on the uC pinout schematic, or the code to support it....hmm Also absolute addressing puts this thing consuming zero page RAM. PC uP do a lot of zero page R/W. I dont see any bidirectional data capabilities. I guess to find the address where the data to be presented is in memory, follow the ANDing and bit shiting he uses to build and store in the 32 bit registers. Interesting read but it's still vague and lacking for our purposes. I do like the compact HW design. Looking at this code, it does make me curious what the Arduino IDE Pico module's command syntax looks like. ?I scanned some googled info on the Pico's state machine and DMA features. Very cool, I really liked what I was able to glean from my quick glance. I didnt absorb enough to figure out if those means are robust enough for our purposes. Even though the state machine's command set was small, it might be enough to do what we want, but at 133 Mhz do we really need to unload the main uC? |
|
The data appears to be in RAM, but there's no clue about?how it's loaded.? As written it should be all zeros. The schematic is also a bit suspect if you ask me, he's using just a plain jane 74LS245 running on?+3.3 as a level converter.? It might work, but it's certainly not "by the book". I knew Teensy's were fast, but I didn't know they were 600 Mhz. If you go to the top project you see he also has a ton of emulators based on the Teensy which are CPU replacements. Interesting... 73's Skip WB6YMH On Sun, Aug 7, 2022 at 7:46 PM Casey Crane <ccrane148@...> wrote:
|
|
It looks like the syntax for? the Teensy module is different. There is not CE/trigger so as it sees the addresses it outputs the memory locations to the data bus continously.
He calls out where the array is in the Teensy but doesnt say how to load it to there. i guess you know that much if you are a Teensy guy....hmmm....not a T-shirt I'd want to wear around town, Apparently the single line reads the pin,? ANDs and Shifts L or R that address bit value, concatenate all the results, then AND that value to identify alocation in the uC's memory map where the arrary is located. Seems like a lot of extra math. He set 3 int32 regs to do this...for a 16 bit address...........I dunno |
to navigate to use esc to dismiss