Welcome, Guest. Please login or register.

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

Description:

0 Members and 9 Guests are viewing this topic.

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #44 from previous page: 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.               
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #45 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 #46 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 #47 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.

 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #48 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 #49 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 #50 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 my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #51 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 :)
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #52 on: August 28, 2019, 01:39:51 AM »
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.

Thanks for the peak preview of 3.2 :).   If there are some changes being done for the C: programs, then there could be a slight improvement for Eval error detection...

Eval '? LFORMAT="%X*N";  this is not producing an error as it should be.  The %X is not correct and should be %X2 or some number after %x.  Instead in 3.1/3.1.4, eval prints something but doesn't make sense (*N doesn't get correctly parsed).  In 4.x, the error is produced saying in affect that LFORMAT is not in correct format.
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #53 on: August 28, 2019, 05:46:23 AM »

Thomas was awarding virtual points to any user guessing some of the new features that 3.2  brings. You guessed one: a working stderr.

And it seems you are now near another, this one is very small. ;-)

It is up to Thomas to "spill the beans".

Mmm...AmigaGuide text search (though I don't think that one is small).   Seems like there was some kind of search in v34.6   And the other "wish" is a fix for the high res. pointer slanting on native amiga screens (and that one surely isn't an easy fix).   This has been there since 3.0...
« Last Edit: August 28, 2019, 06:08:29 AM by my_pc_is_amiga »
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #54 on: August 29, 2019, 04:50:03 AM »
Edit: But after a little experimenting, this looks more like confusion over what %X is and how it works - lformat "%X1*n" works as expexted, with "%X*n" %X apparently just "swallows" the * and the n, while "%X *n" (space betweem X and *) does not. What's correct behaviour here is probably debatable, but I agree that it would be best to exit with error about bad template.

OS4 reports an error about a bad LFROMAT while OS3.x does not.   %X is not the correct format, it needs to be %X1, or %X2, etc. According to AmigaDOS manual, "The %X and %O options require a number of digits specification (for example %X8 gives 8 digits of hex output)."  So my expectation was to have EVAL produce an error.   
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #55 on: August 29, 2019, 04:51:32 AM »
And thanks for all of your hard work!  Sometimes it doesn't appear that folks appreciate the work you are doing but I can assure you MANY of us do..

I copy that.   Yes, thanks for all the hard work!
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #56 on: August 29, 2019, 04:54:03 AM »
  And the other "wish" is a fix for the high res. pointer slanting on native amiga screens (and that one surely isn't an easy fix).   This has been there since 3.0...

Could you please try to describe with more detail this issue you find?

Easier to see with pictures:

a) NTSC Hires Laced with Hires pointer (aspect ratio is messed)
b) Multiscan with Hires Pointer (pointer looks okay).
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #57 on: August 29, 2019, 05:44:03 AM »
Is this a bug?

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 #58 on: August 29, 2019, 06:19:57 AM »
Going back to the SYS:Tools/InitPrinter

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         

From the "open" source :) and from doing a hex dump of InitPrinter, we can see it is a just a aRIN Escape code being sent (0x1B2331):
Code: [Select]
00E0: 5052543A 00001B23 310A0000 000003F2    PRT:...#1......ò 

But wouldn't it make sense to also send a aRIS (0x1B63) beforehand so that the printer first goes back to it's defaults before changing it to the prefs value (before the aRIN)?

The HP Printer driver output (HP PCL code) for the aRIN is this and there is no PCL EscE (PCL code for reset) in there.


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..

.&l2A                          USA Letter
.&d@                           Turn off underline
.&l6D                          6 lines per inch
.&l1l 2e 60F                   Perforation skip mode on, top margin 2lines, 60 text length
.&a4l74M                       Left 4 margin,right margin 74
.&a0R                          Move to row 0
.                              Carriage Return
.&d@                           Turn off underline
.(0N                           ECMA-94 Latin 1
.(s0b 10h 2q 0p 0s 3t 0u 12V   normal,10 chars/inch,Letter,Fixed,Upright,Courier,don't know ,12/72nd inch height
.*r-4U                         4 planes, cymk palette
.*v1S                          Foreground color


 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #59 on: August 30, 2019, 05:31:33 AM »
So the character 'G' would mean 16. I'm not sure whether anything depends on this, but it should reject (or at least skip over) things that are below '0', larger than '9' and below 'A', and anything above 'Z'.

Interesting...I did not know that the "number" after the %X is suppose to be "hex" -ish.   From a user-perspective who does not know the internal working this is kind of confusing.   

eval '? LFORMAT "%X*N"    --> seems like this should throw an error like OS4.
eval '? LFORMAT "%X0*N"  --> outputs same as "%X1*N".    Seems like "%X0" should be thrown out as anything valid (i.e. error) since 0 does not make sense as a qualifier anyways and it is producing single digit output.

For 'G' to 'Z', these are not real hex numbers in the normal sense though these are "nice' to have so that longer number strings are possible.  So not sure what to say there...