Ever since installing the latest OS4 release, I can no longer (well, sort of) print anything.
Not sure if it was a "back to default" UBoot or if it's the actual OS.

My UBoot parallel setting are these: ECP-0x378. I can't remember what I had before my mb battery died. I also used PrintManager, but since it was reported it didn't work with OS4Final, I removed it.

Not to the "sort of" part...

...I could milk a single print out! Couldn't reproduce, but Notepad managed to print a file. After that, every single attempt resulted in failure.
What's going on here? Any sugestions?

A1, OS4, Turboprint.

@BrandonLee

Make sure PAR: and PRT: are in your dosdrivers and don't use turbo prints turbo-par.

_________________
OS4 Rocks
X1000 beta tester, Sam440 Flex (733)

Visit the Official OS4 Support Site for more help.

It may be that your sole purpose is to serve as a warning to others.

@Severin

I have both there already. And more recent versions than I had before. I don't like to do it, but I may try to put the old ones, see if improves.
WHat I DIDN'T have was the PS dosdriver.It's there now.Now it's a bit late, but I'll check everything tomorrow.

The really weird thing is I managed ONE printout (from Notepad).

@BrandonLee

According to the a1parallel releasenotes, you should set ECP mode in U-Boot.
Thats what you did.

Some more ideas. Printing from NotePad with TurboPrint installed is
a complicated case where several things can go wrong. NotPad sends its
output to PRT:, and it prints text. In this case your Printer prefs
settings are ignored, and OS4 printer.device and its printer drivers
are not used.

What may be problematic with TurboPrint: First, its known that its spooler
doesnt work. It has an option for the spooler somewhere, make sure its
not used.

Second, its known that TP has sometimes problems when you tell
it to use a device for printing. Dont know the details, maybe something
with the detection of "paper out" or "printer busy", it doesnt happen with
all devices but I vaguely remember that at least lpr.device and pit.device
(the parallel port driver of the MultiFaceCardIII) didnt work reliable
when used from TP directly. To workaround this problem (or to see if this
problem exists also with a1parallel.device), you can tell TP to print
into a file. When it did that, you can copy that file to PAR: by hand
and see if this works better. When it does, you can try if using PAR:
as output file name in the TP prefs can be used as "permanently workaround".

The third possible problem with TP and printing text (from e.g. NotePad),
not graphics, is that it uses GhostScript to convert the text into a bitmap
and to print that bitmap in graphics mode, at least when you have choosen
a TP printer driver for a printer which has no text mode. Here it gets
complicated, because TP comes with its own version of GhostScript, and OS4
comes with its own version of GhostScript, you have to find out if installing
TP did install the TP version of GhostScript or not, if that did overwrite
the OS4 version or not (eventually both versions are installed in different
directories). TP has GhostScript options in his settings, here you can try
to specify or verify which GhostScript version gets called with which
commandline parameters. Eventually the Snoopy tool from OS4depot may help
you to find out if GhostScript is called, which GhostScript is called,
and if something goes wrong there...

Last edited by TetiSoft on 08-Jan-2007 at 07:39 AM.

@TetiSoft

Some correction here:

Quote:

The third possible problem with TP and printing text (from e.g. NotePad), not graphics, is that it uses GhostScript to convert the text into a bitmap and to print that bitmap in graphics mode, at least when you have choosen a TP printer driver for a printer which has no text mode.

That is not true. TP doesn´t use GS for text mode replacement, it simply copies Amiga bitmap fonts as graphics to the printer (using a temporary RastPort including a bitmap with a height suitable for the chosen print mode, e.g. interleaved printing with use of the upper/lower half of the nozzles or direct printing with use of all nozzles).

The GS installation supplied by TP in fact uses TP as a special output device, so one can print PS files directly to PS: handler using TurboPrint as output device.

Quote:

Second, its known that TP has sometimes problems when you tell it to use a device for printing. Dont know the details, maybe something with the detection of "paper out" or "printer busy", it doesnt happen with all devices but I vaguely remember that at least lpr.device and pit.device (the parallel port driver of the MultiFaceCardIII) didnt work reliable when used from TP directly.

At least for me lpr.device works fine using TP. I don´t know what went wrong for him, but I think it´s a configuration detail (maybe text replacement settings or such), that printing doesn´t work for him anymore.

I tested TP on OS4 Final with an Epson STC685 printer attached to a1parallel.device (btw. when will the "Init"-Line problem within UBoot be solved? I had to cut the init line of my printer cable in order to get my HP printer working, as it is set to active state and stays in active state even when it shouldn´t ), with my old HP DJ500 and my Kyocera FS-820 (in LaserJet3 mode), works flawlessy (of course with the ugly spooler disabled!). Didn´t test USB printing yet, but I believe it will work fine, too.

Greetz

@whose

> TP doesn't use GS for text mode replacement, it simply copies Amiga bitmap
> fonts as graphics to the printer.

You are right, my TP handbook confirms that Sorry, have mixed it up.

> btw. when will the "Init"-Line problem within UBoot be solved?
> I had to cut the init line of my printer cable in order to get my HP printer
> working, as it is set to active state and stays in active state even when it
> shouldn't ), with my old HP DJ500 and my Kyocera FS-820 (in LaserJet3 mode),
> works flawlessy

