How fast do you want it to scan? My old PRO-2006 is still plenty fast and capable with a few Bill Cheek's mods.
View attachment 273231
https://wiki.radioreference.com/index.php/Pro-2006
http://www.wentztech.com/radio/Equipment/Pro2006/pro2006mods.html

6400 channel memory capacity

I wasnt complaining about the scan speed, I was making a point that the speed is possibly low enough so that a PIC's internal memory can be used and controlled.

Yeah nice links, Bill's mods were famous in the 80s. I think the 2006 is a great scanner and I have had many including the AOR5000+ but I am just trying to revive the 2006 as its user interface is so good and simple just as a fun project if I get the time.

 

Do you know what data the scanner puts in the ram? Horrible idea: remove the ram and have it be an output port from some
micro (PIC?). When the scanner reads it you supply the data for the (next?) channel to scan using the address lines
provided by the scanner to decide which channel data to present.

No, I dont, that is something I need to investigate but besides channel and frequency, there is Modulation, channel spacing, delay etc stored.
That is the basic idea but it is a little more complex than that mainly due to the timing of reading and writing.

 

I wasnt complaining about the scan speed, I was making a point that the speed is possibly low enough so that a PIC's internal memory can be used and controlled.

Yeah nice links, Bill's mods were famous in the 80s. I think the 2006 is a great scanner and I have had many including the AOR5000+ but I am just trying to revive the 2006 as its user interface is so good and simple just as a fun project if I get the time.

A 8-bit PIC could emulate/decode the SRAM for the internal controllers but it's likely NOT to be very fast with either function.
https://forum.allaboutcircuits.com/threads/memio-emulator-for-z80.117003/post-916798

I would use at least a 32-bit processor for snooping the bus to handle full speed memory cycle times.
http://www.radiomanual.info/schemi/Surplus_Radioamateur/Realistic_PRO-2006_serv_4.0.pdf

or design a complete digital replacement like this.
http://www.scancat.com/ctlg-os.html
http://www.radiomanual.info/schemi/Surplus_Radioamateur/Realistic_PRO-2006_serv_4.0.pdf

 

Thanks for the links
Interesting your memio project, so at 64MHz it can't hack it.

I guess one way would be to just tap into the keyboard and record & playback via the keyboard commands. Scancat gold was IMHO such a nasty piece of software even when it worked back in the day.

This was an idea for a fun project, but it seems to be getting too complicated. It was an idea to revive the 2006. I have never worked with STM32. I already have two very sophisticated fully PC-controlled scanners. I may have to give up on this idea.

What about taking control of the existing RAM and handing it to a 46K22, i.e. let the original CPU deal with all other stuff and whenever it tries to access the RAM the PIC would take over and deal with the read & write only then back to the original cpu. That way the PIC would be interfaced to USB and can pass memory data?

 

Thanks for the links
Interesting your memio project, so at 64MHz it can't hack it.

I guess one way would be to just tap into the keyboard and record & playback via the keyboard commands. Scancat gold was IMHO such a nasty piece of software even when it worked back in the day.

This was an idea for a fun project, but it seems to be getting too complicated. It was an idea to revive the 2006. I have never worked with STM32. I already have two very sophisticated fully PC-controlled scanners. I may have to give up on this idea.

What about taking control of the existing RAM and handing it to a 46K22, i.e. let the original CPU deal with all other stuff and whenever it tries to access the RAM the PIC would take over and deal with the read & write only then back to the original cpu. That way the PIC would be interfaced to USB and can pass memory data?

Designing and debugging a co-processor system hack wouldn't be easy or fun IMO. The PIC18 architecture just wasn't designed for that sort of stuff. Sometimes it's best to keep it original in a world where Trunked Radio tracking SDR scanners are cheap.

 

I guess you are right...
Thank you for your input.

 

I guess you are right...
Thank you for your input.

This sounds like the perfect problem for an FPGA. An Artix-7 could easily handle the task. The PC interface could be a high speed UART/USB connection. The data could literally be stored in the FPGA block RAM. The FPGA fabric could easily handle keeping up with all data written to / read from the scanner. You could also instantiate a processor in the FPGA if needed. A lot of design work, but an FPGA seems more suitable for this task. I used an FPGA Artix-7 module in the past so you don't have to create a PCB. The Digilent CMOD A7 module would work well for this type of application and it includes a USB programming port for Vivado along with a built in USB/UART channel for PC communications.

 

