Welcome, Guest. Please login or register.

Author Topic: The Os 3.1.4 Thread  (Read 240086 times)

Description:

0 Members and 5 Guests are viewing this topic.

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #644 from previous page: August 23, 2019, 08:23:07 PM »
I tried "InitPrinter", which also prints data through PRT: Is this the 3.1.4 Port-Handler on your side?

Yes this is 3.1.4 port-handler.  I've done a little more testing to compare Workbench versus shell execution.  When I run CMD in the shell with the MULTIPLE option enabled, I don't see any issue (no hits).    The only way to stop CMD in this mode is to send CTRL-C and that works fine.  If I  issue another CMD command from another shell, I'm notified that "CMD: Device already redirected" and CMD will not close.

The only time I'm getting a hit is if I have MULTIPLE=TRUE in the tooltype and I execute as in the sequence I sent before from Workbench:

1) Set these options in the ToolTypes for CMD:
MULTIPLE=TRUE
FILE=ram:CMD_file
2) Double click CMD in workbench to install redirection.
3) In shell do this, ECHO >PRT: "Test" or do the InitPrinter
4) Double click on "CMD" icon in workbench.  This removes but at this point that I get the hit.

If I execute CMD with MULTIPLE from workbench and then execute CMD from shell, shell notify's me that device already redirected and CMD does not close.

While I was playing around and I use the FILE option in the command line, the ASL requester always opens no matter if I specify FILE or not.

Code: [Select]
CMD FILE=ram:test
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #645 on: August 23, 2019, 10:58:38 PM »
A few things I'm noticing with printing and was trying to figure out with the CMD command:

