Amiga.org

Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: kolla on October 25, 2019, 10:47:22 AM

Title: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on October 25, 2019, 10:47:22 AM
Since other threads about "OS 3.1.4" and "Os 3.2" keep derailing because of "most users" who prefer to not see any discussion on the actual operating system, and rather wish that everyone shut up and just hail the whatever the "official team" might come up with... here is an alternative thread, where those of us who are not unconditional "yes men" can also air our thoughts regarding the development of the operating system that is among our favourite hobbies.

From your point of view
- have there been changes in OS 3.1.4 (and the 3.2 preview) that you like in particular?
- have there been changes that you don't like so much?
- have there been changes that are irrelevant for how you use the Amiga?
- have you found bugs? have you reported them? what happened?
- have you needed to make work-arounds as counter-measures for bugs and changes in the OS?
- have you found unintended "features" in the updates that can be exploited in cool ways?
 - what more changes and improvements do you wish to see?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on October 25, 2019, 11:03:04 AM
I can start with saying that the number one killer feature in OS 3..4 for me, is 68000 support for v45 Workbench and ASL prefs.

Sadly the Workbench prefs does not include the Ghostbuster functionality (http://aminet.net/package/util/cdity/GhostBuster) and the OS developers seem incapable of understanding why anyone would wish to hide a device icon, especially since it would prevent the user from selecting the hidden device and formatting it (not really, but that is what an OS developer has given as reason) - and I wish for that functionality for 6800 systems as well - Ghostbuster comes with sources, but it uses Reaction, for which there is no 68000 support, plus I am no big fan of Reaction in the first place. So what to do, what to do... aside from cloning the Workbench prefs program from fresh, there is one option, I suppose - use the Ghostbuster commodity, and just binary patch the prefs (or wait for OS 3.1.4 sources to leak).

Regarding ASL.. I prefer v45 ASL over ReqTools and others, so I use http://aminet.net/package/util/misc/AslToRT (http://aminet.net/package/util/misc/AslToRT) to trap calls to reqtools.library etc and use ASL requesters instead. A more "clean" way, like implementing reqtools.library as a wrapper for ASL, would probably be preferable. Lastly, the "official" family of C:Request#? programs has always been lacking one member - RequestString - there is a myriad of third party variants around, mostly incompatible with each other - it would be very useful with an official RequestString that make all the others redundant.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: F0LLETT on October 25, 2019, 11:04:39 AM
I personally have not seen any issues, when using 3.1.4-2.
However the only thing I dream of is a romable module to scan for CD-ROM, if found mount it. So we no longer need stuff in the DosDrivers to mount it.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on October 25, 2019, 11:19:43 AM
There is no generally valid way how to identify a CD-Rom, or in particular, a device a CD ROM could be connected to. Only those boards that come with an on-board SCSI or IDE might be able to support it. The CDFileSystem itself is ROM-able, though.

Even then, we are out of ROM space and the CDFilesystem does not fit in anymore (about 16K remains free). Before you argue "but we could have 1M ROMs"... well, we could not. The lower 0xE0 ROM space is now populated by the Vampires, so this option is taken as well.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: F0LLETT on October 25, 2019, 11:56:09 AM
There is no generally valid way how to identify a CD-Rom, or in particular, a device a CD ROM could be connected to. Only those boards that come with an on-board SCSI or IDE might be able to support it. The CDFileSystem itself is ROM-able, though.

Even then, we are out of ROM space and the CDFilesystem does not fit in anymore (about 16K remains free). Before you argue "but we could have 1M ROMs"... well, we could not. The lower 0xE0 ROM space is now populated by the Vampires, so this option is taken as well.

How does ATAPIMajik work. That seems to detect fine.
Yes, CDFileSystem is romable but pointless, if it doesn't mount CD-ROM.

I don't own and never will own a Vampire, so Im not interested in it taking up space.
What about catering for both. People who use there Amiga as is and people who want to nuts on upgrades.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on October 25, 2019, 12:18:38 PM
How does ATAPIMajik work. That seems to detect fine.
As the name suggests, it probably only addresses ATAPI CDRoms connected to the on-board scsi.device - if you have one. But that is the easiest part of the problem - it already has a device name ("scsi.device"). The hard part is to find the name of a device a CDRom could be connected to, because there are so many. ("gvpscsi.device", "omniscsi.device", "oktagon.device", "2060scsi.device" just to name some I am aware of). In general, if you have a device name, you do not know whether this is something "scsi-like" or something completely different that may crash or do some other strange things if you try to submit a "HD_SCSICMD" to it.

Thus, in general, the problem cannot be solved without some additional knowledge of the host adater available on the system, and this knowledge has to come from the user creating (or modifying) a mount-list for the CDFileSystem.

Yes, CDFileSystem is romable but pointless, if it doesn't mount CD-ROM.
Right, and creating a suitable mount file is something that cannot be automated for reasons given above. There is no generally valid and robust way how to detect a device a CDRom may be potentially connected to. It requires some user-interaction and some knowledge on the components installed in the system.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: F0LLETT on October 25, 2019, 12:44:02 PM
How does ATAPIMajik work. That seems to detect fine.
As the name suggests, it probably only addresses ATAPI CDRoms connected to the on-board scsi.device - if you have one. But that is the easiest part of the problem - it already has a device name ("scsi.device"). The hard part is to find the name of a device a CDRom could be connected to, because there are so many. ("gvpscsi.device", "omniscsi.device", "oktagon.device", "2060scsi.device" just to name some I am aware of). In general, if you have a device name, you do not know whether this is something "scsi-like" or something completely different that may crash or do some other strange things if you try to submit a "HD_SCSICMD" to it.

Thus, in general, the problem cannot be solved without some additional knowledge of the host adater available on the system, and this knowledge has to come from the user creating (or modifying) a mount-list for the CDFileSystem.

Yes, CDFileSystem is romable but pointless, if it doesn't mount CD-ROM.
Right, and creating a suitable mount file is something that cannot be automated for reasons given above. There is no generally valid and robust way how to detect a device a CDRom may be potentially connected to. It requires some user-interaction and some knowledge on the components installed in the system.

Fair enough. Thanks for the info.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: Gulliver on October 25, 2019, 01:36:04 PM
ATAPIismajik besides using a cdfilesystem (BootCDFilesystem) works together with the CDMounter command to mount cdroms.

It only works, as Thomas mentioned in a very few select device interfaces, which are:

scsi.device
2ndscsi.device (A4000T scsi)
cybppc.device (CyberStormPPC scsi)
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: Louis Dias on October 25, 2019, 03:11:35 PM
The CD32 can boot from CDROM...

Long live the CD32's extended ROM!
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on October 25, 2019, 04:38:06 PM
The CD32 can boot from CDROM...
Yes, of course. But this is not an art and quite easy. It has a CD fie system in ROM (a precursor of the CDFileSystem we have now), and the init function of the ROM component creates a DosList entry (aka "mount entry") that starts the CD file system on the scsi.device.

But as said, it is easy in this case, the mount parameters are known.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: F0LLETT on October 25, 2019, 05:24:16 PM
ATAPIismajik besides using a cdfilesystem (BootCDFilesystem) works together with the CDMounter command to mount cdroms.

It only works, as Thomas mentioned in a very few select device interfaces, which are:

scsi.device
2ndscsi.device (A4000T scsi)
cybppc.device (CyberStormPPC scsi)

That situation is what I would expect. This is why I said about it. We are talking about default config, not fancy stuff. So booting from CD with scsi.device and 2ndscsi.device would be great.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: paul1981 on October 25, 2019, 10:50:48 PM
I personally have not seen any issues, when using 3.1.4-2.
However the only thing I dream of is a romable module to scan for CD-ROM, if found mount it. So we no longer need stuff in the DosDrivers to mount it.

Why though? I honestly don't understand this... it's two files isn't it stored on the boot disk. Why have it in ROM? If it's CD booting you're after, then I'm sure you're aware it can be achieved via scripting in your startup-sequence.
Also, this leads me to something which no one has mentioned really which is the poor old 68000. The more bloat added in the OS or ROM, the slower it will be for poor 7MHz 68000 users who will certainly notice the difference.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: F0LLETT on October 25, 2019, 11:11:10 PM
I personally have not seen any issues, when using 3.1.4-2.
However the only thing I dream of is a romable module to scan for CD-ROM, if found mount it. So we no longer need stuff in the DosDrivers to mount it.

Why though? I honestly don't understand this... it's two files isn't it stored on the boot disk. Why have it in ROM? If it's CD booting you're after, then I'm sure you're aware it can be achieved via scripting in your startup-sequence.
Also, this leads me to something which no one has mentioned really which is the poor old 68000. The more bloat added in the OS or ROM, the slower it will be for poor 7MHz 68000 users who will certainly notice the difference.

Thats why there are different roms for different machines. Like using floppy or HDD, I would rather it all there on boot on a 1200 / 4000.
Anyways, Ill just stick to my CD32 startup-sequence.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: paul1981 on October 26, 2019, 10:56:25 PM
I personally have not seen any issues, when using 3.1.4-2.
However the only thing I dream of is a romable module to scan for CD-ROM, if found mount it. So we no longer need stuff in the DosDrivers to mount it.

Why though? I honestly don't understand this... it's two files isn't it stored on the boot disk. Why have it in ROM? If it's CD booting you're after, then I'm sure you're aware it can be achieved via scripting in your startup-sequence.
Also, this leads me to something which no one has mentioned really which is the poor old 68000. The more bloat added in the OS or ROM, the slower it will be for poor 7MHz 68000 users who will certainly notice the difference.

Thats why there are different roms for different machines. Like using floppy or HDD, I would rather it all there on boot on a 1200 / 4000.
Anyways, Ill just stick to my CD32 startup-sequence.

We can't have a 1MB ROM now anyway to fit this extra stuff in thanks to the Vampire.  It seems they're going to be very successful - I'd love to have a stake in them.  :P
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: TribbleSmasher on October 26, 2019, 11:25:56 PM
Seems like you misspelled stake for stab... :P
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: F0LLETT on October 26, 2019, 11:37:33 PM
I personally have not seen any issues, when using 3.1.4-2.
However the only thing I dream of is a romable module to scan for CD-ROM, if found mount it. So we no longer need stuff in the DosDrivers to mount it.

Why though? I honestly don't understand this... it's two files isn't it stored on the boot disk. Why have it in ROM? If it's CD booting you're after, then I'm sure you're aware it can be achieved via scripting in your startup-sequence.
Also, this leads me to something which no one has mentioned really which is the poor old 68000. The more bloat added in the OS or ROM, the slower it will be for poor 7MHz 68000 users who will certainly notice the difference.

Thats why there are different roms for different machines. Like using floppy or HDD, I would rather it all there on boot on a 1200 / 4000.
Anyways, Ill just stick to my CD32 startup-sequence.

Im using 1 MB ROM now with latest 3.1.4-2
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on October 27, 2019, 10:38:58 AM
- have there been changes that you don't like so much?
Yes there have been, several, but let's start with the most serious one - the new shell v46.

While I have enjoyed following the development of shell v45, v46 comes with a number problems:
  * it is buggy, changes are many and so are the bugs, they manifest themselves in the strangest ways and without access to neither sources, nor documentation (aside from the v45 guide on aminet), nor bug tracker, it is sometimes extremely tricky to fathom wtf is going on.
  * it is totally unnecessarily embedded in kickstart ROM chips, meaning its problems are "frozen" -
  * it introduces features "taken out of thin air", no consulting or interaction whatsoever with the shell users at large
  * its features are utter overkill for the so called "most users"
  * many of its features are pointless or have "issues" since they rely on a third party product to work as intended
   (a product with unclear legal status, an update with all ties to to Amiga Inc. removed would clear this up)

If I was Hyperion, I would not have allowed shell v46 in the kickstart chips. I would have insisted on keeping the built in kickstart shell small and tidy and, only with the limited set of required features - all this to make sure it is as tiny and as rock solid as possible. A cleaned up OS 3.1 shell, an amiga equivalent of POSIX /bin/sh. And then this minimal shell can be replaced on boot by more experimental, feature rich v46/47/whatever L:Shell-Seg on boot by SetPatch. And I would not make it available on ROM chips until at least a few months of testing "in the wild".

More later.

Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: giZmo350 on October 27, 2019, 04:01:50 PM

  * many of its features are pointless or have "issues" since they rely on a third party product to work as intended
   (a product with unclear legal status, an update with all ties to to Amiga Inc. removed would clear this up)

I agree with this 110%.... Nothing against the devs creating this HW but, supporting their HW in ROM makes NO sense to me. They [the 3rd party HW devs] could easily supply an install kit that handles ALL of their HW requirements. SoftKick it! Constant changes could be downloaded & they could make it as dang bloody big as they wanted to! Supporting their HW in ROM seems to be a marketing ploy more than anything.

When I build a machine, whether it be Amiga, DOS 6.X, Win3.X, Win9.X, Apple 68K, (where the BIOS doesn't support optical drives), the first thing I do is get the optical drive working - especially auto-boot! It's a must for me.

If CDDA (auto boot - auto start) support were built into Amiga ROM, that would be a HUGE game changer for me & maybe for a lot of other users! Just load my 68K optical drive supporting software and go! It may be the number one reason users moved to newer HW back in the 90's. It was for me - all HW platforms!

Using 3.2.X ROM space to support optical drives would be a pure joy. I would buy it! Kiss that ERD goodbye!  ;)
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: TribbleSmasher on October 27, 2019, 06:09:56 PM
I would rather like to see full PCMCIA support for booting CF cards, micro HDDs etc...
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on October 28, 2019, 12:44:26 PM

  * many of its features are pointless or have "issues" since they rely on a third party product to work as intended
   (a product with unclear legal status, an update with all ties to to Amiga Inc. removed would clear this up)

I agree with this 110%.... Nothing against the devs creating this HW but, supporting their HW in ROM makes NO sense to me.

Hm - HW as in hardware? I was talking about third party software, not hardware (I thought this was obvious)
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: F0LLETT on October 28, 2019, 01:15:31 PM

  * many of its features are pointless or have "issues" since they rely on a third party product to work as intended
   (a product with unclear legal status, an update with all ties to to Amiga Inc. removed would clear this up)

I agree with this 110%.... Nothing against the devs creating this HW but, supporting their HW in ROM makes NO sense to me.

Hm - HW as in hardware? I was talking about third party software, not hardware (I thought this was obvious)

Yes, but he has a point. Why support Vampire in the rom and not CD-ROM on ide scsi thats already part of the machine.

I would rather like to see full PCMCIA support for booting CF cards, micro HDDs etc...

This too would be awesome.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on October 29, 2019, 06:06:02 AM
Yes, but he has a point. Why support Vampire in the rom and not CD-ROM on ide scsi thats already part of the machine.
There is no Vampire support in kickstart ROM, I don't know why you suggest that there is.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: F0LLETT on October 29, 2019, 03:08:48 PM
Even then, we are out of ROM space and the CDFilesystem does not fit in anymore (about 16K remains free). Before you argue "but we could have 1M ROMs"... well, we could not. The lower 0xE0 ROM space is now populated by the Vampires, so this option is taken as well.

Yes, but he has a point. Why support Vampire in the rom and not CD-ROM on ide scsi thats already part of the machine.
There is no Vampire support in kickstart ROM, I don't know why you suggest that there is.

Misread, it takes up address space. Point is, there should be no worrying about other hardware. Each amiga is as is. So it should be updated on that basis.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: slaapliedje on October 29, 2019, 11:51:38 PM
I could see how CD-ROM booting would be difficult to achieve, unless you only supported it for systems that have onboard IDE or SCSI by default, or possibly anything that was from Commodore.  Hell, the CSPPC is supposed to have that feature, but I don't think I've ever gotten it to actually work.

I'd like to see the 060 libraries included, but I'm not sure how generic they are, if they work with all accelerators, etc.  But at least they fixed it so it'll detect an 060 and will still actually boot and complain that the libraries aren't in place.

I completely agree getting some of the 'standard' functions in to KS/WB that have been third party things for years.  Hell, I wish MUI could become part of the standard install at this point.  I'm sure it's on the list of 'things to do during a fresh install' since so much software relies upon it.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: TribbleSmasher on October 30, 2019, 06:49:13 PM
Well, for ROM updates sooner or later a reboot will be required, maybe there is a way to configure a path from within loadmodule can install a resetproof cd device and filesystem....
So the configuration would not happen on the very first boot, but after the full installation.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: DamageX on October 31, 2019, 01:02:06 AM
I'm not up to speed on everything so I could be talking nonsense, but what about making a compressed ROM image which is able to fit more stuff. The kickstart on '030+ systems is often copied to fastRAM anyway.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: giZmo350 on October 31, 2019, 01:34:35 AM
Yea, fit more stuff. It could be decompressed on the fly at boot up and copied to RAM:  and off you go.... with a SCSI CDRW whirring away!  Great observation DX! The forum needs new blood like you!  8)
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on October 31, 2019, 06:05:07 AM
But at least they fixed it so it'll detect an 060 and will still actually boot and complain that the libraries aren't in place.
The kickstart makes sure that any 040/060 (or similar) FPU is "turned off" on initial boot, and then Setpatch turns it on when loading appropriate CPU libraries.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on October 31, 2019, 06:18:34 AM
I'm not up to speed on everything so I could be talking nonsense, but what about making a compressed ROM image which is able to fit more stuff. The kickstart on '030+ systems is often copied to fastRAM anyway.
I believe your first observation is the most accurate one :) At best, only parts of the kickstart can be compressed, and you would also need a decompressor and validator in place... it quickly grows bigger than what you gain.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on October 31, 2019, 06:22:27 AM
Yea, fit more stuff. It could be decompressed on the fly at boot up and copied to RAM:  and off you go.... with a SCSI CDRW whirring away!  Great observation DX! The forum needs new blood like you!  8)

