The datasheet on the USB interface chip should be retrievable. If one additionally traces the PCB one could create a new FPGA binary for the existing hardware.
I have - up to date - not received any request on documentation of DENEB for driver development. The documentation exists (well, it could be in a nicer form, and more detailed on some points, but ASCII never dies ;-) ) and will be made available to anyone who's interested in doing some driver work.
Datasheet of the ISP1760 (former Philips, then NXP, now Sony-Ericsson, tomorrow... good question) is available on the web, and for doing driver development you don't need to do any FPGA reverse engineering (which is, by the way, possible, but definitely not a real fun).
The FPGA "program" for DENEB (which is three programs, to be correct, one for Zorro III, one for Zorro II and Fast-Zorro II, and one for rescue mode) is quite complex. Especially the Zorro III image contains quite a few goodies which take care of certain Buster bugs, and just "writing a new FPGA image" will almost sure take some time until you have reached some stable operation, at least with one type of CPU cards.
Moreover, Zorro III is asynchronous by nature, and FPGAs are naturally synchronous devices, and I can only tell from own experience that Dave Haynie's notes on synchronization are worth reading... that's why the DENEB bus interface is running at 100MHz internally to get stable conditions on the bus.
Which reminds me - there was one attempt to design a Zorro III RAM card from some users while I was doing the ZorRAM design work. I have never seen any working card from that project, which was (if I remember correctly) using an FPGA as bus interface. Last things I heard there was "fast, but unstable operation"... typical symptoms of sync problems.
In total, it is about 500kB VHDL source code for Zorro III PIO and DMA operation.
And this code is not included in the documentation, for the same reasons why you can't get the source code of Poseidon hardware drivers - there's quite a lot of work and experience within ("closed" in your words).
These things will happen over and again as long as people let them self depend on closed software or hardware.
I think the problem here is somewhat more complex (and agree on that this is not the issue of that thread, but thinking of solutions to cope with the situation).
BTW, the documentation for driver development never was "closed" for any of the E3B products - at least if the chip documentation was not NDA'ed like the SUBWAY/HIGHWAY controllers at the beginning (it was released after some time, before we were simply not allowed to disclose it to third parties).
Michael
