Welcome, Guest. Please login or register.

Author Topic: Os 3.1.4 - List of bug fixes and changes by component  (Read 84932 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Tygre

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #119 from previous page: December 11, 2018, 02:21:40 AM »
@Thomas Richter

No, you only say that dos device name must end with a letter that corresponds to a partition, whatever that is may very well depend on the partition layout, there is no exact answer, right? The MBR partition table may not list partitions in "correct" order, the extended partition may or may not exist on either of the four possible primary partitions, and the order of logical partitions is also not necessarily fixed. Does CrossDOS care about partition ordering? No answer. Does it get confused if there are primary partitions "behind" an extended partition? Who knows. Is there a specific letter associated with exactly the second logical partition of an extended partition? I suppose answer is - not really.

Why don't you try and report in this thread? (Or create a dedicated thread about your questions?) That would be useful to everyone and Thomas could go back to listing and explaining "bug fixes and changes by component", which is the reason for this tread. (Not to serve as an in-depth, developers' manual for AmigaOS v3.1.4.)
« Last Edit: December 11, 2018, 02:24:28 AM by Tygre »
 
The following users thanked this post: klx300r

Offline wiser3

  • Jr. Member
  • **
  • Join Date: Jan 2007
  • Posts: 84
    • Show only replies by wiser3
    • http://www.trep4.com/
Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #120 on: December 11, 2018, 04:01:58 AM »
Could someone with qualified knowledge please comment on the prospects of implementing these features in the future:

1. change public (like WB) screen mode resolution/properties when applications are open on it
2. make shortcut icons that launch exe or scripts from another location
3. resize windows by dragging the borders
4. clickToFront funtionality built-in instead of via commodity
 

Offline NinjaCyborg

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #121 on: December 11, 2018, 07:37:43 AM »
(2) on your list is already possible with IconX or project icons and default tools.
 

guest11527

  • Guest
Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #122 on: December 11, 2018, 10:01:37 AM »
Concerning 1), this is not possible. If you reopen the workbench, all bitmaps have to be exchanged, and by that rastports and windows. Programs can and will use pointers to such resources, or even build their own without informing the Os, so you cannot just exchange this structure under the feet of the program.

Concerning 2), this is entirely up to you to create such icons. There is no need to handle this by the workbench. IconX or CLICon can do that just fine, or even the workbench natively if you want to. What is indeed missing is a workbench item (or a tool) to create soft- and hardlinks, especially now that workbench and shell handle them.

Concerning 3), this is is an intuition tweak. Unfortunately, many if not most programs assume that the size gadget has a fixed size. We run into this issue when trying to implement a 1:1 size mode, and aborted the attempt because it ruined the design of multiple programs. While correctly written programs such as the workbench or the console continue to work, most programs do not. Hence, this is not a realistic option.

Concerning 4), I disagree. A commodity is exactly the right place for functionality like this. Not all people want it or need it, and for those that do, dragging ClickToFront into the WBStartup folder is a very easy exercise to configure the system as they like. We do not need to blow up the core system with functionality that can be easily provided by (system conforming, non-patching) tools.
 
The following users thanked this post: Tygre, NinjaCyborg

Offline kolla

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #123 on: December 11, 2018, 10:57:52 AM »
Why don't you try and report in this thread?
Why do you assume I have not tried? I have tried. Lots. Did it work? Not really.
Though I have zero problems with FAT95, attempts at making equivalent mount point entries for crossdos have been mostly futile
Since it is so damn quirky both to get documentation and "support", I will hereby leave it to others to discover issues and report them in the sycophantic manner necessary.

