AmigaOS 3.2 released!

[SpeedGeek]

Originally Posted by A4000Bear

Any suggestions that I haven't tried yet?

Replace the expansion.library from OS3.2 with the expansion.library from OS3.1.4 (or older version). If that doesn't work then try replacing the exec.library in the same manner.

It's unlikely that any other "OS3.2 Updated" module is causing your problems but not exactly impossible.

If you didn't need the 68030.library + mmu.library installed for any previous version of AmigaOS then you shouldn't need them for OS3.2 either.

Also, if your system crashes before booting then they won't solve the problem anyway.

[boemann]

Originally Posted by Don_Adan

Ok, my english is very poor. But where I wrote that this is FFS disks problem?

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

I wrote that this is OFS disks problem. On PPA i wrote that it must be bug in initialisation of dos.library. Because only OFS disks opened dos.library when booting. And it was found by PPA user Cezarykl, who did very complex betatesting of kickstart 3.2 to find reason.

I don't think you said so but it was speculated on PPA.

Anyway we have looked a bit more and the difference between the two versions of the OFS bootblack is that the newer opens expansion library to set a stay silent flag.

When this flag is not set by the bootblock code we have the problem. It seems to be an issue in kickstarte, but a good and safe workaround is to use the install command from AmigaOS 2.0 or later. It will safely work on KS 1.x as well as later versions.

We have noted the bug in our bugtracker but will likely not fix it any time soon (read years) as we have a lot of other issues to fix first.

[Thomas Richter]

Frankly, if users overclock their boards, anything can happen. This could also be an issue of the (physical) ROM. Note that expansion has some delay loop that allows boards to react on the autoconf logic.

I do not know who (beyond me) touched System-Startup lately, but the only difference between the flag in expansion set or not set is that if the flag is not set then a dummy is printed to the console. The purpose of this dummy is just to force-open the console, which is otherwise an "AUTO" window. I do not see this issue here.

[Don_Adan]

Originally Posted by boemann

I don't think you said so but it was speculated on PPA.

Anyway we have looked a bit more and the difference between the two versions of the OFS bootblack is that the newer opens expansion library to set a stay silent flag.

When this flag is not set by the bootblock code we have the problem. It seems to be an issue in kickstarte, but a good and safe workaround is to use the install command from AmigaOS 2.0 or later. It will safely work on KS 1.x as well as later versions.

We have noted the bug in our bugtracker but will likely not fix it any time soon (read years) as we have a lot of other issues to fix first.

Nothing was speculated about FFS disks on PPA, I can only suspect that translation from polish to english is very often poor. And this is not safe workaround to install bootblock from Amiga OS 2.0+. Why? Because exist thousends of Amiga disks with OFS bootblocks. And simple it has no sense to install new bootblock on many old disks. Exactly I mean that exist houndreds of Amiga old disks with "echo" command used in startup-sequence. And exist much more than 2 OFS bootblocks, f.e FileMaster 2.2 has own version of OFS bootblock. Many games has modified version of OFS bootblock too.
And it dont looks good for me, if easy (i think) to fix bug needs years to be fixed. From my point of view new version of kickstart must be at first compatible with previous Amiga kickstarts.

[SpeedGeek]

Originally Posted by Thomas Richter

Frankly, if users overclock their boards, anything can happen. This could also be an issue of the (physical) ROM. Note that expansion has some delay loop that allows boards to react on the autoconf logic.

Since he went to the expense of purchasing a 50 MHz 68030 CPU and his Board was specifically designed to run @ 50 MHz he is not overclocking.

This is just another example of software developers which don't understand the hardware, and in particular why software delay loops won't fix any problem which requires a hardware fix.

[Thomas Richter]

Originally Posted by SpeedGeek

Since he went to expense of purchasing a 50 MHz 68030 CPU and his Board was specifically designed to run @ 50 MHz he is not overclocking.

