Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Hollywood MAL AMIStore App Store A600 Memory

AuthorTopic: The Os 3.1.4 Thread  (Read 77822 times)

0 Members and 3 Guests are viewing this topic.

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #720 on: September 08, 2019, 10:54:45 AM »
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?
Turned out to not be related to OS 3.1.4, it was a third party commodity that did more than what documentation said it would.
So, my my apologies for moaning - on "naked" OS 3.1.4, requesters work as normal.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Online my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #721 on: September 09, 2019, 12:22:42 AM »
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?
 

Online my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #722 on: September 09, 2019, 05:43:00 AM »
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?

 

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #723 on: September 09, 2019, 07:34:44 AM »
Is there a way to have this work?
Only way to have it work reliably, is to use a console replacement that features its own palette settings. One alternative is ViNCEd - http://aminet.net/package/util/shell/ViNCEd (note that this version is old, but newer versions are only included in OS 3.9, various boingbags and BestWB, with copyright Amiga Inc. - not as a single archive. Note also that these ViNCEd versions come with their own version of More which installs to S:, which is a script that work around an issue with original CBM More - this work-around is not needed with the More of OS 3.1.4 anymore, from what I understand... an updated VINCEd that get rid of confusing copyright notices and more "streamlined" installation for OS 3.1.4 owners would probably be a good idea)
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 
The following users thanked this post: my_pc_is_amiga

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #724 on: September 09, 2019, 08:37:51 PM »
1) FixFonts
I added this to the bug tracker. It's pretty minor at this point.

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?
No, a disagreement of how AmigaOs considers printers to work, and how postscript printers do work in reality. As I already explained, AmigaOs assumes a line printer, so every character is printed immediately, then the print head is moved. Or it is moved according to the control characters. Unfortunately, postscript doesn't work like that. It is a page printer system, so sequences like TAB or backspace do not work as they would work under assumption of AmigaOs.

What the postscript driver does is that it cheats. It keeps instead a line buffer, then when the Amiga transmits a control character like "backspace", it erases the last character in the line buffer, moves the "virtual print head" back, and then inserts the next character to be printed on top of it.

The line buffer is then printed on the next LF/CR.

So this is all to make the usual ASCII control sequences work "approximately correct" even if postscript does not work like that.

Of course, if the line feed never comes, the buffered line is never printed.
 

Online my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #725 on: September 10, 2019, 05:50:05 AM »
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.
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #726 on: September 10, 2019, 12:52:34 PM »
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.
Well, I added this back mostly on the basis of "it has always been like that", but quite frankly, I don't get the use-case. Actually, I think it is potentially dangerous for the common user as this type of installation is allowed, but would mostly result in non-working fonts. What also happened is that intellifont became fully localizable (so there is a catalog now).
 

Online my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #727 on: September 10, 2019, 03:28:21 PM »
Well, I added this back mostly on the basis of "it has always been like that", but quite frankly, I don't get the use-case. Actually, I think it is potentially dangerous for the common user as this type of installation is allowed, but would mostly result in non-working fonts.

I'm actually still confused over the purpose of the initial first level dir. disk scan then.  What was Intellifont doing with the scan information if not adding to the installation paths for the cycle gadget? It sounds like you added that back in now but is there something else that Intellifont is doing with that information.

Would like to understand more of why the fonts would be non-working for a non-assigned FONTS: path.

 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #728 on: September 10, 2019, 04:32:15 PM »
I'm actually still confused over the purpose of the initial first level dir. disk scan then.  What was Intellifont doing with the scan information if not adding to the installation paths for the cycle gadget?
The same it ever did. Scanning for fonts. Whatever fonts were found and not in the system appear on the left hand side for installation. Since all your fonts are already installed, it does not find any new, so the left hand remains empty for you. That was the original purpose of Intellfont - original name "Fountain" - to be a source of fonts. Thus, you can insert a font disk in any drive, click on Intellifont, and there you go.

Would like to understand more of why the fonts would be non-working for a non-assigned FONTS: path.
Well, simply because diskfont does not look for fonts there. So if I put a font outside of FONTS:, the system ASL requester does not show them.
 

Online my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #729 on: September 11, 2019, 05:51:47 AM »
Thus, you can insert a font disk in any drive, click on Intellifont, and there you go.

