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
- Xcat
- Messages
Search
|
Re: XCat NG changes
On Tue, Aug 9, 2022 at 5:12 PM swguest via groups.io
<swguest@...> wrote: The way the legacy Xcat worked was that all frequency / PL / scan list changes just updated RAM for the special "VFO" mode (mode 1). A separate (custom) command could store the current contents of the VFO (mode 1) into a specified mode. That's the only time flash was written. When the radio was used as a remote base via standard CI-V commands or Doug Hall control nothing was ever written to flash. On the plain X there wasn't any kind of checksum on the code plug. The setting the VFO set the RX frequency, the TX frequency was also set by adding a signed TX offset value to the specified receive frequency. Doug Hall is a thing for remote base people, it's supported by lots of controllers. Personally I never used it, my controllers were all DIY and I found serial much easier to deal with. There's a fair number of people using Xcats with Asterisk/AllStar systems for remote bases and AFAIK they all use CI-V. All of the pins are used, too bad the Pico PCB didn't bring out all the rest of the GPIO lines (4) that would have made things a bit less tight. There's I2C GPIO expansion ports, but they are only good for slow signals. With all of the level converters and pin limitations updating the technology is certainly ADDING complexity and chip count... that's not how it's supposed to work! 73's Skip WB6YMH If the code is there, accessory design TBD. |
|
Re: Has anyone fully decoded the X9000 memory mapping?
I don't care what's in it. One mode is fine. I had the pins offset wrong. You have to hang 4 over the edge for a 2k eeprom. It now shows fail 01/82 which is a bit of progress. I don't have a floppy and and my usb to floppy drive setup now so I can't get the original codeplug or one made or read from this radio from the programming computer right now but I do have some from others. Attached is one. On Tue, Aug 9, 2022 at 6:23 PM swguest via <swguest=[email protected]> wrote: Hmmm..odd that it didnt complain about a 9k but did about a 2k. being 2048 byte but trimmed to 0-2047 in you hex editor. |
|
Re: XCat NG changes
I'm thinking the data update write to EEPROM is going to be (relatively) slower than a mirror copy to RAM. |
|
Re: Has anyone fully decoded the X9000 memory mapping?
Hmmm..odd that it didnt complain about a 9k but did about a 2k. being 2048 byte but trimmed to 0-2047 in you hex editor.
Well you know it does something. The radio may have hung on the fact that the byte id is set for UHF. I dont know why you 2k LB is failing. Try putting the full 9k LB file in the emulator. If that fails I'll make one and post it. What do you want in it. 10m 6m and w/ some slaved PLs? |
|
Re: XCat NG changes
My plan is to have an area in RAM that mirrors the EEPROM data. The
PIO state machine would DMA data from the RAM buffer to the GPIO pins automagically. The CPU would have nothing to do except montor the serial port for commands (CI-V or SB9600). If a command came in that modified the VFO it would just update the bytes in RAM. No need to stop the state machine, if the Syntor happens to read at the exact microsecond it might get inconsistent data, but that's no worse than no data if the state machine were stopped. The reason for only updating the data output on address change was just to optimize the response time... probably something that's not even needed. I don't like losing functionality that the legacy Xcat has, but I have no idea if anyone ever used it or now (Doug Hall "user functions" primarily). I put a digital pot in my 2 meter radio for squelch. I tested it with the PC control program, but I never really used it for lack of control system support. "Back in the day" there were WAY more than a few trips to the hill to tighten or loosen 2 meter and 6 meter squelches! 73's Skip WB6YMH On Tue, Aug 9, 2022 at 3:35 PM swguest via groups.io <swguest@...> wrote:
|
|
Re: Has anyone fully decoded the X9000 memory mapping?
No joy yet. It loaded up the uhf file off the web site and the software?didn't complain. I was able to transfer it to the device's RAM and verify and it was happy. However, the radio just stays on SELF CHECK. I tried trimming one of my codeplugs but whatever I did was not correct as the Romulator did not like it. On Tue, Aug 9, 2022 at 3:58 PM swguest via <swguest=[email protected]> wrote: Not directly. |
|
Re: Has anyone fully decoded the X9000 memory mapping?
Mine is 6.00SP so it's old. On Tue, Aug 9, 2022 at 4:44 PM swguest via <swguest=[email protected]> wrote: Just curious.? R8.01 runs is a cmd window without griping. Keep me from having to mess w/the NEC..............which |
|
Re: XCat NG changes
No, I get it. That's what I was thinking. I like that design too, once I mulled it over a bit....ala KISS.
...that was part of the epifany. Why worry about addr change? Let it read the addr and write the data as fast as it wants or add some NOPs or equivalant. When the /CE does go low it might write the pins with the same data dozens of times before the CE is released. As long as the outputs dont "blink" ,should be no harm no foul. All the uC's I've seen overadvertize the I/O. Once you muddle thru the cant use this if that, avoid using the other when your doing something else...... Looks like the Pico is plenty fast to multiplex addr lines via latches or use a parallel to serial scheme but that increases parts count/complexity..there goes KISS. One thought is to mirror the codeplug data in RAM at boot time and serve the codeplug data from RAM. Probably helps speed a bit too, but mainly it will let PH II data manipulation occur in the EEPROM at will without interfering with the read operation, or serve a partial edit of frequency values. The last step of the data modification routune would be to pause the state machine, refresh the RAM with the new data and restart the state machine. Also, the radio is going to expect to read and calc the checksum first thing on it'd bootup. The emulator needs to online serving data before that. |
|
Re: XCat NG changes
The /CE input will be wired directly to a bus transceiver between the
bus and the Pico. The CPU won't be aware of /CE state. I may be overly optimistic, but the plan is for the PIO state machine to update data out everytime the address input changes. Going to extreme measures to save a pin. 73's Skip WB6YMH On Tue, Aug 9, 2022 at 2:46 PM swguest via groups.io <swguest@...> wrote:
|
|
Re: XCat NG changes
CE in?regard to what? On Tue, Aug 9, 2022 at 4:46 PM swguest via <swguest=[email protected]> wrote: I didnt se a /CE input. |
|
Re: Has anyone fully decoded the X9000 memory mapping?
Just curious.? R8.01 runs is a cmd window without griping. Keep me from having to mess w/the NEC..............which
I fired it up today after a long time down...the HDD spun up but the bios was trashed.... dead battery..........Had to find the C/H/S data and enter it in the bios to get 'er to boot.....WHEW! - thought it was a goner. Need to replace battery, Re-setting the bios is going to be a PITA after every powerdown. |
|
Re: Has anyone fully decoded the X9000 memory mapping?
I don't recall now. My IP rolled or VPN Pi tunnel?imploded or something and I can't get back to the home PC to check. It's some SP 128 mode version I think, or at least that's what I recall the folder being named. I thought it was version 6 something. On Tue, Aug 9, 2022 at 4:16 PM swguest via <swguest=[email protected]> wrote: There is a byte (lost dics) on zero page that identifys the band. |
|
Re: Has anyone fully decoded the X9000 memory mapping?
There is a byte (lost dics) on zero page that identifys the band.
I dont thinks the radio will implode, create a micro black hole and suck in the known universe but I'm reasonably sure it wont like it. I dont recall ever trying but I dont think the RSS will even allow a mismatch to get that far. All the divider data will be whack for a T71 so I have no idea what you will get. Do you have R8.01 of chprog? |
|
Re: Has anyone fully decoded the X9000 memory mapping?
Awesome, thanks! On Tue, Aug 9, 2022 at 3:58 PM swguest via <swguest=[email protected]> wrote: Not directly. |
to navigate to use esc to dismiss