Let's make a closely MXT like detector!

[boilcoil]

This AI is a sly one.
Interestingly, there were no compilation inconsistencies due to the unspecified "paging" for the programs in the second page, called by the main program -
call dsp_filter
call dsp_ground
call dsp_metrics ...
But since everything works, there is obviously no problem.

[Aziz]

The AI did all this whilst I was gardening ... its prepping the docs now.

The gardener is always the murderer. In this case to the secrets of the source/binary code.


BTW, regarding the averaging of the phases in the code.
Never average the phase angles. Do it in the I/Q part and average the I and Q parts. Than calculate the phase, when it is required.

Good job Paul!

[moodz]

This AI is a sly one.
Interestingly, there were no compilation inconsistencies due to the unspecified "paging" for the programs in the second page, called by the main program -
call dsp_filter
call dsp_ground
call dsp_metrics ...
But since everything works, there is obviously no problem.

this is what the AI said ...

[moodz]

The gardener is always the murderer. In this case to the secrets of the source/binary code.


BTW, regarding the averaging of the phases in the code.
Never average the phase angles. Do it in the I/Q part and average the I and Q parts. Than calculate the phase, when it is required.

Good job Paul!

[moodz]

[Taktyk]

The AI took maybe an hour to do this... I estimate a couple of months for an experienced engineer ( from scratch + debugging ).
The chip utilisation shows one super power of assembly code ...

The real question is: what exactly did the AI accomplish here? xDD

Because in my experience, the reality looked much less “magical” than the hype posts suggest.

Claude Code + Opus 4.7 could spend hours analyzing the firmware and still not fully understand everything. The model would return to difficult functions, create separate files for unresolved code, and iteratively refine its interpretations. Honestly, that behavior inspired much more confidence because it looked closer to actual reverse engineering.

Gemini Flash 3.5 and GPT5.5(codex), on the other hand, was extremely enthusiastic from the beginning. It spent hours generating refactors and claiming it had produced fully semantic C code. The problem appeared later when I started verifying the results carefully.

It turned out that:
- some functions did not even exist in the original assembly,
- some dependencies were completely invented,
- the model added its own logic,
- several interpretations looked plausible but had no grounding in the actual firmware.
This is the classic issue with current models:
they can generate extremely convincing local explanations and code, while globally hallucinating the architecture of the entire system.

That is why, for projects like this, raw intelligence is not enough. What matters just as much is whether the model has some form of “awareness of uncertainty”.

Ironically, I trust a model more when it: says “I do not fully understand this yet”, revisits difficult parts iteratively, marks uncertain functions and maintains multiple hypotheses,
than a model that very quickly claims it has completely reverse engineered an old embedded firmware system.

Recovered and semantically reconstructed code after many hours of analysis:
https://github.com/takzen/whites-mxt...src2/ram_map.h

[moodz]

The real question is: what exactly did the AI accomplish here? xDD

Because in my experience, the reality looked much less “magical” than the hype posts suggest.

Claude Code + Opus 4.7 could spend hours analyzing the firmware and still not fully understand everything. The model would return to difficult functions, create separate files for unresolved code, and iteratively refine its interpretations. Honestly, that behavior inspired much more confidence because it looked closer to actual reverse engineering.

Gemini Flash 3.5 and GPT5.5(codex), on the other hand, was extremely enthusiastic from the beginning. It spent hours generating refactors and claiming it had produced fully semantic C code. The problem appeared later when I started verifying the results carefully.

It turned out that:
- some functions did not even exist in the original assembly,
- some dependencies were completely invented,
- the model added its own logic,
- several interpretations looked plausible but had no grounding in the actual firmware.
This is the classic issue with current models:
they can generate extremely convincing local explanations and code, while globally hallucinating the architecture of the entire system.

That is why, for projects like this, raw intelligence is not enough. What matters just as much is whether the model has some form of “awareness of uncertainty”.

Ironically, I trust a model more when it: says “I do not fully understand this yet”, revisits difficult parts iteratively, marks uncertain functions and maintains multiple hypotheses,
than a model that very quickly claims it has completely reverse engineered an old embedded firmware system.