Quote
(Not to serve as an in-depth, developers' manual for AmigaOS v3.1.4.)

I am not a developer, I am just trying to _use_ the software I bought, which is not so easy with documentation lacking and/or spread in bits an pieces all over, and no interest from Hyperion whatsoever beyond ownership and sales, certainly not to offer any support.

If I actually _was_ a developer, I would certainly miss an in-depth developers manual as well, but no such thing exists, does it.

EDIT: On the topic of CrossDOS - when was developer rights to CrossDOS passed over from Consultron to Hyperion, anyways? OS 3.1 only came with a limited version of CrossDOS, and CBM only had limited rights to develop CrossDOS themselves, it was a typical example of "bundleware", crippled to not interfere with the sales of the commercial version.
« Last Edit: December 11, 2018, 11:24:43 AM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

guest11527

  • Guest
Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #124 on: December 11, 2018, 11:26:57 AM »
Why do you assume I have not tried? I have tried. Lots. Did it work? Not really.
No, you haven't. You're whining, complaining, but not reporting. There is a difference between asking for support (which, quite frankly, is not even my job, nor the purpose of this thread, but let it be as it is), and complaining for the purpose of complaining. There is a reason why I ignore complaints from people like you because they are not serious. You know that, I know that. Let's stick to this arrangement.

Since it is so damn quirky both to get documentation and "support", I will hereby leave it to others to discover issues and report them in the sycophantic manner necessary.
DosTypes and support for partition mounting did not change in CrossDos. Not at all. It's this way since CrossDos shipped, and by that I mean "back in CBM days". I'm just re-iterating what you should have in your manual with 3.1 in first place, and apparently, what people forgot. There is a reason why this is 3.1.4 and not 3.2.

So the partition assignment to letters is *not* changed, the dos types are *not changed*. And please, don't tell me it is particularly hard to adjust the dos type to the types I provided, and change the name of the icon (potentially) to the naming rules I provided. Despite this being all "old news".

I am not a developer, I am just trying to _use_ the software I bought, which is not so easy with documentation lacking and/or spread in bits an pieces all over, and no interest from Hyperion whatsoever beyond ownership and sales, certainly not to offer any support.
Use the manual from 3.1. Really. There isn't really much of a difference. 3.1.4 is a *bug fix* release. It is not an "all new operating system".  This was never the point of the exercise.

If I actually _was_ a developer, I would certainly miss an in-depth developers manual as well, but no such thing exists, does it.
The developer CD *is* there, you can use it. The includes are the same as those for 3.1. There is *one* thing that changed, and that are three new bits in the Environment vector, and believe it or not, there is documentation for this out in the Aminet. It was put there the first day 3.1.4 was out for sale.
 
The following users thanked this post: Tygre, First Ninja, NinjaCyborg

Offline Minuous

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #125 on: December 11, 2018, 01:05:02 PM »
Presumably the Preferences-related include files have changed for OS3.1.4 though, as some of those file formats have been changed/extended.
 

Offline matt3k

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #126 on: December 11, 2018, 04:47:42 PM »
Hi Thomas,

First off a HUGE thank you.  3.1.4 has been awesome fun on my 3000.

I have been trying to use PFS3AIO to install on a drive.  I installed the handler via the 3.1.4 hdtoolbox and it assigns it to international FFS.  I have seen that in the past so I thought I was fine and checked long file names and formatted the drive.  The PFS splash screen didn't come up at the end, so I assume it didn't work.

I'm using the native 3000 scsi controller.

 

Offline Tygre

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #127 on: December 11, 2018, 05:49:53 PM »
Thomas already answered Kolla very well :) but let me add regarding:

I am not a developer, I am just trying to _use_ the software I bought, which is not so easy with documentation lacking and/or spread in bits an pieces all over, and no interest from Hyperion whatsoever beyond ownership and sales, certainly not to offer any support.

that this thread is not about Hyperion, it is about "Os 3.1.4 - List of bug fixes and changes by component".
Please create a new thread if you want to discuss Hyperion support (or lack thereof).

guest11527

  • Guest
Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #128 on: December 11, 2018, 08:03:23 PM »
Concerning file systems, there is a third one that comes with 3.1.4, and that is the CDFileSystem that reads CDRoms. The V45 version has almost nothing in common with the original CBM version. It is a close cousin of the Os 4 version, though, and borrowed many features from there. At the same time, it is both ahead and behind it, but the story is a bit complicated....

Similar to the FFS and CrossDos, it is multithreaded - which is a new feature. That is, if a CD-read is triggered, the file system remains responsive and can answer requests as long as the corresponding CD blocks are in cache. What the CD file system caches are administrative blocks, not data blocks. That is similar to the FFS. This multithreading is new, compared to both the Os 3.1 and the Os 4.0 version, and just a consistent new feature in all file systems.

