AROS ABIv0 20201110 Development

[Amiwell]

That's very good TBH. It might be that fixing these two gifs is the best possible solution rathen then trying to do tricks with with datatypes. I need to analyze this further.

Correcting the two gifs solves the problem with the small and peculiar GifAnimas of AmiGG, but on the AROS Build, "standard" GIFAnim (the ones used on the WEB), they will not be recognized and cannot be executed.

With the Modified Descriptors, on the other hand, everything works perfectly, both AmiGG and "all" commonly used GIFAnimations on the Web, see screenshot.

To mean the Animations you see in the Screenshot with the AROS Build you cannot run them !

You used the same datatypes as the contrib archive

[AMIGASYSTEM]

I closed owb copied other fonts and restarted the program without doing any reboot

After you have copied "all" the "Fonts" from Build 20201110, and overwritten your own, you must clean the OWB Chace and reboot if you want to notice the problem ! If you have not done this you will not notice any difference.

[AMIGASYSTEM]

You used the same datatypes as the contrib archive

GIFAnim.datatypes contrib works well, even if installed together with GIF.datatypes, you will be able to see GIF Images and Animations correctly, but the AmiGG Program will not work, AmiGG works only with the Descriptors modified by me, and the conversions of the two files mentioned above.

[Amiwell]

You used the same datatypes as the contrib archive

GIFAnim.datatypes contrib works well, even if installed together with GIF.datatypes, you will be able to see GIF Images and Animations correctly, but the AmiGG Program will not work, AmiGG works only with the Descriptors modified by me, and the conversions of the two files mentioned above.

ok i understand but there is file ".gifanim.i386" what is this?

[AMIGASYSTEM]

That's very good TBH. It might be that fixing these two gifs is the best possible solution rathen then trying to do tricks with with datatypes. I need to analyze this further.

Unraveled the mystery, basically the fake Animations, are nothing more than GIF images with a transparent background.

Basically if on a GIF Image (GIF 87a),  you create the transparent border, it is automatically saved as GIF 89 (Acronym for GIF Animated), then as if it were an animation.

Conclusion, if I remove the transparencies to the images in AmiGG, there will be no more conflicts and the GIF datatypes of the Build and the GIFAnim of the Contrib can be used simultaneously, and my Descriptors will no longer be needed

EDIT:

Negative, with the Build/Contrib GIF and GIGAnim Descriptors, you cannot use AmiGG, even if you convert the fake Images

Basically the 2 Build/Contrib Descriptors, have identical file internals, only the designated datatypes change, hence the possible confusion in Image/Animation recognition.

for the time being on AROS One remain my descriptors which do not have these problems in recognizing files.

[ncafferkey]

  - ATA=off switch (use ATA=disable)

Boot prefs may need to be updated to use this option, and also for other things (e.g. when it parses the first boot configuration, it thinks USB is disabled and floppy is enabled, perhaps because boot options have changed or vary between ABIs).

Recorded for future: https://github.com/deadw00d/AROS/issues/91

Thanks.

  - Moved Sashimi to SYS:Tools/Debug

What about Bifteck?

  - Moved PCITool and ACPITool to SYS:Tools/Hardware

IMHO this doesn't necessarily make sense. Several other tools could be considered hardware related, e.g. HDToolBox, SysExplorer, ShowConfig, not to mention the printer tools.

The mentioned tools were at some point moved to Development, which means they were not installed in standard installation (Development is not installed by default). However I often use these tools to ask user to provide information on their system and so I found it important to have them in standard installation. (Bifteck I don't use - if you use it go ahead and move it).

As for directory placement it's a subjective topic. I think there is more than one way of grouping these programs that would seem valid from certain point o view.The way that it is now, it good enough for me.

Fair enough, I realise it's always going to be subjective. To be clearer though, I probably should have said where I do think is a good place for them rather than where I don't Still just IMHO, but I was used to and happy with PCITool directly in SYS:Tools, and I'm guessing a lot of other users were too. I know it wasn't your decision to move them to Development.

Re Bifteck, my reasoning is that like Sashimi it's also a useful tool for users to capture system information either for themselves or to pass on to developers.

[deadwood]

Is there some magic involved in creating a USB FAT pen drive that is visible by AROS? I formatted a 4GB pendrive with MBR, FAT32 LBA primary partition under Linux and when I attach it to AROS (either native or VirtualBox), the volume is visible as NDOS. :/ When I format it from AROS side, it become visible under AROS, but Linux reports that file system is damaged. :/

[AMIGASYSTEM]

I format the 4/8 GB Pendrives from Windows in FAT32 and they are visible correctly even from AROS

Of course when I use a Pendrive to install AROS or OS3, before I use it on Windows, I delete the partition first, also you have to also clean up the Bootloader "RDB" otherwise even if you format it in FAT32 and it works fine everywhere, the Bootloader "RDB" remains stored on the Pendrive, this happens also with HDs.

Probably Linux in your pendrive still sees the AROS Bootlloader, try to delete the partition and do a Wipe on the first 2/300 MB, so you delete the AROS BootLoader

This also happens:

Depending on the initialization the same pendrive, after formatting it FAt32 on AROS is assigned a different def_icon, def_USB or def_hardisk, this depends on what is left in the bootloader.

A proper cleaning of the pendrive should have def_USB as an icon.

[deadwood]

Re Bifteck, my reasoning is that like Sashimi it's also a useful tool for users to capture system information either for themselves or to pass on to developers.

Since I don't use Bifteck, moving it is an unnecessary change for me - which I try to avoid. If you believe you will need it for your development or for remote-user-debugging, go ahead and move it (move binary and icon, don't move the source code please).

[deadwood]

@AMIGASYSTEM

Unfortunatelly doing full erase of pendrive did not help. The FAT partition visible from Linux is not visible from AROS. Looks like some specific bug between USB and fat-handler, as I prepared a virtual disk image with same parameters (MBR, FAT LBA, primary partition, 4GB) and this disk works correctly under AROS. I'll need to invastigate this.

[AMIGASYSTEM]

Just for verification, have you tried formatting the Pendrive on Windows? If you don't have Windows I prepare a 4GB USB image formatted with Windows and "burn" it to your Pendrive.

[deadwood]

@AMIGASYSTEM

Thanks, I already located the problem. It might be that Windows formats a bit different and you will never have this problem.

[deadwood]

First patch available:
https://axrt.org/development/20201110-PATCH-D1.zip

PATCH-D1:
  - ScreenMode crash on nVidia cards
  - fat-handler now recognizes certain Linux-formatted partitions

Open topics:
  - kernel needs IOAPIC disabled for nVidia PCI-E cards to work
  - ACPI Reboot/Shutdown on VMs
  - Acer Aspire One / Eepc USB problems
  - https://github.com/deadw00d/AROS/issues/86
  - https://github.com/deadw00d/AROS/issues/88
  - AmiGG does not start with GIFAnim

[AMIGASYSTEM]

I noticed that the Wanderer Prefs GUI has become very large, and no it is not possible to resize it, can it be resized like in the old Builds ?

[miker1264]

@AMIGASYSTEM

Thanks, I already located the problem. It might be that Windows formats a bit different and you will never have this problem.

@deadwood

That's correct. Fat32 formatting can be different for each OS. Even Windows 2000 formatted Fat32 differently than more recent OS versions. There used to be a 32GB limit for Fat32 partition size then it became the 128GB limit. There are subtle differences even between Windows versions. It's very possible that Linux formats Fat32 differently. I believe it's called VFat but I'm not sure about that last part.