Thanks -- I somehow got totally confused but now it is making sense (I wasn't thinking about Source files for the disk scan at all).   This is very nice -- I tired it just now with a font disk in DF0: and it found 2 fonts that was missing from my FONTS:.   It compares what is already installed versus what was installed and listed in the source pane, 2 missing out of 3 in DF0: -- nice! I tried the older version of Intellifont and it only showed 1 out out 3 even though I had 2 missing.  So it seems to be better there.

A few feedbacks:

It scans the RAD: disk but does not scan RAM: disk.   Only reason for a RAM: disk scan would be if I had found a bunch of fonts to install and put them in RAM (like from Aminet)

For the left side pane, would be nice to have some kind of cycle gadget as well.  Maybe 1 cycle for the listing of the disk scan and a way to add to the cycle gadget list with the file folder.  For example, if I had decided to insert a CD-ROM  after launching the program, I could add some fonts to install but could still go back to the disk scan list as well. The way it works now is the "disk scan" list gets removed with whatever is put in by the user by the file folder icon.   

One other thing I noticed is if I do a manual source add to DF0: then it doesn't scan the 1st level directories.  I have to go to the specific font dir. one by one. 
« Last Edit: September 11, 2019, 05:55:40 AM by my_pc_is_amiga »
 

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #730 on: September 11, 2019, 10:40:59 AM »
What happens to "Fonts:" when you insert a disk labeled "Fonts"? Where does "Fonts:" take you? :)
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #731 on: September 11, 2019, 05:08:38 PM »
What happens to "Fonts:" when you insert a disk labeled "Fonts"?
Nothing. The fonts target is only computed from DLT_DIRECTORY entries in the DosList. As far as ASL or DiskFont is concerned: They don't mind whether the volume is FONTS: or FONTS: is an assign. Which is also the reason why the install disks are named Fonts and Locale (and not Fonts3.1.4 and Locale3.1.4).
 

Offline Thomas Richter

Re: The Os 3.1.4 Thread
« Reply #732 on: September 11, 2019, 05:19:25 PM »
So it seems to be better there.
For some reason, it only scanned disks if the disk was handled by the trackdisk.device. Which today makes little sense as you probably want to install fonts from CD, a USB thumbdrive and so on...

It scans the RAD: disk but does not scan RAM: disk.
That's right. It only scans devices that have a "startup vector" and hence are usually handled by some sort of file system. RAM: does not fall into this scheme, even though it is a file system by its own. Why that decision was made is unclear to me. This is legacy code.

One other thing I noticed is if I do a manual source add to DF0: then it doesn't scan the 1st level directories.  I have to go to the specific font dir. one by one.
That's correct. This is due to the format on which such "font add-on disks" where supposed to be delivered. You can read a bit more on this in the in-program help (press "HELP", then click on all the buttons - probably try the source button). There are two types of "font add-on disks" supported: The Amiga "font library disks", and so called PC "FAIS" disks. Foramts are a tiny bit different, and intellifont has scanning support for both of them. They had fonts in particular directories the program would find, and only such directories or places are scanned.

From the way how the code looks, I would say that this is essentially an Agfa program that was originally developped for PC, and then ported over to Amiga (with more or less success), taking the concepts of the PC workflow with it. The same also applies to the "bullet.library" which is actually an Agfa (compugraphic) library that was (rather poorly) ported to Amiga, and then, with lots of effort, fixed by Olaf.

For example, the bullet library in its original (3.1) incarnation was not even a proper library. Only one program could use it at a time. If more than two fonts were supposed to be created at the same time, they would both use the same global space in the library, overwriting each others data. As said, Olaf fixed this for 3.9, and it was a little polished for 3.1.4.
 

Offline utri007

Re: The Os 3.1.4 Thread
« Reply #733 on: September 12, 2019, 08:15:48 PM »
What about if I just want to burn eprom, but not install OS3.1.4 update. Files on update floppy doens't seem to be ready modules?
ACube Sam 440ep Flex 800mhz, 1gb ram and 240gb hd and OS4.1FE
A1200 Micronic tower, OS3.9, Apollo 060 66mhz, xPert Merlin, Delfina Lite and Micronic Scandy, 500Gb hd, 66mb ram, DVD-burner and WLAN.
A1200 desktop, OS3.9, Blizzard 060 66mhz, 66mb ram, Ide Fix Express with 160Gb HD and WLAN
A500 OS2.1, GVP+HD8 with 4mb ram, 1mb chip ram and 4gb HD
Commodore CDTV KS3.1, 1mb chip, 4mb fast ram and IDE HD
 

Offline Gulliver

Re: The Os 3.1.4 Thread
« Reply #734 on: September 13, 2019, 07:45:33 PM »
What about if I just want to burn eprom, but not install OS3.1.4 update. Files on update floppy doens't seem to be ready modules?

Please refer to section 9.3 of the AmigaOS 3.1.4 FAQ.

http://aminet.net/docs/help/AmigaOS_3.1.4-FAQ.txt