@dcbingaman I am sure an FPGA would have no problem doing the job. I on the other hand wouldnt have a clue how to program it and I am a bit past the learning FPGA mode. I can just about handle the MCU and PC software as I only do programming as and when needed.
I am just a bit surprised that a new PIC couldn't replace the original CPU, or maybe I misunderstood that. In any case, it all seems too much work to be fun anymore, I will just have to find another project.

 

Just a (last) thought, PIC18F46K22 has a 3896 byte SRAM, can that not be used as a replacement for the external SRAM? Again you have to remember the scanner only does 26 channels per second.
Cant remember if the SRAM on a PIC is non-volatile memory.

 

Just a (last) thought, PIC18F46K22 has a 3896 byte SRAM, can that not be used as a replacement for the external SRAM? Again you have to remember the scanner only does 26 channels per second.
Cant remember if the SRAM on a PIC is non-volatile memory.

If I understand correctly:
- You want to have another 'SRAM' that the scanner can write to just like the other 'SRAM'?

or

- You want to monitor when the scanner is reading from a specific location in the SRAM and identify the channel associated with it?

Can you elaborate some? I have a feeling I am not understanding the actual goal? I agree the scanning is rather slow at 26 channels per second. A PIC will not have an issue with that. I think where the issue comes in is the fact that the address bus and data bus have a read and write strobe and the data is only present during the read/write strobe to memory. That could be handled by simply latching the data into a register (or set of registers if you need both the address and the data) using say a SN74HC377N 8 bit register. You may need more than one to cover all the address bytes and data bytes. The data would be latched on the rising/falling edge of the read or write strobe from memory. Then you could send the read/write strobe to one of the digital inputs of the PIC and have the PIC call an interrupt routine upon the rising/falling edge, read the data from the registers and do whatever you need at that point. I think this is what you want to do?

 

Or the 74HC165 parallel to serial for fewer PIC pins used (or 74HCT165 for TTL logic levels?).

 

Or the 74HC165 parallel to serial for fewer PIC pins used (or 74HCT165 for TTL logic levels?).

Another possibility might be to just use a small CPLD like the Xilinx XC9572 or similar. You don't need to write it in VHDL/Verilog, there is tools that will take a digital schematic and convert it into a bin file for the CPLD. This way you only need one 44 TQFP instead of a bunch of DIP packages.

 

@michael8 throwing another conversion in the mix will just make things slower. I am not so much worried about the number of wires.

@dcbingaman my opening thread kind of explains it but if not, here is a brief-ish run at it, in summary:

1 - The idea was to add text to each channel on an external LCD display
2 - To use the same PIC that controls the LCD display to facilitate USB control of the scanner
3 - To possibly use the internal memory of the PIC (SRAM) if it is non-volatile or EEPROM to store the channels (replacing the scanner's SRAM that needs battery back up.

Old but a very good scanner from the mid-80s. Has 400 channels that only display the frequency, it can get difficult to remember what service each channel is. New scanners can tag some text to each channel as a reminder and have PC interface so that you can see the status of the scanner and can fully control it.

A - The PIC either can passively monitor the address & data lines and set up its own memory/channel & text tag and put it on the external LCD every time the scanner stops on an active channel.

B - Or can the scanner's SRAM be replaced with the PICs internal memory SRAM or EEPROM

So as you say in your post, monitor and latch with a 10-bit latch and 8-bit latch for the data, PIC reads and stores the content of the channels. An app on the PC is used to control the scanner via the PIC and add text tags to the channel.

I dont see the original scanner cpu servicing its SRAM at its maximum speed of 15-20nS, the cpu has loads of stuff to do and therefore it is rather slow due to the massive amount of serial data that the PLL chip in the scanner requires for each channel, hence the slow 26 channel per second.

A simpler way would be just to interface fully with the keyboard of the scanner and just get the PIC to record what is keyed into the memory.

Hope that makes sense.

Excellent ideas re FPGA and CPLD but they are just too much for me, I dont want to be spending too much time on this, as it is, I need to do the electronics, the firmware and the PC side app - with all the possible complication its already tipping to the decision to 'No'!