a) Not sure if this is intended but "InitPrinter" is initializing twice:
Code: [Select]
0000: 1B266C32 411B2664 401B266C 36441B26    .&l2A.&d@.&l6D.&   
0010: 6C316C32 65363046 1B266134 6C37344D    l1l2e60F.&a4l74M     
0020: 1B266130 520D1B26 64401B28 304E1B28    .&a0R..&d@.(0N.(     
0030: 73306231 30683271 30703073 33743075    s0b10h2q0p0s3t0u     
0040: 3132561B 2A722D34 551B2A76 31530D1B    12V.*r-4U.*v1S..     
0050: 266C3241 1B266440 1B266C36 441B266C    &l2A.&d@.&l6D.&l   
0060: 316C3265 3630461B 2661346C 37344D1B    1l2e60F.&a4l74M.     
0070: 26613052 0D1B2664 401B2830 4E1B2873    &a0R..&d@.(0N.(s     
0080: 30623130 68327130 70307333 74307531    0b10h2q0p0s3t0u1     
0090: 32561B2A 722D3455 1B2A7631 530D0D0A    2V.*r-4U.*v1S...     
00A0: 0C         



b) When I first turn on the computer and then turn on the HP 932C deskjet printer, it goes through some kind of reset (including a form feed).  But if I turn it off and on again it doesn't do that again. The Power LED goes on and when I go through the echo >prt: "test", I eventually get the "Check cables" requester.  Hitting cancel, seems to make the printer go through the reset and is happy again.

c) Also, the HP 932C printer is strange in that after the Init sequence or even with a normal echo >prt: "test", I get a"Resume" light blinking on the printer -- though seems like i can safely ignore that.   I was trying 2 drivers in Pagestream.   This is the end of the output.   Pagestream drivers issues a Reset and system printer driver issues a form feed.  For Pagesteam driver, I don't get the resume light blinking.

Code: [Select]
Pagestream Driver
0350: 57F4000D 03E0003F FFFFF800 7FFFF000    Wô...à.?..ø...ð.     
0360: 01F01B2A 62313757 F4000D03 E0003FFF    .ð.*b17Wô...à.?.     
0370: FFF8003F FFC00001 F01B2A62 3557EC00    .ø.?.À..ð.*b5Wì.     
0380: 0103FE1B 2A72431B 45                   ..þ.*rC.E           


Pagestream with Prefs. Printer Driver
14810: 1B266C31 6C326536 30461B26 61346C37    .&l1l2e60F.&a4l7     
14820: 344D0D1B 2A6F3071 32441B2A 7030581B    4M..*o0q2D.*p0X.     
14830: 2A723046 1B2A7433 3030521B 2A723066    *r0F.*t300R.*r0f     
14840: 32343030 73347431 7530411B 2A62326D    2400s4t1u0A.*b2m     
14850: 30571B2A 62326D30 571B2A62 326D3057    0W.*b2m0W.*b2m0W     
14860: 1B2A6232 6D30571B 2A72431B 266C316C    .*b2m0W.*rC.&l1l     
14870: 32653630 460C                          2e60F.               
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #646 on: August 24, 2019, 09:30:00 AM »
The only time I'm getting a hit is if I have MULTIPLE=TRUE in the tooltype and I execute as in the sequence I sent before from Workbench
I finally found the culprit here after looking at the code for a while. The problem was that CMD was apparently using the buffer of the FILE tooltype for appending the digit for identifying multiple outputs, which was of course only allocated to hold the name itself. (Outch!). So that got fixed. What I also fixed is that FILE was ignored when run from the shell. I've no idea why was that.

Thank you for the report!
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #647 on: August 24, 2019, 09:50:09 AM »
A few things I'm noticing with printing and was trying to figure out with the CMD command:

a) Not sure if this is intended but "InitPrinter" is initializing twice:
InitPrinter() doesn't initialize much. It just creates the ANSI "reset" code, and that is it:

Code: [Select]
Write(file,"\x1b#1\n",4)
This is, essentially, InitPrinter. (Hear, AmgiaOs source code public. (-;)). Everything else is up to the printer driver which takes this ANSI code and generates the printer-specific verson of it. This generate a bunch of CSI codes that are created both by the aRIS command (which is the nice name of this reset sequence), and the generic initialization of the printer that installs the page margins etc from the preferences.

c) Also, the HP 932C printer is strange in that after the Init sequence or even with a normal echo >prt: "test", I get a"Resume" light blinking on the printer -- though seems like i can safely ignore that.   I was trying 2 drivers in Pagestream.   This is the end of the output.   Pagestream drivers issues a Reset and system printer driver issues a form feed.  For Pagesteam driver, I don't get the resume light blinking.
The problem is that the amiga printer model is that of a line printer. You print a line, you are done. Unfortunately, this printer model is not adequate for today. Your hp is a page printer, that is, it needs an entire page at once. The reason why it is blinking is that it misses the form feed to indicate that the page has been transmitted completely, but this never comes. The problem is that we cannot simply send this when closing PRT: since that doesn't fit the model of the line printer either. There is no problem with a program opening and closing PRT: every line - this is acceptable behaviour. Even worse, if we would create a form feed at the end of a text output, it would be no longer possible to mix graphics and text on the same page. We had all this during beta testing, but there is no good solution to the problem. You can eject the page manually, you can create a form feed by software and send it to PRT:, all of this is fine.

So, in essence, I had the choice to either print some output incorrectly (by injecting always form feed when closing the device) or by leaving an inconvenience at the user. I believe what we settled at is to create the formfeed after printing graphics output, but not after text output. This is the best I can offer with the aged "page model" the Amiga has.
 
The following users thanked this post: LoadWB

Offline kamelito

Re: The Os 3.1.4 Thread
« Reply #648 on: August 24, 2019, 03:51:22 PM »
Is it possible to print to file line by line and when you’ve a page you send it to the printer?
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #649 on: August 24, 2019, 04:55:15 PM »
Is it possible to print to file line by line and when you’ve a page you send it to the printer?

I'm not sure what you're asking. Certainly it's possible from an application to do that. AmigaOs cannot and should not distinguish whether a page is complete or not. This is, however, not an implementation strategy for the printer.device for the problem I just mentioned. As stated, it is perfectly fine for an application to print a line, then wait five seconds, then print another. There is no way for the printer.device to find out whether the two lines were supposed to go on the same page or on two different pages.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #650 on: August 25, 2019, 03:33:56 AM »

