Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A600 Memory

AuthorTopic: The Os 3.1.4 Thread  (Read 80906 times)

0 Members and 3 Guests are viewing this topic.

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #675 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 #676 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 #677 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 kolla

Re: The Os 3.1.4 Thread
« Reply #678 on: August 29, 2019, 06:27:06 AM »
Of course, "eval" cannot compute anything from that, so it prints an error.

Well, it doesn't print any error, and that's the real bug here.

B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #679 on: August 29, 2019, 06:52:50 AM »
Of course, "eval" cannot compute anything from that, so it prints an error.

Well, it doesn't print any error, and that's the real bug here.
Sorry, what? Eval prints an error. List does not, never did. printf() neither prints or returns an error for an unknown formatting string.
 

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #680 on: August 29, 2019, 07:11:59 AM »
Sorry, what? Eval prints an error.
OK, sure, if you say so - this "attitude of denial" is what I disliked when sending bug reports to you.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 
The following users thanked this post: my_pc_is_amiga

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #681 on: August 29, 2019, 10:56:56 AM »
As my_pc_is_amiga wrote, on OS4 this makes more sense, eval gives an error.
« Last Edit: August 29, 2019, 10:58:58 AM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 
The following users thanked this post: my_pc_is_amiga

Offline paul1981

Re: The Os 3.1.4 Thread
« Reply #682 on: August 29, 2019, 12:05:00 PM »
  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).

On a Hires or Hires Laced PAL/NTSC screen with a Hires pointer the pointer will not be interlaced. Is this what you mean? On a Multiscan screen you will get a Hires pointer of a double vertical resolution too (640x480 which matches the screen mode). Remember also that the aspect ratio of 640x480 is different to 640x400 which does make a difference. I believe there is a program on aminet to Lace the pointer.

Online Gulliver

Re: The Os 3.1.4 Thread
« Reply #683 on: August 29, 2019, 01:32:50 PM »
  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).

On a Hires or Hires Laced PAL/NTSC screen with a Hires pointer the pointer will not be interlaced. Is this what you mean? On a Multiscan screen you will get a Hires pointer of a double vertical resolution too (640x480 which matches the screen mode). Remember also that the aspect ratio of 640x480 is different to 640x400 which does make a difference. I believe there is a program on aminet to Lace the pointer.

I was thinking the exact same thing. When the screen mode proportions change, so does the mouse pointer.
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #684 on: August 29, 2019, 05:20:03 PM »
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.
Well, I checked. *N does get parsed correctly. Also, Eval doesn't do anything wrong, it just uses VFWritef of the dos.library. The dos.library however just swallows the character following the %X, and ignores it if it is not in range. Actually, as part of the tripos library, it not only accepts hex digits there, but anything. 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'.
 

Offline my_pc_is_amiga

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

 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #686 on: August 30, 2019, 05:40:16 AM »
Quote from: paul1981 link=topic=73661.msg844992#msg844992

On a Hires or Hires Laced PAL/NTSC screen with a Hires pointer the pointer will not be interlaced. Is this what you mean? On a Multiscan screen you will get a Hires pointer of a double vertical resolution too (640x480 which matches the screen mode). Remember also that the aspect ratio of 640x480 is different to 640x400 which does make a difference. I believe there is a program on aminet to Lace the pointer.

Not sure if related to pointer interlace or not but that sounds like the issue or the affect that is happening.  On a hires screen (no interlace), why would the pointer need to laced? I can kind of understand it for hires interlace but not hires.   

The "http://aminet.net/package/util/misc/LacePointer" only works for lores pointer mode.   LoRes pointer mode does not seem to have any strange affects in the aspect ratio from what I recall or seen recently in other screenmodes...I haven't check thoroughly though.
« Last Edit: August 30, 2019, 05:53:57 AM by my_pc_is_amiga »
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #687 on: August 30, 2019, 05:43:53 AM »
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...
Eval does not attempt to validate the formatting pattern. It just uses them to do the formatting by the dos.library. That the pattern looks so strange is part of the BCPL legacy. Actually, the whole rule that the digit or number after the X is the field width comes from BCPL, and that letters A to Z are valid there also comes from BCPL. It's part of the syntax defined by the language.
 

Offline paul1981

Re: The Os 3.1.4 Thread
« Reply #688 on: August 30, 2019, 09:35:18 PM »

Not sure if related to pointer interlace or not but that sounds like the issue or the affect that is happening.  On a hires screen (no interlace), why would the pointer need to laced? I can kind of understand it for hires interlace but not hires.   

The "http://aminet.net/package/util/misc/LacePointer" only works for lores pointer mode.   LoRes pointer mode does not seem to have any strange affects in the aspect ratio from what I recall or seen recently in other screenmodes...I haven't check thoroughly though.

I was just stating that the pointer on a Hires PAL or NTSC screen will not be interlaced even if in an interlaced mode. I suppose Commodore chose this behaviour because an interlaced pointer would drive the user crazy without a flicker fixer (only minority of users had these)...who knows?! That's my best guess.

Interestingly though, when this happens and the user is using a Hires pointer on a Hires Laced screen, obviously the pointer accuracy is only at half vertical resolution because it's not laced...but this isn't quite true. I just tested it with the multiple selection (hold left mouse down to select icons) and you do get the full vertical resolution accuracy in reality, but the pointer only updates it's vertical position on every 2nd row (it can't do any other as it's not laced). If you use the keyboard controls to move the mouse you can clearly see this behaviour - a movement left or right is one keypress at a time per pixel, but for the vertical direction it takes two keypresses to move the mouse pointer that you see, but Workbench does 'see' that bit inbetween that it couldn't show with the pointer so the mouse does actually run at full laced resolution. I think there should be an option to lace the pointer in interlaced screenmodes via Pointer Prefs. I haven't tested A multiscan interlaced screen, but I'd bet that the pointer would not be laced either.
« Last Edit: August 30, 2019, 09:37:56 PM by paul1981 »
 

Offline trekiej

Re: The Os 3.1.4 Thread
« Reply #689 on: August 31, 2019, 01:19:09 AM »
My A2000 has a 68000 in it.
Would 3.1.4 have to make a Look Up Table for Floating Point Operations?
Amiga 2000 Forever :)
Welcome to the Planar System.