Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A600 Memory

AuthorTopic: Os 3.1.4 - List of bug fixes and changes by component  (Read 25412 times)

0 Members and 1 Guest are viewing this topic.

Offline Thomas Richter

Os 3.1.4 - List of bug fixes and changes by component
« 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.
The following users thanked this post: gregthecanuck, BeLaww, LoadWB, F1Lupo, BSzili, NinjaCyborg

Offline Thomas Richter

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #1 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.
The following users thanked this post: F1Lupo, Dynamic_Computing

Offline Thomas Richter

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #2 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.
The following users thanked this post: F1Lupo

Offline NorthWay

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #3 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.

Offline Thomas Richter

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #4 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.

Offline Thomas Richter

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #5 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.
The following users thanked this post: F1Lupo

Offline pawelek

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #6 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 :(

Offline Thomas Richter

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #7 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.

Offline Thomas Richter

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #8 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.
The following users thanked this post: F1Lupo

Offline Dr_Procton

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #9 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!

Offline F1Lupo

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #10 on: October 12, 2018, 12:52:23 AM »
many many thanks Thomas ;D
c64-dual sids, A1000, A1200-060@50, A4000-CSMKIII
Indivision AGA & Catweasel MK4+= Amazing
! My Master Miggies-Amiga 1000 & AmigaOne X1000 !
--- www.mancave-ramblings.blogspot.ca ---
  -AspireOS.com & Amikit- Amiga for your netbook-
***X1000- I BELIEVE *** :angel:

Offline Gryfon

  • Full Member
  • ***
  • Join Date: Nov 2002
  • Posts: 102
  • Country: gb
  • Total likes: 3
  • Gender: Male
Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #11 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.
\\"We should take off and nuke the entire site from orbit.  It's the only way to be sure.\\" Ripley, Aliens

Offline Thomas Richter

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #12 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.

Offline kreciu

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #13 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" ;).
A1200inE/BOX/3.1.4/AmigaOS3.9+BB1,2,3,4/060/66Mhz+603+/330Mhz/256Mb/FAST-ATA V /MediatorTX/R9200SE/SpiderUSB/LAN/SB128/16Gb-CF/DVD-ROM/ZIP-250/FDD-HD
PC/AmigaOS4.1/Xeon 1265Lv3  with Amiga Forever 2016!!!.
Dell T600/Win98SE/XP/256Mb/Radeon9600Pro/SBLive!/80Gb/DVD-ROM
Color Classic/System 7.1/030/16Mhz/FPU/10Mb/80Mb HDD
Performa 6400/System 8.6/PPC 603ev180Mhz+G3 350Mhz/Rage128Pro/136Mb/80GB HDD

Offline Thomas Richter

Re: Os 3.1.4 - List of bug fixes and changes by component
« Reply #14 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.