It also supports the "DirectSCSI" flag. Regularly, the CDFileSystem attempts to read from the CD (or DVD) by means of CMD_READ. However, not all hostadapters support 2048 block sectors (as required) CD ROM data track access, and hence, this control flag turns out to be quite useful here as well. Previous solutions for the same problem used the "control" entry in the mount list, though details depended on the particular implementation.

Despite cache and multithreading, the CDFileSystem features a third mechanism to speed up accesses, and this is "read ahead". If a program does not attempt to read a large amount of blocks one after another, but is rather asking data block by block, this would imply that the CDRom has to start and stop reading, slowing down the transfer. The CDFileSystem instead now automatically loads block N+1 into cache when block N is read such that this access can then be satisfied quickly.

Multiple extensions made it into the 3.1.4 version compared to the 3.1 version: Joliet support (the proprietary "we don't read standards" standard from Microsoft for long file names), and Rock Ridge (the universally-accepted except on windows version for long file names), plus the Amiga-specific extension for protection flags (a proprietary, though popular and necessary extension). They all came in from the Os 4 version.

What also came in through Os 4 is support for audio tracks. That is, audio tracks appear as "AIFF" files on the CD file system and then can be played through MultiView, though an AIFF datatype (which, sorry to say, we did not include). Well, mostly Os 4, as there is more to say. Os 4 does not "read ahead" and "multithread" for audio, and unfortunately, there are about 30 different ways how to get audio data from a CD ROM (I love standards, you can select between so many of them). Os 4 had about support for three. The 3.1.4 version has a rather delicate algorithm to try them out, then stick to the one that worked, so you don't need to configure this in the mountlist.

What came also came in from Os 4 is support for UDF, which is the file format used by DVDs. It is a bit more modern than the ISO format, though UDF support includes caching, which it did not in Os 4, so it should hopefully perform better. Actually, UDF support was much more polished in the 3.1.4 version.

There are other things that did not make it into this version, though, simply because we run out of time, or haven't had material for testing. The Os 4 version also supports some simple video format (CDXA) but no support in the file system. Trouble is here lack of documentation, and lack of test material. There are multiple track formats a CD can be formatted in, not just 2048 byte sectors and 2352 audio blocks. It was - to me - completely unclear which format these disks take. As this is a rather exotic format, I decided to ditch it. As soon as I know more, I might reconsider, but so far nobody really complained.

The Os 4 variant also supported HFS and HFS+, the "we do make proprietary formats" format from Apple. Unfortunately, I don't have any fruit in the house, and neither test data to assess it, furthermore, the Os 4 code was depending on some GNU specific extensions to ANSI C such as function definitions within functions (today, one would probably call that "closures") which first had to be restructured to fit into ANSI-C to make it compile with SAS. Well, in the end, this looked all to risky, with no test data, and only a "best guess interpretation" what this GNU C should mean, so it was also ditched. It would have extended the work by probably another month, and this was hard to justify.

There are probably a couple of "strange" CD drives still alive in some machines that do not play by "any rule" (i.e. any formulated standard) that we may have forgotten, or for which we have no clear idea how to detect or support. For example, it is at least known that some (really old) CD drives return audio data as "big endian". While this sounds plausible on the Amiga, the MMC audio specs specifically require little endian, and thus the endian switch is always made. Of course, with rather bad side effects on such drivers that play in the wrong (or right?) order. As there at this time no clear guideline how to identify such ancient beasts, nor an idea how to drive them, there is no support for them either. If you have to happen such a thing, let me know, we probably find a solution. But, again, they probably all died out 10 years ago already...

There are also a couple of other tiny bugs here and there found during the review of the Os 4 code, so actually, overall code quality should have been improved - that, plus multithreading - should hopefully give you a rather stable and fast CD experience. It is actually more a "four file systems in one package" right now.

Just one word of warning: Do not expect CD audio to work on winUAE. It won't. The problem is that winUAE does not emulate MMC commands nor the CD-ROM TOC correctly, so no data comes through. That's not the fault of the CDFileSystem.
 
