mmr4000le unable to complete disk formatting, "NcrInterruptServiceRoutine: Unexpected bus disconnect"

[chungy]

In standard MAME 0.273, the mmr4000le machine always has an "NcrInterruptServiceRoutine: Unexpected bus disconnect" error after disk formatting reaches 100% by running cd:\mips\arcinst on any of the Windows NT CD-ROMs (which are presently just in the ibm5170_cdrom set...).

To do this, run the program cd:\mips\arcinst (this is the partitioning stage for NT on MIPS), and it will take a long time, but once it reaches 100%, it'll fail with "NcrInterruptServiceRoutine: Unexpected bus disconnect"

The kicker here, this used to work, until commit 8a9c1aa. By reverting this commit, formatting, and all disk access afterward, works as expected:

Given this commit's comment, it seems that the correct SCSI controller was changed to by @ajrhacker and perhaps it's just unusably buggy in the present MAME code. If that's the case, reverting the commit is a hack that defies MAME's accuracy goals, but it remains irritating that the hack is required to get a working system.

Tagging @pmackinlay also at @cuavas's suggestion.

[ajrhacker]

From my limited testing of this system, I could see that it wasn't reading the 53CF94 ID byte correctly. I just pushed a fix which might help (fd93123).

[chungy]

That seems to have broken it even more. Running cd:\mips\arcinst just results in this now

[ajrhacker]

I've pushed another commit to hopefully deal with this issue (9bbb3b4).

[chungy]

Now it doesn't even POST anymore.

[cuavas]

@ajrhacker is there a system where you’ve actually verified these changes are improvements? It seems to just be getting more broken with each change.

[angelosa]

Are you sure it's 53CF94 to begin with? Reference at https://gunkies.org/wiki/MIPS_Magnum claims standard 53C94

[ajrhacker]

@angelosa: The "quick rundown of what I've been able to pull together" on that wiki page doesn't strike me as a necessarily reliable source of technical information. I don't think it's impossible, however, that some PCBs did use a standard 53C94.

[cuavas]

What’s your reference for it being a 53CF94?

[ajrhacker]

Emulex FAS216, mentioned in the driver notes, is nearly equivalent to 53CF94. The SCSI chip test code does try to read the ID (which does happen to be different for both) from the extra register not found on previous 53C9x models (such as Emulex's earlier ESP216, which more closely resembles 53C94).

It looks like emulation of 53CF94-specific features just hasn't been fleshed out enough to be completely trustworthy; little more than the 24-bit extension of the transfer counter has been added so far.

[chungy]

Seems to be the 53C94, not 53CF94:

https://www.si.edu/object/microsoft-windows-nt-development-board-jazz-rev-1-mips-r4000-processor:nmah_742557

Second photo, bottom right.

[ajrhacker]

mmr4000le with Windows NT definitely supports both 53C94 and 53CF94, though it expects the latter to be clocked faster. (The emulation was having trouble booting because it failed to do the appropriate clock conversion.)

[chungy]

Do you have evidence that boards shipped with the 53CF94 chip?

[ajrhacker]

This was a generic platform supported by several different manufacturers. At least one Olivetti model did in fact use FAS216, which as stated above is similar to but not quite the same as 53CF94. Some evidence for that is here:

http://mail-index.netbsd.org/port-arc/2000/10/07/0003.html

[rb6502]

@ajrhacker Just set jazz.cpp back to plain 53C94 since that's 1) proven to be a thing that actually shipped and 2) works in MAME.