Re: Has anyone fully decoded the X9000 memory mapping?
The HC11's are Spectra class and later, probably Maras and Max's, GM's etc too
This is a Hitachi HD 6301 or 03,? I'd have to peek at the board to say which, but yeah, I've got it ...let me look.
tThe X uses a Hiticihi uC too I believe....dont recall which on that either but it isnt the same as the 9000.
|
Re: Has anyone fully decoded the X9000 memory mapping?
De:
What is the exact part number? The NXP data sheet I found for the
M68HC11E says 0,256,512 or 768 bytes of RAM.
If anyone has the data sheet for the CPU please upload it to the files area.
73's Skip WB6YMH
toggle quoted message
Show quoted text
On Fri, Aug 5, 2022 at 11:26 AM Dennis Boone <drb@...> wrote:
> Anyway, that does make me wonder how much RAM is in the
> Hitachi. (I've got the .pdf, just got to look for it) Suffice it to
> say to remember the scan config of 64 possible mode to scan, for up
> to 64 modes, that's 8 bytes x 64 and all that data is
> mapped/referenced per mode in the Hitachi's RAM? WOW. That uC is a
> little more of a workhorse that I first suspected.
256 bytes on the CPU, and I didn't see any offboard.
De
|
Re: Has anyone fully decoded the X9000 memory mapping?
Anyway, that does make me wonder how much RAM is in the > Hitachi. (I've got the .pdf, just got to look for it) Suffice it to > say to remember the scan config of 64 possible mode to scan, for up > to 64 modes, that's 8 bytes x 64 and all that data is > mapped/referenced per mode in the Hitachi's RAM? WOW. That uC is a > little more of a workhorse that I first suspected. 256 bytes on the CPU, and I didn't see any offboard. De
|
Re: Has anyone fully decoded the X9000 memory mapping?
@ Skip,
Your just a Wiki demon aint ya.
Great work!
Now look what you did..........More squirrels, more shiny objects......lol
Looks like I know what I'll be doing the rest of the day.
|
Re: Has anyone fully decoded the X9000 memory mapping?
@ Mike/K5JR,
? Thanks for the input!
? AH...someone who's got the scoop...several times it sounds like. I know I read somewhere , maybe Mike B.'s site?,? what info is maintained by the unswitched 5v source, and yes remove the 12v main supply and it goes away.
There was also an issue w/the unswitched 5v source when swapping X, X9000 personality boards, but I think there was a workaround?.....Anyway, that does make me wonder how much RAM is in the Hitachi. (I've got the .pdf, just got to look for it) Suffice it to say to remember the scan config of 64 possible mode to scan, for up to 64 modes, that's 8 bytes x 64 and all that data is mapped/referenced per mode in the Hitachi's RAM? WOW. That uC is a little more of a workhorse that I first suspected.
I was thinking EEPROMS were 100k, but? even at 10k, that is 10 writes a day for over 2 1/2 years. That's a lot of re-configuring your scan list.
So you kill a byte in the scan list after a couple of years...eh, move it all to another mode location.
The real damage is the checksum byte locations. They change with every save of a codeplug that has just 1 bit altered.
@ Skip,
Yup, I saw those the last time I made a Digikey order and tossed one in the cart. Paying shipping anyway, WTH. That was my "Uh now I need to learn some Python" moment....and it's still in the anti-static bag.
It does look like a good candidate for Phase I, especially coupled with that dual source bus tranceiver.
Form factor, resources,speed and no internal 2,4 ghz radio. Any issues with the 133 Mhz clock TBD I guess.
The Aurduino C? code I was scrapping together was for the AT2560 based MiniMega. It is 5v totorant, but only 16 Mhz clock so may not be fast enough to decode addy and serve data without a more complex interface. Also would need an external 2.4 radio for wireless interface. Another TBD.
Reading should be pretty straight forward,
Writing/altering is going to be much more timing critical.
Another big concern is physical HW interface. TheX has a common connector to access the busses, not so easy for the X9000. It will have to come thru the EEPROM's DIP socket. Casey has some ideas, so do I, but we havent gotten around to sharing/critiquing them yet.
Yeah, C64, big fan. It stoled the show in it's day. Very advanced combination of HW for what it was.
So....guess I'm looking for a "MicoPython for Dummies" .pdf now..........
|
Re: Has anyone fully decoded the X9000 memory mapping?
I think there must be some separate SRAM to save user configurable scan and last used parameters that is held up by the unswitched A+ (regulated to 5V).
toggle quoted message
Show quoted text
On Fri, Aug 5, 2022 at 10:55 AM, Skip Hansen wrote:
EEPROMs have a limited number of write cycles, I doubt it would be
written to by a scan. I might be written to as a result of a user
input to save the last selected mode perhaps?
If you change modes and then power cycle the X9000 does it come up on
the last selected mode?
73's Skip WB6YMH
On Fri, Aug 5, 2022 at 7:51 AM swguest via groups.io
<swguest@...> wrote:
On Fri, Aug 5, 2022 at 06:50 AM, Casey Crane wrote:
I didn't think it was written during operation but then again where do user scan list edits reside?
Excellent point. if it isnt in RAM with the other config info, then is has to be in the codeplug.
Being in the RAM isnt likely. A mode change would overwrite the edited data with new data from the EEPROM about the selected mode's scan settings.
Easy check - make a read and save, edit a scan list then read and save again, then compare.
The NP scan list is a bit map array of the last 8 byte of the a modes byteset.
Also, if 03h and/or 04h have changed there was a checksum recalculation.
|
Re: Has anyone fully decoded the X9000 memory mapping?
I've added a *BUNCH* of links to the Wiki for projects using the
RP2040 for ROM/EPROM/EEPROM emulation.
73's Skip WB6YMH
toggle quoted message
Show quoted text
On Fri, Aug 5, 2022 at 8:40 AM Skip Hansen <skip@...> wrote:
Well I think I'm sold on the RP2040. I've been looking around and I
think I've found our design... Just substitute a Syntor X9000 for the
Commodore 64 !
.
And there's a better form factor than the Adafruit offering:
So no "intentional emitters" inside of the radio, just a serial port
like the Legacy Xcat. Externally it might be hooked to a ESP32 to
provide BT or WiFi connectivity to a control head.
Thoughts?
73's Skip
On Fri, Aug 5, 2022 at 7:52 AM Skip Hansen <skip@...> wrote:
Hi team Xcat2022!
I think I was wrong about using the standard FET bidirectional level
converter for the data bus. I've done some more reading and if we
drive the bus high it just looks like a pull up resistor, not an
active source so it should be fine.
Additionally I've been reading up on the rp2040 ... WOW it's
programmable IO is amazing. There is ZERO doubt it can keep up with
whatever timing the X 9000' s CPU throws at it. And more importantly
from a hobby standpoint I've never played with one before and it looks
like "FUN"...
Pi Picos are **IN STOCK** today for $4.00.
73's Skip WB6YMH
On Fri, Aug 5, 2022 at 7:35 AM swguest via groups.io
<swguest@...> wrote:
@ Dennis,
I doubt any new designs use 5v logic anymore...sign of the times.
Component support for the legacy stuff that is 5v is getting slim to obsolete/NLA a well.
I expect the STM family are a good line, I've never looked that way...too many other irons in the fire. I'll have to do a bit of research to see how they stack up.
@ Skip,
True. Addy and control lines are tied to GPIOs that can be put to Hi-Z by the uC they belong to. I completely missed that.
That is one nice collection of gates! It ticks all the boxes for a bus tranceiver. Are 24 pin SOIC breakout boards available?
As for non RSS writes, I wouldn't think so.
The unswitched 5v maintains last powered user config state like last mode, Prio1/Prio2 selections, man or scan state at last power down, probably some other stuff too...presumably stored in RAM in the Hitachi?
I suspect putting the radio thru some operational paces while monitoring the /WE would tell the tale.
That said, the config data held by the unswitched 5v might also be a clue as to how much of the EEPROM the uC reads on a manual mode change, and what may need to be written during a data modification operation.
For the purposes of normal operation mode, what exactly it looks for is not relevant since we will be providing a complete image of valid codeplug data via the emulating process.
I think a 2.4ghz radio external to the radio's case will be needed if you expect much signal.
Still not sure about how nicely the ESP32's 240 Mhz clock is going to play with the radio's internals.
Only one way to find these things out....
|
Re: Has anyone fully decoded the X9000 memory mapping?
I’m pretty sure that the User entered Scan/Prio, last used Mode info > is *not* stored in the EEPROM. For some of the trunking models of the X, at least, I'm quite sure that some "current radio parameters" _are_ stored in an EEPROM, and I'm pretty sure that it's the code plug EEPROM. That's not relevant to anything we're discussing here, but it suggests an interesting exploration of the design decisions needed for such radios. The choices for writable permament on-board storage were far more limited in the early to mid-80s than what we're used to now. If the device is rated for 10k writing cycles, then you could write it three times a day every day for 10 years. Would that be enough? Did Moto expect that the EEPROMs in such radios would need to be replaced during their intended service life? What was the intended service life? De
|
Re: Has anyone fully decoded the X9000 memory mapping?
I’m pretty sure that the User entered Scan/Prio, last used Mode info is *not* stored in the EEPROM. When 12v power is removed from the radio, those selections are forgotten and the User must re-enter every stinking one of them. I’ve been through it zillions of times due to removing radio power when extended parking is necessary. Rebuilding the P1/NP Scan lists for 128 Modes is a PITA.. The Spectra doesn’t lose it’s User enter scan lists when main power is removed.?
tnx Mike / K5JR? Alpharetta GA
toggle quoted message
Show quoted text
On Aug 5, 2022, at 10:51 AM, swguest via groups.io <swguest@...> wrote: ?On Fri, Aug 5, 2022 at 06:50 AM, Casey Crane wrote:
I didn't think it was written during operation but then again where do user scan list edits reside?
Excellent point.? if it isnt in RAM with the other config info, then is has to be in the codeplug.
Being in the RAM isnt likely. A mode change would overwrite the edited data with new data from the EEPROM about the selected mode's scan settings.
Easy check - make a read and save, edit a scan list then read and save again, then compare.
The NP scan list is a bit map array of the last 8 byte of the a modes byteset.
Also, if 03h and/or 04h have changed there was a checksum recalculation.
|
Re: Has anyone fully decoded the X9000 memory mapping?
Well I think I'm sold on the RP2040. I've been looking around and I
think I've found our design... Just substitute a Syntor X9000 for the
Commodore 64 !
.
And there's a better form factor than the Adafruit offering:
So no "intentional emitters" inside of the radio, just a serial port
like the Legacy Xcat. Externally it might be hooked to a ESP32 to
provide BT or WiFi connectivity to a control head.
Thoughts?
73's Skip
toggle quoted message
Show quoted text
On Fri, Aug 5, 2022 at 7:52 AM Skip Hansen <skip@...> wrote:
Hi team Xcat2022!
I think I was wrong about using the standard FET bidirectional level
converter for the data bus. I've done some more reading and if we
drive the bus high it just looks like a pull up resistor, not an
active source so it should be fine.
Additionally I've been reading up on the rp2040 ... WOW it's
programmable IO is amazing. There is ZERO doubt it can keep up with
whatever timing the X 9000' s CPU throws at it. And more importantly
from a hobby standpoint I've never played with one before and it looks
like "FUN"...
Pi Picos are **IN STOCK** today for $4.00.
73's Skip WB6YMH
On Fri, Aug 5, 2022 at 7:35 AM swguest via groups.io
<swguest@...> wrote:
@ Dennis,
I doubt any new designs use 5v logic anymore...sign of the times.
Component support for the legacy stuff that is 5v is getting slim to obsolete/NLA a well.
I expect the STM family are a good line, I've never looked that way...too many other irons in the fire. I'll have to do a bit of research to see how they stack up.
@ Skip,
True. Addy and control lines are tied to GPIOs that can be put to Hi-Z by the uC they belong to. I completely missed that.
That is one nice collection of gates! It ticks all the boxes for a bus tranceiver. Are 24 pin SOIC breakout boards available?
As for non RSS writes, I wouldn't think so.
The unswitched 5v maintains last powered user config state like last mode, Prio1/Prio2 selections, man or scan state at last power down, probably some other stuff too...presumably stored in RAM in the Hitachi?
I suspect putting the radio thru some operational paces while monitoring the /WE would tell the tale.
That said, the config data held by the unswitched 5v might also be a clue as to how much of the EEPROM the uC reads on a manual mode change, and what may need to be written during a data modification operation.
For the purposes of normal operation mode, what exactly it looks for is not relevant since we will be providing a complete image of valid codeplug data via the emulating process.
I think a 2.4ghz radio external to the radio's case will be needed if you expect much signal.
Still not sure about how nicely the ESP32's 240 Mhz clock is going to play with the radio's internals.
Only one way to find these things out....
|
Re: Has anyone fully decoded the X9000 memory mapping?
No it doesn't so you are probably correct. My eeprom indicates it has a 10k write cycle life according to the seek data sheet.
That seens to eliminate user initiated write cycles.?
On Fri, Aug 5, 2022, 09:55 Skip Hansen < skip@...> wrote: EEPROMs have a limited number of write cycles, I doubt it would be
written to by a scan.? I might be written to as a result of a user
input to save the last selected mode perhaps?
If you change modes and then power cycle the X9000 does it come up on
the last selected mode?
73's Skip WB6YMH
On Fri, Aug 5, 2022 at 7:51 AM swguest via
<swguest=[email protected]> wrote:
>
> On Fri, Aug 5, 2022 at 06:50 AM, Casey Crane wrote:
>
> I didn't think it was written during operation but then again where do user scan list edits reside?
>
> Excellent point.? if it isnt in RAM with the other config info, then is has to be in the codeplug.
> Being in the RAM isnt likely. A mode change would overwrite the edited data with new data from the EEPROM about the selected mode's scan settings.
> Easy check - make a read and save, edit a scan list then read and save again, then compare.
> The NP scan list is a bit map array of the last 8 byte of the a modes byteset.
> Also, if 03h and/or 04h have changed there was a checksum recalculation.
>
>
|
Re: Has anyone fully decoded the X9000 memory mapping?
EEPROMs have a limited number of write cycles, I doubt it would be written to by a scan. I might be written to as a result of a user input to save the last selected mode perhaps? If you change modes and then power cycle the X9000 does it come up on the last selected mode? 73's Skip WB6YMH On Fri, Aug 5, 2022 at 7:51 AM swguest via groups.io <swguest@...> wrote:
On Fri, Aug 5, 2022 at 06:50 AM, Casey Crane wrote:
I didn't think it was written during operation but then again where do user scan list edits reside?
Excellent point. if it isnt in RAM with the other config info, then is has to be in the codeplug.
Being in the RAM isnt likely. A mode change would overwrite the edited data with new data from the EEPROM about the selected mode's scan settings.
Easy check - make a read and save, edit a scan list then read and save again, then compare.
The NP scan list is a bit map array of the last 8 byte of the a modes byteset.
Also, if 03h and/or 04h have changed there was a checksum recalculation.
|
Re: Has anyone fully decoded the X9000 memory mapping?
Hi team Xcat2022! I think I was wrong about using the standard FET bidirectional level converter for the data bus. I've done some more reading and if we drive the bus high it just looks like a pull up resistor, not an active source so it should be fine. Additionally I've been reading up on the rp2040 ... WOW it's programmable IO is amazing. There is ZERO doubt it can keep up with whatever timing the X 9000' s CPU throws at it. And more importantly from a hobby standpoint I've never played with one before and it looks like "FUN"... Pi Picos are **IN STOCK** today for $4.00. 73's Skip WB6YMH On Fri, Aug 5, 2022 at 7:35 AM swguest via groups.io <swguest@...> wrote:
@ Dennis,
I doubt any new designs use 5v logic anymore...sign of the times.
Component support for the legacy stuff that is 5v is getting slim to obsolete/NLA a well.
I expect the STM family are a good line, I've never looked that way...too many other irons in the fire. I'll have to do a bit of research to see how they stack up.
@ Skip,
True. Addy and control lines are tied to GPIOs that can be put to Hi-Z by the uC they belong to. I completely missed that.
That is one nice collection of gates! It ticks all the boxes for a bus tranceiver. Are 24 pin SOIC breakout boards available?
As for non RSS writes, I wouldn't think so.
The unswitched 5v maintains last powered user config state like last mode, Prio1/Prio2 selections, man or scan state at last power down, probably some other stuff too...presumably stored in RAM in the Hitachi?
I suspect putting the radio thru some operational paces while monitoring the /WE would tell the tale.
That said, the config data held by the unswitched 5v might also be a clue as to how much of the EEPROM the uC reads on a manual mode change, and what may need to be written during a data modification operation.
For the purposes of normal operation mode, what exactly it looks for is not relevant since we will be providing a complete image of valid codeplug data via the emulating process.
I think a 2.4ghz radio external to the radio's case will be needed if you expect much signal.
Still not sure about how nicely the ESP32's 240 Mhz clock is going to play with the radio's internals.
Only one way to find these things out....
|
Re: Has anyone fully decoded the X9000 memory mapping?
On Fri, Aug 5, 2022 at 06:50 AM, Casey Crane wrote:
I didn't think it was written during operation but then again where do user scan list edits reside?
Excellent point.? if it isnt in RAM with the other config info, then is has to be in the codeplug.
Being in the RAM isnt likely. A mode change would overwrite the edited data with new data from the EEPROM about the selected mode's scan settings.
Easy check - make a read and save, edit a scan list then read and save again, then compare.
The NP scan list is a bit map array of the last 8 byte of the a modes byteset.
Also, if 03h and/or 04h have changed there was a checksum recalculation.
|
Re: Has anyone fully decoded the X9000 memory mapping?
@ Dennis,
?I doubt any new designs use 5v logic anymore...sign of the times.
Component support for the legacy stuff that is 5v is getting slim to obsolete/NLA a well.
I expect the STM family are a good line, I've never looked that way...too many other irons in the fire. I'll have to do a bit of research to see how they stack up.
@ Skip,
True. Addy and control lines are tied to GPIOs that can be put to Hi-Z by the uC they belong to. I completely missed that.
That is one nice collection of gates! It ticks all the boxes for a bus tranceiver. Are 24 pin SOIC breakout boards available?
As for non RSS writes, I wouldn't think so.
The unswitched 5v maintains last powered user config state like last mode, Prio1/Prio2 selections, man or scan state at last power down, probably some other stuff too...presumably stored in RAM in the Hitachi?
I suspect putting the radio thru some operational paces while monitoring the /WE would tell the tale.
That said, the config data held by the unswitched 5v might also be a clue as to how much of the EEPROM the uC reads on a manual mode change, and what may need to be written during a data modification operation.
For the purposes of normal operation mode, what exactly it looks for is not relevant since we will be providing a complete image of valid codeplug data via the emulating process.
I think a 2.4ghz radio external to the radio's case will be needed if you expect much signal.
?
Still not sure about how nicely the ESP32's 240 Mhz clock is going to play with the radio's internals.
Only one way to find these things out....
|
Re: Has anyone fully decoded the X9000 memory mapping?
I didn't think it was written during operation but then again where do user scan list edits reside??
On Fri, Aug 5, 2022, 08:11 Skip Hansen < skip@...> wrote: The address lines, chip select and output enable could be just voltage
dividers since they are inputs to the emulator.? I don't think the
standard FET bidirectional voltage converter will work for the data
bus since it needs to be tristated when chip enable isn't active.? I
think a SN74LVCH8T245 would do the trick.
Big question:? Other than when the radio is programmed using RSS is
the "EEPROM" ever written?? If not that may simplify the hardware and
software design.
73's Skip WB6YMH
73's Skip
On Thu, Aug 4, 2022 at 8:27 PM Dennis Boone <drb@...> wrote:
>
>? > Wasnt to say it cant be done, just a consideration in HW design.Six
>? > of those would get a bit cumbersome in a final design but probably
>? > fine for prototyping/proof of concept work. A hand fab'd assy
>? > tailored to the rest of the layout would be best...maybe in the form
>? > of an ESP32 shield?
>
> As logistics and manufacturing have gotten problematic over the last
> couple of years, it seems like 5V capable things have faded faster than
> the newer 3.3V (or lower) designs.? In looking at some of these embedded
> board options, it's pretty clear that virtually none of them are 5V
> friendly.? It doesn't really matter what we pick, we're going to need
> level shifting.
>
> I wasn't proposing just using the Sparkfun boards, of course, though it
> might be the quickest way to do some development work.? But the concept
> called a shield or a cape, designed for whatever board we choose, seems
> viable.
>
> Stretch goal: I just looked at one of the "Black Pill" boards based on
> the STM32F401CE or similar chip.? The layout doesn't seem particularly
> complex.? I sort of half wonder if it might be possible to design and
> build a slightly larger board with the 'Pill circuitry and the level
> shifters all together.
>
> De
>
>
>
>
>
|
Re: Has anyone fully decoded the X9000 memory mapping?
The address lines, chip select and output enable could be just voltage
dividers since they are inputs to the emulator. I don't think the
standard FET bidirectional voltage converter will work for the data
bus since it needs to be tristated when chip enable isn't active. I
think a SN74LVCH8T245 would do the trick.
Big question: Other than when the radio is programmed using RSS is
the "EEPROM" ever written? If not that may simplify the hardware and
software design.
73's Skip WB6YMH
73's Skip
toggle quoted message
Show quoted text
On Thu, Aug 4, 2022 at 8:27 PM Dennis Boone <drb@...> wrote:
> Wasnt to say it cant be done, just a consideration in HW design.Six
> of those would get a bit cumbersome in a final design but probably
> fine for prototyping/proof of concept work. A hand fab'd assy
> tailored to the rest of the layout would be best...maybe in the form
> of an ESP32 shield?
As logistics and manufacturing have gotten problematic over the last
couple of years, it seems like 5V capable things have faded faster than
the newer 3.3V (or lower) designs. In looking at some of these embedded
board options, it's pretty clear that virtually none of them are 5V
friendly. It doesn't really matter what we pick, we're going to need
level shifting.
I wasn't proposing just using the Sparkfun boards, of course, though it
might be the quickest way to do some development work. But the concept
called a shield or a cape, designed for whatever board we choose, seems
viable.
Stretch goal: I just looked at one of the "Black Pill" boards based on
the STM32F401CE or similar chip. The layout doesn't seem particularly
complex. I sort of half wonder if it might be possible to design and
build a slightly larger board with the 'Pill circuitry and the level
shifters all together.
De
|
Re: Has anyone fully decoded the X9000 memory mapping?
Wasnt to say it cant be done, just a consideration in HW design.Six > of those would get a bit cumbersome in a final design but probably > fine for prototyping/proof of concept work. A hand fab'd assy > tailored to the rest of the layout would be best...maybe in the form > of an ESP32 shield? As logistics and manufacturing have gotten problematic over the last couple of years, it seems like 5V capable things have faded faster than the newer 3.3V (or lower) designs. In looking at some of these embedded board options, it's pretty clear that virtually none of them are 5V friendly. It doesn't really matter what we pick, we're going to need level shifting. I wasn't proposing just using the Sparkfun boards, of course, though it might be the quickest way to do some development work. But the concept called a shield or a cape, designed for whatever board we choose, seems viable. Stretch goal: I just looked at one of the "Black Pill" boards based on the STM32F401CE or similar chip. The layout doesn't seem particularly complex. I sort of half wonder if it might be possible to design and build a slightly larger board with the 'Pill circuitry and the level shifters all together. De
|
Re: Has anyone fully decoded the X9000 memory mapping?
@ Dennis
I bought some of those/similar off Amazon for another project I never got back to either....lol
Wasnt to say it cant be done, just a consideration in HW design.Six of those would get a bit cumbersome in a final design but probably fine for prototyping/proof of concept work. A hand fab'd assy tailored to the rest of the layout would be best...maybe in the form of an ESP32 shield?
I guess my higher concern is the extra RF (240mhz) that will be inside the shield, and how well the BT will work thru the shield and the radio case. Maybe it will matter maybe not. The only way to find out is to power one up, button every thing up and see.
I dont have any ESP stuff. Havent had the need to BT to or from anything so far.
....plus I'll have to level up to Python. Guess I'll add it to the bucket list...lol
Also, a correction? "HC05's are WiFi only AFAIK," should read "BT only"
Post editing would be a nice feature
|
Re: Has anyone fully decoded the X9000 memory mapping?
Skip nominated an ESP32. Blazing fast, lots of I/O, WiFi & BT > capable, inexpensive and readily available. > Also, not a 5v device. It would require 3V3 to 5v level converters > for evey I/O line to/from the host system. A bi-directional level shifter is literally a mosfet and two resistors. Here's a design that has four of 'em on a postage stamp: Pretty sure we could easily design and fab something small that provides enough of these shifters to get the job done for a pretty small price. De
|
RFI-EMI-GUY