Re: Has anyone fully decoded the X9000 memory mapping?
Not sure yet. I'm not at home but I do have the software pulled up on my laptop. It imported the file without complaining but I can't power up the device until I'm at the radio since it gets power from the EEPROM socket. They are UHF files but at least I should be able to see how the device interfaces with the software. I will try an original codeplug hex file from the radio too and hopefully that will work as swguest?suggested so I don't have to buy a reader too.
@ Casey,
?Those fils fix you up?
|
Re: Has anyone fully decoded the X9000 memory mapping?
Not directly.
The RSS makes 9k files but only writes 2048 or or 8192 byte to the radio.
Make a codeplug for a 2k radio, save it then delete all the data after 7FFh in Hex workshop or whatever.
You can probablr put that full 9k on the Romulator and the radio wont care because it is only looking at/for 2k
|
Wow, we got a lot of functionality from that lowly?16F874 PIC "back in the day".? Once I got down to actually assigning GPIO lines I realized that the RPI Pico really doesn't have as many GPIOs as I would like.? It's "enough", but just barely.?
I've summarized the GPIO usage and limitations in the Wiki in the new Xcat NG hardware repo ().
Please have a look and let me know your comments.
p.s. I find the github wiki much easier to use than the groups.io wiki (probably because I've used it before) which why a new URL.
p.p.s I link the name Xcat NG better than Xcat-2022 which will look silly in 2030 (grin).
73's Skip WB6YMH
|
Re: Has anyone fully decoded the X9000 memory mapping?
I was curious if the RSS generated codeplug would work directly. I'll try that too. The romulator software allows for binary, intel hex, motorola hex, and ascii. It will be like winning the lottery if it actually all works though so I'm not holding out too much hope.
On Tue, Aug 9, 2022 at 01:04 PM, Casey Crane wrote:
Intronics Pocket Romulator
Let 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.
|
Re: Has anyone fully decoded the X9000 memory mapping?
@ Casey,
?Those fils fix you up?
|
Re: Has anyone fully decoded the X9000 memory mapping?
Nice link Dennis. I think he only has a T71 though..........
|
Re: Has anyone fully decoded the X9000 memory mapping?
toggle quoted message
Show quoted text
On Tue, Aug 9, 2022 at 3:25 PM Dennis Boone < drb@...> wrote: ?> Do you are anyone have a binary or hex image of one of the 2k X9000
?> EEPROMS?
Two distinct codeplug images here:
The two with close serial numbers are identical.
De
|
Re: Has anyone fully decoded the X9000 memory mapping?
Do you are anyone have a binary or hex image of one of the 2k X9000 > EEPROMS? Two distinct codeplug images here: The two with close serial numbers are identical. De
|
Re: Has anyone fully decoded the X9000 memory mapping?
On Tue, Aug 9, 2022 at 01:04 PM, Casey Crane wrote:
Intronics Pocket Romulator
Let 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.
|
Re: Has anyone fully decoded the X9000 memory mapping?
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
?> 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
|
In one of my posts in the other thread I located some existing pins that will get signals "in and out of the can", but as several of them are for KVL keyloading it would be nice to multiplex them with a transmission gate so that functionality remains.
Otherwise the idea of using the SB9600 bus is a better idea because it gives simultaneous access to the control head and the RIB interface.
toggle quoted message
Show quoted text
On Mon, Aug 8, 2022 at 04:52 PM, Skip Hansen wrote:
Hi Dave,
?
I would rather NOT use the USB serial port to simplify the wiring and to minimize high speed signals inside of the radio.? USB would be used to flash the board with the initial?flash image.??
?
Possible wiring options:
1. Route 3.3V Rxd, Txd via unused control cable pins or just drill a hole for a 3 pin cable.
2. Route 5V Doug Hall clock and data line via unused control cable pins or just drill a hole for a 3 pin cable.
?
For the Xcat-9000 another option would be to use SB9600 for communications and attach the Xcat2022 to the SB9600 bus internally.? ?No need to find unused control?cable poins or drill holes for a new cable.? I'm starting to like this...
?
Testng the Doug Hall interface should be easy even w/o a radio.? You would need one of your controllers connected to the new board and the original?XCat PC control program or a successor.? Frequencies set via the Doug Hall interface can be read back over CI-V.? If they are correct then we're good to go.
?
73's Skip WB6YMH
On Mon, Aug 8, 2022 at 11:41 AM Dave WA1JHK < wa1jhk@...> wrote:
Hi Skip,
> Do we still need Doug Hall support?? If so we will need level converters for that interface.? Personally I'd like to drop it, I don't have any way to test it.
I wrote the Doug Hall RBI-1 firmware support for the S-COM 7K controller.? I still get requests for RBI support on the S-COM 7330 -- I'm in the middle of implementing that now.? I have an RBI and radios to test with.? I don't have an Xcat and radio, though I'm sure we can fix that.
Will the USB connector on the Pico replace the serial port?
BTW, there's both a MicroPython (the original) and CircuitPython (supported by Adafruit).
73,
? Dave
On 8/8/2022 9:22 AM, Skip Hansen wrote:
Good morning Dave!
Thank you for volunteering !!!?
The C64 Rom project is very close to what we need, you can find the schematic here: .?
The schematic for the original Xcat is here:?/g/xcat/files/XCat%20files/xcat-schematic.PDF.?
I'll get started on generating a new schematic.
So questions for all that are interested:
Do we still need RS232 level converters for the serial port?? My opinion is NO, 3v3 levels and an FTDI USB cable for a PC connection.
Do we still need Doug Hall support?? If so we will need level converters for that interface.? Personally I'd like to drop it, I don't have any way to test it.
What did we miss on the original Xcat that we can add now?? One request I remember is support for 64 modes, that should be no problem for the new board.
My idea for the Xcat 2022 is for it to be a completely open source project including the firmware and PCB.?
If someone wants to build one themselves, great!
If someone wants to kit it up and sell a kit then have at it (it won't be me!).
If someone wants to sell built and tested boards more power to them (that wont be me either!).
73's Skip WB6YMH
|
This email has been checked for viruses by Avast antivirus software.
|
?
?
|
 Well this is exciting! Much appreciation for Skip and everyone else working together on this. ?+1 here for someone with Doug hall’ed xcats on the air who would really like to see support for that. I’d be happy to do any testing on the bench here.?
Cheers Sam
On Mon, Aug 8, 2022 at 8:22 AM, Skip Hansen < skip@...> wrote: Good morning Dave!
Thank you for volunteering !!!?
The C64 Rom project is very close to what we need, you can find the schematic here: .?
The schematic for the original Xcat is here:?.?
I'll get started on generating a new schematic.
So questions for all that are interested:
Do we still need RS232 level converters for the serial port?? My opinion is NO, 3v3 levels and an FTDI USB cable for a PC connection.
Do we still need Doug Hall support?? If so we will need level converters for that interface.? Personally I'd like to drop it, I don't have any way to test it.
What did we miss on the original Xcat that we can add now?? One request I remember is support for 64 modes, that should be no problem for the new board.
My idea for the Xcat 2022 is for it to be a completely open source project including the firmware and PCB.?
If someone wants to build one themselves, great!
If someone wants to kit it up and sell a kit then have at it (it won't be me!).
If someone wants to sell built and tested boards more power to them (that wont be me either!).
73's Skip WB6YMH
|
Hi Dave,
I would rather NOT use the USB serial port to simplify the wiring and to minimize high speed signals inside of the radio.? USB would be used to flash the board with the initial?flash image.??
Possible wiring options: 1. Route 3.3V Rxd, Txd via unused control cable pins or just drill a hole for a 3 pin cable. 2. Route 5V Doug Hall clock and data line via unused control cable pins or just drill a hole for a 3 pin cable.
For the Xcat-9000 another option would be to use SB9600 for communications and attach the Xcat2022 to the SB9600 bus internally.? ?No need to find unused control?cable poins or drill holes for a new cable.? I'm starting to like this...
Testng the Doug Hall interface should be easy even w/o a radio.? You would need one of your controllers connected to the new board and the original?XCat PC control program or a successor.? Frequencies set via the Doug Hall interface can be read back over CI-V.? If they are correct then we're good to go.
73's Skip WB6YMH
On Mon, Aug 8, 2022 at 11:41 AM Dave WA1JHK < wa1jhk@...> wrote:
Hi Skip,
> Do we still need Doug Hall support?? If so we will need
level converters for that interface.? Personally I'd like to
drop it, I don't have any way to test it.
I wrote the Doug Hall RBI-1 firmware support for the S-COM 7K
controller.? I still get requests for
RBI support on the S-COM 7330 -- I'm in the
middle of implementing that now.? I have an RBI and radios to
test with.? I don't have an Xcat and radio, though I'm sure we
can fix that.
Will the USB connector on the Pico replace the serial port?
BTW, there's both a MicroPython (the original) and CircuitPython
(supported by Adafruit).
73,
? Dave
On 8/8/2022 9:22 AM, Skip Hansen wrote:
Good morning Dave!
Thank you for volunteering !!!?
The C64 Rom project is very close to what we need, you can find
the schematic here: .?
The schematic for the original Xcat is here:?/g/xcat/files/XCat%20files/xcat-schematic.PDF.?
I'll get started on generating a new schematic.
So questions for all that are interested:
Do we still need RS232 level converters for the serial port?? My
opinion is NO, 3v3 levels and an FTDI USB cable for a PC
connection.
Do we still need Doug Hall support?? If so we will need level
converters for that interface.? Personally I'd like to drop it, I
don't have any way to test it.
What did we miss on the original Xcat that we can add now?? One
request I remember is support for 64 modes, that should be no
problem for the new board.
My idea for the Xcat 2022 is for it to be a completely open source
project including the firmware and PCB.?
If someone wants to build one themselves, great!
If someone wants to kit it up and sell a kit then have at it (it
won't be me!).
If someone wants to sell built and tested boards more power to
them (that wont be me either!).
73's Skip WB6YMH
|
|
This email has been checked for viruses by Avast antivirus software.
|
|
I am all for a "translator". I mentioned this elsewhere. What about the "09" control head? Are they useful? Cheap enough? Plentiful?
PMUN1045C
On Mon, Aug 8, 2022 at 03:04 PM, Joe M. wrote:
Would it be possible to use say a Spectra control head
or even an XTL CH and interface that with the X/9000?
I'm thinking have a CH that talks to the interface,
then the interface talks to whatever the radio is.
(IOW: a translater that uses the CH input
and programs the radio accordingly)
Some of those older CHs are dated and limited.
Joe M.
On 8/8/2022 2:55 PM, Dennis Boone wrote:
> So questions for all that are interested:
This wasn't exactly a question, but:
I'll point out that for the X, one of the very handy things about having
an Xcat is that you don't need to unbutton the radio to fish out its
code plug unit. Even if you're not doing VFO, it's a far easier reflash
over serial.
For either the X or the 9000, the "RSS" is a lot easier to interact
with, since it's not constrained to suitcase programmers, slow DOS
machines, weird text-file driven unix command line tools, etc.
What I'm roughly suggesting is that for both the Xcat-2022 and the
Xcat9000-2022, one potentially nice operating mode to preserve is "load
the code plug, then use the native control heads".
*asbestos suit*
De
|
@Joe,
Although they speak SB9600 structure and protocol, it's unlikely many (if any) of the actual command packets are the same for a given function. At least for a radio from the X9000's era.
?Acquiring enough knowledge to create a uC program to translate each command sent and received by both the radio and the head would be a true labor of love.
Interfacing an XTL or MCS2000 or other head via SB9600 to an emulating uC device like we are talking about is almost as intensive.
The concept is awesome, like you said the OEM heads are getting a hard to come by and more than a bit long in the tooth.
Since such translating would be processor intensive, it would sure be a good reason to unload the uC by way of using the state machine/DMA scheme Skip mentioned.
@ Casey,
?RE: VFO operation ideas....how is you mad scientist hat fitting today?........
|
@ Dennis,
?Since this isn't Newsgroups (are they even still around?) or some of those other forums, We need a sign that say "Asbestos PPE not required to operate here".
I do agree maintaining (and establishing for the X9000) a non RSS based PC program to access the emulator's codeplug data for maintenance purposes is a good idea.
|
My thoughts on this were to try to use an MCS2000 head translated to whatever format decided upon. They are about the only full keypad CH available in any numbers that are cheap and more advanced.
On Mon, Aug 8, 2022 at 2:04 PM Joe M. < mch@...> wrote: Would it be possible to use say a Spectra control head
or even an XTL CH and interface that with the X/9000?
I'm thinking have a CH that talks to the interface,
then the interface talks to whatever the radio is.
(IOW: a translater that uses the CH input
and programs the radio accordingly)
Some of those older CHs are dated and limited.
Joe M.
On 8/8/2022 2:55 PM, Dennis Boone wrote:
>? ?> So questions for all that are interested:
>
> This wasn't exactly a question, but:
>
> I'll point out that for the X, one of the very handy things about having
> an Xcat is that you don't need to unbutton the radio to fish out its
> code plug unit.? Even if you're not doing VFO, it's a far easier reflash
> over serial.
>
> For either the X or the 9000, the "RSS" is a lot easier to interact
> with, since it's not constrained to suitcase programmers, slow DOS
> machines, weird text-file driven unix command line tools, etc.
>
> What I'm roughly suggesting is that for both the Xcat-2022 and the
> Xcat9000-2022, one potentially nice operating mode to preserve is "load
> the code plug, then use the native control heads".
>
> *asbestos suit*
>
> De
>
>
>
>
>
>
|
I'm not against it and I thing it would be great.?
As a personal goal I would still like to pursue some verion of a project that is a full featured touch interface with front panel programming, VFO, scan, large alphanumeric names based on regular fonts with per channel PL/DCS programmability. Basically a low-band Yaesu type unit. These things are just too high performing RF wise not to be explited to the maximum, in my opinion. Of course, that leads to things becoming much more tedious, custimized, probably much more cost and custom?work. Probably more of a personal project.
Just getting a handle on the basic TX/RX and signalling controls of it is the key. From there the options are unlimited.
Just my thoughts anyway.
On Mon, Aug 8, 2022 at 1:55 PM Dennis Boone < drb@...> wrote: ?> So questions for all that are interested:
This wasn't exactly a question, but:
I'll point out that for the X, one of the very handy things about having
an Xcat is that you don't need to unbutton the radio to fish out its
code plug unit.? Even if you're not doing VFO, it's a far easier reflash
over serial.
For either the X or the 9000, the "RSS" is a lot easier to interact
with, since it's not constrained to suitcase programmers, slow DOS
machines, weird text-file driven unix command line tools, etc.
What I'm roughly suggesting is that for both the Xcat-2022 and the
Xcat9000-2022, one potentially nice operating mode to preserve is "load
the code plug, then use the native control heads".
*asbestos suit*
De
|
Re: Has anyone fully decoded the X9000 memory mapping?
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
|
Would it be possible to use say a Spectra control head
or even an XTL CH and interface that with the X/9000?
I'm thinking have a CH that talks to the interface,
then the interface talks to whatever the radio is.
(IOW: a translater that uses the CH input
and programs the radio accordingly)
Some of those older CHs are dated and limited.
Joe M.
toggle quoted message
Show quoted text
On 8/8/2022 2:55 PM, Dennis Boone wrote: > So questions for all that are interested:
This wasn't exactly a question, but:
I'll point out that for the X, one of the very handy things about having
an Xcat is that you don't need to unbutton the radio to fish out its
code plug unit. Even if you're not doing VFO, it's a far easier reflash
over serial.
For either the X or the 9000, the "RSS" is a lot easier to interact
with, since it's not constrained to suitcase programmers, slow DOS
machines, weird text-file driven unix command line tools, etc.
What I'm roughly suggesting is that for both the Xcat-2022 and the
Xcat9000-2022, one potentially nice operating mode to preserve is "load
the code plug, then use the native control heads".
*asbestos suit*
De
|
RFI-EMI-GUY