Recovered and semantically reconstructed code after many hours of analysis:
https://github.com/takzen/whites-mxt...src2/ram_map.h

Actually when I used to work ( LOL ) .... one of my engineering tasks was protecting intellectual property. If Garrett do own the whites IP rights then blatently putting up copies / reverse engineering the firmware is a violation of copyright and could result in a takedown notice to this forum at a minimum and something more threatening at worst. ( depending on jurisdiction firmware copyright can be 70 years + ).

I saw that you and others were doing ( presumably good work ) but you are still creating a derivative work ( by reverse engineering ) so you are back at my first statement above.

The AI claimed to have fully decoded and extracted everything the orignal code does .. this was trivial for the AI BUT again refer to my first statement. ( so I wont be publishing it here unless someone else cares to do it).
It did this by compiling the assembly code, running it in a simulator with code stubs that simulated all the inputs / ouputs ( like the adc, the pots, the swiches, the audio ) etc and seeing if it matched the behaviour from the schematic and the user manual. The AI looked into registers and memory in the simulator to figure out what was changing what ... this is an old hardware hacker method.

Unlike your commendable efforts I have only shown that there is an alternate path to achieve an outcome that does not involve reverse engineering the code but infers the required internal code from looking at the behaviour of the circuit, the signals at each pin and lastly reading the fine manual ( aka RTFM ) .. .that is the AI reading the manual ... not me.

You mention your analysis where claude etc spent hours determing the inner workings etc ... this is where context engineering comes into play.
My approach is to look at the schematic ... what is the circuit doing at each pin. What is the signal behvaviour at each pin. What is the code that could produce that behaviour or process that signal. Then read the user manual, what are the controls, the LCD display, the boot behaviour, the switch functions ( description of each ). What is the timing of all these signals. This is the context.

The most important part is to start generating code then run it through a compiler then a chip emulation ( cycle accurate ). Its not like there were no bugs ... there were quite a few ..particularly around interrupts. Then the AI changes the code ... runs the sim again etc. until the code runs in the sim with no errors and the timings / behaviours are all consistent.

There is no hype here .. the interface to any LLM seems to be "hypy" in nature. I am just reporting what it was reporting to me.

By doing a clean room build "the uncertainty" you mention is removed. Yes in the original firmware there are variables that are "uncertain what this does / is for". In hindsight there are no "magic" algorithms in the original code in fact there are quite a few shortcuts and space saving assembly kludges that were not needed since the code fits easily into the chip.

Could there still be bugs ... absolutely ! ... but I ( err the AI ) has only spent a couple of hours on it.

So to answer your question .. .what did the AI achieve here ? ... plenty !

See the full assembly source attached ...

[Aziz]

Hi all,

some words about AI and the so called "hype".

There is no hype in AI at all. Absolutely no. It is real.
It is a damn fnk real thing.

There won't be real investments in billions/trillions dollars if this would be a "hype".

If the AI says nonsense, it has learned nonsense. Because the internet & publications contain these nonsense.
But the AI is getting better and better.
It's the beginning.
We will say in 10 years still "it is the beginning".
And we will say this again in 20 years "it is the beginning..".

AI ain't being hype. And it is getting better and better.

[moodz]

Hi all,

some words about AI and the so called "hype".

There is no hype in AI at all. Absolutely no. It is real.
It is a damn fnk real thing.

There won't be real investments in billions/trillions dollars if this would be a "hype".

If the AI says nonsense, it has learned nonsense. Because the internet & publications contain these nonsense.
But the AI is getting better and better.
It's the beginning.
We will say in 10 years still "it is the beginning".
And we will say this again in 20 years "it is the beginning..".

AI ain't being hype. And it is getting better and better.

... bigger than the invention of the wheel IMHO

[Aziz]

And can you imagine, that 1 TB of data (it is a small hard disc), which contains 2 trillion parameter neural network (4-bit floating point number) contains the whole world knowledge and the processing scheme for the knowledge?
We are heading to the multi-trillion parameter networks. Faster and faster.