The following users thanked this post: Steady, Orphan264, Tygre, NinjaCyborg

Offline QuikSanz

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #129 on: December 12, 2018, 03:20:53 AM »
Not sure of the mechanism but what about CDDA?

Chris
 

Offline kolla

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #130 on: December 12, 2018, 05:22:51 AM »
Why do you assume I have not tried? I have tried. Lots. Did it work? Not really.
No, you haven't.

So you are calling me a liar?

Well, you also did not believe me regarding LoadModule not detecting CD32 correctly, did you...

Quote
DosTypes and support for partition mounting did not change in CrossDos. Not at all. It's this way since CrossDos shipped, and by that I mean "back in CBM days".

That means it is only compatible to _really_ old MSDOS FDISK ways of building the MBR and EBR... hm.

Quote
I'm just re-iterating what you should have in your manual with 3.1 in first place, and apparently, what people forgot. There is a reason why this is 3.1.4 and not 3.2.

Please point me to the page in the OS 3.1 manual that speaks of this - I have them all, even searchable online, and I only find vague references to mounting Syquest cartridges as "D:".

http://amiga.nvg.org/amiga/reference/AmigaOS3.5_Manual/workbench/book-main122.html
http://amiga.nvg.org/amiga/amigafaq/AmigaFAQ_65.html

And "the official manuals" are no better...
https://wiki.amigaos.net/wiki/AmigaOS_Manual:_Workbench_CrossDOS

I have "Das Buch" here somewhere, maybe it is mentioned in that one?

