Let's make a closely MXT like detector!

[Carl-NC]

Even then, use an F-series chip that is reprogrammable and debuggable.

[KRinAZ]

Why would you want to use a C-series micro? They are OTP and non-debuggable. If you want to stick with PIC use a more modern chip with plenty of flash and MPLabX support.

Agreed 100%
This bit of the conversation - with any talk about a PIC or MPLab - is purely about the effort to get the code from the PIC16C76 from my MXT. Believe me, I am sold on using a modern micro for this project, and over in post #113 I cover my choice of STM32's for this project, and why I chose the ones I did. If I do ever mess around with PIC micros it would be with F (flash based) ones, but I don't see myself messing with PICs - other than trying to read code from them when the need arises - e.g. Altra's desire to get the code from the PIC in his CNC machine...but that is off topic for this thread...

The talk about the debugging capabilities of the PIC16Cxx only relates to an easier vs harder route to getting the code from the PIC (if possible) for potential use of code bits in this project.

Thanks for making this point - this project is STM32 based for sure, 100%, no worries, I already have a NUCLEO-F303K8 to use for the early breadboarding and prototyping for this project. The schematic and control board won't use a NUCLEO though, but a (currently) STM32F303K8T6 LQFP32 chip.

[KRinAZ]

Hi KRinAZ, can you tell us what your "fun tools" are? I have an old cnc machine controller that uses a pic18f. The company that made the controller has been out of business for at least 15 years. I would like to build a back up controller if I can dump the hex. Thanks

First a note - again - this project going forward will use a STM32 micro, the below is just for those who want to try to access the code burned into a PIC....

