USB2 speed working on X1000 (printing)?

[blmara]

Hi! Tested first time printing on X1000 and OS4.1. I have a HP Laserjet 1022 printer and I'm using usbprinter.device and the OS4.1 HP Laserjet 5 printer driver. I have previous experience using the same combination on a A1XE800, and while it produced fine graphics in 600x600 resolution and fairly good also in 300x300, it was very very slow compared to my PC with the same printer but using USB2.

For some reason, the printing speed is very slow also on X1000! For one page PDF printout (http://www.edu.vantaa.fi/mikkola/531181[1].pdf) using AmiPDF & Workbench printer driver-setting it took over 5 minutes with Density 4 = 300x300 and greyscale 1! On my PC the printing is almost immediate. My own program using DumpRPort strip printing show similar results: quality ok, but speed horribly slow.

Could it still be using USB1.1 speeds? How can I detect this? CPUInfo docky shows max 20% CPU usage while waiting and waiting for the printout, so it must be something else.

Marko

[nbache]

Could it still be using USB1.1 speeds? How can I detect this? CPUInfo docky shows max 20% CPU usage while waiting and waiting for the printout, so it must be something else.

Try printing to a file and then copying the file to your printer ("copy <filename> TO PRT:" in a Shell). Is it the creation of the file or the copying to the printer which is slow?

Best regards,

Niels

[musa]

Hello
Tested just the same document on my X1000 with a hp photosmart on usbprinter.device and phphotosmart driver.
First time Amipdf froze my x1000.
Tried again and this time it took 29 seconds.
So I loaded the document in Gimp then printed it in 27 seconds. My linux machine printed the same document from Gimp in 25 seconds.
On the x1000 was print quality pretty bad while on linux machine was fine and sharp.
The conclusion here is that my speed is nearly as my linux machine. Both under 30 sec.

[blmara]

...
On the x1000 was print quality pretty bad while on linux machine was fine and sharp.
The conclusion here is that my speed is nearly as my linux machine. Both under 30 sec.

Was printing resolution the same (if quality is bad in OS4, may be the resolution is not as good)?
Marko

[blmara]

Could it still be using USB1.1 speeds? How can I detect this? CPUInfo docky shows max 20% CPU usage while waiting and waiting for the printout, so it must be something else.

Try printing to a file and then copying the file to your printer ("copy <filename> TO PRT:" in a Shell). Is it the creation of the file or the copying to the printer which is slow?
...

Hi! I tried the following:

1) used AmiPDF's Laserjet 5 (gray) driver and printed to a file in RAM:
Took only few seconds, but when issuing the COPY command the printer started to print the file as a text with PCL commands and weird characters. How to make the printer to understand the file as a pic?

2) used AmiPDF's Workbench printer driver and used Workbench 'File' driver. Also very quick, but prints IFF which is not copyable to printer...

Marko

[nbache]

1) used AmiPDF's Laserjet 5 (gray) driver and printed to a file in RAM:
Took only few seconds, but when issuing the COPY command the printer started to print the file as a text with PCL commands and weird characters. How to make the printer to understand the file as a pic?

Okay, my fault. I'm doing this from memory. I think you might need to copy to USB0: or whatever device name your USB printer appears as, i.e. circumventing printer.device (which has already been used when printing to file) and thus sending the file "raw" to the printer.

I have never used usbprinter.device myself, so I'm not sure about this.

Best regards,

Niels

[xenic]

Could it still be using USB1.1 speeds? How can I detect this? CPUInfo docky shows max 20% CPU usage while waiting and waiting for the printout, so it must be something else.

Try printing to a file and then copying the file to your printer ("copy <filename> TO PRT:" in a Shell). Is it the creation of the file or the copying to the printer which is slow?

I don't think that's going to work. When you print to a file, printer.device processes the data and saves it to the file with all the printer codes embedded. If you copy the file to PRT: the printer.device will process the data a second time and add more printer codes; which just creates a mess.

On a classic Amiga, AmigaOne or µA1 you would copy the processed file (with printer codes embedded) to PAR: so it would go directly to the printer with nothing added. Unfortunately, that won't work of a system that has no parallel port like SAM and X1000. The DEVS:NSDPatch.cfg file has never been updated for SAM and X1000. NSDPatch.cfg maps the parallel.device to a1parallel.device for old AmigaOne & µA1 but there is no remapping for SAM & X1000. The NSDPatch.cfg file needs a new mapping to of the parallel.device to usbprinter.device for SAM & X1000.

That brings up another issue. How do you map the X1000 in NSDPatch.cfg? There is no designation defined for X1000 listed in the NSDPatch.cfg file. There is a disignation for AmigaOne (MACHINE=AMIGAONE) and SAM440 (MACHINE=SAM440), but there is no designation for X1000 or SAM460. We can't use AMIGAONE for the X1000 because the parallel port mapping for the old AmigaOne would then be applied to an X1000.

We Need Updated NSDPatch Designations (and possibly NSDPatch) For X1000 & SAM460!

[xenic]

1) used AmiPDF's Laserjet 5 (gray) driver and printed to a file in RAM:
Took only few seconds, but when issuing the COPY command the printer started to print the file as a text with PCL commands and weird characters. How to make the printer to understand the file as a pic?

Okay, my fault. I'm doing this from memory. I think you might need to copy to USB0: or whatever device name your USB printer appears as, i.e. circumventing printer.device (which has already been used when printing to file) and thus sending the file "raw" to the printer.

I have never used usbprinter.device myself, so I'm not sure about this.

You can't do it unless you create your own DosDriver for usbprinter.device. I created one called USBPRT: for my system but would have preferred to remap parallel.device to usbprinter.device in NSDPatch.cfg. If it's remapped in NSDPatch.cfg then sending data to PAR: will send the data to the printer on all OS4 hardware. (i.e. constistancy)

[xenic]

@blmara
I tested printing your PDF file to my HPPhotosmart printer through USB. It took 24 seconds. Seven seconds of that time was AmiPDF processing the file with GhostScript. I doubt if your problem is with USB; more likely the printer driver or GhostScript.

[blmara]

1) used AmiPDF's Laserjet 5 (gray) driver and printed to a file in RAM:
Took only few seconds, but when issuing the COPY command the printer started to print the file as a text with PCL commands and weird characters. How to make the printer to understand the file as a pic?

Okay, my fault. I'm doing this from memory. I think you might need to copy to USB0: or whatever device name your USB printer appears as, i.e. circumventing printer.device (which has already been used when printing to file) and thus sending the file "raw" to the printer.

I have never used usbprinter.device myself, so I'm not sure about this.

You can't do it unless you create your own DosDriver for usbprinter.device. I created one called USBPRT: for my system but would have preferred to remap parallel.device to usbprinter.device in NSDPatch.cfg. If it's remapped in NSDPatch.cfg then sending data to PAR: will send the data to the printer on all OS4 hardware. (i.e. constistancy)

I tried to make USBPRT: by copying PRT: mountlist and changing the device to usbprinter.device. But still the printer seems not to understand the AmiPDF-created file as PCL graphics but prints junk texts. I'm not good at mountlists, should I change some other parameters in the mountlist?

Marko

P.S. There is still something wrong with my settings. Tried also to print screen grab picture at http://amigaworld.net/modules/myalbum/p ... 349&full=1
by Multiview, setting the Workbench Printer Prefs to HP_Laserjet_5, usbprinter.device, Density 5 (600x600), Greyscale 1, limits: Absolute. The printout was beautiful, but it took several minutes (didn't even count here).