I'll describe the issue as best I can without notes in front of me.
Please do me the favor of replying back with more questions if anything does not make 100% sense.
Also, since this is a hardware issue, I'm not sure exacly what level of comfort you might have with this,
More questions are always welcomed.. don't be aftraid to ask, on or off list as you wish.
When a bunch of peripherals share a common (parallell) bus, there is an understanding that only one device at a time will drive the bits of that bus. This is generally managed with an address decoder, which offers an "enable" signal to the addressed device, as well as a Read/Write bit, which indicates whether the peripheral is being talked to or read from.
So the "contract" is that you can drive the bus ONLY when you are being addressed AND you are being read from. at all other times you may READ the bus but not drive it. If two devices were to try and "drive" the bus at the same time, the result would be unpredictable, and possibly "bad" for the drivers that are wrestling for control.
This explanation is a bit simplified, but if what I wrote so far makes no sense, then the next part will only get worse..
Because the Xena chip has such a unique, flexible, and fast I/O structure, it was envisioned by the developers that it could interface DIRECTLY to the bus, doing it's own address decoding and all that "glue" logic.. Which would be a neat trick. It was designed with that in mind.
Now on to our specifics: The "fast localbus" multiplexes the high half of the address bus, the low half of the address bus, and the data bus on to one 16 bit wide group.
Sharing this bus are an FPGA. (I think), the Compact Flash socket, and the boot ROMs (2)..
There are pretty tight timing constraints when you see the address (in two parts) then respond IMMEDIATELY with a data read or write (if the address is yours).. but that's not where we tripped up.
This "localbus" is leading to a half-dozen devices, and the total capacitance is.. a bit more than I would have wished for (sorry, no technical data available, please bear with me).
This will work fine as long as the "bus drivers" on each of the attached devices is strong enough to drive the bus wires QUICKLY to their desired state..
But the output transistors on the Xena chip are not "bus drivers", and while they MIGHT have been strong enough in the original design, a process called "die shrink" is a normal part of a chips development, involving downsizing everything as much as possible to keep the chip affordable.
So the Xena can READ data from the localbus as fast as you might want to go, but WRITING from Xena to the PA6T takes WAY TOO LONG. The only way I could make it work at ALL was to go change the device timing settings to the slowest possible speeds, then cut the master clock to half speed.. then I could get data through, but it would be binary OR'ed with the last half of the address.. forcing even more wacky adjustments.
That's about as deep as I can go without finding my old notes.
The "keepout" section is what enables the Xena output buffers.. if left ON at the wrong time it may cause bus contention. (see above)
In an obvious effort to end on a brighter note:
The X5000 has a bigger PGA, which is now (in part) dedicated to buffering all the Xena bus signals.. Yippee!!
There is also a fair bit of what appears to be "dual port ram", so the Xena and the main processor can exchange data without needing to synchronize.
This should be quite exciting.
As I mentioned already: I'm fairly sure of this, but PLEASE ask questions if you want more detail.
And don't solder anything based only on my memory.
Closer to your question:
Some part of the program "sets up" the bus timing.. If you were to build a project where the Xena is written to, but never replies, you could alter that bus
timing considerably, and go really fast.. passing data IN TO Xena can be done quite fast and quite safely. no damage if it fails except possibly some garbled data.
I had never "played" with bus timing before this project. It's not difficult, but it did take me a little time to get my head wrapped around what was really happening.
You could probably "watch" other devices too.. Boot ROMs, Compact Flash.. All that data is flying right by the Xena chip.. Hmm..
If you're brave enough, mechanic has dug deeper than most on this thing. He does have an appreciation for the "bleeding edge" stuff. He scares me just a bit, but I say that with appreciation as well.
As far as soldering goes.. Optical S/PDIF is optical.. so safe once the board is built.. MIDI IN is also optically isolated.. and I mentioned before that I have some chips (so far untested) that are Bi-directional, fully isolated, and also do voltage conversions too. a bit pricey, but everything you ever wanted in a Xena I/O buffer.
For those that are more timid, our favorite Amige dealer has my Xorro now, so they can get all the details from my build. They just might offer a build service if you ask for it..
and I have a few sticks of those addressable RGB LEDs, if I EVER get ahead of my other fourteen projects.