AmigaOS 3.2 released!

[mateusz_s]

Regarding my CF card problem after upgrading to 3.2.2: http://eab.abime.net/showpost.php?p=...postcount=1457

is reading CF card from PCMCIA depends only on that 2 files:
- handler like L:CrossDOSFileSystem or L:fat32
- and the drivers compactflash.device ?

I guess that this new Hot Fix wont fix this xD But I will try..

ps.
It would be great if the future releases - the Install disk would have option to mount
CF card thru PCMCIA - it would improve and speed up the system installig process so much.

[ClarkKent71]

Are there any way to turn dithering off for picture.datatype for other color-resolutions than hi color Workbench?

I find that dithering is quite ugly for low-color amigas (for example in 32 colors). This has allways been the case i AmigaOS. It is also quite time-consuming on slow Amigas. Only hi color is mentioned in the help file.

Just compere loading and rendering a picture on Workbench on an low-color Amiga in Ad Pro, with showing the same picture through Datatypes. Not only is the dithering terrible in the last case, it often chooses wrong color(s).

[Olaf Barthel]

Originally Posted by mateusz_s

Thanks for help..
So I used this help CF boot starting disk that uses old fat32 filehandler from aminet: https://sites.google.com/one-n.co.uk...boot-cfd-fat95

And CF reader started working again on it!
So its not the hardware problem.

To sum up:
After updating to 3.2.2 PCMCIA card reader stopped working.
After changing the handler from CrossDOSFileSystem to fat32
(from aminet) it started working again..

Looks like a file system bug to me, then. Could be that this is an easy fix, but I doubt it... I assume that by the name of the file system, you were using the long name variant rather than the 8.3 name scheme?

I would like to compare the fat32 file system implementation with what AmigaOS 3.1.4 and beyond have shipped with in the form of CrossDOSFileSystem, but 253,853 bytes of assembly code for the fat32 file system is just too much for this tiny little overheated brain

[kamelito]

Can you tell which function expose the issue? You may even have a test program that can be used to narrow down the issue. Please provide the info or at least what changed in Exec.
Dunno if it was already stated but the error is 0100 000c in the RAM process.
The problem is when you write to Ram: by copying file to it. Reading from Ram: when you copy from Ram: to CF card for example does not show any problems.

[boemann]

Originally Posted by kamelito

Can you tell which function expose the issue? You may even have a test program that can be used to narrow down the issue. Please provide the info or at least what changed in Exec.
Dunno if it was already stated but the error is 0100 000c in the RAM process.
The problem is when you write to Ram: by copying file to it. Reading from Ram: when you copy from Ram: to CF card for example does not show any problems.

Who are you commenting on and asking ?

[kamelito]

@Boemann you or any AmigaOS dev team member that can give an answer.

[boemann]

Originally Posted by kamelito

@Boemann you or any AmigaOS dev team member that can give an answer.

Sorry I have a really hard time understanding your very short questions?. What are you even asking about ? please be a lot more specific.

[tron^fr]

Originally Posted by boemann

Who are you commenting on and asking ?

Fairly sure he is generally refering to:

https://eab.abime.net/showpost.php?p...postcount=1329


There is some discussion going on if this issue is purely V4 related.

According to https://eab.abime.net/showpost.php?p...postcount=1460 - it seems that from Amiga OS Dev Team perspective it is an issue solely V4 related. Which could imply that this issue has not reported by a significant number of for instance 68060 or PiStorm Users.


Is this the right conclusion - purely V4 related ?


If so, the V4 Team and others can focus on the V4 related SW/HW parts.



Other than that, I admire the Amiga OS 3.2 development and in particular Codecraft.

[kamelito]

Yep Tron it is exactly this.

[mfilos]

@Kamelito
AS tron^fr said, I stated the exact problem you describe here: http://eab.abime.net/showpost.php?p=...postcount=1329 along with videos and my full troubleshooting method to detect the issue..

As a summary (and from my own PoV):
- When using 3.2.2 ROM I have the Alert Orange errors while running applications (even CLI). I also have RAM-Recoverable errors when starting MCP from Startup-Sequence. If I use the test ROM of 3.2.1 + the 3 modules (exluding the exec.library) then no problem with MCP or orange alerts.
- No problem of ANY KIND using Failsafe mode (that runs under PAL and no RTG system).
- No problem of ANY KIND using the same CF mounted on my A600 using V2-600 accelerator (which uses same 080 core) but has 128MB of RAM (instead of 512MB of my V4SA)
- No problem of ANY KIND using the same CF mounted on WinUAE configuration clone of my system
- No problem of ANY KIND disabling Superscalar mode in Vampire configuration (using 1 instead of 2 pipes), meaning lower MIPS.

Sadly I don't have any other Amiga with accelerator to test so my only tests are either by V2-600 or V4SA or WinUAE.

Some other users (TheCorfiot) had the same error with 3.2.2 on his Blizzard 1260 board (with 256MB RAM) running OS3.2.2. Next week he could be doing some tests removing his extra RAM to see if that has something to do with it or not. As he's a friend I'll try to see if it's related to this sort of issue or not... Till then, I have no actual proof.
There are also some other references from users using CaffeineOS on PiStorm (updated to 3.2.2) but I have no pictures or references to show... alas no actual proof.

That's all from my own PoV trying to do my best to help :/

