ns32081.cpp: fix for SFSR and LDSR opcodes that dont compute anything #13626
Conversation
Elektraglide
commented
Apr 27, 2025
Elektraglide
commented
- consistent formatting of bytes
- consistent formatting of bytes
| @@ -112,7 +112,8 @@ void ns32081_device_base::state_add(device_state_interface &parent, int &index) | |||
|
|
|||
| template <typename T> T ns32081_device_base::read() | |||
| { | |||
| if (m_state == RESULT && m_op[2].issued < m_op[2].expected) | |||
| LOG("read: state(%d) issue(%d) expected(%d)\n", m_state, m_op[2].issued, m_op[2].expected); | |||
| if ((m_state == STATUS || m_state == RESULT) && m_op[2].issued < m_op[2].expected) | |||
There was a problem hiding this comment.
This change is not correct. Per section 3.9.1 "Slave Processor Protocol", the status must be read before attempting to read any results.
There was a problem hiding this comment.
There is NO result to read.
There was a problem hiding this comment.
Reading the status is mandatory, results or not.
| @@ -656,7 +657,7 @@ void ns32081_device_base::execute() | |||
| if (!m_out_spc.isunset()) | |||
| m_complete->adjust(attotime::from_ticks(m_tcy, clock())); | |||
|
|
|||
| m_state = STATUS; | |||
| m_state = m_op[2].expected ? STATUS : IDLE; | |||
There was a problem hiding this comment.
This change is also not correct. Reading the status is mandatory in the protocol, regardless of whether there are results or not.
There was a problem hiding this comment.
Thats not what Tektronix 4404 does. Try it.
There was a problem hiding this comment.
Reverted and now not getting the "read protocol error" I wasn't imagining it - but I have seen tek4404 FPU get into a weird state that only a reboot can fix.
There was a problem hiding this comment.
oh, helps if you turn on logging...
There was a problem hiding this comment.
The Tektronix documentation describes in some detail the circuit responsible for ensuring status is only read when the FPU signals completion, and there's no indication there that reading the status is optional.
The National Semiconductor documentation is also pretty clear about how the protocol works, and the only exception (where status is not read) is explicitly documented for the LMR/LCR instructions, which are a different type/format. In addition, AN-383 explicitly states (in relation to step 6 of the protocol): "This transfer is mandatory, regardless of whether the information presented by the FPU is intended to be used.".
If the Tektronix code is truly failing to read the status under some circumstances, I think the explanation and proper fix relate to the currently unemulated "abort" behavior. The datasheet states that writing a new slave ID byte (i.e., starting a new instruction) will cancel any protocol in progress. To emulate this properly will require separating the ID byte write from the existing write() function, so that the proper input status can be identified without relying on the state machine. While emulating this will likely fix the Tektronix driver, it does raise a question about how that system guards against unintentionally aborting an instruction that was in progress (again, mentioned in the application note).