You can do _all you need_ if you just add a boot device to your system that contains the needed kickstart modules. It can be a partition on a disk, a floppy... anything.  Personally, I am leaning to doing what old 68k Macs had all those years ago - a dedicated "magic" partition at the start of the hard drive, dedicated for ROM modules and updates. One can argue that Amiga users should be smart enough to not need this, and just have the components floating around in SYS:, but I am not so sure.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on October 31, 2019, 06:27:13 AM
The lower 0xE0 ROM space is now populated by the Vampires, so this option is taken as well.

The Vampires already support 1MB kickstarts, AROS uses 1MB kickstarts, and if there is any trouble regarding addresses, the Vampire products are still supported and the issues can be dealt with in updates. So, I believe your argument is pretty weak.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on October 31, 2019, 08:10:26 AM
The lower 0xE0 ROM space is now populated by the Vampires, so this option is taken as well.

The Vampires already support 1MB kickstarts, AROS uses 1MB kickstarts, and if there is any trouble regarding addresses,
The vampires use the lower kickstart area to patch in their exec scheduler replacement for the extended register set, and their own AROS image (which comes with the modified scheduler). The original kickstart does not run unmodified on it to my very knowledge. There is some on-the-fly patch addressed to it to make it search the lower 512K area (which is not populated and not in the kick modules search list).

Thus, instead of following good engineering practise and use available extension mechanisms such as autoconf or the F-space ("debug") ROM or a CPU library, the vampire relies on its own mechanisms, which partially populates the E0-area, yes.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on October 31, 2019, 08:13:36 AM
Thus, instead of following good engineering practise and use available extension mechanisms such as autoconf or the F-space ("debug") ROM or a CPU library, the vampire relies on its own mechanisms, which partially populates the E0-area, yes.

Good, then I suggest ignoring the Vampire cards and if things break, it will be up to them to fix it - after all, the 68080 has a proper MMU which they control fully, how hard can it be.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on October 31, 2019, 08:28:00 AM
Good, then I suggest ignoring the Vampire cards and if things break, it will be up to them to fix it - after all, the 68080 has a proper MMU which they control fully, how hard can it be.
I don't know what you call "proper", and I don't see how the (rather minimal and incompatible to anything instead of proper) MMU has to do anything with the issue. It cannot remap address spaces.

Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on October 31, 2019, 09:53:25 AM
I don't know what you call "proper", and I don't see how the (rather minimal and incompatible to anything instead of proper) MMU has to do anything with the issue. It cannot remap address spaces.
From what I understand, that is the entire job of the "proper MMU" of the 68080 on the Vampire cards - to map addresses around so that AmigaOS (or EmuTOS) finds what it expects at the addresses it expects. For example, with "v3 core", map the entire chipset register address space out to where SAGA is located.

But regardless of this, it should be none of your concerns, and instead a concern for those who keep breaking "the rules".
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: DamageX on November 01, 2019, 12:12:30 AM
I'm not up to speed on everything so I could be talking nonsense, but what about making a compressed ROM image which is able to fit more stuff. The kickstart on '030+ systems is often copied to fastRAM anyway.
I believe your first observation is the most accurate one :) At best, only parts of the kickstart can be compressed, and you would also need a decompressor and validator in place... it quickly grows bigger than what you gain.
Everything except the initial hardware diagnostics and the decompressor could be compressed. Decompressor is easily less than 1KB. BTW, this is how PC BIOS ROMs have been since the mid '90s.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 01, 2019, 06:54:23 AM
Everything except the initial hardware diagnostics and the decompressor could be compressed. Decompressor is easily less than 1KB. BTW, this is how PC BIOS ROMs have been since the mid '90s.
Yes, they even use Lha from what I recall. However, the Amiga kickstart, is not the equivalent of a BIOS, and when did you last see a BIOS that was 512kB? :)

What I suggest is to keep the Amiga kickstart small yet functional - strip the "user interface" parts (shell, workbench.library and icon.library) to their bare minimums, enough to boot and work with legacy floppies. They can be replaced with feature rich on-disk variants when booting off hard drives.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 01, 2019, 07:55:16 AM
Everything except the initial hardware diagnostics and the decompressor could be compressed.
Just to elaborate on this - exactly what, in your opinion, can be compressed?
Here is the content of the A1200 CBM OS3.1 40.68 kickstart
Code: [Select]
exec                                    14K
expansion                              2.8K
romboot                                3.8K
graphics.library                       104K
dos.library                             39K
filesystem                              24K
console.device                          15K
layers.library                          13K
scsi.device                             10K
con-handler                             10K
input                                  5.8K
audio.device                           4.3K
card.resource                          3.1K
utility.library                        2.5K
battclock.resource                     2.4K
ramlib                                 1.1K
ramdrive                               1.6K
cia.resource                           1.0K
misc.resource                          236B
wbtask                                 252B
potgo.resource                         376B
filesystem.resource                    472B
disk.resource                          908B
mathffp.library                        1.2K
timer.device                           3.6K
mathieeesingbas.library                3.7K
keymap.library                         3.3K
bootmenu                               5.7K
trackdisk.device                       7.3K
icon.library                           9.2K
ram-handler                            9.2K
shell                                   17K
intuition.library                      112K
gadtools.library                        23K
workbench.library                       70K
battmem.resource                       544B
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 01, 2019, 09:12:21 AM
Everything except the initial hardware diagnostics and the decompressor could be compressed. Decompressor is easily less than 1KB. BTW, this is how PC BIOS ROMs have been since the mid '90s.
First, this not only requires compressing the binaries. It would also require to include relocation information in the (ROM) based compressed image. It also means that the data needs to be decompressed to some place since it could no longer run from ROM (as it does now).

Thus, it would enlarge the RAM footprint (by approximately 512K), and thus make the kickstart less attractive to use on low-end machines.

3.1.4 requires 1.5MB ram minimum to run it comfortable. (1MB RAM extension plus 512K chipmem). With an additional 512K RAM required for the kickstart, users would already need a 2MB RAM expansion.

I don't consider this a good option.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: DamageX on November 01, 2019, 08:56:49 PM
Yes, they even use Lha from what I recall. However, the Amiga kickstart, is not the equivalent of a BIOS, and when did you last see a BIOS that was 512kB? :)
Um... today? 512KB BIOS is common on 200x era PCs.
Quote
What I suggest is to keep the Amiga kickstart small yet functional - strip the "user interface" parts (shell, workbench.library and icon.library) to their bare minimums, enough to boot and work with legacy floppies. They can be replaced with feature rich on-disk variants when booting off hard drives.
This is also not a bad idea. In your list graphics.library and intuition are the biggest chunks, and their only use before booting is what, the early startup menu where you get to pick between NTSC/PAL, etc.?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: DamageX on November 01, 2019, 09:18:01 PM
First, this not only requires compressing the binaries. It would also require to include relocation information in the (ROM) based compressed image. It also means that the data needs to be decompressed to some place since it could no longer run from ROM (as it does now).
Yes, decompressing (the whole thing, or close to it, in one big block) to somewhere. That's what I was hinting at when I mentioned the practice of relocating ROM to fastram via the MMU.

I don't know how feasible it is to run everything from a nonstandard memory region (ie. not using the MMU to remap it to the ROM area). I'm guessing your suggestion of relocs is based on the fact that fastRAM uses different addresses depending on the hardware setup? How far along in the boot process do you have to get before accelerator/expansion card RAM configuration is known?

Obviously, lack of RAM and/or MMU (and maybe decompression time) would preclude this type of build from being used with low-end machines. But users of low-end setups probably have a shorter wishlist of functionality they want to have added into kickstart. I don't know if you already have separate variants of the ROM for different machines, or one for ECS and one for AGA or what...
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: psxphill on November 02, 2019, 04:21:23 AM
It would also require to include relocation information in the (ROM) based compressed image.

I used skick/mkick for a while, RTB/PAT files for skick/mkick would be nice. Although I'm not sure about the benefits of compressing it into a ROM
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 02, 2019, 07:03:05 AM
This has nothing to do with a MMU. You cannot run compressed code directly anyhow, so it does not make sense to remap anything to anywhere. As compressed code requires decompression first, and the ROM area would be populated (otherwise compression would not make sense), you need to decompress to RAM, and as you decompress to RAM, you need to relocate as you do not know where the target RAM will be.

This is neither related to SKick, as - again - SKick maps the ROM to RAM, though with relocation information - but mapping a compressed image to some place makes neither sense.

One way or another, this is not a good option. It requires more RAM, not just the decompressor, and as most users use hard disks anyhow, it is much simpler to load the modules missing in ROM from harddisk instead. It also makes the kickstart more flexible.

The kickstart comes with sufficient components to give you access to the system, and - starting with 3.2 - also with sufficient functionality to update many modules from harddisk should the disk contain newer components. There is really no need to spoil RAM for compression that is not needed.

Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 02, 2019, 07:31:37 AM
That’s of little use when “most user” wants to boot from floppy or ADF, disabling the hard drives to save the little ram there is.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 02, 2019, 11:07:50 AM
That’s of little use when “most user” wants to boot from floppy or ADF, disabling the hard drives to save the little ram there is.
Ah, and you know what "most users want"? If so, my thesis would rather be "most users want the kickstart to be able to boot into games". And for that, you typically neither need a workbench, nor would compressed components in ROM be any helpful. Frankly, if this is all you want, then Kickstart 1.3 is probably your best option.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 02, 2019, 12:11:36 PM
Ah, and you know what "most users want"?
You know that I consider "most users" a myth, an excuse to cling on to when "developers" run out of real arguments :)
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: psxphill on November 02, 2019, 01:30:05 PM
This is neither related to SKick, as - again - SKick maps the ROM to RAM, though with relocation information - but mapping a compressed image to some place makes neither sense.

How is it not related? Both load the kickstart from somewhere into RAM, whether it's from floppy, hard drive or a compressed ROM. I'm not sure I'd bother compressing it into ROM, but I have and would load a kickstart from floppy and hard drive.

One way or another, this is not a good option. It requires more RAM, not just the decompressor, and as most users use hard disks anyhow, it is much simpler to load the modules missing in ROM from harddisk instead. It also makes the kickstart more flexible.

It's a good option if you want to be able to load different kickstarts but don't have an MMU or hardware that lets you load kickstart from disk in another way. It's more flexible than being limited to one version of kickstart.

For the limited use case that you are arguing against then I agree, but that doesn't mean that I wouldn't load kickstart into RAM in other situations.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: paul1981 on November 02, 2019, 10:01:38 PM
Yes, they even use Lha from what I recall. However, the Amiga kickstart, is not the equivalent of a BIOS, and when did you last see a BIOS that was 512kB? :)
Um... today? 512KB BIOS is common on 200x era PCs.
Quote
What I suggest is to keep the Amiga kickstart small yet functional - strip the "user interface" parts (shell, workbench.library and icon.library) to their bare minimums, enough to boot and work with legacy floppies. They can be replaced with feature rich on-disk variants when booting off hard drives.
This is also not a bad idea. In your list graphics.library and intuition are the biggest chunks, and their only use before booting is what, the early startup menu where you get to pick between NTSC/PAL, etc.?

No, their real use is after booting. Removing them will completely break nearly all existing AmigaDOS software when booting from floppy disk. I don't believe that would be much of a selling point.
Loading the modules from hard disk would have to be done before booting from floppy. I wonder if this 'list of modules' could be stored on a designated RDB? Or at least a flag on the RDB which tells Kickstart that 'Modules are on this drive/partition!' The Kickstart could then look for valid modules on that drive and load them, all before the system comes ready...so no reboot would be required and it's all done before even booting from the hard disk (ie. even before the Startup-Sequence). This way, from a cold boot you could still load that old floppy software up and it would work. I envisage the bootmenu could control these modules too (able/disable). If no hard disk is found (and thus no modules) then it could search for modules from floppy in 'Devs/Modules'. If that isn't found, then that's the users fault.
I wouldn't remove anything from Kickstart except something insignificant to make room to implement the above (Thomas has a few candidates, but I don't agree with audio.device being removed).
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 03, 2019, 12:11:07 AM
Ah, and you know what "most users want"?
You know that I consider "most users" a myth, an excuse to cling on to when "developers" run out of real arguments :)
Then why do you come up with such a fake argument to begin with?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 03, 2019, 12:16:10 AM
How is it not related? Both load the kickstart from somewhere into RAM, whether it's from floppy, hard drive or a compressed ROM. I'm not sure I'd bother compressing it into ROM, but I have and would load a kickstart from floppy and hard drive.
Because it is an entirely different mechanism. SKICK attempts to guess how to relocate binaries, with an additional patch file that was "hand generated". LoadModule, and System-Startup work by standard HUNK files that carry relocation information within them. Thus, no MMU is needed for disk-based modules, and no guesswork is needed for relocation, and the format is a standard binary load format.