There was a bug report in the OS4 bugzilla database (#1661)about the printer
init line held in the wrong state, in the meantime this report is set to
"fixed" and confirmed as working with a1parallel.device 51.6 so V52 should
also work. When it doesnt do that for you, please reopen the bug or talk
to Stephan Rupprecht.

@TetiSoft

Quote:

You are right, my TP handbook confirms that Sorry, have mixed it up.

No problem

Quote:

There was a bug report in the OS4 bugzilla database (#1661)about the printer init line held in the wrong state, in the meantime this report is set to "fixed" and confirmed as working with a1parallel.device 51.6 so V52 should also work. When it doesnt do that for you, please reopen the bug or talk to Stephan Rupprecht.

Well, seems that I have to check my (not changed) parallel cable or fix my old cable to test a1parallel.device...

Would be really great if it would work now without cable snipping. Thx for that hint!

Greetz

@whose

Speaking of A1parallel.device...

...I managed to get Notepad working (through Turboprint), finally. My old system had the PAR dosdriver pointing to device "parallel.device". The OS4Final had "A1parallel.device".
On my old dosdriver file I had a note saying that I had changed it back then, too. Can't recall why, but it seems it only works if I remove the A1 bit.
Just finished printing from IBrowse and it works, too, so I guess this is solved. ;)

Thanks for all the replies.

@BrandonLee

Quote:

On my old dosdriver file I had a note saying that I had changed it back then, too. Can't recall why, but it seems it only works if I remove the A1 bit.

This is really strange, but if it works for you, it´s fully okay

I will do some tests with a1parallel.device the next days, perhaps I run into problems. Then I will pop up here and tell about it

Greetz

@BrandonLee

I have a guess why it´s working this way:

TP sets up it´s own "parallel.device" entry in the system (intended for redirection of calls to standard parallel.device, which will be patched if available, to TP´s parallel.device).

Regarding PAR: printing, the "a1parallel.device" entry will be ignored by TP then, because TP doesn´t patch any non-parallel.device to "parallel.device with TP use". TP will be circumvented in this case.

Nonetheless it is strange that notepad does PAR: printing... as far as I remember it´s standard printing goes directly through printer.device, hence the "a1parallel.device" setting within TP prefs should do it´s job (normally). Did you choose "Print" menu entry or "Save" and then saving to PAR: for printing? "Print" should do flawlessy with TP installed, without use of PAR: or any other port handler.

I am not in front of my A1, so I can´t verify my thoughts yet, but I will do as soon as I am in front of my A1 again.

BTW: you will get in trouble if you want to print via PAR:, if TP is not installed. You will have to set up PAR: to a1parallel.device again in this case.

Greetz

@whose

> TP sets up it's own "parallel.device" entry in the system (intended for
> redirection of calls to standard parallel.device, which will be patched if available, to TP's parallel.device).

Oh well... So it not only installs an 68k V39 "printer.device" into memory
out of thin air, but also a "parallel.device"? Why cant it avoid patching
everything and simply install its drivers into PRINTERS:?

With WB2.x the patching was necessary because printer.device didnt support
24bit colors, but these days are over in the meantime...

> Nonetheless it is strange that notepad does PAR: printing...

It doesnt, as already written, it prints to PRT:. You can search the "PRT:"
string in the binary

@whose

Nonetheless it is strange that notepad does PAR: printing... as far as I remember it´s standard printing goes directly through printer.device, hence the "a1parallel.device" setting within TP prefs should do it´s job (normally)

Maybe that's why Notepad worked (once) before I changed the parallel.device...Why it stopped working afterwards is a mystery...

Did you choose "Print" menu entry or "Save" and then saving to PAR: for printing?

I did a direct "print" from the menu.

@BrandonLee

Edit: Seen tetisoft´s post too late...

Please check your PRT: setup and if you are doing some configuration for it inbetween and after bootup.

Another edit: I had a look at PRT: now and I saw that it states "printer.device" for output device. Make sure that your PRT: entry does contain "printer.device", not parallel.device or a1parallel.device.

Maybe that´s the weirdo...

Greetz

Last edited by whose on 09-Jan-2007 at 12:00 PM.
Last edited by whose on 09-Jan-2007 at 11:54 AM.

@TetiSoft

Strange enough, so it should print very well for BrandonLee, as TP replaces the printer.device, too (as used by PRT: handler). Maybe, he configures something for the PRT: earlier in his startup sequences?

The patching orgy is a "trademark" of TP, but it works for now, that is all we need for the time being I would like to see another printing mechanism than TP, perhaps when time goes by, something will evolve? But, pleaaaaase, no CUPS or something "unhandy" like it.

There must be a way to implement an intelligent printer driver system for AmigaOS, without big background daemons, dozens of textual config files and such...

Greetz

Last edited by whose on 09-Jan-2007 at 12:01 PM.
Last edited by whose on 09-Jan-2007 at 11:55 AM.

@whose

There must be a way to implement an intelligent printer driver system for AmigaOS, without big background daemons, dozens of textual config files and such...

I guess this is an area where OS4 will have big trouble catching up. There are multiple printers and drivers, it's impoosible to convert them all.
TurboPrint was a godsend, even if it's somewhat "difficult".

@whose
Please check your PRT: setup and if you are doing some configuration for it inbetween and after bootup.

Not that I know of.
And PRT: states printer.device, not parallel.device.

It works, so I can't really complain. ;)