I finally found the culprit here after looking at the code for a while. The problem was that CMD was apparently using the buffer of the FILE tooltype for appending the digit for identifying multiple outputs, which was of course only allocated to hold the name itself. (Outch!). So that got fixed. What I also fixed is that FILE was ignored when run from the shell. I've no idea why was that.

Thank you for the report!

Nice!  Thanks for finding and fixing!   For CMD with ASL requester, what is the expected behavior when we hit cancel in the ASL?   With a cancel in ASL, I get a "Check printer / cable" requester and then if I hit cancel there I get message that CMD redirection has been removed.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #651 on: August 25, 2019, 04:10:26 AM »

This is, essentially, InitPrinter. (Hear, AmigaOs source code public. (-;)). Everything else is up to the printer driver which takes this ANSI code and generates the printer-specific verson of it. This generate a bunch of CSI codes that are created both by the aRIS command (which is the nice name of this reset sequence), and the generic initialization of the printer that installs the page margins etc from the preferences.

a) It looks like the printer.device does its own Initprinter() when opened, then SYS:Tools/InitPrinter does  Initprinter() and then before PRT: closes, it adds a form feed at the end.   I think you might mean aRIN since if I send aRIS, I only get the PCL code of "*EE" (HP reset code).  One question is why the Initprinter() does not issue aRIS at the beginning before the aRIN? 

Another way to say this if that I can see aRIN when doing below and see the form feed at the end (using CMD).  The "test" text sits inbetween.

Code: [Select]
echo >prt: "test" NOLINE

b) I'm actually seeing a form feed (CTRL-L) in text mode and in graphic mode.  And if I do below with no CMD, a form feed happens on the ink jet printer and resume light blinks.

Code: [Select]
echo >par: CTRL-L NOLINE

c) If I do a PCL code of a single reset, the power LED starts blinking (according to the manual when LED blinks this means data is being received):
Code: [Select]
echo >par: "*EE" NOLINE
If I do a second "*EE", then it stops blinking.  No clue why I get 2 different responses for the same code being sent.

And finally, if I do a:
Code: [Select]
echo >par: "*EEtest*EE" NOLINE
The text "test" gets printed and the 2nd reset ejects the paper without a form feed.  No resume light blinks. Or alternatively,

Code: [Select]
echo >prt: "test" NOLINE
echo >par: "*EE" NOLINE    ; turns off blinking by issue reset after form feed (0xC) from prior command.

It seems like the Pagestream driver when it issues a *EE (PCL reset) at the end, this essentially does a form feed and no resume light blinks.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #652 on: August 25, 2019, 04:30:54 AM »
Is it possible to print to file line by line and when you’ve a page you send it to the printer?

I'm not sure what you're asking. Certainly it's possible from an application to do that. AmigaOs cannot and should not distinguish whether a page is complete or not. This is, however, not an implementation strategy for the printer.device for the problem I just mentioned. As stated, it is perfectly fine for an application to print a line, then wait five seconds, then print another. There is no way for the printer.device to find out whether the two lines were supposed to go on the same page or on two different pages.

There is this book "Mastering Amiga Printers" that mentions on page 173 that if you do

ECHO >PRT: IS THERE ANYONE THERE NOLINE that "the output data is now sitting in the printer's line buffer" and then if you issue

ECHO >PRT:

the text will print.

But with FormFeed appended at the end when redirection close, this doesn't seem to work that way anymore. It will just print right away.  I have no clue why ECHO > prt: would work without a string being sent.  I guess ECHO >PRT:  was suppose to send the 0x0D 0x0A. 

If you do a ECHO >PRT: "", then you will get 0x0D 0x0A and 0x0C.       
If you do a ECHO >PRT: "" NOLINE, then actually nothing happens.

 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #653 on: August 25, 2019, 08:18:13 AM »