Apparently, not. What else to say? This *could* be taken serious, but for that, I want to see a GVP Board *sold* as 50MHz board, running at 50Mhz and showing problems, not one that "may or or may not be suitable for 50Mhz because someone in the internet claims that it might be."



Until then: Clock the board according to the specs at which you bought the board.

[SpeedGeek]

Originally Posted by Thomas Richter

Apparently, not. What else to say? This *could* be taken serious, but for that, I want to see a GVP Board *sold* as 50MHz board, running at 50Mhz and showing problems, not one that "may or or may not be suitable for 50Mhz because someone in the internet claims that it might be."

Until then: Clock the board according to the specs at which you bought the board.

Apparently, you did not read his post completely. His Board is now running stable @ 50 MHz with OS3.1, OS3.9 and even OS3.1.4.

[Olaf Barthel]

Originally Posted by Don_Adan

And it dont looks good for me, if easy (i think) to fix bug needs years to be fixed. From my point of view new version of kickstart must be at first compatible with previous Amiga kickstarts.

Some more context on this issue: the problem right now is to figure out where past changes may have resulted in the outcome you reported.

Two operating system components are directly involved at this stage, these being con-handler (which opens the boot CLI window) and shell (which processes the S:Startup-Sequence). Both components have seen significant rework in the past and merely getting them into a state fit for debugging what goes on will require significant investment of effort and time.

We're still a small group of developers and other operating system components or even the long delayed NDK 3.2R5 update also need time and effort spent on them. We try our best to figure out how to resolve the issues which we can tackle, which remains a major challenge. This is how the "may need years to be fixed" statement came about.

Both shell and con-handler are among the most "accidentally complex" parts of the dos.library "family" which also contains the ram-handler and filesystem. That complexity takes its toll

[Thomas Richter]

Originally Posted by SpeedGeek

Apparently, you did not read his post completely. His Board is now running stable @ 50 MHz with OS3.1, OS3.9 and even OS3.1.4.

That does not prove anything, actually. The ROM neither explains why the board crashes when then machine is already up as at this time, expansion has already done its job. Thus, all bets are open. I still believe some timing is off as the components are not suitable for 50Mhz and this adds together with an older "chinese recycled" EPROM that may have some timing issues by itself.

Again, to make this an issue, report on a *real* 50Mhz board with components qualified to 50Mhz.

[Don_Adan]

Originally Posted by Olaf Barthel

Some more context on this issue: the problem right now is to figure out where past changes may have resulted in the outcome you reported.

Two operating system components are directly involved at this stage, these being con-handler (which opens the boot CLI window) and shell (which processes the S:Startup-Sequence). Both components have seen significant rework in the past and merely getting them into a state fit for debugging what goes on will require significant investment of effort and time.

We're still a small group of developers and other operating system components or even the long delayed NDK 3.2R5 update also need time and effort spent on them. We try our best to figure out how to resolve the issues which we can tackle, which remains a major challenge. This is how the "may need years to be fixed" statement came about.

Both shell and con-handler are among the most "accidentally complex" parts of the dos.library "family" which also contains the ram-handler and filesystem. That complexity takes its toll

Yes, I understand that small group of developers is limitation.
But i think that for new AmigaOS/kickstart much important at begining are changes which removed original Amiga kickstart limitations, not visual AmigaOS changes. For example removed 2GB file size limit and 2GB memory. Easy fix/extension is replacing (for kick 3.3), all errors which set bit #31 as error with #-1 as error. It will be not break compatibilty with older programs, but all new Amiga programs, can use Seek,Read,Write up to 4GB file, and after some changes in exec.library its possible to handling up to 48 bit or 64 bit long files.
Some people asked why some new programs need AmigaOS 3.2, when can works on 3.1 or 3.9 too?
Right reply can be, that new AmigaOS has no old AmigaOS limitations.
I think that some EAB coders can help AmigaOS developers with this, but You must ask.

[Thomas Richter]

Originally Posted by Don_Adan