It's a good option if you want to be able to load different kickstarts but don't have an MMU or hardware that lets you load kickstart from disk in another way. It's more flexible than being limited to one version of kickstart.

For the limited use case that you are arguing against then I agree, but that doesn't mean that I wouldn't load kickstart into RAM in other situations.
LoadModule,SKick and System-startup have different purposes, so it is hard to compare. SKick replaces an entire kickstart blob (in a rather hacky fashion, requires hand-generated patch files). LoadModule replaces isolated modules from disk, requiring a reboot. System-Startup updates ROM modules from RAM without requiring a reboot, loading them from disk as needed.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 03, 2019, 04:37:46 AM
Ah, and you know what "most users want"?
You know that I consider "most users" a myth, an excuse to cling on to when "developers" run out of real arguments :)
Then why do you come up with such a fake argument to begin with?
I was not the one who brought “most users” into this, you did. And at the same time you use “low end systems” as an argument as well. Well, what do you know? Did you conduct a survey or something? I find the way 3.1.4 (and now 3.2) is being developed and delivered very questionable, lots of rather strange decisions are being made “behind closed doors” and that is why this very thread exists in the first place - if you cannot watch others having opinions about the project, then ignore this thread and stick to your own.

What I can tell is that I have seen more than once people be confused about not being able to boot into workbench from floppies and disk images that worked well earlier, both programs and games. You can perhaps count on A4000T systems having hard drives, but for a500/a600/a1200/cd32 there are plenty of people who just swap between various cf or sd cards for “hard drives” and use gotek as floppy drive. And such systems are better off with plain old 3.1 kickstart at this point, as 3.1.4 introduces a number of problems.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 03, 2019, 05:46:16 AM
I was not the one who brought “most users” into this, you did.
Read your post #43.

And at the same time you use “low end systems” as an argument as well. Well, what do you know? Did you conduct a survey or something? I find the way 3.1.4 (and now 3.2) is being developed and delivered very questionable,
As in what? I gave reasons, you ignored them and washed them away because you like to complain? That technical experts make decisions in product development as all over the world, in all professional products, and your opinion isn't received? (Which is, by the way, a decision you made.) That software development is not a democratic process where you replace experience and workforce by a count of noses?

Kolla, I'm a firm believer in democracy, but I'm not a firm believer that this principle carries over into product development. This is not an open source product, and it is not supposed to be.  The market decides whether a product is good or bad, whether it sells or not. This is how the world works.

Don't like it? Then don't buy it.  That is how the world works. I can deal with that. Actually, every company would be happy to *not* have people like you as customer. If another compromize would have been made, you, yes *you in particlar*, have had other complains. I bet.

lots of rather strange decisions are being made “behind closed doors” and that is why this very thread exists in the first place - if you cannot watch others having opinions about the project, then ignore this thread and stick to your own.
If Microsoft develops windows, those decisions are also made behind closed doors. If Apple develops ios, those decisions are also made behind closed doors. For good reason - such discussions are made between developers that understand the technical background, and that are willing to work to make something happen.

It is good industry practise not to open up everything, because if you put every detail into discussion, you would end up nowhere or a pile of incompatible stuff that does not fit together, a lot of discussions (as this one) that do not drive the process, and does not help to get anyone anywhere.

It is of course also good industry practise to listen to customer voices, which happens here. Customers, note well! But it is also good practise to ignore whiners, complainers and nay-sayers - because you are complaining out of principle, and not out of the motivation to create a better product.

You don't like the product? Well, do not buy it. This is how the world works. I believe every serious company would be happy not to have a customer like you.

What I can tell is that I have seen more than once people be confused about not being able to boot into workbench from floppies and disk images that worked well earlier, both programs and games.
I already told you. It doesn't fit, and 1MB is not an option either because that also causes incompatibilities. It is neither an option for the ECS machines. I told that about 1000 times, you wash that away - you don't want to understand the reason. Compression is not an option either because it costs in the end 512K more RAM to begin with.

Every Os development is a matter of making compromizes of some sort. 3.1.4 is not different, and 3.2 is not different either. The compromize that was made was: You going to boot from harddrive, you have a little bit more RAM (1.5MB), you have the same computing power (68K is enough). This is in good tradition to the way how the A4000T ROM was built, and in that sense nothing new. We even offered two different upgrade paths, so left choices to the customer.
The compromize being made was a much smaller one than that of 3.9. Which required more RAM, a more powerful machine, a double boot, a 68020 at minimum.

Every other decision (1MB ROM, compression) would have meant *other* compromizes, with other drawbacks. There is no silver bullet that addresses e very need, and you cannot make everybody happy. And nobody can make you happy, but we know that already, don't we?

Concerning games: Games fall into two cases: Either, it boots directly into the game, then the workbench is not needed. Case closed. Or it uses the workbench - but then it is system friendly and hence has access to the harddrive. And, woha, by pure magic, it finds the workbench, even if you boot from disk.  Harddisk: Yes, that is part of the compromize.

So, in fact, the problem you claim to exist does not exist in realitiy, and I haven't heard about any user claiming that game XYZ did not run due to the decision of off-loading two ROM components (that have been off-loaded before). Except your "out of principle" whining.

Oh, just shut up...

You can perhaps count on A4000T systems having hard drives, but for a500/a600/a1200/cd32 there are plenty of people who just swap between various cf or sd cards for “hard drives” and use gotek as floppy drive. And such systems are better off with plain old 3.1 kickstart at this point, as 3.1.4 introduces a number of problems.
And yet, you can boot from disk, provided the workbench.library and icon.library are on it. So, nobody is harmed. And if those people feel more comfortable with 3.1, then so might it be. A 1MB kickstart would not fit into the ECS systems anyhow, and you cannot fit more features into the same ROM and RAM footprint. Just does not work.

Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 03, 2019, 09:38:25 AM
What is your goal with these essay long rants here Thomas, closing down this thread? I was requested to open my own thread about my issues, so I did, only to find it littered within a few hours about rather irrelevant discussions about booting from CD drives and 1MB kickstart roms...

It is perfectly doable to fit variants of workbench.library and icon.library in a 512kB rom. Note that I didn’t argue for 1MB rom, I just find some of your arguments a bit far fetched.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 03, 2019, 10:22:16 AM
I was not the one who brought “most users” into this, you did.
Read your post #43.
Read your post #42.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 03, 2019, 01:39:04 PM
It is perfectly doable to fit variants of workbench.library and icon.library in a 512kB rom. Note that I didn’t argue for 1MB rom, I just find some of your arguments a bit far fetched.
No, it is not. There is not enough ROM space. Not even close. With all other extensions, we have currently about 16 to 32K free, depending on the machine. This is not remotely enough to fit anything close to a workbench into the ROM. The scsi.device grew by quite some amount (>4GB support) the FFS grew for the same reason. The shell grew. Graphics grew (consistent code for all machines), utility grew (68060 support), mathieeesingbas grew (same reason), intuition grew (window movement). Even with original 3.1 workbench and 3.1 shell and 3.1 icon and shell, and without wbfind/system-startup (which you would need to load a new workbench from, so one cannot get rid of it), the code does not fit anymore, so please do not make anyone believe it might.

You have probably no idea how tight the 3.1 ROM is. It only worked because CBM added some additional tweaks (open libraries by tags, OpenDevice(NULL...), only 68020 code for some machines), and it did not work for the A4000T at all.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 03, 2019, 02:02:42 PM
when booting from floppy disk. I don't believe that would be much of a selling point.
Loading the modules from hard disk would have to be done before booting from floppy.
Well, this is pretty much what System-Startup does in 3.2. The problem is, you cannot really load anything from harddisk without the modules initialized you need to run the harddisk, which is already quite a bit. Actually, exec, expansion, timer, misc, disk, utility and dos are needed, also graphics and intuition (and probably some other minor ones I forgot).

I wonder if this 'list of modules' could be stored on a designated RDB? Or at least a flag on the RDB which tells Kickstart that 'Modules are on this drive/partition!' The Kickstart could then look for valid modules on that drive and load them, all before the system comes ready...so no reboot would be required and it's all done before even booting from the hard disk (ie. even before the Startup-Sequence).
I wonder what the benefit of this would be. The only additional module you need to load them from the regular file system is the file system, and *that* can sit in the RDB anyhow by tradition. The drawback of having modules in the RDB is that you do not see them, you also need dedicated tools to manipulate them there, and you run into potential compatibility issues with the firmware of the drive - which is responsible for handling the RDB (and not the kickstart, note well!).

So, in a sense, we are with 3.2 exactly where you propose us to be, except that there is a "default module" in  ROM as well, which can be overridden by a RAM module. This only works for modules that are not initialized for accessing the harddrive, of course (intuition is some special exception, but the 3.2 intuition received a new feature, namely it is able to be shut down afterwards for getting replaced). And except that the modules are stored in the regular file system, so they are easy update and manipulate.

The only components you could remove from ROM because they non-essential for booting are mathffp,mathieeesingbas and audio, but again, some firmware might depend on them being available for their boot process because they have been in ROM, so I was really hesitating to make the change. They can be updated by System-Startup, of course.

There is no fine-control for this, but there will be an on-off switch in the boot menu to avoid trouble in case you accidentally trashed one of the replacement modules on disk, i.e. there is a fail-safe fall-back mode "rom boot only" mechanism. User programs could jump in to create a per-module switch, simply by renaming compoents on disk.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: psxphill on November 03, 2019, 05:07:51 PM
Because it is an entirely different mechanism. SKICK attempts to guess how to relocate binaries, with an additional patch file that was "hand generated". LoadModule, and System-Startup work by standard HUNK files that carry relocation information within them. Thus, no MMU is needed for disk-based modules, and no guesswork is needed for relocation, and the format is a standard binary load format.

I think you misunderstood my post. You appeared to be saying that skick wasn't related to compressed kickstart, I was saying it was.
Without MMU you would need to allocate ram to decompress kickstart and so it would need to be relocated.

LoadModule,SKick and System-startup have different purposes, so it is hard to compare. SKick replaces an entire kickstart blob (in a rather hacky fashion, requires hand-generated patch files). LoadModule replaces isolated modules from disk, requiring a reboot. System-Startup updates ROM modules from RAM without requiring a reboot, loading them from disk as needed.

I understand the difference between skick and loadmodule.

The files necessary for skick could be machine generated, no matter how hacky you consider it.

skick support would be great
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 03, 2019, 06:09:59 PM
The files necessary for skick could be machine generated, no matter how hacky you consider it.

skick support would be great
Yes, it certainly could (the information is in the relocation information generated by the compiler), though I wonder why I should invest time into it, given than LoadModule can do that as well, without requiring additional information. Also note that SKick will have problems with autoconfiguring hardware as the system has to go through a second autoconf scan.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: paul1981 on November 03, 2019, 10:47:06 PM
when booting from floppy disk. I don't believe that would be much of a selling point.
Loading the modules from hard disk would have to be done before booting from floppy.
Well, this is pretty much what System-Startup does in 3.2. The problem is, you cannot really load anything from harddisk without the modules initialized you need to run the harddisk, which is already quite a bit. Actually, exec, expansion, timer, misc, disk, utility and dos are needed, also graphics and intuition (and probably some other minor ones I forgot).

I wonder if this 'list of modules' could be stored on a designated RDB? Or at least a flag on the RDB which tells Kickstart that 'Modules are on this drive/partition!' The Kickstart could then look for valid modules on that drive and load them, all before the system comes ready...so no reboot would be required and it's all done before even booting from the hard disk (ie. even before the Startup-Sequence).
I wonder what the benefit of this would be. The only additional module you need to load them from the regular file system is the file system, and *that* can sit in the RDB anyhow by tradition. The drawback of having modules in the RDB is that you do not see them, you also need dedicated tools to manipulate them there, and you run into potential compatibility issues with the firmware of the drive - which is responsible for handling the RDB (and not the kickstart, note well!).

So, in a sense, we are with 3.2 exactly where you propose us to be, except that there is a "default module" in  ROM as well, which can be overridden by a RAM module. This only works for modules that are not initialized for accessing the harddrive, of course (intuition is some special exception, but the 3.2 intuition received a new feature, namely it is able to be shut down afterwards for getting replaced). And except that the modules are stored in the regular file system, so they are easy update and manipulate.

The only components you could remove from ROM because they non-essential for booting are mathffp,mathieeesingbas and audio, but again, some firmware might depend on them being available for their boot process because they have been in ROM, so I was really hesitating to make the change. They can be updated by System-Startup, of course.

There is no fine-control for this, but there will be an on-off switch in the boot menu to avoid trouble in case you accidentally trashed one of the replacement modules on disk, i.e. there is a fail-safe fall-back mode "rom boot only" mechanism. User programs could jump in to create a per-module switch, simply by renaming compoents on disk.

From a cold boot, can 3.2 boot from floppy disk with hard disk modules already loaded? The flag (which could point to a volume where modules are stored) if not stored on the RDB, could be stored just after the RDB. Isn't there a 'reserved blocks' feature or something in HDToolbox I seem to recall? Upon cold boot the system could read this flag, load the modules and then boot from either DF0 or whatever else is available. The bootmenu for example (if the imaginary 'Modules button' is selected) could list the modules (from the designated volume) and the user could be given individual control over them (Module version number could also be listed). Regarding the flag again, if it's not found it wouldn't matter (ie. a 2.x or 3.1 drive attached).

Or, preferably perhaps, it could do all the same as above, but forget the flag, and just search for the modules from the disk with the highest boot priority (modules could even be searched for from floppy if a devs/modules drawer is found). Obviously , if no disk is inserted in DF0 it will next look in DH0 devs/modules (providing that DH0 has the next highest boot priority).

If, for some reason someone connects an additional hard disk or has an additional partition/volume with a higher priority and they don't want the modules loaded from there (ie. it has the devs/modules directory also), then there could be a little config file in devs/modules of the unwanted volume which could be read before the modules are loaded which simply has the the real volume/partition from which you want the modules to actually be loaded from - and this would also be reflected in bootmenu). Or, I suppose temporary control instead could be had from within the bootmenu if such a problem arises.

All of this I mention because I was thinking of the system being up-to-date and ready, ready even from cold booting into a floppy disk (or any other boot device).
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 03, 2019, 11:15:50 PM
Sorry, I still fail to see how all this is related to the RDB? It is really the wrong place to store arbitrary binary data. To load data from another harddisk, you only need a file system, and *that* comes from the RDB. "Reserved blocks" are not really "reserved" for that - it is just a left-over of the two-blocks "boot block" of floppies.

Thus, I wonder, why do you want to hide the modules from the user by placing them into a non-accessible spot?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: Gulliver on November 03, 2019, 11:49:40 PM
@paul1981

