X89uGNzm

1AmigaOS 3.1.4 List of bug fixes and changes by component
2Revision 1.2 (27.02.2019)
3Copyright 2019 Hyperion-Entertainment
4
5Preface:
6
7AmigaOS 3.1.4 was an Amiga Operating System bug-fix update released on 
8the 30th of September, 2018.
9
10Thomas Richter, its lead developer, made a public blog regarding the 
11changes involved in that release.
12
13This is just a compilation of those notes sorted by OS component.
14
15Contents:
16
171. Exec.library
182. Expansion.library, battclock.resource, utility.library and 
19cia.resource
203. Scsi.device
214. Graphics.library
225. Intuition.library
236. Layers.library, gameport.device, keyboard.device, input.device, 
24timer.device and console.device 
257. FastFileSystem (FFS)
268. Bootmenu and Syscheck
279. WBFind and RAMLib
2810. Shell
2911. RAM-Handler, diskfont.library, asl.library and bullet.library
3012. Workbench.library and icon.library
3113. Math libraries
3214. Datatypes
3315. ARexx
3416. Devices
3517. Handlers
3618. Pipes
3719. CrossDOS
3820. CDFileSystem
3921. Animation.datatype and anim.datatype
4022. Printer.device
4123. Printer drivers
4224. Icon.library (in depth)
43
44----------------------------------------------------------------------
451. Exec.library
46
47We'll probably start at the very core of the system: exec. Exec is the 
48AmigaOS microkernel, responsible for initializing the hardware and 
49administrating all its resources such as memory, libraries, devices... 
50and is also responsible for task switching.
51
52There are a couple of small/tiny fixes in exec all around.
53
54First, if you have a 68060 processor, you no longer need an F-Space 
55fix to turn off the FPU. Exec no longer crashes on a 68060 FPU. Yet, 
56you still need the 68060.library to enable it. This was to avoid 
57incompatibilities.
58
59The test for the ranger memory was broken and actually overwrote the 
60memory contents, making it unsuitable for reset-resent programs. This 
61got fixed.
62
63If GetMsg() was called in a tiny loop, the 68060 would not allow 
64collection of any interrupt(s) and the system would deadlock. This was 
65fixed, too. This was a patch previously included in SetPatch.
66
67Exec now reserves 16K of chip memory for emulator business. You no 
68longer need "PrepareEmul" or "MuMove4K" to run Shapeshifter and 
69friends. If you need the 16K back, there is a utility on Aminet called 
70"MoveLow" which restores the previous setting until the next reboot.
71
72There was a problem with software failures during reboot which could 
73deadlock the system. This was fixed, too.
74
75ROMWack is back--the sad story of the "SAD" debugger is history now. 
76ROMWack is the built-in ROM debugger. It is rather bare-bone. Connect 
77a serial terminal at 9600-8N1, press "Del" on a software failure, and 
78you get a serial terminal to debug the code. For a better debugger, 
79there is "COP" on Aminet.
80
81Exec had some rudimentary support for "task trees" that never worked, 
82and were never used by any program. All of this code was retired, and 
83support for that and "ETasks" were removed. They were never used, 
84never tested, and were also incomplete, so it was just non-working 
85dead code.
86
87Exec in V39 changed the structure of memory pools. Unfortunately, some 
88software depended on the internal undocumented structure, so the 
89change was reverted and the memory pools are back to the state of 
903.1, except that the bugs in 3.1 were fixed; i.e. FreePooled() had an 
91issue. FreePooled() also slightly changed its policy of how puddles 
92are handled to speed up the Ram Disk.
93
94Also, AVL tree support was removed from exec since it really does not 
95belong there. This was never used either (except for the 3.9 pools), 
96so it went away as it was just dead code.
97
98There are probably a couple more tiny fixes I would need to look up, 
99but I do not remember them at the moment.
100
101----------------------------------------------------------------------
1022. Expansion.library, battclock.resource, utility.library and 
103cia.resource
104
105Let's continue with this list with a couple of small issues. Next in 
106chain is expansion, which configures the hardware. Expansion had an 
107issue when merging memory of several boards together to one single 
108pool--this operation could have failed in a couple of situations. 
109Expansion also copied one byte too much out of the config ROM (or 
110config nibbles) of a board. We also put in a couple of speed brakes to 
111keep the board hardware happy even on fast CPUs. For at least one 
112betatester, this made an old A2091 work again.
113
114Similar speed brakes went into the battclock.resource because fast 
115CPUs were just too fast for the slow real time clock. This fixed 
116issues especially related to the Vampire. Thanks to the Vampire team 
117for the report.
118
119Then, we have utility.library which also implements 32x32 divisions 
120and multiplications, and a 32x32 to 64-bit multiplication. The latter 
121was especially bug-ridden and returned the result the wrong way around 
122on 68000 processors, which was fixed. This multiplication is not 
123available on the 68060, so the code is now smart enough not to use it 
124if a 68060 is detected.
125
126Previously, there were at least two versions of utility.library; one 
127for the 68020 and up, and one for the 68000, and the ROMs contained 
128either of the two versions. Now we have a unified utility.library, and 
129only one version, which keeps the build process simpler.
130
131With cia.resource there is nothing new to admire, except that it now 
132reveals its version number. The only thing that is new is the version.
133
134----------------------------------------------------------------------
1353. Scsi.device
136
137More words about another component: scsi.device. Actually, there is no 
138singular "scsi.device", but many: The scsi.device for the A600, one 
139for the A1200, the A4000, the A3000, and the A4000T even has two of 
140them. Some of them are identical, or closely related. They build from 
141"a bunch of code", some of which is common to all the devices, some 
142are model specific.
143
144Version 45 fixes a memory allocation issue where one IORequest was 
145allocated too short, thus trashing memory. Also, the device failed to 
146check whether or not some of the memory allocations during startup 
147succeeded. If they were not (quite unlikely, but possible), the device 
148used the non-existant memory anyhow. It now runs into a controlled 
149software failure.
150
151There were, however, more serious shortcomings of the device: The 
152device now supports LBA48 commands, and works with large (aka 
153"modern") hard disks or storage devices. Clearly, it supports 64-bit 
154commands. As in OS 3.9, it speaks NSD64, but (probably to Heinz 
155Wrobel's dislike) also TD64.
156
157In addition, ATAPI is now supported by scsi.device, and the INQUIRY 
158simulation of the (in reality, not-SCSI, but IDE) device now also 
159supports Compact Flash (CF) cards. It previously reported a device 
160class that applications typically do not know how to handle.
161
162----------------------------------------------------------------------
1634. Graphics.library
164
165More updates... to graphics.library. This library is one of the 
166age-old legacy components responsible for low-level graphics and 
167rendering operations. Like the scsi.device, it existed in multiple 
168versions: One for OCS and ECS models, and one for AGA. Emphasis on 
169"existed", because there is now one unified graphics.library that 
170handles AGA, ECS and OCS equally well.
171
172On the "small bugs fixed" list we had a bug in Flood() which did not 
173work on screens larger than 1024 in any dimension since it only used 
17410-bit precision to keep the coordinates on the fill-stack, so a 
175Flood() on a SUPERHIRES-screen would have caused strange effects. The 
176FIRST_DOT flag in Complement-mode did not work correctly; an issue 
177which was addressed back then by "PatchDraw" but is now fixed directly. 
178Also, the line drawer made a lot of ping-pong calls between C and 
179assembler--quite unnecessarily so. A couple of bugs were addressed in 
180the Area calls, and this part of graphics also contained some dead 
181code. Some of the bitmap blitter support functions did not work 
182correctly on interleaved bitmaps, an issue that had already been fixed 
183by earlier versions of SetPatch.
184
185Then, we have a tiny improvement in the "rectangle and region 
186rectangle" handling, which is the graphics counterpart of the layers 
187"cliprect" system for collecting damage and handling damaged regions. 
188Why there are two independent systems for this nobody knows, but while 
189layers kept a cache for cliprects to minimize memory fragmentation, 
190graphics re-allocated its regions and region-rectangles one by one 
191from global memory, throwing a fragmentation bomb at the system. 
192Graphics now uses a pool for these low-level structures and recycles 
193them to reduce the fragmentation. It also makes things slightly faster. 
194ClearRegionRectangle() was also needlessly complicated and was 
195replaced by a much simpler function.
196
197What is common to all these functions is that their former 
198implementation did not behave nicely in case they run out of memory. 
199Now it is guaranteed that the operations are "atomic", i.e. either 
200they work completely, or the rectangles remain untouched. Previous 
201versions of graphics could have left them in an inconsistent state in 
202the event it ran out of memory in the middle of an operation.
203
204All of the "chunky to planar" conversion functions have been 
205completely rewritten from scratch. They partially used the blitter, so 
206the CPU first had to perform the conversion to Chip RAM (which was 
207slow) and then the blitter blitted it to the screen (which was slow). 
208This was a good idea back then when the blitter was fast compared to 
209the CPU, but this is no longer true, so the new implementation is 
210CPU-only, optimized assembler. It is now about twice the speed of the 
211old code.
212
213Last but not least, our betatest team identified a really bizarre 
214age-old bug of graphics that could trash memory (yes, really) if you 
215switched from one monitor to another (e.g. HIRES to PRODUCTIVITY) and 
216at the same time change the pointer resolution (from 35ns to 70ns) on 
217AGA systems. Graphics in this case "pokes" (for lack of a better term) 
218into the active copper lists without going through the copper 
219abstraction layer, but unfortunately at the time graphics (triggered 
220by Intuition) attempts the poke, the copper lists are already gone. 
221This was a nasty little bug which took quite a while to hunt down.
222
223----------------------------------------------------------------------
2245. Intuition.library
225
226The intuition.library is a major change, but not even (to a major 
227degree) my change. The problem with the original intuition.library is 
228that it was compiled with a compiler that is no longer available, 
229namely Greenhill C. We only have SAS/C nowadays. Both compilers have 
230advantages and disadvantages. SAS/C has registerized parameters 
231(function parameters are passed in CPU registers), is more modern and 
232speaks ANSI-C, and supports creating operating system components. 
233Greenhill C is an old K&R C compiler with an optimizer that is better 
234than that of SAS/C at times, but it only supports stack-based function 
235calls and thus depends on "register ping-pong stub functions" between 
236the OS function and the implementation. It also supported a neat trick 
237where short structures (such as a rectangle) were passed directly 
238instead of making a copy; a trick a couple of functions depended upon.
239
240In 1993, the Intuition Greenhill C code was ported by Peter Cherna to 
241SAS/C, which was a tremendous feat because it required touching a lot 
242of legacy K&R C functions to ANSI C and fixing (or providing) all the 
243function prototypes. Greenhill C was very lazy about pointer 
244correctness, so casts were missing all over the place, and parameters 
245were passed in and out in a rather leeway approach.
246
247Unfortunately, now two other players have entered the playground, and 
248these are Picasso96 and CyberGraphX. Due to their very nature, they 
249depend on the Greenhill compiler carrying out their register and stack 
250allocations. Some features they need are simply not accessible through 
251the official Intuition interfaces. One example is: when allocating the 
252bitmap of a new screen, they need to know how the memory is organized 
253and which viewmode the memory should be used for, i.e. truecolor, 
254hicolor, indexed, planar... but Intuition does not deliver this data. 
255So, they just grab the data from registers where it "happened to lie 
256around by pure chance", left behind by the code compiled by Greenhill. 
257Under SAS/C everything is different, with both the registers and the 
258stack used differently, so the hacky approach taken by both RTG 
259functions no longer work.
260
261For Picasso96, the parameters it expects (and where they're located) 
262are known, so a "kludge" function in assembler just provides the 
263missing data. "It is known" here means that there is a common subset 
264of people that have access to Picasso96 *and* the OS. For CyberGraphX, 
265this is not the case, so it remains completely unclear what exactly 
266CyberGraphX expects, which interfaces it needs, and how we could 
267provide them. We contacted Frank Mariak on the problem, and would be 
268happy to provide Intuition V45 to him to integrate CyberGraphX into 
269this release, and/or provide similar kludge functions or interfaces to 
270make it work. Unfortunately, at this time not much has happened yet, 
271but we all hope that 3.1.4 will become successful enough to make it an 
272attractive development target.
273
274Now for my contributions (this is not really that much). First of all, 
275you can now drag windows out of the screen. This is actually simpler 
276than it looks because it's primarily a job layers.library has to do, 
277and layers was already modified quite a while ago to support this 
278service. Intuition was only modified to make use of this service, and 
279its "window movement" functions were adjusted for testing the window 
280bounds differently when the feature was enabled. By default, this is 
281only on Workbench and not on custom screens; but every custom screen 
282can request it by a flag or a tag.
283
284Secondly, a lesser-known feature is that Intuition now places windows 
285under the mouse pointer in case the window does not indicate a target 
286position and allows auto-adjustment of its position. Hence, if you 
287open up a preference program or Workbench "Execute command" or "Rename" 
288dialog box, then they will pop up under your mouse and not on the 
289top-left edge of the window. This is hopefully more useful, and 
290intuitive (well, wasn't that the purpose of Intuition in first place?).
291
292Other minor changes are that autorequests now allocate a larger 
293stack--the previous stack was really tight and less than 256 bytes 
294were left, which (if additional patches were in the sytem) caused 
295stack overruns. The other fix was an off-by-one error in allocating 
296the name of a public screen which could have crashed memory.
297
298----------------------------------------------------------------------
2996. Layers.library, gameport.device, keyboard.device, input.device, 
300timer.device and console.device 
301
302Let's continue right here. For layers.library, there is nothing to 
303report as already mentioned. It is newly-compiled with better settings, 
304some fine-tuning and a bug in InstallClipRects (). The problem was 
305that at least one program assumed that layers.library recalculated the 
306ClipRects when installing a ClipRect. Layers V45 did that only if the 
307ClipRect differed from the one currently installed. Said software, 
308however, has changed the Cliprect "under the butt" of layers and then 
309reinstalled. You just do not do that...
310
311Gameport, input and keyboard devices are unchanged except for details. 
312That was a coherent ROM module, but for the sake of better modularity, 
313I pulled them apart, and they are now individually built. Furthermore, 
314they now support NSD. I'm not a fan of that, but at least you have a 
315consistent interface. 
316
317Just like the timer.device, which is unchanged except for NSD support. 
318
319Console.device also includes NSD support, a fix in CSIm (the sequence 
320that changes the crayons in the console), and another fix to handle 
321semaphores that was just a bit confused there. Otherwise, it is 
322identical to the version that came with 3.9.
323
324----------------------------------------------------------------------
3257. FastFileSystem (FFS)
326
327More new components. The FFS, FastFileSystem. This is still the 
328Amiga FFS, based on the same assembly code we had before, with a 
329couple of bugs fixed here and there, plus a couple of new features.
330
331First, some bug fixes: The bitmap size computation contained an 
332off-by-one error, which, in rare cases, triggered running the 
333disk-validator every time the FFS was booted. There are now additional 
334size checks for the size of the volume name.
335
336Concerning filename sizes: The FFS now supports two new "flavours", 
337namely DOS\06 and DOS\07, which support "long filenames" using the 
338same layout as in AOS 4. Filenames can now be 106 characters long. 
339This means, in worst case scenarios, that the FFS needs to allocate an 
340extra block for holding the comment as well, which required additional 
341logic.
342
343Another new feature is that the FFS speaks TD64, NSD and SCSI natively; 
344there is no longer the need for NSDPatch as FFS is (in most cases) 
345capable of figuring out the command set itself. Hence, if you run a 
346hostadapter based on the omniscsi, or the Oktagon, or Phase5 boards, 
347large partitions and large harddrives are no longer a problem.
348
349Just a small warning: If you make your partitions large, I also 
350recommend enlarging the block size. I suggest 4K blocks for 
351flash-based media, as otherwise the bitmap grows too large and thus 
352slows down system booting as it initially goes through a minimal 
353validation step requiring the entire bitmap to be held in memory. 
354Furthermore, 4K blocks also help wear-leveling of the flash disk as 
355they organize their internal memory in larger pages than the usual 512 
356byte size.
357
358SCSI transfer needs to be enabled manually, but HDToolBox can do that 
359for you. Or you can use the mount option "DirectSCSI=1" if you mount 
360manually.
361
362Concerning mount options, there are two new ones: "EnableNSD" enables 
363usage of the NSD command set, which is "on" by default, but can be 
364turned off in case the firmware of the hostadapter has problems with 
365it, and "Superfloppy", which allows automatic sizing on removable 
366media. Say you have a ZIP drive that supports both 100MB and 250MB 
367media, *do not* put an RDB on it; mount it with "Superfloppy=1" and 
368FFS will figure out the drive geometry itself, and also resize the 
369drive geometry, just as it does when switching between high density 
370and double density disks.
371
372Last but not least, there is one "hidden" feature we do not support 
373officially, and this is DOS\08. Nobody remembers how, but OS 3.9 
374already supported it, albeit incompletely. It is an FFS variant that 
375supports long filenames limited to 54 characters, but is backwards 
376compatible to the older flavours of FFS such that you can easily 
377upgrade from DOS\03 to DOS\08, gain additional length, but do not need 
378to reformat. However, unlike the OS 3.9 variant, this version works. 
379We still do not support it officially as Diskdoctor (another story for 
380another article) does not support it, but otherwise it works well.
381
382----------------------------------------------------------------------
3838. Bootmenu and Syscheck
384
385A few more components. On the one hand, we have the bootmenu, which is 
386also responsible for displaying non-existent expansion boards in case 
387of a misconfigured system. Similar to that of OS 3.9, bootmenu can 
388switch between PAL, NTSC and 31kHz modes, but the latter is only 
389available on AGA and not ECS machines. Interestingly, the 3.9 variant 
390had tried to install DBLPal on the ECS boxes, which of course did not 
391work.
392
393If you boot from the 31kHz modes, you should still load the 
394appropriate monitor driver, because otherwise the modes are missing 
395the names. Logically, the ROM has no localization information, which 
396only loads into the system with the monitor drivers.
397
398Unlike the bootmenu of 3.9, Nessie is missing (I already said that 
399there are no Easter eggs this year), but Syscheck does not show the 
400boards that can not integrate it as a "defect", but only as not 
401configured. This happens, for example, if there is not enough space in 
402the AutoConfig area. The screen only turns red when the memory on one 
403of the RAM expansions is really malfunctioning.
404
405----------------------------------------------------------------------
4069. WBFind and RAMLib
407
408A completely new ROM component is "WBFind", even if one does not find 
409it under this name in ROM, but instead under "workbench.library" and 
410"icon.library". The purpose of this component is as follows: As soon 
411as someone tries to initialize one of the above components, this 
412component makes sure that the corresponding library is searched for 
413and initialized on all mounted media, and it is also responsible for 
414the nice "Please insert a volume containing .... in any drive" 
415requester.
416
417Two comments for the experts: First, this sounds redundant, since the 
418OS itself can load libraries from hard disk, so why add WBFind? And 
419second, why those names? WBFind previously existed on the A4000T.
420
421First: The difference is that "ramlib"--this is the part that normally 
422loads the libraries from disk--looks only in LIBS:. But we wanted a 
423mechanism where Workbench can be loaded from the Install3.1.4 disk if 
424you did not read the manual again and forgot to install it; ergo, the 
425advanced search path, and WBFind.
426
427Second: Yes, that was the case with the A4000T, where ROM space was 
428too small. But the implementation was a completely different one; 
429namely, as a patch in OpenLibrary (), which then extended the search 
430path itself. Unfortunately, this approach had the disadvantage that it 
431was a patch, and this in particular collided with other patches in 
432OpenLibrary. If you install things like BetterOpenLibs for instance, 
433deinstalling workbench.library will de-install BetterOpenLibs after 
434uninstalling the patch, and that may not be the point of the matter. 
435On the other hand, "WBFind" works without any patches and loads the 
436library "piggyback" on the back of a ROM component of the same name 
437instead of RAMLib.
438
439Speaking of RAMLib, there were two minimal changes: First, RAMLib no 
440longer uses SIGF_SINGLE because it needs several libraries in its init 
441code itself. This has already been fixed in 3.9 times by SetPatch, but 
442is now official. Second, the stack is increased, giving the init 
443functions of loaded libraries a little more "air."
444
445----------------------------------------------------------------------
44610. Shell
447
448One of my favourite playgrounds is, of course, Shell. Since I bumped 
449the version number, there must be something new. The new feature is 
450that pipes are built-in, so you no longer need support from external 
451commands. This sounds like a minor change, but the big advantage is 
452that any such external command does not have to repeat parsing of the 
453rather obscure Shell syntax. Shell itself does it all. In particular, 
454this goes for all the strange rules on backticks, asterisks and quotes 
455that are easy to get wrong.
456
457Pipes require support from Queue-Handler, which is included in 3.1.4 
458as a handler that needs to be stored in L: and has to be mounted on 
459startup. Be aware that you need to use this particular pipe handler, 
460and not any of the alternatives you find in Aminet. The Queue-Handler 
461in 3.1.4 was completely rewritten from scratch and unrelated to 
462Commodore's implementation or any of the versions on Aminet that all 
463have their little problems. The most prominent problem is handling of 
464"break", i.e. if you abort one of the ends of a pipe. Queue-Handlers 
465typically forget to terminate the other end of the pipe, causing CPU 
466hogs or other problems, so make sure you get the right handler.
467
468The syntax is as it used to be: A "|" connects the output of the left 
469program to the input of the right program, such that, for example: 
470
471list | more 
472
473pipes the output of list through the pager. Additionally, we have "||" 
474as command, which concatenates the output of the programs to the left 
475of the double-bar to the program on the right, creating a new common 
476stream.
477
478Last but not least, there is one new built-in command, and that is (. 
479No, no typo, the name of the command is really an opening bracket. It 
480takes ) as the last argument and executes all commands within the 
481brackets in a sub-Shell. This sounds curious, but has its use in 
482combinations such as:
483
484(list || dir) | more
485
486which concatenates the output of list and dir, and then sends it to 
487the pager.
488
489Pipes have other uses, of course. For example, the commands "sort" and 
490"search" also operate in pipes, such that:
491
492list | sort
493
494gives a sorted output of list. There is no new option required for 
495list for doing it--the existing commands are sufficient. Similarly, 
496"search" in a pipe looks for a particular string coming through the 
497pipe, and if so, prints it.
498
499A couple of features had to wait as they came in too late. In my 
500private experimental version, there is also a variant of the Execute 
501command that can also read its input from the pipe, such that:
502
503list lformat="...." | execute
504
505executes a command sequence constructed by "list" without requring a 
506temporary file.
507
508Also, Tab expansion had to wait. There is a little bit of experimental 
509code around (here and there) and a design as well that works quite 
510differently from the currently existing hacks. In particular, I 
511dislike the idea that the console has to do the expansion, because it 
512(again) has to parse the pesky Shell syntax, and getting this parsing 
513right is non-trivial. So the Shell shall do it, and this is precisely 
514the idea. One way or another, it requires modifications to the console 
515and also the Shell, and we ran out of time.
516
517----------------------------------------------------------------------
51811. Ram-Handler, diskfont.library, asl.library and bullet.library
519
520The ROM components would almost have been dealt with, because nothing 
521has changed with dos.library. The Ram-Handler has done a bit, 
522especially the treatment of soft links, which now works, and the Ram 
523Disk shows actual utilization and not just 100%.
524
525Of course, there are still disk-based components and holes; maybe I'll 
526start with diskfont.library and asl.library. Diskfont had a bug 
527('built' by me) in the 3.9 variant that caused the tags of fonts to 
528not land properly in the cache. Luckily, there are hardly any fonts 
529that use this feature to carry around additional metadata. Otherwise, 
530the cache still exists, but has been given a new version number and 
531will be rebuilt once at the first call.
532
533The Diskfont API, which is compatible with OS 4.0, has been enhanced 
534with features that allow direct access to a glyph engine such as 
535"bullet" (for Compugraphic fonts). Under 3.1.4 this does not use a 
536program, but at least you can now let letters render individually, if 
537it feels responsible for a component.
538
539ASL has learned a few new tags from OS 4.0, but is largely unchanged. 
540It's just compiled a bit differently and has become shorter--perhaps 
541like some other components as well.
542
543We once had in diskfont and ASL (as a remnant of OS 4.0) support for 
544"code pages" in the code, so you could not only be able to use fonts 
545like Latin-1. I have to admit, though, that this experiment backfired 
546so much that all this stuff flew back. This requires much more 
547thorough investigation of all the side effects and implications that 
548go down to the file system (unfortunately), and I still do not have a 
549really good idea how that could work. At least not like we tried it.
550
551The bullet.library (Compugraphic) has not changed much except for a 
552few minor optimizations. Here, Olaf had thoroughly cleaned up. 
553Nevertheless, this is the rather terrible legacy code that Commodore 
554probably bought cheaply. In particular, the code has the problem of 
555using variables with external binding (commonly called "global 
556variables") so that two tasks that use bullet at the same time step on 
557each other's feet. Olaf fixed that with some magic and craftsmanship, 
558and that version is in 3.1.4.
559
560The most important change for Compugraphic is not in the 
561bullet.library, but in the inconspicuous "if.uc" file, which contains 
562the translation tables from ISO-Latin to Compugraphic encoding. 
563Apparently partially incomplete, so that certain fonts were rendered 
564incomplete. One of our beta testers (Mikhail) has made a point of 
565completing the spreadsheet after coding out the code. In fact, the 
566whole corner "Compugraphic" is rather undocumented and opaque.
567
568----------------------------------------------------------------------
56912. Workbench.library and icon.library
570
571On to the next components: workbench.library and icon.library. If you 
572look in the ROM contents, you will find two components with these 
573respective names. However, they are not really the libraries; but 
574loaders. Hence, if someone opens one of the libraries, what the ROM 
575really does is load the corresponding component from disk. The A4000T 
576already did something similar, though the corresponding component was 
577called "WBFind".
578
579So, a few questions (maybe):
580
581*) Why is this done in the first place? After all, the "RAMLib" OS 
582component is already responsible for loading components from disk, so 
583why create a new component for that?
584
585*) Why is it done differently than in the A4000T?
586
587First of all, RAMLib unfortunately only looks in the ROM, and in LIBS:, 
588but this is probably not enough. We also want to provide a option so 
589the user can re-insert the "Install" disk and get workbench.library 
590from there and have a bootable system in all cases.
591
592Secondly, the A4000T "WBFind" component worked differently. It 
593installed a patch in OpenLibrary() such that OpenLibrary also looked 
594in different paths, and then removed the patch as soon as Workbench 
595was loaded. This sounds trivial enough, but it caused a problem in the 
596event that the Startup-sequence installs something into OpenLibrary(). 
597Then, if WBFind removes its patch, it typically also removes any other 
598patch that was installed in the Startup-sequence, and that is 
599something that certainly causes a surprise. A typical "victim" of 
600WBFind on the A4000T is BetterOpenLibs. One more reason for avoiding 
601patches whenever possible.
602
603RAMLib itself also has some (minor) changes. First of all, it no 
604longer uses SIGF_SINGLE for its own process communication. This is 
605because some LibInit() functions of disk-based components use this bit 
606itself. Secondly, the stack size of RAMLib has been extended to give 
607such libraries a bit more "headroom".
608
609Why all of this in the first place? First of all, there's simply not 
610enough ROM space. One could, in principle, base this on the specific 
611Amiga model which of the two libraries are in ROM and which are in RAM, 
612but this complicates deployment a lot, and also reduces testability as 
613(in any support case) one would need to ask, "Which ROM type is 
614deployed?". So keep it simple and use the same configuration for all 
615ROMs.
616
617Secondly, and (probably more importantly), it is easier to update the 
618two components without touching the ROM. In fact, I would have 
619preferred to remove other components from ROM, such as audio.device, 
620the mathffp.library and mathieeesingbas.library. None of them are 
621required to bootstrap the system, and it would have made upgrading 
622them easier as well. 
623
624Not this time, though. We will probably do that later, as Olaf was 
625afraid that some third-party firmware may depend on them. We may get 
626more experimental later. For workbench.libary and icon.library, we at 
627least had some experience that this does not harm anything.
628
629----------------------------------------------------------------------
63013. Math libraries
631
632Math stuff. Yes, there are new math libraries (again). Two of the math 
633libraries are unfortunately in ROM. mathieeesingbas and mathffp. For 
634reasons beyond me, mathieeesingbas was even initialized during 
635bootstrap, even if it was not needed. This had several bad side 
636effects, such as having a non-FPU version of the library on the 68060 
637as the library became active before SetPatch, so the 68060.library had 
638to clean up behind it. Another problem was that there were (again) 
639multiple versions of the same library, i.e. with different build 
640options depending on the target model. Now, there is one unified code 
641per library, and not multiple.
642
643As far as mathffp is concerned, the library ran (on purpose) into a 
644division by zero exception in case someone wanted to divide a floating 
645point value by zero. This is, however, not the way floating point 
646should work. Instead, it should return INF or -INF. Now, mathffp does 
647not have either, so instead HUGE_VAL or -HUGE_VAL is returned. Then 
648again, mathffp is not very suitable for numerics in the first place as 
649it does not have denormalized numbers either. The whole documentation 
650for mathffp was quite opaque, too; for example, it claimed that 
651FFPSub() subtracts one argument from another (so far, so good), but 
652not which argument from which. For some strange reason, the arguments 
653were documented the wrong way around compared to the IEEE version, 
654causing even more confusion. So this was cleaned up--namely, the 
655documentation. The RAM counterpart (mathtrans) was only mildly 
656extended to use a larger Cordic table for log and exp such that 
657results are a bit more precise. Yet, the whole mathffp/trans library 
658collection failed any serious test(s) regarding numerical stability, 
659so just avoid, avoid, avoid...
660
661Mathieeesingbas I already mentioned, but there is one additional trick 
662the IEEE libraries learned. Similar to "jumpy, the magic timer device" 
663we now also have "jumpy, the magic math libraries": That is, if at 
664some point after math libraries initialization, the FPU becomes 
665available, the math libraries reinitialize themselves and switch to 
666the FPU code. And vice versa. There is still support for the 
667fpsp.resource which comes with the MuLib libraries, so that did not 
668change.
669
670Mathieeesingtrans did not change, except that it was a major headache 
671to compile it, given that the SAS/C compiler actually does not support 
672single precision IEEE math. This is probably the topic of another 
673episode as it required major magic and trickery.
674
675Mathieeedoubbas and singbas only changed insofar as they configure the 
676FPU a little differently, namely "extended precision, round to zero." 
677The results of the computation are still the same as the last 
678operation in each call to the math code--still implying a rounding to 
679double or single precision--but the advantage of the different 
680rounding mode is that a task can open both libraries simultaneously 
681without a conflict, which was not possible before. You either had to 
682use single or double precision, but could not mix them (safely, 
683without much additional trickery). "Round to zero" is not a very 
684sophisticated rounding mode, though it fits the CPU implementation of 
685the math libraries and is thus consistent. Probably not quite ideal, 
686though.
687
688I do not recall any changes to mathieeedoubtrans.
689
690----------------------------------------------------------------------
69114. Datatypes
692
693Datatypes: There is a new datatypes.library which inherits numerous 
694vectors from the OS 4.0 datatypes, including functionality to read the 
695source from memory rather than a file. Actually, if you ask me, this 
696is probably a bit overdesigned as existing features in the dos.library 
697could do the same. But, well, why not...
698
699The datatypes themselves are beyond what's in OS 3.9, with many, many 
700issues addressed. Both the 8svx.datatype and sound.datatype can now 
701play stereo. Actually, sound.datatype somehow made strange assumptions 
702about the memory type ("if it is not Fast RAM, it must be Chip RAM") 
703that were not entirely true. It only worked because the compiler did 
704not optimize so well and the code contained plenty of duplication. One 
705issue, however: The SVX (without "8") datatype from Aminet does not 
706like it, simply because it does not follow the right protocol when 
707allocating memory for the sound.datatype, so just delete this. 8svx 
708will take over.
709
710The picture.datatype can handle RTG graphics just fine (as did the 
7113.9 counterpart), but had issues fixed concerning the placement of the 
712graphics. If the image height was less than the screen height, the 
713graphics would be rendered incorrectly. There is one difference, 
714though; namely the interpretation of 
715ENV:classes/datatypes/picture/forcev43. What used to be a simple "yes" 
716or "no" choice is now a list of programs that should be promoted to 
717the V43 (OS 3.5) interface which allows rendering of RTG graphics. 
718The list contains the usual suspects by default ("MultiView" and 
719"IPrefs"), but can be enlarged as needed. See the FAQ for details.
720
721Animation had a lot of issues, and caused a lot of trouble. First, 
722buffering was simply incorrect such that one could not "go back" in an 
723animation without causing strange artifacts. Then, it was a CPU hog 
724because the main loader engine used "busy waiting"--a really bad 
725design in a multitasking operating system. It also had issues 
726rendering screen formats not native to the system which are now 
727automatically promoted. Thus, a HAM8 anim will now render correctly on 
728an RTG screen on an ECS machine, or will even be requantized on an ECS 
729screen. Hence, many more anims now play fine.
730
731The anim.datatype (which uses the animation.datatype) also had issues 
732concerning the interpretation of the frame count; namely, it could be 
733off by two frames.
734
735What we did not modernize (but only bugfix) were the gradientslider 
736and colorwheel gadgets. Sorry, this was just too much work. But at 
737least, both gadgets now interoperate with ReAction, which did not work 
738very well with the previous (V40) versions; so that's at least 
739something.
740
741There is neither a new text.datatype, so there is unfortunately no 
742"copy/paste" in text. This is because we do not have ReAction, and the 
743version that supports this requires ReAction. Too bad. Some parts 
744would need to be rewritten to work on GadTools, but there was no time 
745doing so.
746
747What was common to all datatypes was, however, incorrect locking in 
748the library handling functions such as LibOpen or LibExpunge. All 
749implementations had race conditions which could leave a task running 
750in one of the functions while the library is flushed under its feed. 
751This was also fixed all along.
752
753----------------------------------------------------------------------
75415. ARexx
755
756There are a couple of changes in (and around) ARexx. First, the 
757rexxsyslib.library worked fine in reopening the 
758mathieeedoubbas.library over and over again, but unfortunately ignored 
759the result, and only used the first library base. However, with the 
760new "jumpy, the magic math library" the library base might have 
761changed because the FPU was turned on. Not any more. 
762
763Then, we had a bug in FindDevice() which prevented ARexx from locating 
764scripts in multi-assigned... (ahem) assigns. Instead of using 
765dos.library functions, ARexx there used Forbid()-locking for the 
766dos-lists.
767
768Finally, we had an issue in WORD(). It only took two arguments, and 
769not two or three arguments; so this was fixed.
770
771Also, there are changes for all the commands in Rexxc. They now use 
772ReadArgs() consistently, and hence support "?" as an argument to query 
773the arguments they take. "Rx" is a special case, but had special 
774issues. If you ever tried to execute a script from "Ram Disk" like 
775this:
776
777rx "Ram Disk:script.rexx"
778
779you probably know. The above does not do what you think, but tries to 
780execute the string in quotes as ARexx commands directly. To resolve 
781that, "rx" takes a new argument "script" that enforces the argument in 
782quotes to be a script and nothing else. This requires the new 
783rexxsyslib.library as well. Hence:
784
785rx script "Ram Disk:script.rexx"
786
787does the right thing, and is also used by the Shell implicitly for 
788
789ARexx scripts. The "script" argument brings another change, namely the 
790interpretation of the script arguments. It then uses "Shell-style" 
791syntax, meaning that "*"" is the quote, because * is the escape 
792character, unlike in rexx, where """" would indicate the quote (count 
793the quotes!). This is useful because:
794
795rx script "Ram Disk:script.rexx" "$arg"
796
797expands correctly, even if the variable $arg contains blanks or 
798quotes--which are escaped by the Shell with an asterisk; not a double 
799quote.
800
801Last but not least, since OS 3.9, rexxsyslib.library contained the 
802"RVI" (ARexx variable interface) which allows setting Rexx variables 
803from Rexx hosts. This used to be in amiga.lib (for strange reasons). 
804The OS tools such as Workbench and Ed (but also Multiview and some 
805datatypes) no longer link against amiga.lib, but use the RVI in the 
806rexxsyslib.library directly, avoiding code duplication.
807
808----------------------------------------------------------------------
80916. Devices
810
811More news on devices. We start with a seemingly harmless device: 
812clipboard.device. It (temporarily) keeps characters for copy and paste 
813operations, or offloads it to disk. Strangely, it defaults to the Ram 
814Disk, which is probably not a good idea if RAM is low. Anyhow. The 
815clipboard.device is new. Really new. The problem with the old design 
816was that it used Forbid()/Disable() locking, and hence did not work 
817"so well" with multitasking. I am not even clear whether this always 
818worked as intended, as the clipboard.device also made file operations 
819to write clips to disk, and hence broke forbids.
820
821The v45 clipboard.device uses semaphores. This is a bit touchy as one 
822must not run into a semaphore conflict, aka "deadlock". It seems I 
823succeeded there.
824
825There are a couple of minor tweaks in the serial.device, especially to 
826take precautions for some 68040 systems where blocking interrupts by 
827writing to custom chips may leave a chance for a "delay slot" into
828 which an interrupt may still be triggered. CMD_WRITE was also 
829 unnecessarily slow by requiring going through an interrupt for 
830 writing the first character. This is no longer necessary. Parity 
831 check was partially missing on CMD_READ, depending on the 
832 configuration. 
833
834There are only a few changes in the parallel.device. The device used 
835to add a sleeper port to the public port list, though who should look 
836for it there as it is only used for internal operations? In fact, this 
837was only used to initialize the port; so it was not needed.
838
839What is common to all devices is that they support NSDQuery, i.e. 
840support requesting the device command set. I am not a big fan of this 
841mechanism as it has a couple of design issues, but it is too late to 
842fix this, so we keep it (unfortunately).
843
844The printer.device is a story of its own, so I will report separately. 
845A longer story.
846
847The mfm.device for CrossDOS trashed registers on some calls. It could 
848also crash in case the code failed to initialize the disk geometry. 
849CrossDOS does, but not necessarily any other user. Also, its stack was 
850really too small.
851
852Last but not least, narrator.device: No, it is not part of 3.1.4. 
853Unfortunately. I was able to contact its owner, SoftVoice, who are 
854still in business. Unfortunately, they were not willing to license it, 
855so we have to do without it. Too bad. The same goes for the 
856translator.library. In case you wonder, SoftVoice also provided S.A.M. 
857(on C64 and the Atari 8-bit series). I would have loved to see, err, 
858hear, narrator again.
859
860----------------------------------------------------------------------
86117. Handlers
862
863Handlers are one level above devices, and reside in L:. Their 
864interface stems from Tripos, and hence a lot of BCPL legacy is found 
865here. The very last snippet of BCPL code is, however, finally gone. 
8663.1.4 includes a completely new Aux-Handler that was written from 
867scratch in C. For those that do not know: Aux is the "serial" 
868counterpart of CON:. Unlike SER:, which only reads and writes 
869characters, AUX: also buffers lines and includes a couple of keyboard 
870shortcuts for editing text. Hence, you can start a new Shell on a 
871serial terminal with:
872
873newshell AUX:
874
875The AUX: handler here now also handles ^C through ^F more carefully, 
876and ACTION_WAIT_FOR_CHAR allows buffering of multiple requests.
877
878Speaking of SER:, this is implemented by the Port-Handler, which is 
879also responsible for PAR: and PRT:. It is also new and fixes many 
880issues. The previous version crashed if multiple read or write 
881requests were piled up, and hence did not support asynchronous I/O at 
882all. It also tries to identify the nature of the device it talks to, 
883and hence changes its interface to either speak "parallel", "serial" 
884or "printer" language, even if you connect it to another device--which 
885is also a new feature. If you open "SER:" with the additional "path 
886name" NOWAIT (i.e. Open("SER:NOWAIT")), then SER: will not block when 
887no characters are in the input buffer of the serial port. It will 
888return immediately.
889
890The full set of options encoded in the path name is 
891"BAUD/N,CONTROL,RAW/S,NOWAIT/S,TRANSPARENT/S,UNIT/K/N", where "BAUD" 
892sets the serial speed, and CONTROL sets the serial parameters, e.g. 
893"8N1" is 8-bit, no parity, 1 stop bit. NOWAIT we discussed above. RAW 
894turns off the translation from LF to LF/CR pairs for the printer, and 
895TRANSPARENT disables the translation of Amiga-specific (ANSI) control 
896characters to printer-specific sequences. UNIT sets the unit number.
897
898For some strange reason, the old Port-Handler neither supported 
899ACTION_WAIT_FOR_CHAR, which was a logical packet to support, 
900especially with the serial console. Strange...
901
902Also, a ^C sent to the requesting process aborts the I/O interface. If 
903you previously sent a string to PAR:, but the printer was not ready, 
904the system deadlocked because the process cannot be aborted waiting 
905for PAR: to return, which it never did...this changed now, and even a 
906"LIST >PAR:" can be safely aborted.
907
908Speaking of speaking, there is a revised Speak-Handler, though no 
909narrator.device for it. There is not much new, except for a couple of 
910minor fixes. ^C to abort speaking did not work quite right, it also 
911stayed in memory permanently, and parsing of opt/ as well.
912
913The queue-handler is completely new and unrelated to any former 
914QUEUE-Handler. It handles abortion of queues ("broken pipes") 
915correctly now, and this is the queue-handler you should use for the 
916new shell. Even though there is no "IN:" or "OUT:" as in OS 4, there 
917is "PIPE:". That is:
918
919type s:foo | type pipe: hex
920
921is a complicated way to type s:foo in hex. The "PIPE:" filename of the 
922second "type" command accesses the input pipe.
923
924Similarly,
925
926list lformat="..." | execute PIPE:
927
928creates a list of commands with list, and executes it with "execute". 
929Here, PIPE: also accesses the input stream (reading end) of the pipe. 
930PIPE: can also be used as the writing end of a pipe, i.e.
931
932type s:foo to PIPE: | type pipe: hex
933
934works too; just more complicated. Hence, no need for "IN:" or "OUT:", 
935just write "PIPE:" and it will figure out into which end of the pipe 
936the stream will go--reading or writing.
937
938Other than that, there are also named pipes, as before. They can be 
939read or write by name. For example:
940
941type s:foo to pipe:bar &
942type pipe:bar hex
943
944starts the first command in the background, and then reads from the 
945same pipe, with type again. Even more complicated than before, but 
946does just the same...
947
948There are more new handlers: CrossDOS, and the CDFileSystem. I will 
949cover them later in a separate blog.
950
951----------------------------------------------------------------------
95218. Pipes
953
954Shell Pipes: We had this already. It is an old feature in a new 
955interface--there is no longer the Pipe command because the Shell 
956handles it all by itself. The advantage is that there is no need to go 
957through a second-step parsing, which is particularly tricky with the 
958awkward Shell language. Depending on the Pipe command you used, some 
959recognized tokens like STDIN: or STDOUT: to access the input or output 
960stream directly. Note well that there is no "device" named STDIN: or 
961STDOUT:, this was simply "guessing and token recognition", to allow 
962such things as:
963
964list | type stdin: hex
965
966which would give a directory listing in hex. Don't ask what this is 
967good for; it is just the simplest example I could think of. "Type" 
968does not support "reading" from stdin, so you had to use this token.
969
970With 3.1.4, there is no "Pipe" command, and there is no longer any 
971magic token that represents a stream. But you can do the same by 
972similar means, by a feature of the qeue-handler. If it is opened 
973without any filename, it rather reads or writes (depending on how it 
974is opened) from the currently active input or output pipe. 
975
976Sounds complicated? Not really, it is quite straightforward. The above 
977converts to:
978
979list | type pipe: hex
980
981Hence, list pipes its output to the pipe, and "type" picks it up there, 
982via "PIPE:". There is no ambiguitity and "PIPE:" is context-sensitive; 
983i.e. you can run the same in two Shells Simultaneously without any 
984chance of confusion because "PIPE:" knowns where the input or output 
985comes from or goes to, and PIPE: also knows whether it should operate 
986from the reading or writing end of the pipe because the program opens 
987the stream either for reading or writing. In the above case, for 
988reading of course, so it connects to the output of list.
989
990Morale of the story: Just replace STDIN: or STDOUT: (if your "pipe 
991command of the day" supported that) by PIPE: and all will be good.
992
993----------------------------------------------------------------------
99419. CrossDOS
995
996I believe I've already provided some details on CrossDOS, but I'm 
997doing it again and going a bit more into depth. CrossDOS is also 
998pretty much new, at least many major parts have been exchanged, and 
999there is unfortunately still one bug left we need to fix in a 
1000follow-up release (tentatively, 3.1.4.1). The big picture is that 
1001CrossDOS is now multithreaded, same as FFS, and it can handle large 
1002volumes (though, due to the bug, not long FATs). That means, it 
1003supports FAT16, FAT24 and (that is the new part) FAT32. It also 
1004includes support for long filenames, something called "VFAT" in the 
1005Linux world. The last M$ patents on this stuff ran out February of 
10062018, so we are safe.
1007
1008"Multithreaded" means that CrossDOS can fire off an I/O operation such 
1009as reading a long file, and can still respond to other incoming 
1010requests. As long as the requests can be handled from cache--and 
1011CrossDOS does have a cache--they can be answered immediately. Previous 
1012CrossDOS releases tried this in a clumpsy way, by always starting two 
1013processes. One handled "ACTION_DISK_INFO", and forwarded all other 
1014requests to a second task. This would at least avoid slowing down the 
1015frequent disk check by Workbench which triggers exactly this packet, 
1016but otherwise didn't help much. The new CrossDOS is a single process; 
1017not two, but it uses a technique called "coroutines", something it 
1018shares with FFS and the CDFileSystem (more on this in another episode).
1019
1020For normal routines, you have subroutines A, B, C where A calls B, 
1021then B calls C, C returns to B, and B returns to A. Coroutines work 
1022differently. From A's perspective, A calls B, and--from inside B--B 
1023calls A. A typical example for this (and this is how it works in just 
1024another project of mine, ViNCEd) is the parsing of CSI sequences, e.g. 
1025CSIx;ym to set the font color and font attributes in the console. 
1026Here we have one function B that calls A to get a new character, then, 
1027if this is a CSI or ESC, it reads the next--OK, is it a 
1028number?--parses the number, then continues parsing to the next 
1029semicolon, then when the final letter arrives, it has all the 
1030parameters it needs to collect, and calls the corresponding 
1031lower-level function to set the attributes. So, the 
1032parser--here B--needs the data letter-by-letter or digit-by-digit. 
1033Unfortunately, this is not the way the data arrives. Instead, the user 
1034writes data into the console, and probably not even in complete 
1035sequences. There is nothing wrong writing the CSI with a single write 
1036call, then writing the digits in a second call, and then writing the 
1037final letter in a last call. So, from that perspective, the function 
1038that receives all the requests from the user--and this is A--gets data 
1039in chunks, and then calls into B. So from the perspective of 
1040dos.library, the top-level is A, which collects user requests, and 
1041calls into the parser B. From the parser perspective, namely B, it 
1042needs to call A to retrieve the next character. Clearly, this doesn't 
1043work with classical subroutines, because either A or B would need to 
1044be turned "inside out".
1045
1046There are two solutions for this problem. One solution is "state 
1047machines", which are hard to debug and complicated to write, but 
1048classical and work with the methods of high-level languages such as C, 
1049and the other solution is "coroutines", which is a long forgotten art 
1050form, probably best described in Knuth's "The Art of Computer 
1051Programming", which is not supported by C, but requires a small 
1052assembly stub. It is (or was) supported by BCPL, as implemented in 
1053Tripos, and probably one of the reasons why the OFS used it. FFS uses 
1054its own coroutine functions, and so does CrossDOS and CDFileSystem.
1055
1056There is more to share about CrossDOS. My experience with it is that 
1057most people assume that it works like FAT95, but it does not. FAT95 is 
1058not multithreaded, and it is not quite as capable as CrossDOS. Again, 
1059we need to take a detour for the details. On the Amiga, partitions are 
1060indicated by the Rigid Disk Block, a couple of blocks at the start of 
1061a disk that specifies where the partitions start and end. This rigid 
1062disk block is to be interpreted by the firmware of the host adapter. 
1063This is, for example, the Guru ROM, or the GVP boot ROM, or even part 
1064of the scsi.device. It is not the FFS or OFS that deals with it. 
1065Floppies don't use a Rigid Disk Block, and removable media such as ZIP 
1066should not use it either (this is a bad idea; more later).
1067
1068Of course, PCs don't use a Rigid Disk Block. They use a BIOS Master 
1069Boot Record (MBR) partiton table (though with UEFI, not anymore; they 
1070use yet another structure). The problem is: the hostadapter cannot 
1071read this structure (there is not even a hostadapter there), so nobody 
1072in the OS feels responsible for the MBR partition table. So CrossDOS 
1073has to jump in. It can be run in two modes:
1074
1075- Using the drive entirely as if it would be a floppy (this is the 
1076"superfloppy" mode).
1077
1078- Interpreting the partition table, then handling one partition of the 
1079drive. It then needs to know which partition it should be responsible 
1080for.
1081
1082Back when CrossDOS was implemented, the new "SuperFloppy" flag in the 
1083MountList did not exist, so they looked for other solutions, which is 
1084the DosType field in the MountList.
1085
1086So, if the DosType is MSD\0, it is a SuperFloppy; no partitions are 
1087assumed, and the whole disk is just one file system. This is identical 
1088to setting "SuperFloppy = 1" in the MountList. There is a second 
1089equivalent DosType, namely MDD\0 which does the same thing. This is 
1090probably some legacy mechanism to switch between single and double 
1091density, but it is no longer in use and the two are now equivalent. 
1092One single file system per device.
1093
1094If the DosType is MSH\0, a MBR partition table is instead assumed to 
1095be on the drive, and then "SuperFloppy" must be 0; i.e. off. Of course, 
1096then CrossDOS needs to know which partition to access, and there is no 
1097such field in the MountList. Instead, it uses the name of the handler. 
1098If the device name ends with C, it is the first partition; if it ends 
1099with D, it is the second partition; and so on. This is probably to 
1100mirror the typical Dos "partition names" where C: is the first 
1101partition on the internal hard disk, D: the second, and so on. Hence, 
1102you cannot name the devices as you like, but the name of the icon in 
1103DEVS:DOSDrivers needs to end with the right character names.
1104
1105Thus, to keep it short, three things need to be fixed to switch over 
1106from FAT95 to CrossDOS:
1107
1108a) Change the FileSystem entry in the MountList to 
1109L:CrossDosFileSystem
1110
1111b) Change the DosType to 0x4d534800 for MBR-partitioned drives or 
11120x4d534400 for SuperFloppies (or keep 0x4d534800 and add 
1113"SuperFloppy = 1").
1114
1115c) Change the name of the icon such that the last letter indicates the 
1116right partition.
1117
1118FAT95 uses a different DosType, namely 0x46415400, and uses a 
1119different way to indicate partitions, and people often forget to 
1120change this. In particular, FAT95 uses the last digit of the DosType 
1121to indicate the partition number, i.e. 0x46415401 is the next 
1122partition.
1123
1124There is, however, something wrong with this hack, and what FAT95 
1125attempts here is a bad idea. And for this, we need another excursion, 
1126and this is the FileSystem.resource. This is an invention that came 
1127into life with v34 (Kick 1.3) and autobooting. The problem it tries to 
1128solve is that if you have a hard disk with many partitions and a 
1129floppy, then each of these devices clearly needs a file system. 
1130However, without any further trick, the same file system needs to be 
1131loaded once per partition, hence for a three-partition drive and two 
1132floppies, five copies of the FFS would have to be loaded into RAM. 
1133This is clearly a very bad, wasteful idea.
1134
1135Instead, we have the FileSystem.resource, which "buffers" file systems. 
1136So, whenever a partition is mounted, the Mount command (or the 
1137firmware of the host adapter) checks in this resource for a file 
1138system with the same DosType as the one it needs for mounting the 
1139partition, and if it finds one, it just recycles what it finds there. 
1140Hence, there are three CrossDOS entries in the FileSystem.resource 
1141once you mount a CrossDOS device, installed there by CrossDOS itself: 
1142MSH\0, MSD\0 and MDD\0, and all three point to the same CrossDOS code.
1143
1144Now, consider the same for FAT95: Instead, you could have as many as 
1145255 entries in the FileSystem resource for that: One for FAT\0, the 
1146first partition, one for FAT\1, the second partition and so on, up to 
1147FAT\255, the 256th partition. This is clearly not practical. FAT95 
1148misuses the DosType for something it was not designed for, and its 
1149authors probably forgot about the implications it has for the 
1150FileSystem.resource.
1151
1152In the meantime, CrossDOS had one bug fixed, namely that the version 
1153that came with 3.1.4 accepted only FATs (directories) with at most 16 
1154blocks in size. This was part of a legacy check mechanism to identify 
1155corrupt disks, but is no longer relevant for today, so it got removed. 
1156CrossDOS now *also* supports the FAT\xx DosType just because I know 
1157that only a minority of users read instructions, or even this text, 
1158but there is no entry (for reasons given above) for this DosType in 
1159the FileSystem.resource, so the code isn't shared. It just loads 
1160CrossDOS again from disk, wasting your memory. 
1161
1162Avoid the waste, change the DosType.
1163
1164----------------------------------------------------------------------
116520. CDFileSystem
1166
1167Concerning file systems, there is a third one that comes with 3.1.4, 
1168and that is the CDFileSystem that reads CD-ROMs. The V45 version has 
1169almost nothing in common with the original Commodore version. It is a 
1170close cousin of the OS 4 version, though, and borrowed many features 
1171from it. At the same time, it is both ahead and behind it, but the 
1172story is a bit complicated...
1173
1174Similar to FFS and CrossDOS, it is multithreaded, which is a new 
1175feature. That is, if a CD-read is triggered, the file system remains 
1176responsive and can answer requests as long as the corresponding CD 
1177blocks are in cache. What the CDFileSystem caches are administrative 
1178blocks; not data blocks. That is similar to FFS. This multithreading 
1179is new, compared to both the OS 3.1 and the OS 4.0 version, and just a 
1180consistent new feature in all file systems.
1181
1182It also supports the "DirectSCSI" flag. Regularly, the CDFileSystem 
1183attempts to read from the CD (or DVD) by means of CMD_READ. However, 
1184not all hostadapters support 2048 block sectors (as required) CD-ROM 
1185data track access, and hence, this control flag turns out to be quite 
1186useful here as well. Previous solutions for the same problem used the 
1187"control" entry in the MountList, though details depended on the 
1188particular implementation.
1189
1190Despite cache and multithreading, the CDFileSystem features a third 
1191mechanism to speed up access, and this is "read ahead". If a program 
1192does not attempt to read a large amount of blocks one after another, 
1193but is rather asking data block by block, this would imply that the 
1194CD-ROM has to start and stop reading, slowing down the transfer. The 
1195CDFileSystem instead now automatically loads block N+1 into cache when 
1196block N is read such that this access can then be satisfied quickly.
1197
1198Multiple extensions made it into the 3.1.4 version compared to the 3.1 
1199version: Joliet support (the proprietary "we don't read standards" 
1200standard from Microsoft for long filenames), and Rock Ridge (the 
1201universally-accepted except on Windows version for long filenames), 
1202plus the Amiga-specific extension for protection flags (a proprietary, 
1203though popular and necessary extension). They all came in from the 
1204OS 4 version.
1205
1206What also came in through OS 4 is support for audio tracks. That is, 
1207audio tracks appear as "AIFF" files on the CD file system and then can 
1208be played through MultiView, though an AIFF datatype (which, sorry to 
1209say, we did not include). Well, mostly OS 4, as there is more to say. 
1210OS 4 does not "read ahead" and "multithread" for audio, and 
1211unfortunately, there are about 30 different ways of obtaining audio 
1212data from a CD-ROM (I love standards, you can select between so many 
1213of them). OS 4 had about support for three. The 3.1.4 version has a 
1214rather delicate algorithm to try them out, then stick to the one that 
1215worked, so you don't need to configure this in the MountList.
1216
1217What also came in from OS 4 is support for UDF, which is the file 
1218format used by DVDs. It is a bit more modern than the ISO format, 
1219though UDF support includes caching, which it did not in OS 4, so it 
1220should hopefully perform better. Actually, UDF support was much more 
1221polished in the 3.1.4 version.
1222
1223There are other things that did not make it into this version, though, 
1224simply because we ran out of time, or haven't had material for testing. 
1225The OS 4 version also supports the simple video format (CDXA) but no 
1226support in the file system. The problem here is lack of documentation, 
1227and lack of test material. There are multiple track formats a CD can 
1228be formatted in; not just 2048 byte sectors and 2352 audio blocks. It 
1229was--to me--completely unclear which format these disks take. As this 
1230is a rather exotic format, I decided to ditch it. As soon as I know 
1231more, I might reconsider, but so far no-one has really complained.
1232
1233The OS 4 variant also supported HFS and HFS+, the "we do make 
1234proprietary formats" format from Apple. Unfortunately, I don't have 
1235any fruit in the house, and neither test data to assess it; 
1236furthermore, the OS 4 code was dependent on some GNU specific 
1237extensions to ANSI C such as function definitions within functions 
1238(today, one would probably call that "closures") which first had to be 
1239restructured to fit into ANSI-C to make it compile with SAS. Well, in 
1240the end, this all looked too risky, with no test data, and only a 
1241"best guess interpretation" what this GNU C should mean, so it was 
1242also ditched. It would have extended the work by probably another 
1243month, and this was hard to justify.
1244
1245There are probably a couple of "strange" CD drives still alive in some 
1246machines that do not play by "any rule" (i.e. any formulated standard) 
1247that we may have forgotten, or for which we have no clear idea how to 
1248detect or support. For example, it is at least known that some (really 
1249old) CD drives return audio data as "big endian". While this sounds 
1250plausible on the Amiga, the MMC audio specs specifically require 
1251little endian, and thus the endian switch is always made. Of course, 
1252with rather bad side effects on such drivers that play in the wrong 
1253(or right?) order. As there are no clear guidelines at this time as to 
1254how to identify such ancient beasts (nor an idea how to drive them), 
1255there is no support for them either. If you have to happen such a 
1256thing, let me know, we'll probably find a solution. But, again, they 
1257probably all died out 10 years ago already...
1258
1259There are also a couple of other tiny bugs here and there found during 
1260the review of the OS 4 code, so actually, overall code quality should 
1261have been improved--that, plus multithreading--should hopefully give 
1262you a rather stable and fast CD experience. It is actually more of a 
1263"four file systems in one package" right now.
1264
1265Just one word of warning: Do not expect CD audio to work on WinUAE. It 
1266won't. The problem is that WinUAE does not emulate MMC commands nor 
1267the CD-ROM TOC correctly, so no data comes through. That's not the 
1268fault of the CDFileSystem.
1269
1270----------------------------------------------------------------------
127121. Animation.datatype and anim.datatype
1272
1273Maybe a bit more in-depth information on one of the datatypes, the 
1274animation.datatype and anim.datatype. Actually, they sound related, 
1275but their job is a bit different. The animation.datatype is the 
1276generic base to play animations, in the same way as the 
1277picture.datatype shows pictures. The anim.datatype is specifically 
1278there for interpreting IFF ANIM files, and therefore related to the 
1279ILBM datatype, which are IFF pictures. Besides ANIM, the only other 
1280datatype "on top" of the animation.datatype is the CDXL.datatype, 
1281which plays very simple animations, small movie clips more than video 
1282(given the resolution and bit depth Amigas can handle).
1283
1284Animation was one of the things we debugged for too long, the ratio 
1285between bugs and actual code was... quite surprising, to put it mildly. 
1286First, you need to understand how this thing works: animation launches 
1287two tasks, one that continuously pulls data from disk and puts it into 
1288a ring buffer--via the anim.datatype or anything else that reads files 
1289that represent video--and a second task that plays the frames. The 
1290problem with the 3.1 version is that there is absolutely no 
1291synchronization: Both tasks access the same data structures, without 
1292even using a semaphore. Clearly, this cannot work. When one task 
1293accesses a data structure while the other is modifying it, you are 
1294asking for problems.
1295
1296Olaf had this fixed for 3.9, so there are now semaphores for the ring 
1297buffer. Unfortunately, the problems did not stop there, so the 3.9 
1298version is not working very well at all. One of the anoyances was that 
1299decoding of frames worked when playing forward, but due to the 
1300dependencies between frames in the ANIM format ("P-frames" as one 
1301would call them) you could not reliably seek backwards. You were often 
1302left with junk on the screen because the decoder used the wrong 
1303reference. Which was fixed, of course.
1304
1305A second interesting effect was that most anims played with two frames 
1306too much. This is one of the "features" of IFF ANIM, namely that the 
1307last two frames reconstruct to images that are identical to the first 
1308two--the reason for this is that DPaint wants to enable players to 
1309play the anims in a loop, without having to go through a full decode 
1310of the first two frames ("I-frames"). So the last two frames are 
1311predictive frames that go back to the initial two frames. There are 
1312two frames; not one, because ANIM uses a front-buffer (shown on the 
1313screen) and a back-buffer (in which data is computed), and swaps 
1314between them for every frame. Which was exactly why seeking backwards 
1315did not work reliably.
1316
1317Then we have screen modes that may turn out to be a problem: For 
1318example, HAM8 can not be played "as is" on an OCS/ECS machine. It 
1319could be played if colors are quantized down to a restricted palette, 
1320and it could be even played in original quality if RTG graphics were 
1321available. Only that the datatype did not attempt any of that. This 
1322also changed, and we got (for a couple of additional cases) custom 
1323"renderers" that reduce the quality to be able to display the 
1324animation on Workbench, or on an RTG screen. Previously, the datatype 
1325would only show an error requester.
1326
1327Synchronization between the two threads (loader and renderer) was also 
1328a bit... strange. One would typically do that with message parsing: 
1329"I'm ready to take four frames, preload them from disk", and so on. 
1330This natural Amiga communication protocol was apparently too 
1331much--instead, the datatype uses about four signals, depending on what 
1332the loader should do (load, stop abort, preload, exit...). 
1333Unfortunately, if the player is busy, and does not require any extra 
1334frames, the loader... just busy-waits and burns CPU time the renderer 
1335could use for showing frames.
1336
1337Needless to say, I stopped this and I'm halting the loader task now if 
1338it has nothing to load, so the datatype is no longer a CPU hog. You 
1339saw this problem on 3.1 and on 3.9 even that the scroll-bar was quite 
1340"quirky" to use--it sometimes did not react, the mouse pointer was 
1341frozen, just because the CPU was locked on the player thread and the 
1342input.device (responsible for moving the pointer) did not get the CPU 
1343until the player released a critical semaphore of Intuition, because 
1344it was busy waiting for the loader, and the loader was busy... doing 
1345nothing. Great job, folks.
1346
1347Since the animation.datatype was written by the same guy as the 
1348sound.datatype, similar problems continued there... but more on this 
1349later.
1350
1351----------------------------------------------------------------------
135222. Printer.device
1353
1354Quite a while ago, I already reported on the printer.device, and that 
1355it was the most nerve-wracking experience we had with 3.1.4. So far, 
1356I've always believed that graphics.library is bad; but despite its 
1357smaller size, printer.device made more trouble--for multiple reasons.
1358
1359First, there is the OS 3.1 printer device and the new development from 
1360Haage & Partner for OS 3.9. Unfortunately, we do not have the 3.9 
1361version, so this was not an option. The 3.0 version was not an option 
1362either as it does not support printing of RTG graphics--it has no clue 
1363about it. Then, there is the V58 or so version from OS 4.x, but this 
1364was not an option either because it was full of code only supported 
1365and meaningful in 4.x, such as library base access.
1366
1367Hence, no good options for development. We settled for an intermediate 
1368version which was before the integration of many OS 4 specific 
1369constructions, but branched off from the V40 version from 3.1. It 
1370turned out that this wasn't a good option either, but the best we had.
1371
1372The first problem we noticed was that buffer management was broken. 
1373Actually, broken in ways similar to the 3.9 version. If you had an old 
1374slow pin-printer, you may have noticed strange artifacts at the left 
1375of the page. This happens because the printer driver renders into the 
1376output buffer while the printer is printing it, and as old parallel 
1377printers are relatively slow, the printer isn't ready before the line 
1378buffer is touched again, so 3.9 was actually unusable with anything 
1379with a slow parallel interface.
1380
1381Another gimic of the 3.9 version was that it supports multiple 
1382printers. This was re-implemented in the OS 4.x variant, and we had it. 
1383But it had a bad side-effect in that whenever you opened the printer 
1384device, it would reload the printer driver from disk. This is probably 
1385not much of an issue with hard disk users as of today, but it is 
1386clearly an annoyance if you want to print from floppy as it causes a 
1387"please insert ... in any drive", everytime you want to print. Our 
1388printer device is now smarter and buffers drivers.
1389
1390Unfortunately, more issues in printer drivers remained: They all have 
1391an initialization code that opens core libraries and returns a failure 
1392code in case initialization failed. Though the printer.device never 
1393checked... so if initialization failed, the printer.device would fall 
1394over. Unfortunately, someone (ehem, Olaf) must have misread the 
1395documentation when implementing the HP printer drivers for 3.9. 
1396Instead of an error code and 0 for success, they return 1 for OK and 
13970 for error, quite the reverse of what is needed. This was never 
1398noticed in 3.9 because there was never any check, but for V45, there 
1399is a check and hence printer drivers from 3.9 just do not work in 
14003.1.4. However, we updated all of them, and the 3.1 drivers are okay 
1401in this respect. Just do not use the 3.9 drivers.
1402
1403Then, Floyd-Steinberg dithering did not work as it required a larger 
1404buffer than it allocated, and then left artifacts on the right-hand 
1405side of the page; at least for low resolutions. This kind of thing 
1406happens if you never attempted to print with a old-style needle 
1407printer with a stunning resolution of 90dpi. Ok, so this was noticed 
1408by our beta team (thanks!) and fixed as well.
1409
1410In 3.1 and 3.9, the printer.device checks for out of paper and offline 
1411conditions, but in 3.1, you never could abort printing. Yes, there was 
1412a nag requester "Printer is out of paper...", but if you attempted to 
1413abort printing, it just came back. The error was never propagated 
1414"upwards" in the code, and the only thing you could do is either 
1415insert paper--or reboot the machine. Even worse, it checked the 
1416parallel port pins just the wrong way around and hence always reported 
1417the wrong error. "Out of paper" if the printer was offline, and 
1418"offline" if the printer was out of paper. The OS 4 version also has 
1419this inverted, and while Olaf invested quite some time to make the 
1420printer abort printing, it was neither completely successful. Just 
1421going through all the layers of the software, and checking 
1422consistently for abortion conditions is quite a hassle.
1423
1424My tests with my antique NEC P6 seem to be succesful in so far as that 
1425aborting a print now really aborts it. This is a bit touchy--you 
1426cannot simply "pull the rug" in the middle of an Esc-sequence which 
1427prints a dot graphic because if you want to continue printing later, 
1428the new commands would then be understood as part of the Esc-sequence 
1429graphics that were unfinished and part of the aborted first printer 
1430job. Apparently, Olaf missed this--you cannot just abort printing 
1431"anytime", you can only abort after the end of a control sequence.
1432
1433Printing with HP printer drivers also turned out to be a hassle, even 
1434though we had updated sources (thankfully provided by Olaf who also 
1435wrote them for 3.9). Whenever we tried, graphics came out just garbled. 
1436It took a while until we found the reason: There was a silent 
1437interface change from 3.1 to OS 4.x in how graphics is exchanged 
1438between the printer.device and its drivers. In 3.1 and below, the 
1439expansion of graphics (i.e. magnification to the printer resolution) 
1440is split between the printer.device and the driver. What the driver 
1441receives is a "run-length" compressed version of the low-resolution 
1442graphics and the run sizes, i.e. two arrays: The graphics data, and 
1443the expansion factors for each pixel. For OS 4.x, the expansion 
1444factors are always 1, and the graphics is expanded by the 
1445printer.device. This enables use of old printer drivers with the new 
1446printer.device, but not using new printer drivers that do not handle 
1447expansion with the old V40 code of the printer.device we had. Hence, I 
1448also updated the HP drivers from Olaf to support the type of runlength 
1449coding used in the 3.1 world.
1450
1451Then, we had similar bugs for downscaling graphics instead of 
1452upscaling graphics. If you downscale in x direction by a factor of sx, 
1453and in y direction by a factor of sy, the printer.device uses a rather 
1454naive "box filter" for the downscaling; i.e. it sums up all pixel 
1455values in boxes of size sx times sy, and then divides by the box size. 
1456Or rather, it should. In fact, it divided by sx+sy instead of sx*sy, 
1457which does, of course, just give nonsense. Strangely, no-one noticed 
1458this before.
1459
1460All this averaging and downscaling has several implications on HAM 
1461graphics as well: Here, the printer.device has to emulate the custom 
1462chip hardware and has to "hold and modify" pixel values itself. This 
1463is all simple if you just have single pixels, but if you also have to 
1464take averages over pixels for downscaling, things can go wrong--and 
1465did go wrong. So HAM printing was broken in V40, and probably still 
1466broken in OS 4.x (not that these machines have HAM in the first place).
1467
1468The printer.device also supports a primitive form of "color correction" 
1469that, essentially, attempts to adjust between the different gamma 
1470exponents of screen and printer, and the different color densities. 
1471It's all a bit naive, but whatever... it should work, which it did not 
1472if downscaling was involved. Actually, the way it works is that it 
1473modifies the palette before printing the image, hence it still does 
1474not work with True color graphics or HAM, both of which do not have a 
1475palette. Speaking of true-color images, printing these images sideways 
1476was broken, too, and just generated nonsense.
1477
1478So, this was really an extremely bug-ridden piece of code, and I 
1479believe there was not a single source file that remained untouched. It 
1480should be fairly ok now.
1481
1482More words of warning: as mentioned, do not use the OS 3.9 printer 
1483drivers. They simply won't work as their initialization code returns 
1484the error indicator just the wrong way around. Use the 3.1.4 supplied 
1485drivers, which were all refactored--not only the HP drivers, also the 
1486Epson and NEC drivers were updated and cleaned up and tested. (Guess 
1487who has an NEC?). In worst case, use the OS 3.1 driver, or send me a 
1488line if you want it updated and are willing to help with testing. 
1489However, they should continue to work unchanged.
1490
1491A second (not-) change is the preferences system. OS 3.1.4 uses the 
1492OS 3.1 preferences system, which means that there are separate 
1493preference files for the printer and the printer graphics 
1494configuration as these are two different preference programs. In 3.9, 
1495this all moved to a single program and a single file. While the 
1496printer.device of 3.1.4 supports and reads the 3.9 preferences files 
1497just fine (it is just another IFF dialect) the 3.1 settings from the 
1498second preferences file override the 3.9 settings. So, either use the 
14993.1.4 preferences program consistently, or delete the printer 
1500preferences in ENVARC: and only use the 3.9 preferences program. Both 
1501works, but do not mix them. In case of doubt, delete the printer 
1502preferences from ENVARC: and create new ones; this will work.
1503
1504A feature we do not have is the printer preferences preview. This was 
1505added in the 3.9 printer.device--namely to generate a preview using 
1506the latest settings--but documentation on how to do that is missing. 
1507Hence, no preview for 3.9 preferences. As soon as we find out, we may 
1508add it.
1509
1510----------------------------------------------------------------------
151123. Printer drivers
1512
1513The post was long enough, but I still forgot something...
1514
1515HP LaserJet printer drivers... The LaserJets, and actually most modern 
1516printers are page-printers; not line printers. That is, they receive 
1517an entire page, and then print it once it is complete, unlike the 
1518old-style needle-printers that printed graphics line-by-line as it 
1519comes in.
1520
1521This has an impact on how printer drivers work, and this may be a bit 
1522confusing at first: whenever the printer driver closes down, it has to 
1523eject a form feed as otherwise nothing is printed at all. Hence, if 
1524you redirect several commands to PRT: such as:
1525
1526Code: [Select]
1527list >PRT:
1528dir >PRT:
1529
1530the output of list and dir will appear on separate pages for the 
1531LaserJet and DeskJet printers simply because the Shell closes the 
1532redirection file after each command.
1533
1534The alternative would have been not to print the form feed, but this 
1535would mean that you probably do not get *any* output at all until you 
1536run a command that manually prints a form feed.
1537
1538I decided against this. This is error prone, and even worse, "service 
1539prone". Consider the bug reports on "my printer does not work" if 
1540there is no output, even though there is clearly a redirection to PRT: 
1541in the Shell. It is one of the decisions "you cannot simply do it 
1542right".
1543
1544There is a second strange "gotcha" in the printer drivers for the HP 
1545printers, and this is due to PPaint (Cloanto, do you read?). This 
1546program tries to outsmart the printer driver to allow borderless 
1547printing on some printers, at least. For this, it first reconfigures 
1548the page size to "wide tractor", no matter what the user configured as 
1549page size, and then computes the page limits manually, and prints 
1550"white" in those page areas that are, according to PPaint's 
1551computation, within the printable area.
1552
1553Now, there is no "wide tractor" paper option for the HP printers. Only 
1554A3 and A4, US Letter and US Legal. So the HP drivers have to "outsmart" 
1555PPaint and emulate such a page. Of course, the printer cannot print on 
1556wide tractor settings, but at least it can return the page definitions 
1557such paper would have if it fit into the printer, and this is good 
1558enough to make PPaint happy and let it indicate and let you choose the 
1559correct page size.
1560
1561So, in case you wonder: There is a wide tractor setting in the printer 
1562preferences for the HP printer drivers; but simply do not use. It's a 
1563dummy, just to keep some programs happy.
1564
1565----------------------------------------------------------------------
156624. Icon.library (in depth)
1567
1568I hadn't updated this thread for a while due to lack of time, and I 
1569might have forgotten one thing or another, so here is another tiny 
1570change that will hopefully make life easier: the icon.library.
1571
1572This is a version derived from the 3.9 version, but with two small 
1573changes. For 3.9, the icon.library allowed configuration of the 
1574"maximum filename size" so it knew where to cut off names in case a 
1575".info" file for the icon has to be attached. This feature is gone.
1576
1577Why?
1578
1579Well, actually, it is no longer required, and it was a bad idea. It is 
1580a bad idea because the user hardly knows how long the filenames are 
1581allowed to grow, and even worse, this maximum size depends on the file 
1582system the icon.library is working with, so it cannot be "correct" for 
1583all combinations. If you had an (old) CrossDOS version in the system, 
1584then the filename limit would be "8" (the .info is mapped to .INF by 
1585the 3.1 version of CrossDOS). You surely don't want to set this limit 
1586to "8" just to be able to use CrossDOS.
1587
1588So, new rules apply: icon.library does not limit the filename size at 
1589all. Instead, it now always checks whether or not it can create icons 
1590correctly under the name you give them, and it checks before writing 
1591an .info file whether or not this filename potentially conflicts with 
1592something that already exists on disk--which conflicts because the 
1593filename of the icon and the filename of something else become 
1594identical after truncating to the maximum length. And this truncation 
1595is the job of the file system.
1596
1597So what is the "maximum filename size" in Workbench Prefs good for? 
1598It's really only cosmetic. The only thing it does is limit the maximum 
1599size of the input dialogs Workbench accepts; nothing more. If a 
1600program attempts to create a longer filename, that's all good, 
1601provided icon.library can create such a file and the file is different 
1602from the base (i.e. non-icon) file.
1603
1604When renaming files, Workbench has a heuristic method of truncating 
1605filenames for the "Copy_Of_" renaming of files. It also tests whether 
1606or not it can create a unique name by prepending "Copy_Of_", and since 
1607it cannot test all possible lengths of filenames, it checks for some 
1608typical maximum filenames. 30 characters for DOS\1 through DOS\5, 54 
1609characters for DOS\8 and 106 characters for DOS\6 and DOS\7.
1610
1611So, no need to fiddle with the maximum filename size at all--it's all 
1612automatic.
1613
1614Another change is this "place icons in Fast RAM" setting of OS 3.9. 
1615That's also gone for good. Again, because the user cannot know whether 
1616the graphics system of the screen Workbench is running on supports 
1617this option, as it may depend on the screenmode as well. It's a bad 
1618idea to delegate a decision to a user for something the user, in 
1619general, cannot know, so the switch went away. Instead, Workbench runs 
1620a small test when opening (or re-opening) its screen whether icons can 
1621be placed into Fast RAM--and if so--it simply does it. No need to 
1622configure anything; it's automatic.
1623
1624Finally, how do you move icons to Fast RAM? Well, for graphics cards, 
1625this is what already automatically happens. For native systems, I *do 
1626not* recommend FBlit as this program is known to cause multiple 
1627problems as its patch set is incomplete and has defects. There are two 
1628options: Either, you run the native (AGA) driver of CybergraphX, or 
1629you run the native driver of Picasso96.
1630
1631There is a P96 driver for the ECS/AGA chipset? Yes, there is. Check 
1632Aminet. A relatively recent P96 version is sufficient. With P96 and 
1633this "driver" installed, icons will go to Fast RAM.
1634
1635Frankly, it's not much of a driver, but it does exactly what you want 
1636it to do.
1637----------------------------------------------------------------------
1638----------------------------------------------------------------------