But i think that for new AmigaOS/kickstart much important at begining are changes which removed original Amiga kickstart limitations, not visual AmigaOS changes. For example removed 2GB file size limit and 2GB memory.

That is easier said than done. First of all, please understand that the handling of files is up to the file system, and not (necessarily) up to components of the kickstart. Thus, if a file system is able to handle larger files largely depends on the file system, and those are not (entirely) under the control of the development team. Then, we have interface functions that are not 64-bit clean, such as Seek() or SetFileSize(). Thus, even if we had file systems that can handle such large files, it would be still up to programs using such new interface functions, even things as trivial as printing the file size may raise issues (I remember these issues when updating "LIST" and the workbench when displaying the size of partitions when such partitions are larger than 4GB - that was already non-trivial). Given the "vivid" development of Amiga software, it is not very likely that such new interface functions will be picked up easily. The same goes for the 2GB memory barrier. Some existing software interfaces unfortunately depend on bit 31 of memory pointers, such as AllocEntry() or the exec KickTags. That is, even if we open up this memory region, chances are that you break existing software, causing more incompatibilities than solving an actual problem. After all. in which use case would an Amiga require more than 2GB of memory (not claiming that 640K is enough for everyone, but 2GB may serve us well for quite a while given the age of the system.) [QUOTE=Don_Adan;1633749] It will be not break compatibilty with older programs, [QUOTE] Unfortunately, it will. The KickTag-mechanism is used by more than one program just to name one problem. The best one could hope for is not to make memory beyond 2GB MEMF_KICK-able, but that also implies that programs actually set this memory flag correctly to allocate memory for kicktags. Even worse, on some hardware software *CANNOT* set this flag as some boards do not indicate their memory correctly. See for example LoadModule and its NOMEMFKICK argument - such workarounds are unfortunately quite common. Or, to put it differently, such memory would, for example, break LoadModule simply because LoadModule itself attempts to work around broken firmware. Thus, please understand, it is really not quite as simple as it seems. It is unfortunately quite hard. With every change, you loose some piece of compatibility, and finding the right balance is all but trivial.

[Don_Adan]

Originally Posted by Thomas Richter

That is easier said than done. First of all, please understand that the handling of files is up to the file system, and not (necessarily) up to components of the kickstart. Thus, if a file system is able to handle larger files largely depends on the file system, and those are not (entirely) under the control of the development team. Then, we have interface functions that are not 64-bit clean, such as Seek() or SetFileSize(). Thus, even if we had file systems that can handle such large files, it would be still up to programs using such new interface functions, even things as trivial as printing the file size may raise issues (I remember these issues when updating "LIST" and the workbench when displaying the size of partitions when such partitions are larger than 4GB - that was already non-trivial). Given the "vivid" development of Amiga software, it is not very likely that such new interface functions will be picked up easily. The same goes for the 2GB memory barrier. Some existing software interfaces unfortunately depend on bit 31 of memory pointers, such as AllocEntry() or the exec KickTags. That is, even if we open up this memory region, chances are that you break existing software, causing more incompatibilities than solving an actual problem. After all. in which use case would an Amiga require more than 2GB of memory (not claiming that 640K is enough for everyone, but 2GB may serve us well for quite a while given the
"It will be not break compatibilty with older programs"
Unfortunately, it will. The KickTag-mechanism is used by more than one program just to name one problem. The best one could hope for is not to make memory beyond 2GB MEMF_KICK-able, but that also implies that programs actually set this memory flag correctly to allocate memory for kicktags. Even worse, on some hardware software *CANNOT* set this flag as some boards do not indicate their memory correctly. See for example LoadModule and its NOMEMFKICK argument - such workarounds are unfortunately quite common. Or, to put it differently, such memory would, for example, break LoadModule simply because LoadModule itself attempts to work around broken firmware. Thus, please understand, it is really not quite as simple as it seems. It is unfortunately quite hard. With every change, you loose some piece of compatibility, and finding the right balance is all but trivial.

1. I wrote that exchanging error handling from setting #31 bit to #-1 dont break compatibility. Because #31 bit is set by #-1 value already.
2. I mean about using memory between 2GB-4GB not for Amiga program code, but as limited data memory only. Can be allocated only via new AllocDataMem LVO in exec or something similar, if enhancing AllocMem can be problem.
3. Yes, new FFS must handle bigger files too.
4. For me exist 2 ways to handling big files:
a) adding new LVOs for exec library
b) adding special 16bit ID (in D1 register) for old exec LVO