So far from my findings (and since I'm no AmigaOS developer to know basis) the issues that are probably the cause are either: exec.library, P96, Apollo-Core on V4, more than 128MB RAM on some accelerators(?), or some sort of combination of the mentioned... Certainly not something easy to find and troubleshoot with so many configs around.

[boemann]

Thanks

So yes we have talked with the vampire team and in the middle of March I sent the them the source code to the change in exec.library

We were told that replacing exec.library with the 3.2.1 versions solved the issue. However the only change in exec is that we now try to detect if the system has a gayle chip. If it doesn't have a gayle chip then there are no change.

The feedback we got was that the change was okay, and that the bug must be somewhere else.

Mind you I've also been told that if you disable SuperScalar that also fixes the issue.

Those two things combined have made us conclude for now that it is likely that superscalat is causing it.

We have had no reports from other users than vampire which again leads us to believe it is vampire related.

If this turns out to be wrong we would naturally gladly fix any bugs in 3.2. But right now there is nothing else we can do from the OS side.

[kamelito]

@Boemann if you do a memower $address reported by the recoverable alert you get:

018C60E8 - in -TCB- of Process 0x018C60E8: RAM
018C60E8 - in Memlist of Process 0x018C60E8: RAM

I have not the problem in PAL mode so not an issue with P96 to me.
Dunno what changes has been done in the RAM process code but it is Exec ballpark.

[mfilos]

Just wish some people using PiStorm could post in this thread if they're experiencing these sort of issues or not.
Even people with accelerators or systems with more than 128MB of RAM without issues would help at least to narrow down the possibilities

[boemann]

Originally Posted by kamelito

@Boemann if you do a memower $address reported by the recoverable alert you get:

018C60E8 - in -TCB- of Process 0x018C60E8: RAM
018C60E8 - in Memlist of Process 0x018C60E8: RAM

I have not the problem in PAL mode so not an issue with P96 to me.
Dunno what changes has been done in the RAM process code but it is Exec ballpark.

There have been no change to ram process code. But gurus from that part is most often caused by other things. Eg a program freeing wrong addresses, so this guru is of little use unfortunately.

[boemann]

Originally Posted by mfilos

Just wish some people using PiStorm could post in this thread if they're experiencing these sort of issues or not.
Even people with accelerators or systems with more than 128MB of RAM without issues would help at least to narrow down the possibilities

While a report from pistorm would naturally mean it is not vampire related, I would much rather have reports from users with an mmu. Debugging on the Amiga without an mmu is almost impossible.

[kamelito]

@Boemann the RAM disk has had a complete overhaul in 3.2.2, this to me looks where’s the problem lie.
Is there a way to put the RAM disk from 3.2.1 in 3.2.2 to see if the issue is still reproducible?

[boemann]

Originally Posted by mfilos

roubleshooting method to detect the issue..

As a summary (and from my own PoV):
- When using 3.2.2 ROM I have the Alert Orange errors while running applications (even CLI). I also have RAM-Recoverable errors when starting MCP from Startup-Sequence. If I use the test ROM of 3.2.1 + the 3 modules (exluding the exec.library) then no problem with MCP or orange alerts.
- No problem of ANY KIND using Failsafe mode (that runs under PAL and no RTG system).
- No problem of ANY KIND using the same CF mounted on my A600 using V2-600 accelerator (which uses same 080 core) but has 128MB of RAM (instead of 512MB of my V4SA)
- No problem of ANY KIND using the same CF mounted on WinUAE configuration clone of my system
- No problem of ANY KIND disabling Superscalar mode in Vampire configuration (using 1 instead of 2 pipes), meaning lower MIPS.


So far from my findings (and since I'm no AmigaOS developer to know basis) the issues that are probably the cause are either: exec.library, P96, Apollo-Core on V4, more than 128MB RAM on some accelerators(?), or some sort of combination of the mentioned... Certainly not something easy to find and troubleshoot with so many configs around.

So it is likely the wrong place to think it has something to do with RAM as that is almost only a symptom.

Afaik the a600 disables superscalar to that is just more of the sam hint.

That turning off rtg or using p96 pal mode also makes the problem go away, that could point to the saga driver.

That downgrading exec.library also makes it go away I have no explanation for.

One thing could be that we falsely detect a gayle chip and that that is somehow causing problems for rtg. So either making sure we don't detect gayle (3.2.1 exec) or turning off saga rtg driver. But on the other hand why would saga driver have interest in the gayle chip.

Superscalar could be the reason the gayle chip is falsely detectedb(if it is). It could also be that vampire in some other way fools our detection, which yes could be related to how much ram you have.

It could also be that the gayle detection somehow messes with the saga registers. Not that I think so. And the vampire devs have had a look at the detection code, so they would be in a position to say if this happens or not. From what we heard it is cleared.

All of this is pure speculation. But for now all of these things is something that vampire devs needs to look into. We have no means to do so.

[boemann]

Originally Posted by kamelito

@Boemann the RAM disk has had a complete overhaul in 3.2.2, this to me looks where’s the problem lie.
Is there a way to put the RAM disk from 3.2.1 in 3.2.2 to see if the issue is still reproducible?

Yes just replace it the same way you replace exec.

But I doubt it. While it could surely have bugs I think in this case it is just a symptom because it is allocating a lot of memory. The guru simply says that someone has messed up the memory.

[mfilos]

@Kamelito
Maybe you haven't read my troubleshooting method of how I realized that it was the exec.library the issue...

I replaced every module one-by-one (by the ROM 3.2.1) creating custom Kickstarts that I MAPPED into the Vampire and Ram-Handler wasn't the one to blame in my custom kickstarts.
Replacing Exec.library from 3.2.1 ROM made the issue dissapear.

Using Ram-Handler from 3.2.1 and Exec.Library from 3.2.2 still creates the error.

[kamelito]

@mfilos sorry mate I haven’t read it carefully enough.

@Boemann isn’t there any other tool that Enforcer or it’s fork to track down the issue?