开云体育

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've made a bit more discovery on the codeplug PL data

@ 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.

I'm still not out of ideas for work arounds, but if the codeplug is

@ 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.

@ Skip,
I'm making up a Digikey order list.
I've got other non X9000 related stuff to get, so I figured to make one "complete as possible" order and save on shipping.

I am presuming your KiCad files are general/draft at this point, and actual board design and layout is still undefined.

The reason I mention this is that the SN74LV244APW is a TSSOP package with a finer pitch over the pinout equivalant, wider pitched SN74LV244ADW in the SOIC package.
At this pincount, density of the SOIC is 2x a PDIP, where the TSSOP is 4x the density of a PDIP package.

There does not appear to be a PDIP equivalant for the SOIC packaged SN74LV02. LS yes, LV no.

The SN65176BP appears to be a thru hole PDIP. I socket all PDIPs if possible.

The BSS138 are SMT but the solder points are far enough apart and shouldnt be an issue either. The BS170 appears to be the thru hole equivelant but NA at Dighkey. Jameco has plenty but if that's all that was ordered, min shipping would not be worth it

You didnt call out the Schottky feeding the VSYS but a thru hole device that may be usable is the 1N5820.

The pullups and bypasses I'd like to see in thru hole as well.

Also, did you intend to use a bypass cap on the SN65176BP?

J3 appears to be a 2x6 IDC (male?) headr connector like/similar to the one used on the Xcat.

Rather than task the original EEPROM socket's Vcc point with supplying the new assy, I would recommend a different feedpoint via a (1x2 or more) IDC connector dedicated and bypassed for power.
Space permitting, the "or more" to be unused pins for potential future "flying connection" board interconnect(s).
The 5v feed would be from a (TBD) source on the personality board via "flying lead(s)".

Given the ability, I would also make the Pico "pluggable" on pins.
If there is (ever) a problem, it would make for easier diagnostics, repair and/or replacement.

The Pico's 133mhz clock may require sheilding/RF bypassing and being "on pins" may help to easily add this to the design if needed.

So far Digikey has everything I as looking to order, but my list is not complete

@ Skip,
That definately sounds revolutionary. As you might guess that creates a number of followup queries.
I am looking forward to hearing your POC testing criteria and results..

Control, as in a subtitute/replacement for PC based OEM RSS for block writes to the EEPROM (RSS emulation) and/or byte level writes equating to a form of direct EEPROM writes to effect FPP freq/PL control?

I did see EEPROM block writes by emulating RSS on a non PC platform comming.
I never gave thought to byte level writes using SB9600. I allways perceived it as a"write complete codeplug data to EPROM" routine.

Some are hoping for a replacement for the CH.
Mastering the SB9600 could lead to that as well, or at least enhancing some of it's operations.

Presuming the CH is retained, I guess another step would be to be able to re-program mode/MPL names in it as well with the same SB9600 setup.

With client side HW to be "almost anything with a serial port", depending on the complexity of th UI, that should put minimalist builds of the 16F8s, ATMega328s, etc back in the running.

Low GPIO count adds the ATTiny stuff to the list as well.

Actually since we are literally talking "outside the box" now, that brings us back to a closer look at the ESP32 w/built in 2.4g WiFi potential.

Not to mention the matter of a UI open to a variety of display and data entry configurations.
Beyond a basic UI, users could, if desired, develop a custon UI that fits their needs. Probably not as easy as building a Winamp "skin", but doable nontheless.

I do have a couple of those RIB clones.I have no complaints with them. Issues I've had using them was user error.
I checked Ebay and it looks like they are still in the 20-30 dollar range.

I know there is still much TBD, but I admit this has the potential to open a bunch of doors.
My mad scientist hat is beginning to smolder....

It is hard to think about giving up on a good old-fashioned hardware hack though....