The tools that I was able to use to produce (disassembled from program memory) assembly code from a 16C family PIC (e.g. the code from the PIC16C76 in my MXT) are:
One of
PICStart Plus - beige p/n 10-00157 Revision 10 thru 19 (I have r10, had to burn another PIC17C44, then install it, to do a firmware upgrade) running v3.11.00 firmware (called Picstart Plus OS 3.11.00, included with MPLab IDE v5.7.4)
PICStart Plus - beige p/n 10-00157 Revision 20 thru 22 (better, can download firmware directly to update it)(should work? but I haven't tested)
PICStart Plus - black p/n 10-00379 any Revision (best, can also download firmware directly to update it)(should work? but I haven't tested)
no other programmer, or debugger, to my knowledge, will work

MPLab IDE v5.7.4 - (still accessible at Microchip site) which is ancient and requires true Win95 or Win95 emulation (Win98 is too new and doesn't work) via Win10x32 with NTDVM - but includes tools that are removed from later versions of the MPLab IDE (like outputting usable disassembled assembly code).
no other newer MPLab, to my knowledge, will work.

I have not yet found a way to copy out the binary code directly into a .hex file, but I believe the assembly code can produce a binary file if needed via MPLab...

[KRinAZ]

Well here it is - attached - the disassembled file of the PIC16C76 from my MXT - for your viewing pleasure. Has a column of the ascii of the binary, and a column of the PIC16Cxx assembly code - complete from memory location 0x0000 thru 0x1FFF - hoping someone can prep this with some regex magic and then turn the assembly into C.

Also, if the column with ascii representation of the binary was turned back into a binary 8k x 14 bit hex file it could be burned back to a PIC (I also have the configuration bits needed at burn time) - as Altra may find interesting for his CNC...off topic though...

[Altra]

Great work KR. Have you tried cloning and testing a new pic in the mxt? In my cnc controller it is a F series. Do you think it is readable also?

[KRinAZ]

Great work KR. Have you tried cloning and testing a new pic in the mxt? In my cnc controller it is a F series. Do you think it is readable also?

Thanks. MPLab also generated a .HEX file but it didn't appear to be a binary file, but I only glanced at it, so I still need to verify it is a ready to burn file. If so I'll burn one and see if it operates in my MXT. The PIC16C76's that I have on hand are SOIC-28's but my old version C MXT board takes a 28 pin DIP, so I'll also need to see if my SOIC to DIP adapter will fit into the MXT...

...and I think the F series would be easier to read than the C series chip...can you tell me specifically which PIC18Fxxx it has?

[Altra]

I am on the road until the beginning of June. So I can't check which pic processor I have. I'll pm you when I can get the number. It will be interesting to see what AI can do to generate a C listing from the assembly. Thanks

[KRinAZ]

I have verified that the .HEX file that MPLab generated is in fact a valid .HEX file that can be directly burned to a PIC. I have the soic-28 to dip adapter pcb's that I need on order, and as soon as they arrive (probably Fri 5/15) I will burn a PIC and put it in my MXT and test for functionality.

Assuming it works (I expect it will) I will begin converting the assembly into C as reference code for this project. BTW I'm old school and don't have AI tools so if anyone wants to run that assembly code thru Claude or something, that would be great!

Also in the background I'm chipping away at creating a complete component list, and will soon begin the schematic with a thought towards a build procedure document.

[Taktyk]

WOW! I see the original MXT schematic. I never thought I'd actually get to see it Back in the day, I even redrew the whole thing from the PCB. That said, a lot of the circuits in it are quite outdated now, so copying it 1:1 probably isn't worth it. Conceptually though, if you modernize all the stages especially the transmitter (the original runs with too little current) and a few other sections you could end up with a really solid, high-performance detector.

[Taktyk]

I have started slowly extracting and decompiling the original code from a raw factory ROM dump of the White's MXT (PIC16C76).
Using AI assistance, I am translating the raw assembly into clean, high-level C. So far, I have successfully extracted the core DSP logic (including the 17.5-bit oversampling, VDI phase calculations, ground balance IIR filter, and audio VCO).
You can check out my progress on GitHub:

https://github.com/takzen/whites-mxt...se-engineering

My plan is to go through all 112 functions one by one. I would love to hear your thoughts and collaborate with anyone interested!
Best regards,

[KRinAZ]

WOW! I see the original MXT schematic. I never thought I'd actually get to see it Back in the day, I even redrew the whole thing from the PCB. That said, a lot of the circuits in it are quite outdated now, so copying it 1:1 probably isn't worth it. Conceptually though, if you modernize all the stages especially the transmitter (the original runs with too little current) and a few other sections you could end up with a really solid, high-performance detector.

Understood, for this project the idea is to make a functioning (in the field) MXT like detector - as close to the orig as possible - to establish a high quality prototype. White's did a fantastic job making the MXT and I think re-making a functioning MXT will be enough of a challenge - so let's get to that point first. It's (to me) easier to figure why a mod degrades a functioning prototype, than to make a bunch of changes on paper, build it, then wonder what went wrong...

I for one have a number of fun mods in mind that would branch from the working prototype, but that is way down the road...

[KRinAZ]

I have started slowly extracting and decompiling the original code from a raw factory ROM dump of the White's MXT (PIC16C76).
Using AI assistance, I am translating the raw assembly into clean, high-level C. So far, I have successfully extracted the core DSP logic (including the 17.5-bit oversampling, VDI phase calculations, ground balance IIR filter, and audio VCO).
You can check out my progress on GitHub:

https://github.com/takzen/whites-mxt...se-engineering

My plan is to go through all 112 functions one by one. I would love to hear your thoughts and collaborate with anyone interested!
Best regards,

Nice job on the github project page!

I'll contribute where I can, you guys are ahead of me coding wise.

[KRinAZ]

I have started slowly extracting and decompiling the original code from a raw factory ROM dump of the White's MXT (PIC16C76).
Using AI assistance, I am translating the raw assembly into clean, high-level C. So far, I have successfully extracted the core DSP logic (including the 17.5-bit oversampling, VDI phase calculations, ground balance IIR filter, and audio VCO).
You can check out my progress on GitHub:

https://github.com/takzen/whites-mxt...se-engineering

My plan is to go through all 112 functions one by one. I would love to hear your thoughts and collaborate with anyone interested!
Best regards,

In case code is ever desired to be tested back in an original MXT, I have PIC16F76's that can be erased, reprogrammed, plugged into, and tested in my actual real MXT.

I have already burned the original .HEX file (with config and ID bits) into a PIC16C76 and PIC16F76 (both SOIC). I want to establish 2 things: I can burn the HEX file back into another PIC16C76 and have it operate as the original does (to prove the HEX file is true to the original), and assuming that - I can burn to a PIC16F76 and that it also operates as the original does. The PIC16F76 datasheet says it is pin compatible with the PIC16C76 so it apparently shouldn't matter if it's a C or F PIC, both should operate the same, but seeing it work is what proves it for me.

If amazon would ever get them to me (so much for their estimated delivery date of last week), I have SOIC to DIP adapters on the way. My early version MXT uses a DIP socketed PIC so I need the SOIC to DIP adapters to plug in the PICs that I programmed...

[Taktyk]

In case code is ever desired to be tested back in an original MXT, I have PIC16F76's that can be erased, reprogrammed, plugged into, and tested in my actual real MXT.

I have already burned the original .HEX file (with config and ID bits) into a PIC16C76 and PIC16F76 (both SOIC). I want to establish 2 things: I can burn the HEX file back into another PIC16C76 and have it operate as the original does (to prove the HEX file is true to the original), and assuming that - I can burn to a PIC16F76 and that it also operates as the original does. The PIC16F76 datasheet says it is pin compatible with the PIC16C76 so it apparently shouldn't matter if it's a C or F PIC, both should operate the same, but seeing it work is what proves it for me.

If amazon would ever get them to me (so much for their estimated delivery date of last week), I have SOIC to DIP adapters on the way. My early version MXT uses a DIP socketed PIC so I need the SOIC to DIP adapters to plug in the PICs that I programmed...

Yes, it's definitely worth confirming whether it works 100%, regardless of whether it's the C or F version. If it works, it means everything is fine and we can refine the semantic C code to make it easy to port to another platform, such as an STM32.

I think that once I finish translating this code - which isn't easy, as I'm already on my third refactoring; it can't be done all at once, only step by step, so it will take a while – we will be able to compile it, flash it to the PIC16F76, and see if everything works.

After that, we can choose an STM32, port the code over, and start experimenting with hardware changes - for example, a different, more efficient TX method or a better ADC, like an 18-bit SAR.