machine/wd33c9x.cpp: Negate ACK should trigger an irq

[angelosa]

As part of its OEM protection the NEC PC-9801-55U/PC-9801-55L does the following things (simplified):

1. sends an inquiry request to the HDD;
2. uses a negate ACK once it receives the third byte of scsi_cmdbuf[8], the manufacturer string, cfr.

   mame/src/devices/bus/nscsi/hd.cpp

   Line 174 in 3e3209a

   strcpy((char *)&scsi_cmdbuf[8], " SEAGATE");

3. expects said request causes an irq;
4. wants that the received bytes says NEC otherwise it locks up the machine entirely;

2 and 3 are the important parts of this issue, I'm not sure what kind of interrupt the wd33c9x should really generate, the BIOS makes sure to branch on every single irq state received from the controller. fwiw it's not in initiator state when this happens.

[angelosa]

Additional context:

---

mame/src/devices/machine/wd33c9x.cpp

Lines 771 to 778 in 568ccef

	case COMMAND_CC_NEGATE_ACK:
	LOGMASKED(LOG_COMMANDS, "Negate ACK Command\n");
	// FIXME - This is causing problems, so ignore for now.
	//if (m_mode != MODE_I) {
	// fatalerror("NEGATE_ACK command only valid in the Initiator state.");
	//}
	scsi_bus->ctrl_w(scsi_refid, 0, S_ACK);
	return;

Requires an irq here. This is what I have, not necessarily correct:

		if (m_mode != MODE_I) {

		//  fatalerror("NEGATE_ACK command only valid in the Initiator state.");

			irq_fifo_push(SCSI_STATUS_SELECTION_ABORTED);

			data_fifo_reset();

			update_irq();

		}

Originally posted by @angelosa in 568ccef

NOTE: the data_fifo_reset() is necessary to avoid problems later on i.e. a fatalerror in wd33c9x core.

---

---

PC-98 was cloned by Epson
NEC wanted to OEM lock in their PCs, so they added protections

As also explained by https://www7b.biglobe.ne.jp/~drachen6jp/98scsi.html around the -55U entry.

---

The full list of irqs that the wd33c9x can generate:

mame/src/devices/machine/wd33c9x.cpp

Lines 165 to 204 in 3e3209a

	enum scsi_status_e : uint8_t {
	SCSI_STATUS_RESET = 0x00,
	SCSI_STATUS_RESET_EAF = 0x01,
	SCSI_STATUS_RESELECT_SUCCESS = 0x10,
	SCSI_STATUS_SELECT_SUCCESS = 0x11,
	SCSI_STATUS_COMMAND_SUCCESS = 0x13,
	SCSI_STATUS_COMMAND_ATN_SUCCESS = 0x14,
	SCSI_STATUS_TRANSLATE_SUCCESS = 0x15,
	SCSI_STATUS_SELECT_TRANSFER_SUCCESS = 0x16,
	SCSI_STATUS_TRANSFER_SUCCESS = 0x18,
	SCSI_STATUS_TRANSFER_INFO_MSG_IN = 0x20,
	SCSI_STATUS_SAVE_DATA_POINTERS = 0x21,
	SCSI_STATUS_SELECTION_ABORTED = 0x22,
	SCSI_STATUS_RECEIVE_SEND_ABORTED = 0x23,
	SCSI_STATUS_RECEIVE_SEND_ABORTED_ATN = 0x24,
	SCSI_STATUS_ABORT_DURING_SELECTION = 0x25,
	SCSI_STATUS_RESELECTED_DURING_SELECT_AND_TRANSFER = 0x27,
	SCSI_STATUS_TRANSFER_ABORTED = 0x28,
	SCSI_STATUS_INVALID_COMMAND = 0x40,
	SCSI_STATUS_UNEXPECTED_DISCONNECT = 0x41,
	SCSI_STATUS_SELECTION_TIMEOUT = 0x42,
	SCSI_STATUS_PARITY_ERROR = 0x43,
	SCSI_STATUS_PARITY_ERROR_ATN = 0x44,
	SCSI_STATUS_LOGICAL_ADDRESS_TOO_LARGE = 0x45,
	SCSI_STATUS_RESELECTION_MISMATCH = 0x46,
	SCSI_STATUS_INCORRECT_STATUS_BYTE = 0x47,
	SCSI_STATUS_UNEXPECTED_PHASE = 0x48,
	SCSI_STATUS_RESELECTED = 0x80,
	SCSI_STATUS_RESELECTED_EAF = 0x81,
	SCSI_STATUS_SELECTED = 0x82,
	SCSI_STATUS_SELECTED_ATN = 0x83,
	SCSI_STATUS_ATN = 0x84,
	SCSI_STATUS_DISCONNECT = 0x85,
	SCSI_STATUS_NEED_COMMAND_SIZE = 0x87,
	SCSI_STATUS_REQ = 0x88
	};

[angelosa]

Kale: np2kai uses a disconnect (0x85) there, that sounds good enough to me
Happy: The wd33c93a datasheet suggests TRANSFER_INFO_MSG_IN (0x20) interrupt occurs in response to -ACK
Happy: If it was during not during the Message In phase, it would generate a Terminated interrupt (0x43, 0x44, 0x47) depending on which byte caused the error during the transfer command.
Happy: Also that the wd33c93a should be automatically pausing some of the transfers waiting for -ACK or other signal.

[happy6861707079]

What value does the Inquiry command set in the transfer count register?

[angelosa]

command INQUIRY lun=0 EVPD=0 page=0 scsi_cmdbuf[3]=(00) alloc=0b link=00

[happy6861707079]

"alloc=0b" would seem to indicate the HDD should stop after transmitting the first part of the vendor field for the Inquiry. What value is set for the transfer length for the Transfer Info command to the wd33c93? It seems likely that the Inquiry command completes successfully and the Negate ACK is in response to something else, perhaps the following Status or Command Complete message.

[angelosa]

Doesn't set transfer count at all, sets a 0 to reg 0x11 instead (unemulated?)