I have been on and off writing an emulator for the eZ80 CPU. This CPU has two addressing modes, Z80 mode in which it's effectively an 8-bit processor with a 16-bit address space, and ADL (Address Data Long) mode in which it has a 24-bit address space. There is a CPU control bit 'MADL' (Mixed ADL) for mixed-mode applications; when set, using certain prefixed opcodes will switch modes during call and return.
A Z80 routine can call outside of its 16-bit address space with 'CALL.IL'. This pushes the 16-bit return address onto the 16-bit stack, switches to 24-bit mode, and pushes the magic 'return to 16-bit mode' number to the 24-bit stack. However, it's not clear from the manuals or datasheets what happens if you use the prefixed 'CALL.IL' opcode sequence when the 'MADL' bit is reset.
I asked ChatGPT, because this is something that Google searching hasn't yielded answers for. It had this to say:
"The MADL bit (short for Memory Access During Interrupts Low) is a flag in the Interrupt Control Register that determines whether or not interrupt service routines (ISRs) can access low memory (addresses 0000h-3FFFh) during interrupts."
Plus some more stuff building on that, on CALL.IL being about ISRs, and about low memory. All of it is completely, fundamentally wrong. I did a handful of rounds of trying to steer it to a more correct answer but it continued to get additional basic facts wrong and would lean back to earlier incorrect facts as others conflicted with its answers.
I asked it another question I have, this time about the UART on the CPU. There is a Receive Buffer Register (UARTx_RBR) that contains the head of the receive FIFO. The documentation does not make it clear what is in the RBR if the FIFO is empty, so I asked ChatGPT. It told me a very plausible answer, the one I suspect myself, which is that it'll keep returning the same value until new data is available. But then it went on to tell me this is called receiver overrun, and described how an overrun occurs, including noting that it happens when the FIFO is full. And we went round in circles on this for a little while.
ChatGPT is a major step forwards in our post-truth existence: its answers are an amalgam of the most frequently repeated views on a topic, not those with stronger reasoning or more effective evidence to support. If there is little or no source data on a topic (as would be the case with my very specific questions on a rarely used processor) LLMs are (presently?) unable to detect that they are responding to a topic with limited contextual information and tailor their responses accordingly, and instead confidently provide utter nonsense.
I trust ChatGPT to do things that LLMs are good at, though: if I give it some bullet points and some style guidance it can give me written paragraphs. If I ask it to rephrase a well known song in the style of some modern artist I'll get something back that's pretty plausible. It can give me some starting points for learning more about some well known topic, even.
I would definitely not trust it _at all_ to give me something factual like part numbers of uncommon ICs, because LLMs cannot distinguish between fact and fiction, not in what they ingest, and not in what they produce.