You know, you can always boot from RAD and make it play your way to achieve your desired goal.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 04, 2019, 06:48:13 AM
Thus, I wonder, why do you want to hide the modules from the user by placing them into a non-accessible spot?
Funny you should ask - that is exactly what Apple did, and Compaq did the same with their BIOS. Windows10 today typically has at least one hidden partition. You now, those closed doors decisions that were made for very good reasons by technical competent people without involving users? It's lovely when you can cherrypick when you wish to compare to "the industry".
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: Minuous on November 04, 2019, 08:45:06 AM
If Microsoft were technically competent their OS would not be gigabytes in size and require gigahertz of CPU power to run adequately. And many of their decisions are user-hostile, driven by non-technical reasons. Windows 10 is not something that any OS should strive to be like.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 04, 2019, 02:21:03 PM
Funny you should ask - that is exactly what Apple did, and Compaq did the same with their BIOS. Windows10 today typically has at least one hidden partition. You now, those closed doors decisions that were made for very good reasons by technical competent people without involving users? It's lovely when you can cherrypick when you wish to compare to "the industry".
Though we are talking here AmgiaOs and neither Windows nor ios. And your point for doing the same on the Amiga is?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 04, 2019, 02:31:54 PM
Funny you should ask - that is exactly what Apple did, and Compaq did the same with their BIOS. Windows10 today typically has at least one hidden partition. You now, those closed doors decisions that were made for very good reasons by technical competent people without involving users? It's lovely when you can cherrypick when you wish to compare to "the industry".
Though we are talking here AmgiaOs and neither Windows nor ios.

I appreciate your change of mind regarding the fact that we are talking about AmigaOS and neither Windows nor iOS.

If Microsoft develops windows, those decisions are also made behind closed doors. If Apple develops ios, those decisions are also made behind closed doors. For good reason - such discussions are made between developers that understand the technical background, and that are willing to work to make something happen.

Quote
And your point for doing the same on the Amiga is?
It is not a point for me, I am not a "most user".
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 04, 2019, 02:56:27 PM
It is not a point for me, I am not a "most user".

I can elaborate on this. On certain systems I have (CD32s for example), it is most convenient to keep using the OS 3.1 kickstart, and hence also keep a very small FFS partition at the start of the disk, with only BootCtrl, LoadModule and kickstart modules. On cold boot, this is the boot partition, then BootCtrl is used to deactivates this boot partition (temporary as from early-startup), LoadModule loads all relevant updates and system resets, using new scsi.device, booting into the "real" OS partition which is larger and has fancy long filenames FFS etc.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 04, 2019, 03:36:17 PM
I can elaborate on this. On certain systems I have (CD32s for example), it is most convenient to keep using the OS 3.1 kickstart, and hence also keep a very small FFS partition at the start of the disk, with only BootCtrl, LoadModule and kickstart modules. On cold boot, this is the boot partition, then BootCtrl is used to deactivates this boot partition (temporary as from early-startup), LoadModule loads all relevant updates and system resets, using new scsi.device, booting into the "real" OS partition which is larger and has fancy long filenames FFS etc.
And what has all of this to do with the RDB? Right, nothing.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 04, 2019, 03:38:36 PM
It is not a point for me, I am not a "most user".
Then why coming up with a nonsense argument in first place? Microsoft and Apple surely had their reasons - I do not mind, it is not my problem. Booting the Amiga works differently, so there are different reasons for boot mechanisms.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 04, 2019, 04:11:14 PM
I didn’t mention RDB at all, I just mentioned that having a dedicated “magic” partition for rom updates can be useful also on Amiga. And nothing prevents anyone from doing it already. Consider this as sorting under “tips & tricks” as well as “work-arounds” in the topic of this thread.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: F0LLETT on November 05, 2019, 09:06:11 AM
What is your goal with these essay long rants here Thomas, closing down this thread? I was requested to open my own thread about my issues, so I did, only to find it littered within a few hours about rather irrelevant discussions about booting from CD drives and 1MB kickstart roms...

It is perfectly doable to fit variants of workbench.library and icon.library in a 512kB rom. Note that I didn’t argue for 1MB rom, I just find some of your arguments a bit far fetched.

Sorry didn't realise you wanted this as your own personal thread. Thought it was open to any one to mention stuff, as the title suggests.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 05, 2019, 09:53:36 AM
Sorry didn't realise you wanted this as your own personal thread. Thought it was open to any one to mention stuff, as the title suggests.

It is, I am not stopping anyone.
I just find the discussions about booting from CD drives (which you brought up) and 1MB kickstart (which Thomas brought up) rather irrelevant.
But please go ahead, continue, ad nauseam if you like.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: paul1981 on November 05, 2019, 10:16:41 PM
Sorry, I still fail to see how all this is related to the RDB? It is really the wrong place to store arbitrary binary data. To load data from another harddisk, you only need a file system, and *that* comes from the RDB. "Reserved blocks" are not really "reserved" for that - it is just a left-over of the two-blocks "boot block" of floppies.

Thus, I wonder, why do you want to hide the modules from the user by placing them into a non-accessible spot?

Quote from: paul1981 link=topic=74358.msg846139#msg8461
Or, preferably perhaps, it could do all the same as above, but forget the flag, and just search for the modules from the disk with the highest boot priority (modules could even be searched for from floppy if a devs/modules drawer is found). Obviously , if no disk is inserted in DF0 it will next look in DH0 devs/modules (providing that DH0 has the next highest boot priority).

If, for some reason someone connects an additional hard disk or has an additional partition/volume with a higher priority and they don't want the modules loaded from there (ie. it has the devs/modules directory also), then there could be a little config file in devs/modules of the unwanted volume which could be read before the modules are loaded which simply has the the real volume/partition from which you want the modules to actually be loaded from - and this would also be reflected in bootmenu). Or, I suppose temporary control instead could be had from within the bootmenu if such a problem arises.

All of this I mention because I was thinking of the system being up-to-date and ready, ready even from cold booting into a floppy disk (or any other boot device).

I don't want to hide anything, forget the RDB and flag... as I soon stated above it's not actually needed for this, I just thought this would be a solution for cold booting into any device, with updates - which presently can't be done.  To elaborate a little, this could be a USB thumb drive or SD card or external cd-rom, or even a remote network drive. It opens up a few possibilities. Probably overkill for a small user-base hobby-OS.  :P
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: paul1981 on November 05, 2019, 10:21:24 PM
@paul1981

You know, you can always boot from RAD and make it play your way to achieve your desired goal.

I know, that's why I love AmigaOS.   :)
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 05, 2019, 10:23:04 PM
I don't want to hide anything, forget the RDB and flag... as I soon stated above it's not actually needed for this, I just thought this would be a solution for cold booting into any device, with updates - which presently can't be done.
If I recall correctly (I am currently away from home), it can certainly be done. The "search the fitting module function" of System-Startup is the same function that is also used for "wbfind", which is scanning for the workbench.library and the icon.library. Thus, it is sufficient to have the modules on a mounted volume.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 13, 2019, 11:35:23 AM
Since this turned out to be just as boring and tedious as other threads on OS 3.1.4/3.2, perhaps I can toss in random bugs...

I noticed that a clipboard bug was discovered and reported elsewhere - good! I've had occasional crashes when pasting into KingCON - I realised that this one would be utterly pointless to report, so I am glad it was discovered elsewhere.

So, random bug - when selecting multiple devices devices on Workbench, and then format them from the icon menu, once the first one is formatted with "quick format", the "quick format" option for the remaining devices is grayed out, leaving only regular "format" and "cancel" as options.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 13, 2019, 04:51:26 PM
So, random bug - when selecting multiple devices devices on Workbench, and then format them from the icon menu, once the first one is formatted with "quick format", the "quick format" option for the remaining devices is grayed out, leaving only regular "format" and "cancel" as options.
Actually, not reproducable here. The logic between greying out and not greying out the QUICK option is quite simple: If there is a volume in the DosList that corresponds to the device to be formatted, it is not greyed out. Otherwise it is. Thus, the usual game: Remove all hacks and patches, and try again.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 14, 2019, 08:42:51 AM
Actually, not reproducable here. The logic between greying out and not greying out the QUICK option is quite simple: If there is a volume in the DosList that corresponds to the device to be formatted, it is not greyed out. Otherwise it is. Thus, the usual game: Remove all hacks and patches, and try again.

No hacks, no patches. Booting the OS 3.1.4 Install floppy and plain 3.1.4 kickstart. Fresh hard drive - set up with 4 partitions in HDToolBox, installed "long filenames" (..307), maxtransfer, buffers... save, reboot with OS 3.1.4 Install floppy, select the 4 new partitions, icon menu, format... four format windows show up, all with "quick format" as option. Click "quick format" on either of them, and the remaining three windows refresh and their respective "quick format" buttons are grayed out. In genereal happens to the format window of all "Uninitialized" partitions. Happens on all systems I have tested on, be it "real", emulated or FPGA

But I am not at all surprised that you cannot reproduce - it is not the first time.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 14, 2019, 06:53:49 PM
No hacks, no patches. Booting the OS 3.1.4 Install floppy and plain 3.1.4 kickstart. Fresh hard drive - set up with 4 partitions in HDToolBox, installed "long filenames" (..307), maxtransfer, buffers... save, reboot with OS 3.1.4 Install floppy, select the 4 new partitions, icon menu, format... four format windows show up, all with "quick format" as option. Click "quick format" on either of them, and the remaining three windows refresh and their respective "quick format" buttons are grayed out. In genereal happens to the format window of all "Uninitialized" partitions. Happens on all systems I have tested on, be it "real", emulated or FPGA
Oh, you mean you run multiple Formats in parallel. Yes, of course. This is expected behaviour. Once a disk is formatted, its volume node will vanish from the dos list. Hence, it looks unformatted at this time to all the other format instances. The "Quick" option comes back once the format is complete as it will generate a disk-inserted IDCMP, and the volume node will then become available again.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 15, 2019, 07:58:00 AM
The "Quick" option comes back once the format is complete as it will generate a disk-inserted IDCMP, and the volume node will then become available again.

No, the "quick" option does _not_ come back once the format is complete - if it had come back, I would not have called this a bug. With 3.1.4, for "quick format" to come back, you have to close and reopen the Format program.

With OS 3.1, "quick format" never grays out, one can even do quickformat on many partitions at the same time.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 15, 2019, 08:11:43 AM
With OS 3.1, "quick format" never grays out, one can even do quickformat on many partitions at the same time.
Which is curious since I have not changed the logic of Format.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 15, 2019, 09:24:50 AM
With OS 3.1, "quick format" never grays out, one can even do quickformat on many partitions at the same time.
Which is curious since I have not changed the logic of Format.
Clearly something has changed.

And besides - why gray out only "quick format", and leave the rather more damaging "format" available?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 15, 2019, 04:46:23 PM
And besides - why gray out only "quick format", and leave the rather more damaging "format" available?
The reasoning here is that if the volume is not present, but the device is, then the volume is not readable and requires a full format. Consider an MS-Dos formatted disk inserted, with a FFS mounted on top of the trackdisk.device. Quick format is not an option.

Besides, I cannot reproduce that "Quick" does not reappear after a successful format.I neither quite get why you want to open multiple format windows on the same device.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 15, 2019, 09:02:00 PM
Good lord, why do you have such a hard time understanding??

One Format per partition - I want to format them, one after the other.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 15, 2019, 11:31:49 PM
Partition up a disk with HDToolBox - two partitions.

Reboot.

They both show up as "unititialized".

Select both.

Select "Format" from the icon menu.

Notice how both Format windows, one for each partition, has "Quick format" as options.

Select "Quick format" on one of them.

Answer all confirmation requesters so the partition is formatted.

Let it finish - it is quick.

The partition is now formatted, volume icon shows up on Workbench.

Notice how _THE OTHER_ Format window, for _THE OTHER_ partition now has "Quick format" grayed out - EVEN AFTER FIRST FORMATTING IS FINISHED.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: my_pc_is_amiga on November 16, 2019, 04:46:36 AM
Separate thing I've noticed in 3.1.4:

I have a rather large file: 2,287,031,227 bytes.  The size shows up correctly in the Information window and shell.  But in Workbench view by size, it shows up as ,007,936,069.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 16, 2019, 08:22:15 AM
Note how hard it is to write good bug reports? You are still incomplete on this one.

If the other partition is invalid (i.e. has no volume name on it), then this is expected. This is, again, due to the rather simple logic by which Format checks whether quick formatting is possible or not. If there is no volume name, it assumes that quick format is not possible. This check is made when changing disks, and the disk change is triggered by the disk-inserted message of the first format finishing.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 16, 2019, 09:18:44 AM
So the bug is there, “quick format” should be reappear as available option in the Format window of the second partition once formatting of first partition is done. Like you wrote earlier. Do you acknowledge that this is a bug, or do you write it off as “expected behavior”, even though it makes zero sense from a user’s point of view?

In general, I don’t have a hard time writing bug reports, but with you, and just you, it’s a damn fight every effin time.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 16, 2019, 10:01:05 AM
If the other partition is invalid (i.e. has no volume name on it), then this is expected. This is, again, due to the rather simple logic by which Format checks whether quick formatting is possible or not. If there is no volume name, it assumes that quick format is not possible. This check is made when changing disks, and the disk change is triggered by the disk-inserted message of the first format finishing.

Why is Format doing this check _only_ when disks are changed, and not when Format is launched?
Should "uninitialized" be treated as a special case, a case where "quick format" should be made possible?
Why did this change from OS 3.1?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 16, 2019, 10:05:30 AM
I have a rather large file: 2,287,031,227 bytes.  The size shows up correctly in the Information window and shell.  But in Workbench view by size, it shows up as ,007,936,069.
Yes.
And I would argue that Workbench windows can show file sizes as "human readable", for example "2GB" in you case.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 16, 2019, 02:16:02 PM
Why is Format doing this check _only_ when disks are changed, and not when Format is launched?
I do not know exactly. The code has the gadget disable switch commented out, with a rather cryptic comment on top saying that it has been disabled, that the check through the presence of the volume is not ideal and that the code should instead check to access the disk directly. I *believe* the reason is that you should be given the option to quick-format a non-iniaitlized harddisk, but if you change disks, you are using a removable device where this logic does not apply and a non-present volume is instead the matter of a non-(hard-)formatted medium.

Should "uninitialized" be treated as a special case, a case where "quick format" should be made possible?
Why did this change from OS 3.1?
I do not see that this changed, the comment and this disabling is taken from the 3.1 release.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 17, 2019, 03:24:45 PM
I have a rather large file: 2,287,031,227 bytes.  The size shows up correctly in the Information window and shell.  But in Workbench view by size, it shows up as ,007,936,069.
Apparently, another signed/unsigned mixup. I fixed it.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: my_pc_is_amiga on November 18, 2019, 12:20:58 AM
Great -- another bug squashed!

I have a rather large file: 2,287,031,227 bytes.  The size shows up correctly in the Information window and shell.  But in Workbench view by size, it shows up as ,007,936,069.
Apparently, another signed/unsigned mixup. I fixed it.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: my_pc_is_amiga on November 18, 2019, 04:33:13 AM
Took me awhile to find some hard drive to play with.  I see it happening in Format 40.2 (3.1)  and 3.1.4 (46.14) but in 3.9 (Format 44.19) I do not see this behavior. Quick format does not get ghosted out in the second partition in 44.19 at the completion of the first partition's quick format.

I ran each of the "Format" versions in a 3.9 booting env. -- so it is clearly in the Format code.

And as Thomas has pointed out it does not happen if partitions are non-invalid (i.e. already have valid volume names).


Partition up a disk with HDToolBox - two partitions.

Reboot.

They both show up as "unititialized".

Select both.

Select "Format" from the icon menu.

Notice how both Format windows, one for each partition, has "Quick format" as options.

Select "Quick format" on one of them.

Answer all confirmation requesters so the partition is formatted.

Let it finish - it is quick.