[Aziz]

... bigger than the invention of the wheel IMHO

This is a good underestimation.

It is much much more.

[Taktyk]

Actually when I used to work ( LOL ) .... one of my engineering tasks was protecting intellectual property. If Garrett do own the whites IP rights then blatently putting up copies / reverse engineering the firmware is a violation of copyright and could result in a takedown notice to this forum at a minimum and something more threatening at worst. ( depending on jurisdiction firmware copyright can be 70 years + ).

I saw that you and others were doing ( presumably good work ) but you are still creating a derivative work ( by reverse engineering ) so you are back at my first statement above.

The AI claimed to have fully decoded and extracted everything the orignal code does .. this was trivial for the AI BUT again refer to my first statement. ( so I wont be publishing it here unless someone else cares to do it).
It did this by compiling the assembly code, running it in a simulator with code stubs that simulated all the inputs / ouputs ( like the adc, the pots, the swiches, the audio ) etc and seeing if it matched the behaviour from the schematic and the user manual. The AI looked into registers and memory in the simulator to figure out what was changing what ... this is an old hardware hacker method.

Unlike your commendable efforts I have only shown that there is an alternate path to achieve an outcome that does not involve reverse engineering the code but infers the required internal code from looking at the behaviour of the circuit, the signals at each pin and lastly reading the fine manual ( aka RTFM ) .. .that is the AI reading the manual ... not me.

You mention your analysis where claude etc spent hours determing the inner workings etc ... this is where context engineering comes into play.
My approach is to look at the schematic ... what is the circuit doing at each pin. What is the signal behvaviour at each pin. What is the code that could produce that behaviour or process that signal. Then read the user manual, what are the controls, the LCD display, the boot behaviour, the switch functions ( description of each ). What is the timing of all these signals. This is the context.

The most important part is to start generating code then run it through a compiler then a chip emulation ( cycle accurate ). Its not like there were no bugs ... there were quite a few ..particularly around interrupts. Then the AI changes the code ... runs the sim again etc. until the code runs in the sim with no errors and the timings / behaviours are all consistent.

There is no hype here .. the interface to any LLM seems to be "hypy" in nature. I am just reporting what it was reporting to me.

By doing a clean room build "the uncertainty" you mention is removed. Yes in the original firmware there are variables that are "uncertain what this does / is for". In hindsight there are no "magic" algorithms in the original code in fact there are quite a few shortcuts and space saving assembly kludges that were not needed since the code fits easily into the chip.

Could there still be bugs ... absolutely ! ... but I ( err the AI ) has only spent a couple of hours on it.

So to answer your question .. .what did the AI achieve here ? ... plenty !

See the full assembly source attached ...

You can approach it the way you described and even recreate the detector’s behavior from the manual, schematic, and engineering report. However, my original goal was to create semantically reconstructed code while also testing how well AI could handle such a task.

As for the ownership issue, you are right. That is why I changed the repository to private, and I will no longer publicly share any of this.

[moodz]

You can approach it the way you described and even recreate the detector’s behavior from the manual, schematic, and engineering report. However, my original goal was to create semantically reconstructed code while also testing how well AI could handle such a task.

As for the ownership issue, you are right. That is why I changed the repository to private, and I will no longer publicly share any of this.

Good idea .... of course the danger of clean room implementations is that there is a certain "personality" in the detector that can be lost with a functional replication ( but not original code ).

[Aziz]

And my strong advise to the people out there:
Learn how to use the AI for yourself.
Learn how to use the AI for yourself.
Learn how to use the AI for yourself.

It is a peanut, if it is costing some money. But there are ways to use it for free too.

[Taktyk]

And my strong advise to the people out there:
Learn how to use the AI for yourself.
Learn how to use the AI for yourself.
Learn how to use the AI for yourself.

It is a peanut, if it is costing some money. But there are ways to use it for free too.

AI doesn’t replace thinking - and I honestly have no idea what your comments add to this discussion.