Welcome, Guest. Please login or register.

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

Description:

0 Members and 4 Guests are viewing this topic.

Offline Matt_H

Re: The Os 3.1.4 Thread
« on: July 18, 2019, 12:55:06 AM »
Two things:

First, Thomas, thanks so much for the work you and Olaf (and others?) are doing to polish up 3.1. It’s really great to see the classic “lightweight” branch of the OS maintained again. I’ve bought versions for my 4000T and my 2000.

Second, does the 3000 version come with a SuperKickstart file compatible with the 1.4 ROMs?
 

Offline Matt_H

Re: The Os 3.1.4 Thread
« Reply #1 on: July 18, 2019, 05:46:03 PM »
No, sorry, it does not. The ROM is a regular A3000 ROM. This being said, some users successfully converted it to a superkickstart file. As far as I remember, all you had to do is to attach the right superkickstart code at its end, where this code just comes from the original superkickstart file.

Ah, oh well. Is an official SuperKickstart planned for a later update?  Good to know there are potential workarounds in the meantime.

In the absence of a physical ROM replacement, can LoadModule successfully load in the 3.1.4 modules on a 1.4 system? (after SuperKickstart 3.1 has been softkicked, of course)
 

Offline Matt_H

Re: The Os 3.1.4 Thread
« Reply #2 on: August 13, 2019, 05:04:47 PM »
perhaps I should just switch to anaiis for AmigaOS and see how that works.
Thanks -- I didn't know about Anaiis.  I looks like it only supports subway / highway as of now.  Sirion USB stack for OS4 I guess it out of the question as of now for 3.x -- I'm not aware of any 68k version and assume there isn't any drivers for the classic zorro cards.

Sirion was originally written for the Thylacine card, so a 68K version does exist. But even the OS4 version has extremely limited driver support (for both Amiga cards and USB peripherals) and the 68K version is even older and more limited. As far as I’m aware, none of the OS4 components were ever backported.
 
The following users thanked this post: my_pc_is_amiga

Offline Matt_H

Re: The Os 3.1.4 Thread
« Reply #3 on: September 03, 2019, 04:50:48 AM »
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.
I can replicate this issue. Given that the path is listed in the string gadget just above, listing it again in the cycle gadget is unnecessary. Not sure if listing it a second time is a bug or a feature, but I think the old behavior from 3.1 is better.
 

Offline Matt_H

Re: The Os 3.1.4 Thread
« Reply #4 on: September 03, 2019, 01:47:28 PM »
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.

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

Offline Matt_H

Re: The Os 3.1.4 Thread
« Reply #5 on: September 04, 2019, 04:24:47 PM »
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

NODISKSCAN
Disables the initial automatic disk scan.

The corresponding tooltype should be added to the icon in the 3.2 release as well.
 

Offline Matt_H

Re: The Os 3.1.4 Thread
« Reply #6 on: September 04, 2019, 05:16:09 PM »
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?)
It's not useful on its own, but in conjunction with the path listed in the textfield gadget just above I think it makes sense.
Quote
3.1.4 prints the full font path.
Not necessary, in my opinion, as per above.
Quote
I now added a code to check for paths that are too long. In that case, the name is now abbreviated.
Thanks, that'll help, but I still think the cycle gadget is displaying redundant information.

Perhaps some screenshots will make it easier to explain.

Here's 3.1:
3.1_1.png: A just-started Intellifont under 3.1. Workbench:Fonts (path gadget) is recognized as the first component of Fonts: (cycle gadget).
3.1_2.png: I've clicked the cycle gadget. Path gadget changes to Work:PageStream/SoftLogik/Fonts and the cycle gadget changes to acknowledge it's the second component of my Fonts: path.
3.1_3.png: I've typed Work: into the path gadget, and the cycle gadget helpfully informs me that it's not part of the Fonts: path.
3.1_4.png: I've typed a nonsense path into the path gadget and the cycle gadget informs me it's not valid.

And here's 3.1.4:
3.1.4_1.png: A just-started Intellifont under 3.1.4. Workbench:Fonts (path gadget) is repeated in the cycle gadget.
3.1.4_2.png: I've clicked the cycle gadget. Path gadget changes to Work:PageStream/SoftLogik/Fonts and so does the cycle gadget. I don't see a reason to print this information twice.
3.1.4_3.png: I've typed Work: into the path gadget but the cycle gadget changes to Work:PageStream/SoftLogik/Fonts again. I have no way of knowing whether I've selected my intended Fonts: component (e.g., if I mistyped the path or selected the wrong directory from the ASL requester).
3.1.4_4.png: I've typed a nonsense path into the path gadget. Same behavior as 3.1.4_3.png.


Meanwhile, I can confirm my_pc_is_my_amiga's account that something is different in the startup scanning behavior. I think Intellifont always scanned DF0: (and root directories of other volumes?), but now it's scanning root and first-level directories across my whole hard drive as well. Is that the intended behavior or is that a bug?
 