The partition is now formatted, volume icon shows up on Workbench.

Notice how _THE OTHER_ Format window, for _THE OTHER_ partition now has "Quick format" grayed out - EVEN AFTER FIRST FORMATTING IS FINISHED.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: my_pc_is_amiga on November 18, 2019, 04:54:48 AM
Was seeing if any clues in the "Format" release notes in the NDK 3.9 and found the following.  Though not sure if this means much since there is no way to look at this code to figure out what is being said below.

Code: [Select]
-- OS 3.5 release ---

Format 44.14 (7.12.99)

- rework

- Starting format with more than one WB parameter now correctly closes all
  windows. This is a ugly hack: the main window is closed and reopened
between
  formatting two devices. Too much work to make it nicer (Did you recognize
  that selecting two icons from WB and using menu Icon/Format Disk starts
  Format two times?)

- Removed broken handling of inserting/removing disk while main window is
open.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on November 27, 2019, 10:20:43 AM
More annoyances with Workbench (and shell)... copying icons by dropping source icon onto the target icon in "wbinfo" window - for whatever reason (bug? feature?) this requires that the source is not just a dot.info file, but an actual file (or drawer, or volume...). If you try to just drag a source icon with no associated file over to the target icon in the wbinfo window, exactly nothing will happen. As most icon packages come with just .info files, this is really annoying. Work-around is to create for example empty files for each .info file that lacks an associated file. This can be done fairly easily with a "one-liner" in OS 3.1.4.1 ...

Code: [Select]
List path/to/iconpack all files p="#?.info" lformat "If NOT EXISTS *"%p%m*"*N  Echo NOLINE TO *"%p%m*"*NEndIf" | C:Execute

Note that if Execute is made resident, it will not work to write just "| Execute" - bug that hopefully is squashed in 3.2.

Also note, the shell will barf on any files that have * (asterisk) in the filename, because... asterisks in filenames makes the shell barf in all kinds of funny ways, due to this sign having multiple meanings for the shell, depending on context ("this console", escape sign, substitute for #? if enabled)

And lastly, I have observed inconsistent and timewise weird behaviour with "set echo on" when using pipes and execute... as the whole Shell is up in the air at this point and these may or may not be known issues, I will not bother to conduct detailed test - just a heads up. "the team" (shrug) should thoroughly test behaviour of the shell with "set echo on" and similar "special cases".
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on November 27, 2019, 04:29:16 PM
More annoyances with Workbench (and shell)... copying icons by dropping source icon onto the target icon in "wbinfo" window - for whatever reason (bug? feature?) this requires that the source is not just a dot.info file, but an actual file (or drawer, or volume...). If you try to just drag a source icon with no associated file over to the target icon in the wbinfo window, exactly nothing will happen. As most icon packages come with just .info files, this is really annoying. Work-around is to create for example empty files for each .info file that lacks an associated file. This can be done fairly easily with a "one-liner" in OS 3.1.4.1 ...
I cannot confirm this. If I open the info window, and drag a file with only a .info and no file in it, I get the new icon all fine. The only particular combination in which nothing happens is if you open a drawer which is "list by names", and "show all files", and you drag a file without an icon into the info window. Then nothing happens. Which is plausible as there is no icon to begin with.

Code: [Select]
List path/to/iconpack all files p="#?.info" lformat "If NOT EXISTS *"%p%m*"*N  Echo NOLINE TO *"%p%m*"*NEndIf" | C:Execute

Note that if Execute is made resident, it will not work to write just "| Execute" - bug that hopefully is squashed in 3.2.
I can neither confirm that.

Also note, the shell will barf on any files that have * (asterisk) in the filename, because... asterisks in filenames makes the shell barf in all kinds of funny ways, due to this sign having multiple meanings for the shell, depending on context ("this console", escape sign, substitute for #? if enabled)
This is at this level unfortunate, though a problem of list and lformat and not of the shell. The problem is that List is not smart enough to understand that the %p%m is within quotes, so it does not perform substitution of asterisks. It should replace a single asterisk by two of them to be compliant to the shell syntax, but apparently CBM forgot. An asterisk within double quotes is an escape character. I wonder how this could possibly be fixed without a lot of additional testing within List, but I'll see.

And lastly, I have observed inconsistent and timewise weird behaviour with "set echo on" when using pipes and execute... as the whole Shell is up in the air at this point and these may or may not be known issues, I will not bother to conduct detailed test - just a heads up. "the team" (shrug) should thoroughly test behaviour of the shell with "set echo on" and similar "special cases".
At least not an issue I have on the list. Details?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 02, 2019, 01:00:52 PM
I cannot confirm this. If I open the info window, and drag a file with only a .info and no file in it, I get the new icon all fine. The only particular combination in which nothing happens is if you open a drawer which is "list by names", and "show all files", and you drag a file without an icon into the info window. Then nothing happens. Which is plausible as there is no icon to begin with.

Mea culpa - I was confusing myself with RAWBInfo - default WBInfo does indeed work correctly.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 02, 2019, 01:02:02 PM
Note that if Execute is made resident, it will not work to write just "| Execute" - bug that hopefully is squashed in 3.2.
I can neither confirm that.

Code: [Select]
4.Ram Disk:> which execute
Workbench:C/Execute
4.Ram Disk:> list Workbench:C/Execute
Directory "Workbench:C" on Monday 02-Dec-19
Execute                     6124 h-p-rwed 29-Jun-19 20:52:53
1 file - 13 blocks used
4.Ram Disk:> dir
     Clipboards (dir)
     T (dir)
  Disk.info <sl>
4.Ram Disk:> echo dir | execute
     Clipboards (dir)
     T (dir)
  Disk.info <sl>
4.Ram Disk:> which execute
RES execute
4.Ram Disk:> echo dir | execute
     Clipboards (dir)
     T (dir)
  Disk.info <sl>
4.Ram Disk:> newcli *
New Shell process 3
4.Ram Disk:> 3.Ram Disk:> echo dir | execute
required argument missing
3.Ram Disk:> which execute
RES execute
3.Ram Disk:> endcli
Process 3 ending
4.Ram Disk:> which execute
RES execute
4.Ram Disk:> echo dir | execute
     Clipboards (dir)
     T (dir)
  Disk.info <sl>
4.Ram Disk:>
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 02, 2019, 01:10:48 PM
Notice the "required argument missing" error message - it does not happen in the same CLI processes from where Execute at some point has been made resident.

A work-around is to have "Resident C:Execute" in S:Shell-Startup (and every damn script calling it).
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 02, 2019, 01:16:22 PM
The problem is that List is not smart enough to understand that the %p%m is within quotes, so it does not perform substitution of asterisks. It should replace a single asterisk by two of them to be compliant to the shell syntax, but apparently CBM forgot.

CBM, and everyone else up to List 45.9 from March 22. 2018, apparently.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on December 02, 2019, 01:18:29 PM
A work-around is to have "Resident C:Execute" in S:Shell-Startup (and every damn script calling it).
You *must* make Execute resident, but you better do so in the startup-sequence. Without that, recursive script execution won't work right. This is essential. In 3.2 and on, execute is resident anyhow.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 02, 2019, 01:39:18 PM
A work-around is to have "Resident C:Execute" in S:Shell-Startup (and every damn script calling it).
You *must* make Execute resident, but you better do so in the startup-sequence. Without that, recursive script execution won't work right. This is essential. In 3.2 and on, execute is resident anyhow.

How do you think I discovered this problem?

I do have Execute made resident in Startup-Sequence, but that is not "good enough" - when I open a shell and do (for example) "echo dir | execute" it just says "required argument missing", if I do "echo dir | C:Execute" it works - it also works if I first do "Resident C:Execute" again in that CLI (despite Execute already being resident).
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 02, 2019, 01:42:21 PM
It should really be enough to just do "Protect C:Execute +hp".
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on December 02, 2019, 01:50:08 PM
I do have Execute made resident in Startup-Sequence, but that is not "good enough" - when I open a shell and do (for example) "echo dir | execute" it just says "required argument missing", if I do "echo dir | C:Execute" it works - it also works if I first do "Resident C:Execute" again in that CLI (despite Execute already being resident).
Once again: If you call Execute directly, you do not have recursive shell scripts. In this particular case, it does not matter, but it matters in general.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 02, 2019, 02:50:28 PM
I do have Execute made resident in Startup-Sequence, but that is not "good enough" - when I open a shell and do (for example) "echo dir | execute" it just says "required argument missing", if I do "echo dir | C:Execute" it works - it also works if I first do "Resident C:Execute" again in that CLI (despite Execute already being resident).
Once again: If you call Execute directly, you do not have recursive shell scripts. In this particular case, it does not matter, but it matters in general.

Your answer makes little sense to me - I have exactly zero scripts going on here, and certainly not recursive scripts. I am passing on output from one command over to another via the pipe - and sometimes it works as I have been told is expected, other times it does not. Unless by "script" you mean whatever is created on the left side of the pipe, and recursiveness coming from using scripts from an interactive shell.

If Execute is not at all resident, everything works as expected(*), but if Execute is resident, it does not work, in general. The exception is if Execute is explicitly made resident from the CLI where the piping happening.

* I find it counter-intuitive that Executive will take commands from stdin "/bin/sh style", I would find it more "natural" if it accepted a list of scripts...
Code: [Select]
type s:user-startup | execute vs
Code: [Select]
echo s:user-startup | execute
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on December 02, 2019, 03:04:38 PM
Your answer makes little sense to me - I have exactly zero scripts going on here, and certainly not recursive scripts.
The thing you pipe into execute is what if not a script?


If Execute is not at all resident, everything works as expected(*), but if Execute is resident, it does not work, in general. The exception is if Execute is explicitly made resident from the CLI where the piping happening.
At least I do not see this in the current version of shell and execute, even more so as the pipe construction is part of the startup-sequence that will be shipped.


* I find it counter-intuitive that Executive will take commands from stdin "/bin/sh style", I would find it more "natural" if it accepted a list of scripts...
Code: [Select]
type s:user-startup | execute vs
Code: [Select]
echo s:user-startup | execute
Maybe so, but there are more applications for piping commands into execute than to pipe script names into execute. In particular, for mounting devices and monitor drivers, this is a very handy construction.

You may also recognize that I made "LFORMAT" aware of the shell escaping mechanisms, so that problem is also gone. "RequestFile" already did that right, but LFORMAT did not. One bug at a time....
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: my_pc_is_amiga on December 04, 2019, 06:24:54 AM
This is regards to copy in 3.1.4.1.  Attaching 2 screenshots:

1) On Workbench, I copy a directory called "INTELLIFONT" and there is some issue with one of the files and so I get an error requester.  The error message is somewhat confusing as it mentions error copying "INTELLIFONT" but error is really from the file DESIR***** --> see picture for actual name.  Would be nice to have the requester say the filename with issue and to let user know that only the single file is not going to be copied.

2) I also tried to copy same file in shell and get similar message that object cannot be found.  For this name, what is wrong or why can't it be copied?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on December 04, 2019, 06:44:17 AM
2) I also tried to copy same file in shell and get similar message that object cannot be found.  For this name, what is wrong or why can't it be copied?
It cannot be copied because you specified the file name incorrectly. ~ is a wild card for pattern matching. If it is meant to be a literal, you need to place a ' upfront it. Actually, from how it looks, this seems to be a mangled file name from a FAT directory. Are you copying from CrossDos? It should resolve such strange file names and provide a full FAT file name.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: my_pc_is_amiga on December 04, 2019, 06:58:32 AM
Yes, I'm using CrossDos.  The source file is coming from a USB stick but I have poseiden setup to use crossdos.

2) I also tried to copy same file in shell and get similar message that object cannot be found.  For this name, what is wrong or why can't it be copied?
It cannot be copied because you specified the file name incorrectly. ~ is a wild card for pattern matching. If it is meant to be a literal, you need to place a ' upfront it. Actually, from how it looks, this seems to be a mangled file name from a FAT directory. Are you copying from CrossDos? It should resolve such strange file names and provide a full FAT file name.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on December 04, 2019, 07:07:46 AM
Yes, I'm using CrossDos.  The source file is coming from a USB stick but I have poseiden setup to use crossdos.
Then either something is mangled with the setup, the stick or crossdos. Is it possible to share the image so I can have  a look why Crossdos doesn't resolve the long file name? Which version of crossdos?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: my_pc_is_amiga on December 04, 2019, 07:28:34 AM
Yes, I'm using CrossDos.  The source file is coming from a USB stick but I have poseiden setup to use crossdos.
Then either something is mangled with the setup, the stick or crossdos. Is it possible to share the image so I can have  a look why Crossdos doesn't resolve the long file name? Which version of crossdos?

Attaching the file in *.zip from windows.  Need to unzip from windows so the name stays the same.  If I do it on the Amiga, unarc from 3.9 changes the name.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on December 04, 2019, 07:31:21 AM
Attaching the file in *.zip from windows.  Need to unzip from windows so the name stays the same.  If I do it on the Amiga, unarc from 3.9 changes the name.
No, not the font file. I mean an image of the stick, sector wise. I do not know how to get that with windows, but from Linux, it is a straight "cp" from the /dev file, i.e. "cp /dev/sdd /tmp/out.img", assuming that /dev/sdd is your usb stick.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: my_pc_is_amiga on December 04, 2019, 03:58:29 PM
It actually came from this ISO image:

https://archive.org/details/cdrom-freshfonts-2

Attaching the file in *.zip from windows.  Need to unzip from windows so the name stays the same.  If I do it on the Amiga, unarc from 3.9 changes the name.
No, not the font file. I mean an image of the stick, sector wise. I do not know how to get that with windows, but from Linux, it is a straight "cp" from the /dev file, i.e. "cp /dev/sdd /tmp/out.img", assuming that /dev/sdd is your usb stick.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on December 04, 2019, 04:05:41 PM
It actually came from this ISO image:
https://archive.org/details/cdrom-freshfonts-2
Thanks, but how did it get on your stick? With a PC on Windows? Was the font name already garbled on the ISO image?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: my_pc_is_amiga on December 04, 2019, 04:20:41 PM
Yes, it was with Windows 10 (Iso image gets mounted by Windows).  I'm attaching a screenshot from Windwos of the names that show up.   From their I copied it to a USB drive.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: my_pc_is_amiga on December 09, 2019, 06:49:43 AM
The filename in windows looks like character 233 (Ө) for MS-DOS (PC-8), code page 437:
https://en.wikipedia.org/wiki/Code_page_437

and for 233 decimal in Latin-1 comes out to be é

So that I think is making sense that é shows up on the Amiga but still don't understand why the non-8.3 filename (long filename) does not show up. 

I forgot to mention that this is crossdosfilesystem 45.36.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 14, 2019, 09:02:27 AM
Moving on, since the topic on "that other thread" is about date, setdate etc, I have some thoughts, hopefully by posting here I don't risk getting banned for airing some ideas...


First C:Date

C:Date is a confusing puppy, as it is used both print and set system time.

I find it rather annoying that C:Date *requires* different input, depending on locale settings...

It would be very useful if it ...

* had an LFORMAT option for printing custom date strings, which implies not changing the system time
Code: [Select]
C:Date LFORMAT "The year is %Y, the month is %M, and the date is %D, time is currently %T"
C:Date tomorrow LFORMAT "Tomorrow is %M %D, %Y"

