The Os 3.1.4 Thread

[my_pc_is_amiga]

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

[my_pc_is_amiga]

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.

[my_pc_is_amiga]

I haven't heard if this one was reproducible?

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>



Also, what is correct behavior of CMD when using ASL.  I'm seeing this behavior:
1) Launch CMD (without "FILE" specified) and can set MULTIPLE=FALSE.
2) echo >prt: "Test" in shell.
3) ASL comes up and hit cancel.
4) Wait for some time and requester comes up saying "Check Printer"
5) Hit cancel in requester and this hit comes.

"Capture.txt" --> first capture.
"Capture2.txt" --> 2nd capture after I did a reboot.

Would it make sense that cancel in ASL just cancels entire redirection and also cancel anything going to PRT:?

[my_pc_is_amiga]

ED in 3.1.4 when executed from an existing shell does not open a new console window.  Instead it is using the existing one. 

What I'm finding though is that if I am in a serial terminal shell then I am getting this hit.

1) On Amiga host do the following in the shell:
a) mount AUX:
b) newshell AUX:

2) On serial terminal on remote computer do the following:
ed t:new

3) Hit happens as attached.

Older version of ED will open up new console window on host and no hit.

[my_pc_is_amiga]

I beiieve I found this one. It is a bit hairy and hard to reproduce. The trouble is that CMD apparently used the output buffer of the asl requester to construct
a new unique file name for multiple redirection.

Would it make sense that cancel in ASL just cancels entire redirection and also cancel anything going to PRT:?

Hmm. The question is what "cancel" means for you. I suppose it means "cancel the redirection".

Thanks -- in this test case I used single redirection but I guess it is same issue. 

For me cancel would mean to cancel the entire "job" to PRT: and not send anything but "cancel redirection" alone would be okay.   This is more of a documentation or FAQ thing so that the user can be aware.

How about the the print output of the CMD "Redirected 172 bytes from parallel.device to RAM:CMD_File2" when this is only suppose to be 86 bytes?

[my_pc_is_amiga]

ED in 3.1.4 when executed from an existing shell does not open a new console window.  Instead it is using the existing one. 

Yes. This is intentional.

Cool -- does this mean that ED can work in serial terminal mode (i.e. no menus)?

[my_pc_is_amiga]

The SYS:System/Intellifont behavior has changed a little in 3.1.4.  When starting-up it is actually scanning all of my volume's first level directories for fonts and not just the FONTS: assign and so it is taking some time now to start up.   Also, the cycle gadget now contains the complete path instead of the text "Fonts: Path Component #1" This is okay except the path text is not fitting in the cycle gadget and so the text goes onto other portions of the GUI.

[my_pc_is_amiga]

I ran SnoopDos and do see a difference in the 3.1.4 version and found out there is a NODISKSCAN flag that is not there in 3.1.   When I run with this option, then I see same scanning behavior as 3.1. 

If the new diskscan option is suppose to show all Intellifont directories besides the FONTS: assign, then it isn't doing that.  Only the FONTS: assign shows up in the cycle gadget for me.

A separate thing is in regards to the cycle gadget in the 3.1.4 version.  The cycle gadget in 3.1 shows "Not in Fonts: Path" when adding a path with the file folder gadget when that is not in the FONTS: path.  This is not happening with 3.1.4 -- i.e. there is no text like that.

The SYS:System/Intellifont behavior has changed a little in 3.1.4.  When starting-up it is actually scanning all of my volume's first level directories for fonts and not just the FONTS: assign and so it is taking some time now to start up.   

Actually, this did NOT change. Intellifont always scanned all inserted volumes for fonts.

[my_pc_is_amiga]

Cool -- does this mean that ED can work in serial terminal mode (i.e. no menus)?

That is the idea, yes.

Nice!

[my_pc_is_amiga]

Thanks!  The bigger thing is that that there is no way to add another font path to the cycle gadget list.   In 3.1, you could add a path and that would show up in the cycle gadget list.   This is not happening anymore.   

Side point -- getting the Intellifont template with the 3.1 version in the shell shows 1 option only, VALIDATE/S. In 3.1.4 it is VALIDATE/S, NODISKSCAN/S

I can replicate this as well. Definitely starting to look like a bug was accidentally introduced in the cycle gadget.

The 3.1 version just printed that the directory was in component #n of the path, which was not very useful at all. (How do you count that and why is this
useful information?) 3.1.4 prints the full font path. I now added a code to check for paths that are too long. In that case, the name is now abbreviated.

[my_pc_is_amiga]

Thanks Matt_H for taking the screenshots -- those are very good!   What screen grab program are you using?

[my_pc_is_amiga]

That is intended, of course. It should scan all media, not just some media. It is getting even weirder - depending on the file system of the media, it scanned in different formats.

But valid font directories that are not in the FONTS: assign are not showing up in the cycle list.

[my_pc_is_amiga]

No way to turn _that_ damn "feature" off? I want the requesters to pop up like they used to - in the upper left corner, far away from where I am working, thank you very much!

Have your tried the ASL prefs program to change position and then used the "Override application" option?

[my_pc_is_amiga]

1) FixFonts

a) Executing FixFonts from workbench does not give the user any DOS error message and doesn't show that it completed properly.  From the shell it does give DOS error but it is not too informative as to what file is causing the problem.   This is just an example below.  I actually had a #?.font file that was write protected but had to search it as I did not know which one.

>protect FONTS:emerald.font -w
>FixFonts
FixFonts failed: file is write protected  (Shell gives this


2) If I send this to Postscript printer
echo >PRT: "TEST" NOLINE

Then nothing gets printed.  I'm attaching the CMD output.

With echo >PRT: "TEST", it prints okay (it looks like it needs a LF/CR).  Is this a bug?

[my_pc_is_amiga]

I have this in my shell-startup to set the background to black and foreground text to white. 

Code: [Select]

echo "*e[>1m*e[32;41m*e[0;0H*e[J"
prompt "*n*e[>1m*e[33;41m*e[1m%N.%R.*e[30;41m%S>*e[0m*e[32;41m "
alias CLS "echo *"*E[0;0H*E[J*""

With more and Ed in the same console window, this is not always working.  More when hitting space to next page starts to put background in grey.  Ed does not put text to white.  Is there a way to have this work?

[my_pc_is_amiga]

1) FixFonts

I added this to the bug tracker. It's pretty minor at this point.

Yeah -- definitely a minor issue.  Thanks for adding it to the bug tracker.   Do you have any more comments on the Intellifont?   The larger concern IMO is that I can't tell if any non-FONTS: path can be added to cycle gadget.   From the auto disk scan it doesn't seem to be adding and if I do it manually with File Folder gadget I can't tell.