Of course these are only my suggestions for new Amiga programs, without breaking compatibilty. All old Amiga programs will be works with limitations.

[SpeedGeek]

Originally Posted by Thomas Richter

That does not prove anything, actually. The ROM neither explains why the board crashes when then machine is already up as at this time, expansion has already done its job. Thus, all bets are open. I still believe some timing is off as the components are not suitable for 50Mhz and this adds together with an older "chinese recycled" EPROM that may have some timing issues by itself.

Again, to make this an issue, report on a *real* 50Mhz board with components qualified to 50Mhz.

What it proves is that you are a perfect example of the software developer described in my previous post. Also, he is using components suitable for 50 MHz and he has already proved it.

I don't know if he was using a "Chinese Recycled" ROM or not, but the ROM cycle timing did not change on his Board. It's still running from the 7 MHz clock.

[Thomas Richter]

Originally Posted by SpeedGeek

Also, he is using components suitable for 50 MHz and he has already proved it.

Apparently, not. Again, if you think that the ROM Is to blame, test with a board that is certified for 50Mhz.

[mschulz]

Originally Posted by Don_Adan

1. I wrote that exchanging error handling from setting #31 bit to #-1 dont break compatibility. Because #31 bit is set by #-1 value already.

kicktags do not use the bit 31 to indicate error. In kicktags list bit 31 distinguishes between actual kicktag (bit clear) and pointer to subsequent kicktag list, building this way a primitive mechanism for chaining.

Originally Posted by Don_Adan

2. I mean about using memory between 2GB-4GB not for Amiga program code, but as limited data memory only. Can be allocated only via new AllocDataMem LVO in exec or something similar, if enhancing AllocMem can be problem.

One could extend AllocMem by adding e.g. MEMF_HIGHMEM flag which would be mandatory if someone really wants to request that type of memory. But still it would pose a danger of misusing it.

Originally Posted by Don_Adan

4. For me exist 2 ways to handling big files:
a) adding new LVOs for exec library
b) adding special 16bit ID (in D1 register) for old exec LVO

Special ID sounds like a hack, new LVOs would be better. But not added to exec library, of course, but to dos. Read64(), Write64(), Seek64(), SetFileSize64()...

[Thomas Richter]

The trouble with such extensions is that you also need software to take advantage of it. It is really a chicken-and-egg problem.

BTW, that is up to AmigaDOS and the dos.library, and the file systems - there is more than one. Just to name more issues: It is not only the "missing LVO", also structures are ill-prepared for large files. To name an example, the "FileInfoBlock" structure contains the file size in bytes, in stored in a 32-bit integer. It is declared as "LONG" (essentially because BCPL only has this one integer type, in a nutshell). Thus, the limit for the file size is 2GB.

Even if one would introduce a new "ExtendedFileInfoBlock" with a 64-bit integer for the size, one would need to recompile Os software for taking advantage of this (and probably a new LVO for ExtendedExamine), but what happens with old software that continues to use Examine() and ExNext()? Would they show the wrong information?

One would also need to upgrade file systems, and that is not only the FFS. Despite warnings, people still use some deprecated third party file systems like the SFS with known defects already. What happens then?

[mschulz]

Originally Posted by Thomas Richter

The trouble with such extensions is that you also need software to take advantage of it. It is really a chicken-and-egg problem.