JanusTools comes with some funny info... "CrossDos will not work with the 0x4D534800 DOSType" (http://aminet.net/package/docs/help/CDJanusTools)

Quote
So the partition assignment to letters is *not* changed, the dos types are *not changed*. And please, don't tell me it is particularly hard to adjust the dos type to the types I provided, and change the name of the icon (potentially) to the naming rules I provided. Despite this being all "old news".

Old news, yet...
Quote
CrossDos is also pretty much new, at least many major parts have been exchanged
So what to think. What has really changed and what has not, how does this relate to the official "professional" CrossDOS 7.x Gold etc.

And how do one know in the first place...
Quote
Use the manual from 3.1. Really.
Well, I do have the manuals, all of them, and they are also available online, in multiple languages... searchable.

https://archive.org/details/Amiga_OS_3.1_DOS_1993_Commodore_DE/page/n13?q=CrossDOSFileSystem

If someone could point me to the correct manual and what page that speaks in detail of how CrossDOSFileSystem deals with extended partitions? No?

Well, since documentation is so... intangible... and "nothing at all" has changed, looking at sources can reveal what the problem is.
Quote
*   If DOSType = "ID_MSDOS_DISK_HD", expect a valid FDISK-type
*   hard disk partition table.  It will then parse the partition
*   table to find the desired partition.  It handles MSDOS 3.0
*   primary and extended partitions.  New types of MSDOS partitions
*   4.0 and beyond can be supported if the veil of secrecy is removed
*   from this generally proprietry information.

So then, CrossDOS simply cannot replace FAT95 in many cases, as it simply does not know jack about "modern" incarnations of MBR/EBR.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

guest11527

  • Guest
Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #131 on: December 12, 2018, 08:13:34 AM »
Not sure of the mechanism but what about CDDA?

CDDA is access to digital audio tracks. Yes, you do have that. They appear as ordinary files on the desktop.
 
The following users thanked this post: Tygre

guest11527

  • Guest
Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #132 on: December 12, 2018, 08:16:06 AM »
Why do you assume I have not tried? I have tried. Lots. Did it work? Not really.
No, you haven't.

So you are calling me a liar?
If you want to put it that way, yes, I am. You are lying about your intentions, which is complaining, not seeking help for solving problems. I'm happy to help people to sort out particular problems they have, I am not willing to listen to complaints for the matter of complaining. Go away.
 
The following users thanked this post: Tygre, 10MARC, First Ninja, NinjaCyborg

Offline Tygre

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #133 on: December 12, 2018, 01:32:05 PM »
Why do you assume I have not tried? I have tried. Lots. Did it work? Not really.
No, you haven't.

So you are calling me a liar?

I don't know and I don't care about that. Kolla, please create a thread dedicated to your questions about CrossDOS and related. There, anyone who can will certainly help you. Again, this thread is about "Os 3.1.4 - List of bug fixes and changes by component": not about Hyperion support, not about using CrossDOS, etc.

Thanks for your understanding.

guest11527

  • Guest
Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #134 on: December 13, 2018, 11:22:30 AM »
Maybe a bit more in-depth information on one of the datatypes, the animation.datatype and anim.datatype. Actually, they sound related, but their job is a bit different. The animation.datatype is the generic base to play animations, in the same way as the picture.datatype shows pictures. The anim.datatype is specifically there for interpreting IFF ANIM files, and therefore related to the ILBM datatype, which are IFF pictures. Besides ANIM, the only other datatype "on top" of the animation.datatype is the CDXL.datatype, which plays very simple animations, small movie clips more than video (given the resolution and bitdepth Amigas can handle).

Animation was one of the things we debugged for too long, the ratio between bugs and actual code was... quite surprising, to put it mildy. First, you need to understand how this thing works: Animation launches two tasks, one that continuously pulls data from disk and puts it into a ring buffer - via the ANIM.datatype or anything else that reads files that represent video - and a second task that plays the frames. Problem with the 3.1 version is that there is absolutely no synchronization: Both task access the same data structures, without even using a semaphore. Clear enough, this cannot work. When one task accesses a data structure while the other is modifying it, you are calling for problems.

Olaf had this fixed for 3.9, so there are now semaphores for the ring buffer. Unfortunately, the problems did not stop there, so the 3.9 version is not working very well at all. One of the anoyances was that decoding of frames worked when playing forward, but - due to the dependencies between frames in the ANIM format ("P-frames" as one would call them) you could not reliably seek backwards. You were often left with junk on the screen because the decoder used the wrong reference. Which was fixed, of course.

A second interesting effect was that most anims played with two frames too much. This is one of the "features" of IFF ANIM, namely that the last two frames reconstruct to images that are identical to the first two - the reason for this is that DPaint wants to enable players to play the anims in a loop, without having to go through a full decode of the first two frames ("I-frames"). So the last two frames are predictive frames that go back to the initial two frames. There are two frames, not one, because ANIM uses a front-buffer (shown on the screen) and a back-buffer (in which data is computed), and swaps between them for every frame. Which was exactly the problem why seeking backwards did not work reliably.

Then we have screen modes that may turn out to be a problem: For example, HAM8 can not be played "as is" on an OCS/ECS machine. It could be played if colors are quantized down to a retricted palette, and it could be even played in original quality if RTG graphics would be available. Only that the datatype did not attempt any of that. This also changed, and we got for a couple of additional cases custom "renderers" that reduce the quality to be able to display the animation on the workbench, or on an RTG screen. Previously, the datatype would only show an error requester.

Synchronization between the two threads (loader and renderer) was also a bit... strange. One would typically do that with message parsing: "I'm ready to take four frames, preload them from disk", and so on. This natural Amiga communication protocol was apparently too much - instead, the datatype uses about four signals, depending on what the loader should do (load, stop abort, preload, exit...). Unfortunately, if the player is busy, and does not require any extra frames, the loader... just busy-waits and burns CPU time the renderer could use for showing frames.

Needless to say, I stopped this and I'm halting the loader task now if it has nothing to load, so the datatype is no longer a CPU hog. You saw this problem on 3.1 and on 3.9 even that the scroll-bar was quite "quirky" to use - it sometimes did not react, the mouse pointer was frozen, just because the CPU was locked on the player thread and the input.device (responsible for moving the pointer) did not get the CPU until the player released a critical semaphore of intuition, because it was busy waiting for the loader, and the loader was busy... doing nothing. Great job, folks.

Since the animation.datatype was written by the same guy as the sound.datatype, similar problems continued there..., but more on this later.
 
The following users thanked this post: Steady, Tygre, First Ninja, NinjaCyborg