Offline Matt_H

Re: The Os 3.1.4 Thread
« Reply #7 on: September 06, 2019, 03:36:20 AM »
Thomas, thanks for your answers. Some additional thoughts:

It's not useful on its own, but in conjunction with the path listed in the textfield gadget just above I think it makes sense.
For that, you must have first selected the cycle gadget, which is not necessarily the case, e.g. with CycleToMenus.
Aha! There's the issue: the UI design you're suggesting makes sense with CycleToMenu, but not without it. Maybe it's time to start bundling that commodity with the OS? Or building the functionality into GadTools?

Quote
Thanks, that'll help, but I still think the cycle gadget is displaying redundant information.
Sorry, I don't agree. It was displaying useless information. How is the font path enumeration relevant to the function of the program? How do you know which font path element corresponds to which directory without selecting it?
I looked at the successor program in OS4, TypeManager, and its cycle gadget does both, e.g., "#1: Workbench:Fonts", "#2: Work:PageStream/SoftLogik/Fonts", plus a "Not in Fonts: path" option. Maybe that's the approach to follow.

Quote
3.1_3.png: I've typed Work: into the path gadget, and the cycle gadget helpfully informs me that it's not part of the Fonts: path.
3.1_4.png: I've typed a nonsense path into the path gadget and the cycle gadget informs me it's not valid.
How is it useful to install fonts into something that is not part of the font path? The program should rather go back to one of the font paths if an invalid font is selected.
I could envision a scenario where someone would want to install some fonts in the directory of a word processor or DTP program but not have them be part of the system Fonts: path, so the option to select a non-path directory should remain.

Quote
3.1.4_2.png: I've clicked the cycle gadget. Path gadget changes to Work:PageStream/SoftLogik/Fonts and so does the cycle gadget. I don't see a reason to print this information twice.
Because it allows a quick access if you have CycleToMenu installed. The font path enumeration is useless as information to the user.
I understand the reasoning now. See above re: CycleToMenu.

Quote
3.1.4_3.png: I've typed Work: into the path gadget but the cycle gadget changes to Work:PageStream/SoftLogik/Fonts again. I have no way of knowing whether I've selected my intended Fonts: component (e.g., if I mistyped the path or selected the wrong directory from the ASL requester).
The program should indeed refuse this input and revert the gadget to one of the available paths.
I think the 3.1/OS4 behavior is better, e.g., notifying the user that it's not in the path, in case that's the user's intent like in the word processing/DTP scenario I mentioned. If the entered directory itself is invalid there needs to be some way of alerting the user that something is wrong (to replace the behavior shown in 3.1_4.png) - simply reverting to a path component makes it look like a bug. If you don't want to print an error in the cycle gadget, maybe pair the revert with a beep/screen flash?

I'm finding what I think are additional bugs in the current 3.1.4 version as well. After a non-path directory is entered and the cycle gadget is clicked again, the cycle and path gadgets get out of sync, so it's not clear where the newly installed fonts will end up.

Quote
Meanwhile, I can confirm my_pc_is_my_amiga's account that something is different in the startup scanning behavior. I think Intellifont always scanned DF0: (and root directories of other volumes?), but now it's scanning root and first-level directories across my whole hard drive as well. Is that the intended behavior or is that a bug?
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.
Interesting. I'm not quite sure I understand the rationale, but I've got the NODISKSCAN option so I'm happy. :)


 

Offline Matt_H

Re: The Os 3.1.4 Thread
« Reply #8 on: October 18, 2020, 08:08:15 PM »
Going to change topics a moment.  Installing 3.1.4 on a 3000 with 3.1.4 roms.  Using a SCSItoSD interface for the scsi.  My dh0: drive is 20 gig.  I get a "error validating system: not enough memory" message and the disk won't format.  Is there a work around for this?  I've installed os3.1.4 on a 500 and a 4000 and haven't run into this particular problem.  The 500 didn't have a very large SD and the 4000 has 128 meg of memory.  My A3000 has 8 meg fast memory and 2 meg of chip. Suggestions?

Use a larger block size in HDToolBox and you will be fine.
Go for 4096 bytes per block and it willl solve your issue.

Is 4096 bytes per block the new recommendation for all use cases? Under what circumstances should we use a different setting?
 

Offline Matt_H

Re: The Os 3.1.4 Thread
« Reply #9 on: October 19, 2020, 07:06:41 PM »
@ nbache

Very helpful, thanks. So the logic in the old days was to use a small/512 block size to maximize drive space and since overall drive sizes were small it didn't have an adverse effect on memory consumption?

I'm in the processes of setting up a new SD drive for my 500. Looks like I'll be switching to 4096 before copying my files back. :)