BTW, that is up to AmigaDOS and the dos.library, and the file systems - there is more than one. Just to name more issues: It is not only the "missing LVO", also structures are ill-prepared for large files. To name an example, the "FileInfoBlock" structure contains the file size in bytes, in stored in a 32-bit integer. It is declared as "LONG" (essentially because BCPL only has this one integer type, in a nutshell). Thus, the limit for the file size is 2GB.

Even if one would introduce a new "ExtendedFileInfoBlock" with a 64-bit integer for the size, one would need to recompile Os software for taking advantage of this (and probably a new LVO for ExtendedExamine), but what happens with old software that continues to use Examine() and ExNext()? Would they show the wrong information?

One would also need to upgrade file systems, and that is not only the FFS. Despite warnings, people still use some deprecated third party file systems like the SFS with known defects already. What happens then?

I know this is a chicken and egg problem. And even if dos and filesystems get necessary improvements the question remains - will there ever be a software written to use this new features. Regarding structures - yes, I'm aware of that. But, considering all this, maybe it would be worth looking at OS4/MOS/AROS how they did that?

[SpeedGeek]

Originally Posted by Thomas Richter

Apparently, not. Again, if you think that the ROM Is to blame, test with a board that is certified for 50Mhz.

I never thought the ROM was to blame. This was your suggestion not mine. Since, you didn't know the ROM cycle timing was not affected by the CPU clock change you might have thought this was the problem. But now you know otherwise.

BTW, GVP single ROM Boards always copy the driver code to the system memory. So the ROM is only accessed for a short period of time before booting.

[Don_Adan]

Originally Posted by mschulz

kicktags do not use the bit 31 to indicate error. In kicktags list bit 31 distinguishes between actual kicktag (bit clear) and pointer to subsequent kicktag list, building this way a primitive mechanism for chaining.


One could extend AllocMem by adding e.g. MEMF_HIGHMEM flag which would be mandatory if someone really wants to request that type of memory. But still it would pose a danger of misusing it.


Special ID sounds like a hack, new LVOs would be better. But not added to exec library, of course, but to dos. Read64(), Write64(), Seek64(), SetFileSize64()...

Im sure that some exec LVO's set bit 31 as error, not -1. But it was years ago when i try to optimising dos.library. Maybe I remember something wrong.
Yes, MEMF_HIGHMEM flag can be attribute for AllocMem.
And yes, Read64, Write64 etc is cleaner solution than adding ID.

[Don_Adan]

Originally Posted by Thomas Richter

The trouble with such extensions is that you also need software to take advantage of it. It is really a chicken-and-egg problem.

BTW, that is up to AmigaDOS and the dos.library, and the file systems - there is more than one. Just to name more issues: It is not only the "missing LVO", also structures are ill-prepared for large files. To name an example, the "FileInfoBlock" structure contains the file size in bytes, in stored in a 32-bit integer. It is declared as "LONG" (essentially because BCPL only has this one integer type, in a nutshell). Thus, the limit for the file size is 2GB.

Even if one would introduce a new "ExtendedFileInfoBlock" with a 64-bit integer for the size, one would need to recompile Os software for taking advantage of this (and probably a new LVO for ExtendedExamine), but what happens with old software that continues to use Examine() and ExNext()? Would they show the wrong information?

One would also need to upgrade file systems, and that is not only the FFS. Despite warnings, people still use some deprecated third party file systems like the SFS with known defects already. What happens then?

I dont see how looks FileInfoBlock structure. But some structures has empty/unused/reserved space. I think that free 16 bits (word) is enough, for support big files. Space for 48bit long file is enough for me. For current version of SFS nothing will be changed. Cant handle bigger than 2 or 4GB files. Must be updated like every Amiga file system which exist.

Already exist Amiga software which can take advantage of 48/64 bit long files support, f.e video players. Someone told on PPA, that he plays over 2 GB video file (then up to 4GB is possible to show), but after 2GB this player cant handle fast forward (Seek doesnt works), if I remember right.