But with FormFeed appended at the end when redirection close, this doesn't seem to work that way anymore. It will just print right away.  I have no clue why ECHO > prt: would work without a string being sent.  I guess ECHO >PRT:  was suppose to send the 0x0D 0x0A. 

If you do a ECHO >PRT: "", then you will get 0x0D 0x0A and 0x0C.       
If you do a ECHO >PRT: "" NOLINE, then actually nothing happens.
Echo without arguments sends only a line feed. 0x0A. What the printer driver does with that is up to the printer driver. It probably appends a CR as well. If I recall correctly, we also had a special tweak in the driver that appends a form feed if the printer driver closes without anything being printed, for page printers only.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #654 on: August 25, 2019, 10:26:38 AM »
Echo without arguments sends only a line feed. 0x0A.

It doesn't seem to be doing that...using PAR: below so that printer driver is out of the picture...

Code: [Select]
5.0.Workbench:> run cmd multiple notify
[CLI 1]
5.0.Workbench:> CMD redirection of parallel.device installed

5.0.Workbench:> echo >par:
5.0.Workbench:> ;No ASL comes up, this is not expected.

5.0.Workbench:> echo >par: ""
Redirected 1 bytes from parallel.device to RAM:CMD_File
5.0.Workbench:> type hex ram:CMD_file
0000: 0A                                     .                   

5.0.Workbench:> echo >par: "" NOLINE
5.0.Workbench:> ;No ASL comes up, this I assume is expected with the NOLINE option.     
« Last Edit: August 25, 2019, 10:40:03 AM by my_pc_is_amiga »
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #655 on: August 27, 2019, 05:36:16 AM »
A different observation for the CMD tool.  I'm sending the same number bytes each time but the CMD notify text is reporting an accumulation of bytes.   That is, the text says 172 bytes sent to CMD_File2 but in reality only 86 bytes were sent to that file.

Code: [Select]
5> run cmd notify multiple
[CLI 1]
5> CMD redirection of parallel.device installed

5> echo >PRT: "Test"
Redirected 86 bytes from parallel.device to RAM:CMD_File1
5> echo >PRT: "Test"
Redirected 172 bytes from parallel.device to RAM:CMD_File2
5> echo >PRT: "Test"       
Redirected 258 bytes from parallel.device to RAM:CMD_File3
5>


 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #656 on: August 27, 2019, 06:15:37 AM »
Had a separate question on stderr redirection.   I don't think *> is implemented in 3.1.4 (or even in prior versions)?  I haven't been able to get it to work even though I have gotten it to work in 4.x. 

If for some reason DOS commands produce error it looks like these are passed together with stdout and in the case of >PRT:, these error messages get printed as text to PRT:

 

Offline Gulliver

Re: The Os 3.1.4 Thread
« Reply #657 on: August 27, 2019, 07:52:23 AM »
@Thomas Richter

It seems that my_pc_is_amiga has scored a point!

 ;)
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #658 on: August 27, 2019, 04:20:06 PM »
Had a separate question on stderr redirection.   I don't think *> is implemented in 3.1.4 (or even in prior versions)?  I haven't been able to get it to work even though I have gotten it to work in 4.x. 
*> is implemented on the shell side, unfortunately only few application programs use stderr to this point. The diskdoctor of 3.1.4 will print errors on *> if requested, and *> also redirects CONSOLE:

This will change for 3.2 where I touched the dos.library to redirect PrintFault() through stderr (rather than stdout) and where most application programs in C: where also modified to use stderr consistently for error output.

So in that sense, this is not a failure of the shell which prepares everything fine as it is. It is a matter of the programs not using what has been prepared for them. The situation is improving.
 
The following users thanked this post: my_pc_is_amiga

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #659 on: August 28, 2019, 01:32:20 AM »
@Thomas Richter

It seems that my_pc_is_amiga has scored a point!

 ;)

I've posted too many things and so not sure which one you are referring to :)