* accept input in a universal non-localized formats (iso 8601):
Code: [Select]
C:Date 2019-12-14T08:19:47Z
C:Date 2019-12-14T06:17:47+02:00
C:Date 2019-12-24

* could use timestamp of resources like files, directories, filesystems as reference, instead of system time, also neat for _setting_ the system time from a reference file or filesystem:
Code: [Select]
C:Date FROM S:Startup-Sequence LFORMAT "File is from %T at %D/%M, %Y"
C:Date FROM DH0:
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on December 14, 2019, 09:13:04 AM
So that I think is making sense that é shows up on the Amiga but still don't understand why the non-8.3 filename (long filename) does not show up. 
It cannot, because the character is not in the codeset. The "funny character" is a greek theta ("th"). It is part of the UTF-16 character set Windows uses, and which is also used to encode characters in the long file name. However, the theta is not part of ISO-Latin1, so there is no valid transcription of the file name to the charset AmigaOs uses. For this purpose, CrossDos falls back to the 8.3 filename.

As a reminder: UTF-16 encodes characters in 16-bit codepoints (well, ignoring the extended code pages for a while). The theta is beyond the first 256 byte page, where the first 256 codes are identical to ISO-Latin-1 (the codeset used by the Amiga).
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on December 14, 2019, 09:16:24 AM
I find it rather annoying that C:Date *requires* different input, depending on locale settings...
It requires as input the same format it prints as output.

It would be very useful if ...

* had an LFORMAT option for printing custom date strings, which implies not changing the system time
Code: [Select]
C:Date LFORMAT "The year is %Y, the month is %M, and the date is %D, time is currently %T"
C:Date tomorrow LFORMAT "Tomorrow is %M %D, %Y"
What is the use case for that? That is, what is the situation you run into trouble with the current way how "date" looks like?

Note well that we can certainly add something like Lformat for "date" in principle, but the output would still be locale dependent because the strings into which these formatting options expand into depend on the locale.


* could use timestamp of resources like files, directories, filesystems as reference, instead of system time, also neat for _setting_ the system time from a reference file or filesystem:
Code: [Select]
C:Date FROM S:Startup-Sequence LFORMAT "File is from %T at %D/%M, %Y"
C:Date FROM DH0:
Again, what is the use case? I understand that at some point you want to carry over a date from one file to another. SetDate FROM can do that for you. Why date?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 14, 2019, 10:00:30 AM
I find it rather annoying that C:Date *requires* different input, depending on locale settings...
It requires as input the same format it prints as output.

It means that one cannot use the same input on two systems with different locale, as the TLA for months are different in different languages - it would be convenient if it at least also supported just plain English input.

Ironically and adding to confusion, error messages are _not_ localised, but all plain english.

Code: [Select]
4.Kladd:> date
Lørdag 14-Des-19 10:40:13
4.Kladd:> date yesterday
***Bad args
- use DD-MMM-YY or <dayname> or yesterday etc. to set date
      HH:MM:SS OR HH:MM to set time
4.Kladd:> date "i går"
4.Kladd:> date
Fredag 13-Des-19 10:41:07
4.Kladd:>

(What the use case is for jumping system-time back and forth day by day, I have no idea.. perhaps you know?)


Quote
It would be very useful if ...

* had an LFORMAT option for printing custom date strings, which implies not changing the system time
Code: [Select]
C:Date LFORMAT "The year is %Y, the month is %M, and the date is %D, time is currently %T"
C:Date tomorrow LFORMAT "Tomorrow is %M %D, %Y"
What is the use case for that? That is, what is the situation you run into trouble with the current way how "date" looks like?

Trouble? I just gave two example - it is *useful* for presenting time/date information in a way that is independent of locales - it looks funny when dates are presented in norwegian in a script that otherwise prints out english (and it doesn't help that the Norwegian locales are flawed as well).

Quote

Note well that we can certainly add something like Lformat for "date" in principle, but the output would still be locale dependent because the strings into which these formatting options expand into depend on the locale.

That is fine.

Ideally, IMO, C:Date (and the other CLI tools) should primarily use $LANGUAGE and secondly use locale settings - it should be possible to easily override system wide locale setting with a shell-local/script-local variable. Yes, I know that $LANGUAGE is a legacy BCPL/TRIPOS variable. Any program that is not localised in itself, should never require localised input - the C:Date error messages are in English, for me they should have been in Norwegian - I only found out that I must use "I går" and "I morgen" (yes, two words, with quotes around) by chance.

Quote
* could use timestamp of resources like files, directories, filesystems as reference, instead of system time, also neat for _setting_ the system time from a reference file or filesystem:
Code: [Select]
C:Date FROM S:Startup-Sequence LFORMAT "File is from %T at %D/%M, %Y"
C:Date FROM DH0:
Again, what is the use case?

Sheesh! Again - to present time and date information in a contextual meaningful way from scripts.

Quote
I understand that at some point you want to carry over a date from one file to another. SetDate FROM can do that for you. Why date?
Why do you want to carry over date from one file to another? What is the use case for that?

In my above example, the idea is that "Date FROM DH0:" sets system time from the timestamp of DH0: - useful when DH0: is not initial boot device, for example when booting from RAD:

And can you explain what "Setdate DH0:" actually does?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on December 14, 2019, 10:32:09 AM
It means that one cannot use the same input on two systems with different locale, as the TLA for months are different in different languages - it would be convenient if it at least also supported just plain English input.
Yes, but when is this a problem? So, what is a script where you depend on date to act in a non-interactive way?

Ironically and adding to confusion, error messages are _not_ localised, but all plain english.
That *IS* confusing indeed, it should be consistent.


(What the use case is for jumping system-time back and forth day by day, I have no idea.. perhaps you know?)
To be consistent with the output of "date". Would it be more useful if date would be unable to read all date strings generated by the system? "List" gives you dates in this format (like "yesterday") and date uses the generic system date parser (part of the locale library) and of course, the date parser of the locale library can read whatever it produces. So it is just consistent. Not being able to parse its own output would certainly be a trigger for another complaint.


Trouble? I just gave two example - it is *useful* for presenting time/date information in a way that is independent of locales - it looks funny when dates are presented in norwegian in a script that otherwise prints out english (and it doesn't help that the Norwegian locales are flawed as well).
The correct answer is then to localize the script. Anyhow, the AmigaDos date conversion functions cannot do that. They don't take a locale argument but use the system locale instead. You can change the system locale with the locale preferences, even in a script, though.


 
That is fine.
According to your request, no. The output would still be "gestern" instead of "yesterday" for the German locale.


Ideally, IMO, C:Date (and the other CLI tools) should primarily use $LANGUAGE and secondly use locale settings - it should be possible to easily override system wide locale setting with a shell-local/script-local variable.
Unfortunately, that is a massive change of the locale system, and there are really much more important things than this stuff.


Any program that is not localised in itself, should never require localised input - the C:Date error messages are in English, for me they should have been in Norwegian - I only found out that I must use "I går" and "I morgen" (yes, two words, with quotes around) by chance.
I disagree. Every program that is not aware of the locale should use the right locale right away, and that is the locale selected by the user through the preferences. What would be the point of the preferences if the preferences had no impact on programs that do not have a preference themselves?

Sheesh! Again - to present time and date information in a contextual meaningful way from scripts.
Why is the output of a script running on a German system non-meaningful if it appears in German?


In my above example, the idea is that "Date FROM DH0:" sets system time from the timestamp of DH0: - useful when DH0: is not initial boot device, for example when booting from RAD:
Why does that cause any problems right now? Date is able to parse its own output, including that of list. It looks to me like a simple application of list format, date and backticks. Or execute.

And can you explain what "Setdate DH0:" actually does?
I need to check, it probably depends on the file system.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 14, 2019, 10:33:55 AM
Moving on, on the topic of system time...

Default Amiga system time is default boot system time is 01-Jan-1978 00:00:00, if I recall correctly.

At boot, the Amiga will look for a an RTC (real time clock, typically battery backed), from what I understand this is what battclock.resource does.

If RTC is found, system time is set from that.

If RTC is _not_ fond, it will move on to look for timestamp on the filesystem of the boot device - it is unclear for me what timestamp is actually used, since "the experts" seems to disagree on what is used an what it is supposed to use, and it doesn't help that different filesystems treat these timestamp fields differently. What it looks like though, is that with FFS, the so called "Creation time" is used, and there are no tools in the OS that can alter this timestamp, other than SYS:System/Format. So this means that whenever you boot a system, system time will be the same as when the system partition was formatted, and all changes to files will be marked as done in the "future" on every boot. Not so satisfying.

There are work-arounds for this.

For example I used to have a small script running in the background that just use SetDate to update a SYS:.timestamp every 60 seconds, and on boot a script lists this timestamp file with LFORMAT that matches the input that C:Date accepts (this is so early that locales are not allowed to screw things up yet) and system time is hence set to the last time the sys:.timestamp file was updated. Of course it would help A LOT if C:Date could just have an option FROM, so all locale issues were forever gone for this _use case_. But writing to a disk filesystem every minute or so can be "dangerous", so a more safe option is to instead write to a warm-boot resident area in RAM. One can do this just by using OS tools, simply by making the smallest RAD disk possible, make sure it has lower bootpri than the system disk, and use a timestamp file there, and only write to a disk filesystem when turning off the machine entirely.

But this can be done better. On Aminet there is a tool TimeKeeper that does something clever - it reserves a small address space in RAM, makes it warm-boot resident, and then goes in the background as a "daemon" and keeps on writing the system timestamp to this address space every few seconds. On boot, it will then look for this address space and set system time accordingly. A boot typically takes a few seconds, depending on setup, so it also accepts an offset option, so one can add these seconds. If no timestamp is found, or it is scrambled, it also supports running a command line, which then can be used to set the system time from a different source, for example from timestamp file on a filesystem.

But all this are work-arounds, I very much think that AmigaOS 3 should by much better in dealing with system time on systems lacking RTC, and I certainly have ideas :)

Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 14, 2019, 10:42:29 AM
Yes, but when is this a problem? So, what is a script where you depend on date to act in a non-interactive way?

Any system that lacks a functioning RTC, which I believe is vast majority of Amiga systems.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 14, 2019, 11:01:13 AM
Why is the output of a script running on a German system non-meaningful if it appears in German?

Context.

Just because I have Norwegian locale (which Hyperion says I MUST use to stay license compliant, despite the cringing quality of the locales) does not mean I can not be in non-Norwegian contexts. We live in a reality where one cannot expect everything to be localised correctly, for many of us the correct locale does not even exist, and most of us are not mono-lingual. In SYS:Prefs/Locale can set up a prioritised list of languages, and this can lead to programs/scripts having mixed language output, which can be both entertaining and confusing.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 14, 2019, 11:03:26 AM
Why does that cause any problems right now?
How do you list the timestamp of DH0: ?

In OS 3.2, what is the output of "List FLAT DH0:"?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 14, 2019, 11:08:58 AM
The correct answer is then to localize the script.

I often do, but locales for my preferred native language do not even exist, so it becomes neo-norwenglish.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on December 14, 2019, 04:02:34 PM
In OS 3.2, what is the output of "List FLAT DH0:"?
For example like this. The directory name is "" (empty) and the time stamp is the time stamp of the root.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on December 14, 2019, 05:19:11 PM
If RTC is _not_ fond, it will move on to look for timestamp on the filesystem of the boot device - it is unclear for me what timestamp is actually used, since "the experts" seems to disagree on what is used an what it is supposed to use, and it doesn't help that different filesystems treat these timestamp fields differently.
The time stamp is taken from the creation date of the volume, which is in the root node. The creation date is not adjustable.
ACTION_SETDATE adjusts the modiifcation date of the node, and by that also that of the root node.

But all this are work-arounds, I very much think that AmigaOS 3 should by much better in dealing with system time on systems lacking RTC, and I certainly have ideas :)
Frankly, why do you care? You just said you don't accept the license, so don't want to buy the license, yet bought one.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 14, 2019, 06:47:24 PM
In OS 3.2, what is the output of "List FLAT DH0:"?
For example like this. The directory name is "" (empty) and the time stamp is the time stamp of the root.

For example what? Nothing?
Code: [Select]
Directory "" is empty
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 14, 2019, 06:54:56 PM
The time stamp is taken from the creation date of the volume, which is in the root node. The creation date is not adjustable.
So the system will always boot to the same time, and all file changes will have modification timestamps in the future.

This is what should really be avoided, even when a system is without RTC, time should move _forward_ - not jump back to some rather random specific time on every reset.

Quote
ACTION_SETDATE adjusts the modiifcation date of the node, and by that also that of the root node.

If system time could be taken from modification time of the root node, it would help a lot already - then one can adjust "boot time" simply with "SetDate dh0:"

Quote
But all this are work-arounds, I very much think that AmigaOS 3 should by much better in dealing with system time on systems lacking RTC, and I certainly have ideas :)
Frankly, why do you care? You just said you don't accept the license, so don't want to buy the license, yet bought one.

That is an entirely different problem, which I just explained in a different thread - the license was not presented to me at point of sale - I very much expect the license to change in the future, perhaps even for OS 3.2.

Hyperion is, after all, run by a lawyer, and "legalese" is the only form of communication that works.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 14, 2019, 07:18:39 PM
Moving on from the trolling attempts by the head OS developers... what can be done to improve the system time problem with Amiga systems that have no RTC?

First some goals:
* system time must as much as possible go _forwards_, even between reboots, warm and cold.
* there are situations when going backwards is unavoidable, in such cases, the "amount of time" going backwards should be kept as low as possible

My suggestion is inspired by TimeKeeper and getting timestamp for boot filesystem

One part is placed in kickstart (in existing or new module, why not systemd.. I mean System-Startup), if no functional RTC is found...

* check if a certain address space in chipram contains a valid timestamp, and set system time accordingly
* if no such valid timestmap is found, allocate an address space, it and make it warm-boot resident.
* Continue as today, take timestamp from boot filesystem, but rather "modified" timestamp rather than "created" timestamp.

Second part is "running code", it would be preferable if it too was in kickstart, but if not... something that "always runs", IPrefs is a candidate, and its job is simply to
* if dedicated address space in chipram exists, steadily and frequently update it with current timestamp.

This should keep system time going forward, and updating system time to a more "current" one is a matter of adjusting it manually or via NTP, GSM over serial port or whatever, and then just doing any kind of modification to boot volume - for example "SetDate DH0:"
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on December 14, 2019, 07:33:32 PM
So the system will always boot to the same time, and all file changes will have modification timestamps in the future.

This is what should really be avoided, even when a system is without RTC, time should move _forward_ - not jump back to some rather random specific time on every reset.
You cannot avoid that. Leaving compatibility issues aside, touching a file only "bubbles up" one directory level (i.e. changes the change date of the containing directory), but it does not bubble up to the root level. That is, without doing a full tree search of the boot disk, you cannot prevent that a file has a change date in the future of the root directory.

If system time could be taken from modification time of the root node, it would help a lot already - then one can adjust "boot time" simply with "SetDate dh0:"
Though it is probably a bad idea to change this - besides, it would only be a change if the FFS is used to boot the system. For some bizarre reason, it is the boot file system that sets the system date.

What other file systems do is up to them - but there is no interface (DosPacket) to adjust the creation time of a file system, and inventing one would not improve the situation for any other file system.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 15, 2019, 08:25:35 AM
So the system will always boot to the same time, and all file changes will have modification timestamps in the future.

