Contacting Firebee engineer(s)

All things related to the Atari Coldfire Project

Moderators: Mathias, Mug UK, [ProToS], moondog/.tSCc., Galvez, Moderator Team

User avatar
Foxie
Captain Atari
Captain Atari
Posts: 354
Joined: Wed Feb 03, 2016 7:12 pm

Contacting Firebee engineer(s)

Postby Foxie » Fri Feb 09, 2018 8:33 pm

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
Atari Super Hero
Atari Super Hero
Posts: 584
Joined: Mon Jan 31, 2011 7:39 pm

Re: Contacting Firebee engineer(s)

Postby vido » Mon Feb 12, 2018 8:34 am

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
Atari God
Atari God
Posts: 1680
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Contacting Firebee engineer(s)

Postby mikro » Mon Feb 12, 2018 10:37 am

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

User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 12412
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: Contacting Firebee engineer(s)

Postby wongck » Mon Feb 12, 2018 12:17 pm

Foxie wrote: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.
My Stuff: FB/Falcon CT63/CTPCI+ATI+RTL8139+USB 512MB 30GB HDD CF HxC_SD/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff for sale - click here for list

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 754
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: Contacting Firebee engineer(s)

Postby mfro » Mon Feb 12, 2018 7:54 pm

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.

User avatar
Foxie
Captain Atari
Captain Atari
Posts: 354
Joined: Wed Feb 03, 2016 7:12 pm

Re: Contacting Firebee engineer(s)

Postby Foxie » Tue Feb 13, 2018 2:38 am

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?

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 754
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: Contacting Firebee engineer(s)

Postby mfro » Tue Feb 13, 2018 6:51 am

Foxie wrote: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.


Social Media

     

Return to “FireBee”

Who is online

Users browsing this forum: No registered users and 2 guests