Home Page Forums MAME MAME Requirements?

With bsdimp's great finds, it would be a big help if one of the MAME dev people could convert the Rainbow driver to a modern, slot based format. This would help other contributors to find their way around more easily. The Rainbow is one of those drivers that has attracted different people over the years, and the dual processor, extendable format is really a showcase for what MAME can do.
The conversion is certainly beyond my scope, that's why I'm asking "pretty please"

wd1000_device and wd1010_device appear to be even more limited implementations of the WD[12]0[10]0 that are used in a couple of places. Neither look to be sufficiently robust to replace wd2010. The wd2010 could likely replace both of them, but the interfaces are enough different that I'm not sure I want to bite off doing that.

I'm game to help out. I have some minor hacks to wd2010 in my tree to try to see if it could be generalized like the z80sio derivatives.

I'd like to add support for the dual Winchester adapter...

What's missing in wd1010_device?

I didn't see a clear way to implement the buffer_ready stuff that wd2010_device has. Maybe I overlooked something.

and besides, the only difference between the WD1010 and the WD2010 is the latter has one additional bit in the upper cylinder register and the WD2010 is a more complete implementation to my eye than the wd1010 one, though I base that in part on the number of comments about edge cases.

What's buffer_ready supposed to do? wd1010_device outputs the bcs and bcr pins for buffer control. I'm not sure you should base your assumptions fully on the comments. wd1010_device implements multiple sector reads/writes for example, which wd2010_device does not.

Fair enough. I wasn't entirely sure what it was supposed to do either (though it appears to be an input to the wd2010_device rather than an output) when I looked at it. It just didn't seem to map to anything in wd1010_device, but I didn't study them both deeply with the data sheet in hand...

I certainly don't want my mildly held opinion to start a fight, though... I'm certainly open to changing it based on new data... Though I'd much rather spend my time and energy about learning how to convert this driver to be more slot based...

I don't want to discourage you, but converting a driver to be slot based is a lot of work and usually means rewriting it. A few examples from me are here:

https://git.redump.net/mame/commit/?id=09f25df20d7910b6f156c86040f9a9ca35852701
https://git.redump.net/mame/commit/?id=4d89de93c0dcb0b3069c9226236bfb1a802113cf

This isn't the only way to do it, there are different ways to implement a slot based system. Just look at a few examples in src/devices/bus.

Thanks Duke! That gets me on the right track... I've looked through some of this and I agree it would be a piece of work... though worthwhile maybe...

Are you a good person to ask about it if I hit snags? Are there others? Is there a good place to go to ask for help?

I've disassembled the Univation 2.11 DOS driver. The card is a SCSI card that talks to one device. I have halfway worked out the protocol for the different bus phases. Limitations in 16-bit data structures limit the size of the supported disk to 32MB.
Is there a good example driver to look at for a SCSI device? So far, I've only found READ6, WRITE6 and REQUEST SENSE CDBs that are sent to the device. It doesn't send INQUIRY which implies it might be SASI instead of SCSI-1, but the delta between the two is small.