This is what should really be avoided, even when a system is without RTC, time should move _forward_ - not jump back to some rather random specific time on every reset.
You cannot avoid that.

It can be avoided to a much larger degree than what is the case today.

Quote
Leaving compatibility issues aside

Can you think of any?

Is there any filesystem that Amiga can boot from, that does not have a root node to get system time from?

Do all filesystems that Amiga can boot from currently, all have a creation timestamp to get system time from?

Quote
touching a file only "bubbles up" one directory level (i.e. changes the change date of the containing directory), but it does not bubble up to the root level.
I know that, and nowhere did I imply that _any_ change to a filesystem would change the root node - that was not the point.

Quote
That is, without doing a full tree search of the boot disk, you cannot prevent that a file has a change date in the future of the root directory.

Very true - but again, that was not the point.

The point was to have the *boot system time* moving forward (albeit slowly), and to make it *easy* to bump up boot system time.

Quote
If system time could be taken from modification time of the root node, it would help a lot already - then one can adjust "boot time" simply with "SetDate dh0:"
Though it is probably a bad idea to change this

Because... anything specific you can think of?

 
Quote
besides, it would only be a change if the FFS is used to boot the system. For some bizarre reason, it is the boot file system that sets the system date.

I don't think it is so bizarre, really. Would it be less bizarre to always start in 1978-01-01 00:00:00?

Quote
What other file systems do is up to them - but there is no interface (DosPacket) to adjust the creation time of a file system, and inventing one would not improve the situation for any other file system.

Exactly - do all filesystems even have a creation timestamp?

The check for timestamp on the boot filesystem could have a prioritised list...
* check for the presence of a magic file in the root of the boot filesystem (I use :.timestamp myself)
* check for the presence of a modified timestamp on the root node of the boot filesystem
* check for the presence of a creation timestamp on the root node of the boot filesystem
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: guest11527 on December 15, 2019, 09:57:13 AM
It can be avoided to a much larger degree than what is the case today.
I'm not sure in how far this is a "larger degree". In any case, the date is wrong, whatever mechanism you use to "invent" one from the file system. For those systems without an RTC, the date is probably not important in first case (low end machines, mostly gaming) and for those with an RTC, it does not matter. But I believe we shouldn't make the date seen by the system depending on the operating system.

Is there any filesystem that Amiga can boot from, that does not have a root node to get system time from?
Do all filesystems that Amiga can boot from currently, all have a creation timestamp to get system time from?
How should I know? I do not know whether or if SFS or PFS implement this mechanism.

I don't think it is so bizarre, really. Would it be less bizarre to always start in 1978-01-01 00:00:00?
The design is "upside down", really. Why is it the file system that has to do that? It is not the responsibility of a file system to care about the system time. It should be the responsibilty of the Os bootstrap code (aka "dos.library" pre-3.2, aka "system-startup" 3.2 and up) to do that and find a time source. And why take it only from the boot volume? This arrangement might have made sense at times there was only floppy boot. Realistically, it should be max(all volumes found) *if* a file system is even a source of a time stamp.

Then again, the time is made up anyway, so why bother about it? It's wrong in either case.


Exactly - do all filesystems even have a creation timestamp?
I do not know, not my business.

The check for timestamp on the boot filesystem could have a prioritised list...
* check for the presence of a magic file in the root of the boot filesystem (I use :.timestamp myself)
* check for the presence of a modified timestamp on the root node of the boot filesystem
* check for the presence of a creation timestamp on the root node of the boot filesystem
That's just another algorithm to make up a time, but to which amount is this better? And when? And why? It replaces one bogus time source by another bogus time source, and I don't see the benefits of this.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 15, 2019, 12:27:21 PM
I don't see the benefits of this.

Well, I do - am I alone?

As you say, it is a matter of finding a time source at boot - a functional RTC is the best option, a user maintained timestamp (in memory, or file) is a good second, timestamp from root node of boot filesystem a bizarre third...

The most important is that system time should, as much possible, survive warm boots.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: Tygre on December 15, 2019, 04:55:50 PM
I don't see the benefits of this.

Well, I do - am I alone?

<crickets>
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 16, 2019, 05:42:17 AM
<crickets>

I suppose this means that if OS 3.2 actually will incorporate some of my ideas (it already has), you will be utterly against it?

Or are you just OK with _ANYTHING_, as long as it comes from Thomas?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on December 16, 2019, 03:32:59 PM
Next up, a silly bug - or feature, depending on how you see it. C:Relabel, it is for relabeling volumes (devices, filesystems, partitions, whatever you like calling them), for example “relabel RAM: Memory”. However it doesn’t validate that the argument given is actually a volume/device/filesystem/partition etc or an assign, and this has the funny result that the root device (...) that the assign primarily points at, is relabeled, instead of printing an error message. For example “relabel T: Temp” will on a default setup relabel RAM: to Temp.

Feature? Bug? Nobody knows.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 05, 2020, 11:29:56 AM
On the topic of BOOPSI - whatever happened to the tabs.gadgets and the others from v42?

(http://kolla.no/CDPrefs_1.png)
(http://kolla.no/CDPrefs_2.png)
(http://kolla.no/CDPrefs_3.png)
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 05, 2020, 11:37:13 AM
A simple example of how one can bundle "apps" on Amiga.

http://kolla.no/Bear.lha
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 05, 2020, 11:49:40 AM
So with OS 3.2 it will at last be possible to get the volume label from a device, by using "List DEV: FLAT LFORMAT %F", but it will still have the trailing colon behind the volume label.

I suggest a small change to C:Relabel so that "DRIVE/A, NAME/A" becomes "DRIVE/A, NAME", and if "NAME" is omitted, the current label is printed out.

(and why not rename it from "Relabel" to just "Label" while at it)
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: giZmo350 on January 05, 2020, 01:50:53 PM
<crickets>

I suppose this means that if OS 3.2 actually will incorporate some of my ideas (it already has), you will be utterly against it?

Or are you just OK with _ANYTHING_, as long as it comes from Thomas?

@kolla   I've always wondered why you don't join / are not on the OS3.X devs team in the first place?  ;)
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: giZmo350 on January 05, 2020, 01:53:31 PM
On the topic of BOOPSI - whatever happened to the tabs.gadgets and the others from v42?

(http://kolla.no/CDPrefs_1.png)
(http://kolla.no/CDPrefs_2.png)
(http://kolla.no/CDPrefs_3.png)

I've never even seen this dialog box before...  and this used to be part of the OS? Looks very useful!
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 05, 2020, 04:00:16 PM
@kollaI've always wondered why you don't join / are not on the OS3.X devs team in the first place?  ;)

Because it would require me to sign a nonsense contract with people I don't want to be associated with.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: Rotzloeffel on January 07, 2020, 01:48:38 PM
Because it would require me to sign a nonsense contract with people I don't want to be associated with.

You can Change the contract….. I also did and they agreed….. but... you can not Change the People :)

Question! Do you know, if Thomas allready reads your Posts here? this Relable-bug is interesting… I will put this on the Bugtracker....
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: patrik on January 07, 2020, 02:27:04 PM
Try the which command to get volume name from device:. Unfortunately, before 3.2 it is bugged and doesn’t work if the root of the device doesn’t have +e or +s bit set.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 07, 2020, 06:20:37 PM
Try the which command to get volume name from device:. Unfortunately, before 3.2 it is bugged and doesn’t work if the root of the device doesn’t have +e or +s bit set.
Huh, that looks more like an unintended bi-effect of a bug than an actual feature...
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: Rotzloeffel on January 07, 2020, 06:57:57 PM
C:Relabel, it is for relabeling volumes (devices, filesystems, partitions, whatever you like calling them), for example “relabel RAM: Memory”. However it doesn’t validate that the argument given is actually a volume/device/filesystem/partition etc or an assign, and this has the funny result that the root device (...) that the assign primarily points at, is relabeled, instead of printing an error message. For example “relabel T: Temp” will on a default setup relabel RAM: to Temp.

Feature? Bug? Nobody knows.

This was a bug! Thank you for reporting! This issue is fixed in 3.2! Relabel refuses assigns now!
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: patrik on January 07, 2020, 07:05:25 PM
Try the which command to get volume name from device:. Unfortunately, before 3.2 it is bugged and doesn’t work if the root of the device doesn’t have +e or +s bit set.
Huh, that looks more like an unintended bi-effect of a bug than an actual feature...

"WHICH lets you find a particular command, program, or directory by entering
 its name. If the named item is in the search path, WHICH displays the
 complete path to that item."

http://www.jaruzel.com/amiga/amiga-os-command-reference-help/which.html
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 08, 2020, 04:26:32 PM
"WHICH lets you find a particular command, program, or directory by entering
 its name. If the named item is in the search path, WHICH displays the
 complete path to that item."

Right, but if it ever was intended to take device names as argument and print out volume name, it has been, and still is (OS 3.1.4.1) broken, and even when it works, it still prints volume name with a trailing colon.

I would argue that the only really "correct way", would be to extend C:Info with LFORMAT and %Ns for printing out size, used, free, full, errs, status and name.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: patrik on January 08, 2020, 07:21:10 PM
Out of curiosity, when is volume name without colon needed?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 08, 2020, 08:08:29 PM
When is timestamps on files needed? When is volume names at all needed - why not just name partitions “funny names” straight in hdtoolbox?

I want them for many things, for example when making directories with corresponding names on a backup server... and much more.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: TribbleSmasher on January 08, 2020, 08:21:00 PM
out of curiosity, there is no 'grep' like tool (or any other way) to strip characters from strings?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 08, 2020, 09:38:45 PM
out of curiosity, there is no 'grep' like tool (or any other way) to strip characters from strings?
UNIX grep is not for stripping, it is for searching, vaguely equivalent to C:Search.

To answer your question, if there is a "cut" like tool in the OS itself?
Not really, though you can use C:Ed and a script, or simply dive straight into ARexx.
I think perhaps ThoR may have mentioned variable substitution methods, but I don't recall if it is already in, or possibly in the future.

The easiest tool to use for this kind of stuff currently, is ThoR's own SED which you can find on aminet (util/cli/SED.lha)

EDIT: well, maybe not easiest, as there are various other tools, such as unix inspired or ported cut, paste as well as myriads of grep, sed and awk clones, but most of these are ancient, unmaintained,  unreliable and certainly not sometihng you can expect to be available and anyone else's Amiga. And util/cli/SED.lha renders them all redundant (well, maybe not awk...)
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 08, 2020, 09:51:47 PM
Regarding "WHICH", if it is to take paths to directories, assigns, devices and volumes as arguments (which I have nothing against, btw... just find it a little odd), should it then also not be consequent about it, so that
Code: [Select]
Which LIBS: ALL
not results in
Code: [Select]
Minimig:Libs
but rather
Code: [Select]
Minimig:Libs
Minimig:Classes
as well as other directories that are assigned to LIBS:?

(And then there is that eery situation when you insert a floppy named "Locale" while there also is the assign LOCALE: and suddenly all the catalogs etc in the assign "vanish" as long as the floppy named "locale" is inserted...)
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 08, 2020, 10:23:39 PM
Super tip:

If you want to protect a bunch of files from being deleted or mangled with (well, renaming always work), there is of course C:Protect, but filesystem flags can be overwritten, or overwrite enforced etc.

So a different approach is to use C:Assign.

Assigns do not just work on directories, as they are normally used, but also on files, and once a file is part of an assign, the OS will claim it as "busy" and protect it with claws, beak, fang etc.

So, to be a little paranoid, take all files you really really care about, and make an assign and let it point to all those files.

(http://kolla.no/amiga/protect.png)

Also, one can use assign instead of alias if one wish...

Code: [Select]
Assign Less: SYS:Utilities/More
Less: S:Startup-Sequence

Whacky, huh?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: patrik on January 09, 2020, 12:30:04 AM
Super tip:

If you want to protect a bunch of files from being deleted or mangled with (well, renaming always work), there is of course C:Protect, but filesystem flags can be overwritten, or overwrite enforced etc.

So a different approach is to use C:Assign.

Assigns do not just work on directories, as they are normally used, but also on files, and once a file is part of an assign, the OS will claim it as "busy" and protect it with claws, beak, fang etc.

So, to be a little paranoid, take all files you really really care about, and make an assign and let it point to all those files.

(http://kolla.no/amiga/protect.png)

Also, one can use assign instead of alias if one wish...

Code: [Select]
Assign Less: SYS:Utilities/More
Less: S:Startup-Sequence

Whacky, huh?

Very interesting, thanks for the tips!
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 15, 2020, 08:35:33 AM
I just put this link here, since the misinformation/ignorance level is so entertaining...

http://www.apollo-core.com/knowledge.php?b=9&note=26937&z=ds6kB4
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: Minuous on January 15, 2020, 09:31:36 AM
There are a lot of generalizations in that thread, whereas the actual situation is different depending which OS component is being discussed.

In some cases, the latest sources were available and it was possible to continue on from V45. In other cases, the work had to be redone starting from OS3.1 sources.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 15, 2020, 09:47:27 AM
While I am here - new to latest OS 3.1.4(.1) and 3.2 improved (bugfixed mostly) is the concept of piping to execute to run commands.

For example, the below are equivalent now...
Code: [Select]
execute s:user-startupand
Code: [Select]
type s:user-startup | execute
But how useful is really this?
Well, one can now do trendy hipster silliness like "wget -O - http://amigahaxor.io/infest | execute" also on Amiga. Yay.

However, this feature is a tad confusing, if there was logic to this nonsense, then these would be equivalents:
Code: [Select]
execute s:user-startupand
Code: [Select]
echo s:user-startup | execute
A limitation with this nonsense, is that the stream of lines on the left side of the pipe needs to be fully assembled command lines.
For example output from list with help of lformat, with some luck this works...
Code: [Select]
list sys: all files p="#?.info" lformat "processicon *"%p%m*" mwb2ci" | execute
Cool.

But what if the stream of lines on the left is not based on files, and hence cannot be listed with lformat?
For example, what if it a stream of hostnames that you wish to run a remote command on? Well, one can use some streamline editor, like Thor's own SED:

Code: [Select]
Type myhosts.txt | SED match "{#?}" REPLACE "ssh \-l kolla {1} \*"uptime \-s\*"" | Execute
But that requires that one has SED, and understands SED - a rather daunting program for "most users" - especially with all the ...eh.. exotic .. escaping that is required.

But there is an alternative, tiny and elegant, it in a way mimics xargs on *ix, and its name is EArg. It can do exactly what Execute can do now:
Code: [Select]
type s:user-startup | earg
but unlike Execute, it can also add to the command to be executed, for example
Code: [Select]
type s:users-startup | earg echo "haha hihi"or
Code: [Select]
type s:users-startup | earg between echo haha
So, one can do this:
Code: [Select]
Type myhosts.txt | EArg between "ssh -l kolla" "*"uptime -s*""

http://aminet.net/package/util/shell/EArg
and
http://aminet.net/package/util/cli/SED
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 15, 2020, 09:51:03 AM
There are a lot of generalizations in that thread, whereas the actual situation is different depending which OS component is being discussed.

Right, so what Gunnar writes is utter nonsense:

Quote
This means all the development which went into 3.5 and 3.9 is first of all lost.
3.1.4 is new fork based on 3.1 sources - it is not based on the code of 3.9.
3.1.4 is definitely NOT a bug fixed 3.9
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 15, 2020, 09:56:52 AM
And now he has moderated himself to say that 3.9 and 3.1.4 may share some "third party work/fixes" - yeah, so that is what all OS development since 3.1 has been - third party. Da lolz.

EDIT: Well, isn't it ironic that the hardware project that was said to trigger the interest from Hyperion to further develop OS 3.1, is now going for AROS while maintaining its strong ties to an assembled pirate version of OS 3.9, even to the point that the main developers strongly advice against using any OS3 from Hyperion...
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 15, 2020, 11:40:44 AM
Btw - Michael Farrell - who started that thread - if you read this - the reason why your RAM Disk is blinking, I am guessing, is due to CoffinOS coming with some sort of ENV-handler/happy-env, which sets up ENV: as a dedicated device, and then it has been marked in Prefs/Workbench to be hidden. Enters the script, that (I guess) re-instate that ENV: is an assign to a directory on RAM:, and this confuse the Workbench prefs that goes on to attempt to hide the device associated with ENV:, which is RAM:, only to fail and try again, and again... quick solution is to enter Prefs/Workbench and press "Save" to write a new prefs without any hiding of ENV: - OR to re-enable env-handler/happy-env in Startup-Sequence.

If anyone can be bothered to file a bug with OS 3.1.4 regarding hiding of volumes/devices not checking wether the volume/device is actually a volume/device and not an assign - this resembles the C:Relabel bug from earlier.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 15, 2020, 03:39:23 PM
Minuous status as OS3.2 developer (wherever Reaction goes, so does he) is obviously lost on some.

scsi.device (not .library) supports IDE splitters once there is a rom module with the resident name “ATAPIMajik” in place, it was not known in 3.9, but came along in 4.0 and 4.1, albeit as PowerPC code. Whether it comes with 3.2 or not doesn’t matter, as the cat is out of the bag, so to speak.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 15, 2020, 09:00:54 PM
Fascinating - the head OS 3 developer writes example shell commands that are nonsense, and for pointing it out, one get banned for trolling by this "AMike" character who for some reason is super moderator.

https://www.a1k.org/forum/index.php?threads/67528/page-3#post-1241265 is full of errors.

Code: [Select]
list lformat="DEVS:Monitors/~(#?.info)"
This makes little sense, it does nothing than print out "DEVS:Monitors/~(#?.info)" for every file/dir entry in the current directory, I suppose the idea was to write something to the effect of

Code: [Select]
List "DEVS:Monitors/~(#?.info)" lformat "%p%n"
Ah, gotta love this community with its alpha-nerds and sycophants, team this and team that, and everyone fighting over crumbles and feathers... :)
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: Louis Dias on January 17, 2020, 02:42:25 PM
Most of 3.5 and 3.9 was re-licensed by Cloanto along with some *new* development that 3.1.4 claims is new but wasn't (large disk support) ... Hence Cloanto's OS is called 3.X aka 3.10 as in 10 > 9 as in OS X as in how Microsoft skipped Windows 9 and now the only version of windows they support is 10 aka X.

But I digress...

So - no!  3.5 and 3.9 is not lost thanks to 3.X from Cloanto.  I don't know why this is not known by the sheep...I mean masses...

https://www.amigaforever.com/kb/15-107
https://www.amigaforever.com/kb/16-125
https://www.amigaforever.com/kb/16-120
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: BozzerBigD on January 17, 2020, 03:06:53 PM
Quote
So - no!  3.5 and 3.9 is not lost thanks to 3.X from Cloanto.  I don't know why this is not known by the sheep...I mean masses...

Because there was no marketing, no clamour for it and no interest IMHO! OS3.9 seemed fine for most users though until OS3.1.4 gave the 3.1 loving purists some bug fixes.

Just for clarification is long filename support a function of the File System rather than the OS? FFS in OS3.9 doesn't seem to support more than 30 char filenames? A bit lame in this day and age!
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: Louis Dias on January 17, 2020, 06:14:16 PM
Maybe my memory is bad but I thought FFS could have 255 length filenames...
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 18, 2020, 04:24:31 PM
With DOS\7 it is 107 chars, before it was just 31 chars.
31 was limitation in filesystem, 107 is limit in dos.library, iirc.

In addition there is probably also a max limit for a total path to a file, but I don’t recall that one.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: nbache on January 18, 2020, 05:40:17 PM
@Louis Dias:

In OS4, DOS was changed to allow filenames with a length of 255, if the filesystem supports them.

In case that's what you were thinking of.

Best regards,

Niels
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 21, 2020, 05:34:03 AM
I split my user-startup into many files to ease maintaining and quicker enable/disable by renaming, so in S:Startup-Sequence...

Code: [Select]
If EXISTS S:User-Startup
  Execute S:User-Startup
EndIf

If EXISTS S:User-Startups
  List S:User-Startups ALL FILES P="#?-Startup" LFORMAT "Execute *"%p%n*" TO PIPE:U
  Sort FROM PIPE:U TO PIPE:U
  Execute PIPE:U
EndIf

(I avoid using piping with "|" in startup-sequence, it does NOT reliably work as intended when Execute is resident)

For example, I use NN_ as prefix on these startup-scripts, where NN is a number indicating the sequence of execution...

Code: [Select]
1.Minimig:> List S:User-Startup#? ALL FILES P="#?-Startup" LFORMAT "Execute *"%p%n*"" | Sort
Execute "S:User-Startups/20_REXX-Startup"
Execute "S:User-Startups/50_RAM-Startup"
Execute "S:User-Startups/80_AmiSSL-Startup"
Execute "S:User-Startups/80_CygnusEd-Startup"
Execute "S:User-Startups/80_IconLib-Startup"
Execute "S:User-Startups/80_MUI-Startup"
Execute "S:User-Startups/80_RapaGUI-Startup"
Execute "S:User-Startups/80_Reaction-Startup"
Execute "S:User-Startups/80_TTFLib-Startup"
Execute "S:User-Startups/80_UHC-Startup"
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: CMTX on January 23, 2020, 12:00:43 AM
Hello :) I am a happy os 3.1.4 user/customer. I think it is good stuff and improves over the old 3.1 in key areas. Looking forward to version 3.2!

With that said, there is one thing that bugs me when using this or any other flavour of classic amiga OS; the inability to use dual monitors with ecs/aga and a graphics card. When an rtg screen gets atention the ecs/aga screen dies, and afaik there is no patch or workaround for this. I don't know if this is something that has to be addressed on the Amiga OS side or on the P96 side, but if it's in your hands doing something PLEASE PLEASE PLEASE do it :) There are thousands of Amiga users with gfx cards that would benefit :)

Cheers
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 23, 2020, 01:58:55 PM
With that said, there is one thing that bugs me when using this or any other flavour of classic amiga OS; the inability to use dual monitors with ecs/aga and a graphics card. When an rtg screen gets atention the ecs/aga screen dies, and afaik there is no patch or workaround for this.
If you are using P96:
http://cd.textfiles.com/amigama/amigama199804/WWW/Picasso96/FAQ.html

Quote
Q: What Picasso96 ENV variables are there?
A: There are:
ENV:Picasso96/AmigaVideo: if set to 31kHz, the Amiga will be set to a MULTISCAN-like mode when Picasso96 screens are shown. This is necessary if you want to have a high audio sampling rate because the Amiga audio is coupled with the Display DMA. Only set this if you do not have a 15kHz monitor like the A1084 attached to the Amiga video port.
ENV:Picasso96/BlackSwitching: if set to "Yes", the display will be set to black when screen switches involve a memory transfer of the new screen to the board. This way it might look better. Use it as you like it.

If you are using CGfX4, there are other options - but I can tell you it works as my A3000 has at times been using 3 monitors at once, one on CVPPC, one of CV64 in addition to the native ECS screen.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: Louis Dias on January 23, 2020, 07:27:26 PM
@ multiple screens...

Wouldn't it be nice if you could have an nice touchscreen menu on one screen and then the main app/game screen on the high-powered card?
Oh damn I think I just invented the Wii U...
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: my_pc_is_amiga on January 26, 2020, 03:14:42 AM
In regards to P96 for classic, wondering 2 things when comparing to OS4.0:

1) OS4.0 has a CyberVisionPPC driver -- is this ppc native and if not would it work on 68k?  And wondering why P96 on 68k doesn't have driver if it was developed on OS4?

