Progress has been made! I've tested the revised prototype boards with both my Carrera and Diimo machines without issue, along with a variety of other IO boards. Interestingly, both Carrera and Diimo are somewhat slower than the stock CPU or booster at outright sequential performance but they do make up ground in the random performance which is more essential.
Diimo posted similar performance to the stock CPU, slightly slower at the largest sequential transfers but better at random access.
The Carrera takes a bit of a drubbing as I measured around 2.7mb/s reads max - seems the dynamic bus sizing functionality of its interface circuitry is just as bad as I thought it was. Not much can be done about this, and 2x (and greater) over SCSI is still a noticable improvement
However, writes were not affected and remained around the usual ~5MB/s max, though with a regression at the largest (256K) transfer size. I'll post some benchmarks when I get a chance to collect the results.
I expect this to work with the Bolle riser; one of my testers will be confirming. The test notes above are from my Carrera, a socketed design of my own making, electrically it's got somewhat different characteristics due to shorter signal path which bit me once before.
My boosters of course work all along (as that's what I've been developing with), and unsurprisingly they turn in the best performance numbers due to their particular architecture allowing faster bus cycles. The NuCF boards are also compatible with the IIsi booster after resolving a minor snafu regarding the address strobe timing.
FIrst beta boards will be in the wild shortly. I may have one or two spare, if so I'll post here to see if anyone's interested in doing a bit of testing. The driver I believe to be feature complete - now it's just time to prove it's reliable and look for edge cases.
Next order of business will be designing the final PDS board for the SE30/IIsi/IIfx use case. After that, I've got a prototype NuBus board in hand, based off some parts of the QuadraLink design so it'll be time to start trying to make that work!
Another odd note on drivers: Device drivers should only look at the dCtlPosition field of the DCE in Prime, and should not look directly at the ioPosOffset field of the parameter block. The Device Manager sets up dCtlPosition for the driver, taking into account both the ioPosMode and the ioPosOffset. However, ioActCount, dCtlPosition, ioPosOffset should all still be updated with the results of the read/write.
Turns out there's a rather interesting corpus of knowledge here. I wish I could set up a local search engine that'd index my assortment of reference documents and sites like that....
