Hi Dennis,

I was trying to describe what the legacy Xcat does. Other than where
we are limited by lack of pins (Doug Hall UF output primarily) Xcat NG
will have all of the functionality of the legacy Xcat.

Skip

I thought about that too. At 4 buck a pop, there's your I/O expansion in spades...still have the level traslation HW to factor in, but the new tech is made y the milineal era for the milineal era.
I take solice in the fact that one day they too will know what's it's like to be osoleted....lol

Sound like you earned some stress relief time.
At least you know the money wasnt wasted on something that doesnt work.
There's always tomorrow..........

I'm able to edit the hex of the codeplug then update it and change the receive frequency using your calculator's figures. I verified it with an MT1000 10 meter handheld. I do think it needs a mode change to force a refresh though but I need to verify that yet. I'm tired.?

It likes the uhf codeplug from that website. I'm going to go back and try yours again now to be sure it doesn't like it.

IT WORKS!!! I GOT IT!

It supports 2k up to 256k.
Here is the free software. You can import a file without it connected and check out some of the menus.?


At one point I did see it running through addresses when using the Watch mode but the radio didn't like it. I haven't been able to get back to that happening again yet.?

Here's the web page for it.

Site say it will support a 2k chip so it should work w/original configuration

Yea I tried the different combinations just to be sure.

Nah, you cant take anything off the beginning. It screws up all the zeropage pointers and static data starting point in memory.

Yeah, What Dennis said.
?Is it an 8k or more device??
Did I see it goes up to 28256? I'll look at the site but yeah, you might have to do some reconfig to match that to the radio. Does it say it has a config for 2k?
You'll have to config the socket for to it or lot's of stuff wont match.
Can you publish the docs?

It's like the ribbon cable is put on the 28 pin DIP plug upside down. The top of the device says pin1 - red stripe. I can use a multimeter at the ends of the ribbon cable where a litte bit of the inner conductor is exposed and it's showing continuity to what is actually pin 28.?

WTF

When the device is placed as they seem to describe (2 pins over the

> edge for 2k) then the emulator loses power.

You've combined the emulator instructions about positioning with the
positioning in which the radio expects the 2k vs 8k ROMs to be
installed?

De

I actually noticed that as well and did some trimming. Nothing I do works. When the device is placed as they seem to describe (2 pins over the edge for 2k) then the emulator loses power. It comes back on line if I remove the 2k jumper. I'm thinking this thing isn't going to work for this application, sadly.?

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.

It's also possible to shove a whole code plug mode line (or a whole
plug) into the Xcat. I'd really like that feature to stay.

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

The Pico is an open source design. We _could_ import its schematic, add
our translators and such, and lay out the result. I mean, it's a whole
tree full, and a bunch of shiny baubles on top, but it's end up being
neater than just stapling two boards together, _and_ would let us have
the extra GPIOs easily, _and_ we could eliminate any hardware we don't
need.

De

Attached is one.

The plugs I read the other day all start with 0x1f 0xff, or 0x07 0xff.
This one has a leading 0x00.

The serial number field is consistently 10 characters, and there are
four characters after that before the end of the ROM.

The length of this file is 8908 bytes, but an actual ROM dump is 8192.

I suggest you trim one leading byte and 715 trailing bytes from this
file to see if you get a code plug the radio will eat.

De

Thanks for doing that. I'll try it and let you know.?

@ Casey,
Here's a stab at it. Lowband 10m + 6m + some various PLs you can disect what/where/how in you HE program.

The .rdt, I had to trim.
R8.01 CP's are 513 longer, I thought it was 512 or 511 but nothing added up...(cant find my damned notes,,,).

I just trimmed it to same length as a CP I had made w/R5.x Your RSS *should* load it. RSS is picky about the file size.

The .bin is trimmed to 2k 2048 bytes and I would presume correct for your new toy.

开云体育

Hi Skip,

To prevent data changes during an address change, you could queue up commanded changes to be made after the next address change during the address-to-data setup time.

73,

? Dave
? WA1JHK

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:

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.