2) For the screen dragging in P96, this has probably been discussed but wondering what was done in OS4 to support screen dragging?   Was this an enhancement in the OS or P96 to enable that?
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: nbache on January 26, 2020, 01:44:17 PM
In regards to P96 for classic, wondering 2 things when comparing to OS4.0:

1) OS4.0 has a CyberVisionPPC driver -- is this ppc native and if not would it work on 68k?
Yes, it is PPC native, and no, it won't work on 68k. In spite of the name, it does also work with the BVisionPPC card on the A1200, but again only PPC native.

Quote
And wondering why P96 on 68k doesn't have driver if it was developed on OS4?
It might be because the CyberVision cards were developed and/or marketed by the same company who had the P96 competitor CyberGraphics. It wasn't until later that P96 got to be a de facto standard.

Quote
2) For the screen dragging in P96, this has probably been discussed but wondering what was done in OS4 to support screen dragging?   Was this an enhancement in the OS or P96 to enable that?
I believe it was first and foremost in layers.library, but I wouldn't be surprised if there were also stuff done in intuition and other places. Also not that by now (4.1FE), P96 does not exist as a separate entity, it has been completely integrated into the OS (graphics.library mostly, IIRC).

Best regards,

Niels
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on January 26, 2020, 03:02:59 PM
There is a CVPPC card driver for 68k P96, but the developer seem unwilling to release anything that he isn't able to test and debug first hand. So it really boils down someone sending him a system with a CVPPC (and hence also a CSPPC, or a CS040/060 mk-II iirc).

On the other hand, one can continue to use CyberGraphX v4 with CVPPC and enjoy screen dragging and all the other features that P96 lacks anyhow.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: CMTX on January 26, 2020, 10:00:55 PM
With that said, there is one thing that bugs me when using this or any other flavour of classic amiga OS; the inability to use dual monitors with ecs/aga and a graphics card. When an rtg screen gets atention the ecs/aga screen dies, and afaik there is no patch or workaround for this.
If you are using P96:
http://cd.textfiles.com/amigama/amigama199804/WWW/Picasso96/FAQ.html

Quote
Q: What Picasso96 ENV variables are there?
A: There are:
ENV:Picasso96/AmigaVideo: if set to 31kHz, the Amiga will be set to a MULTISCAN-like mode when Picasso96 screens are shown. This is necessary if you want to have a high audio sampling rate because the Amiga audio is coupled with the Display DMA. Only set this if you do not have a 15kHz monitor like the A1084 attached to the Amiga video port.
ENV:Picasso96/BlackSwitching: if set to "Yes", the display will be set to black when screen switches involve a memory transfer of the new screen to the board. This way it might look better. Use it as you like it.

If you are using CGfX4, there are other options - but I can tell you it works as my A3000 has at times been using 3 monitors at once, one on CVPPC, one of CV64 in addition to the native ECS screen.

This doesn't work in my experience, at least with P96. I cannot try cybergraphics with my card (Vampire). With those env variables activated, the rtg screen is always visible, even if you are working with a native screen, BUT as soon as the RTG screen is focused the native screen dies. So, it's possible to use the native screen while you see the rtg screen working, but it's not possible the other way around. This absolutely kills the double screen experience.

Some time ago I did extensive research of this issue on the net and found many people in the same situation as me. At the end the recommended solution is to buy a second graphics card, but i'd prefer to not spend another 200-300€ more, if possible :)

Cheers
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on February 02, 2020, 07:13:38 PM
Shocking statement from someone intimately involved with OS3 development:

http://eab.abime.net/showpost.php?p=1375937&amp;postcount=71

Essentially saying AROS is pointless because Amiga OS will be open sourced anyways.

Must be a sign of desperation, the end is near...

What will Thomas say?! Gasp!
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on March 02, 2020, 10:16:03 AM
I cannot confirm this. If I open the info window, and drag a file with only a .info and no file in it, I get the new icon all fine. The only particular combination in which nothing happens is if you open a drawer which is "list by names", and "show all files", and you drag a file without an icon into the info window. Then nothing happens. Which is plausible as there is no icon to begin with.

Mea culpa - I was confusing myself with RAWBInfo - default WBInfo does indeed work correctly.

Mea culpa rursus - it does happen with "native" WBInfo and RAWBInfo alike, when the source icon is of type "drawer" and no drawer exists. Changing icon type to "project" (for example) solves this, or making a drawer or a file with corresponding name.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on March 02, 2020, 10:59:53 AM
How to delete all empty files (and hopefully only empty files) in a path "path/", using only shell commands provided with the OS, using a broken implementation of locale in the C:List command as well as "forgiving" behaviour of C:Delete regarding non-existing files when more than one argument is given, one can do this...

Code: [Select]
List path/ ALL FILES LFORMAT "Delete *"%p%n*" T:_this_file_is_%b" | Search NONUM T:_this_file_is_empty | Execute

(then one can argue over why List uses "empty" and not "Empty", since it uses "Dir" and "Soft", and why not just a linguistically neutral "0"...)
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on March 09, 2020, 01:25:13 PM
With newer versions of AmigaOS, there is an alternative way of launching shell scripts from Workbench, which doesn't involve IconX - instead of an icon of type "Project", one can set icontype to "Tool", tick attribute (protection bit) "script" and add CLI and DONOTPROMPT as tooltypes - that is select "Shell" in the "Start from:" menu and remove the "Prompt for input:" tick. On double click, the script will just be executed.

These tooltypes do not work with WBLoad though, which only report "object is not of required type"...

I would argue that a text file that has S-bit set, by default should rather be treated as a tool than as a project by Workbench (and/or Deficons).
It should also be possible to tick for H and P protection bits from WBInfo.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: kolla on October 31, 2020, 02:22:55 AM
In a funny twist of events, this happened:

http://aminet.net/package/driver/media/AtapiMagic

A readme littered with BS about Hyperion ownership, copyrights, distribution restrictions etc (really, this “trick” predates Hyperion OS development, so what’s so special about this code?) so it is not without irony that this binary is the same as in this posting, by OS developer ThoR:

https://forum.amiga.org/index.php?topic=74270.msg847086#msg847086

So, since in that post, in which ThoR included the rom module, he says that anyone who feel like it can test this module and there is no mention of distribution limitations... why is all that BS being posted to Aminet? A little too late too, that binary is distributed widely by now.
Title: Re: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks
Post by: BSzili on October 31, 2020, 08:03:49 AM
This is my favorite part (emphasis is mine):
Quote
AmigaOS always supported 2 devices on the IDE port. To be able to
use 4, a third party software patch called IDEFix was often used. The
problem is that the IDEFix software does not work correctly under many
OS versions
. In fact, on many scenarios, it will most likely fail.
Yeah, under 3.1.4 and 3.2. Translation: we broke compatibility with IDEFix ;)

Quote
AtapiMagic has been tested working under both AmigaOS 3.1.4 and
AmigaOS 3.2. That said, under a few unknown circumstances, it seems it
may not work according to a small amount of reports received
.
This sounds like some Apple press release after they got sued for some hardware issue  ;D