Contacting Firebee engineer(s)

[Foxie]

I have a technical question about how the printer port is implemented on the Firebee, but though I e-mailed mcs at kingx I never heard back. Does anybody know who I could ask to get the relevant info?

In case someone here knows, I need to know the following
Is the port 5-volt tolerant?
Is it open collector or totem-pole?
Can it sink at least 1.6mA?
Can it be used bidirectionally like the ST's printer port?
And in fact, is it implemented in the FPGA yet? I heard the cartridge port isn't implemented yet despite the pin header being present.

[vido]

I am not any hardware expert but as I know printer port is implemented on the FireBee and should work as expected. I think it works ok under EmuTOS but ther is a problem under FireTOS.
I believe Mfro and Roger knows more about that problem ...

[mikro]

Also, pointing Foxie to Mathias and/or the forum could be a good idea as he might require more than just one-off answer.

[wongck]

And in fact, is it implemented in the FPGA yet? I heard the cartridge port isn't implemented yet despite the pin header being present.

IIRC, it was implemented but you need to flash it as it was a later development after the batch was shipped out.

[mfro]

there is a detailed, long article regarding the printer port on firebee.org

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.

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).

You should be able to reach full bandwidth with direct soundchip I/O. I didn't test anything but printing, however.

[Foxie]

Thanks for the detailed info! I've been reading the Cyclone III datasheet to get a clearer picture of what's going on.

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.

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?

[mfro]

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?

The YM is clocked at 33 MHz (the ColdFire's FlexBus clock).

To slow down the port, I just inserted an uncalibrated loop delay (in the good old Atari tradition of hardware-dependend code, so this will probably not run correctly on anything else). Beware of NOPs in your code - they do a pipeline flush on the ColdFire causing a delay way longer than any other single cycle instruction.