The comment that USB serial/parallel converters don't work (in an application one assumes) suggests that the one on the arduino board probably won't accomplish the need either.
Legacy systems that fail with USB converters tend to do so either because they attempt to do register-level access to a legacy port, require a particular fine-grained control feature of the legacy port which the USB does not emulate, or cannot cope with the quite high latency of the USB interface (USB is fast at moving a lot of data, but each packet takes a surprisingly long amount of time, so it's pathetically slow for rapid interchanges of short message).
Sometimes the solution to the latency problem is to refactor the application so that the high level software does not attempt to do bit-level I/O, but instead makes requests of an external controller such as an arduino that has low-latency I/O. So for example, the mac/pc says "run this jtag sequence" as a single packet - perhaps a serial message delivered to the driver in one write() or at least without any intervening reads. The arduino then bit bangs dozens to hundreds of clock cycles on whatever it's talking to, and then maybe it delivers a summary result back over the usb to the computer.
But solving problems in that way requires that the ultimate software be open to modification (or have a mode of talking to a network-remote device server or something like that), and it requires understanding the task at a fine level of detail in order to split out the low-latency part of the problem and implement it on the external controller.