Thanks for the detailed info! I've been reading the Cyclone III datasheet to get a clearer picture of what's going on.
mfro wrote:Regarding 5V tolerance: the port does not have dedicated level shifters, but uses the (Altera recommended) 5V adaption 'trick' using a resistor and the built-in PCI clamp diodes of the FPGA.
IMHO, this should be safe. There is a small risk, however, as the PCI clamps only get active once the FPGA configuration is loaded (which takes a few seconds after power-on). I did not see any damage during my tests, but decided to disconnect the printer after that (I don't need it anyway), so I can't provide long term experience.
It looks like the datasheet warns against applying 5V when the device hasn't been configured, so it does seem a bit risky for use with a normal printer. Perhaps it should be recommended to install a diode pack inline with the printer port? However, I'm more interested in connecting MIDI devices to the port rather than printers.
I'm not sure if the Firebee actually drives the data lines on the printer port high. Some printer port MIDI devices rely on being able to pull the data lines low - without the port being set to input mode. If the Firebee tries to drive the pins high, this could cause damage.
mfro wrote:In theory, the port should just work as it does on an original ST. Just several magnitudes faster - required us to insert busy waits into EmuTOS and FreeMiNT parallel port drivers to slow it down to IEEE standardised strobe timing (busy waits are missing in FireTOS which is the reason printing will not work there).
This is definitely something I'll have to watch out for. So the 625ns YM access delay has been eliminated? Which method did you use to slow the strobes down? I'd rather not dedicate an entire MFP timer to the task, perhaps a calibrated delay loop is viable?