New Kickstart 3.9.1 68k on the way

[olsen]

...

- added mathieeedoubtrans 45.6
- added mathtrans.library 37.2

These two libraries are used extremely rarely, and then only by disk-based applications which already take their time loading and running. Software which requires high performance math uses inline FPU instructions, and not this.

There is very little benefit of putting these two libraries into ROM, and you may find much better uses for the space occupied by them.

[Cosmos Amiga]

These two libraries are used extremely rarely, and then only by disk-based applications which already take their time loading and running. Software which requires high performance math uses inline FPU instructions, and not this.

There is very little benefit of putting these two libraries into ROM, and you may find much better uses for the space occupied by them.

The mathieeedoubtrans.library is important because of his sin & cos... Compilators must use it for getting only one programm for all 020+ (the 68060.library patch this mathieeedoubtrans.library).

I don't want see anymore many versions _020, _040 and _060 of a same programm, it's lame...


This mathieeedoubtrans.library is 8.1 Kb, so I keep it. And the mathtrans.library is only 2.7 Kb...

[bloodline]

Sorry, but not in a real Amiga, over there, it is crappy shame.

In x86 or high speed emulation it is pretty good and I can agree that it surpasses 3.1. But in an Amiga is a big "NO".

The big hole in AROS 68k is the graphics library, which has no Amiga specific "Hardware Acceleration". But, in case you have forgotten, Cosmos likes to take some 68k source and then optimise it... What better candidate is there than AROS!? There are no licence/copyright issues, he has access to the original C source and it need optimising for the 68k... It's basicly cosmo's Dream come true!!

[olsen]

The mathieeedoubtrans.library is important because of his sin & cos... Compilators must use it for getting only one programm for all 020+ (the 68060.library patch this mathieeedoubtrans.library).

Yes, it's important for applications which cannot use inline FPU instructions, and actually use the transcendental math libraries (if I remember correctly, most applications used the compiler-supplied link libraries instead; the only serious user of the IEEE math libraries was ixemul.library).

This doesn't change the fact that these libraries are extremely rarely used, which is one of the reasons why Commodore put them on disk.

Optimizing code, like optimizing space, is in finding the best leverage your choice gives you. If you stick these libraries into ROM then you're making it a little easier for old "Imagine" and whatever software falls into the same domain on 68000/68010/68EC020/68030 (without FPU) machines to start and run. That's very little leverage you get out of including these libraries.

If there's room, well, then no harm done. But the point will certainly come when you need to make harder choices on what is a good fit for the ROM and what could go and stick to being disk-loaded instead. The transcendental math libraries are prime candidates here.

[guest11527]

This brings us back to the start! Replace the old stuff with the new stuff and you eliminate the reboot patch. Perfect sense.

This is pretty much what I say. Nothing requires patching anything. What had to be written is only a small bootstrap loader that loads the libraries, devices and resources that are usually in ROM from the flash, and off you go. The bootstrap loader could be put in ROM, but would not require regular updating, unlike the system libraries which could be maintained independently. This is a much more flexible approach than any other "ROM update". It would boot rather quickly, and would allow system components to be upgraded without ever touching the ROM based bootloader. Simpler, easier, quicker...

[guest11527]

The problem with the math libraries is worse, actually. The math libraries do not work "out of the box", they require CPU specific support. Actually, using the FPU requires CPU specific support, this is what the 680?0.libraries are good for. It is more than adding support for unsupported instructions - it is support for "non-normalized" IEEE numbers. IOW, if you want to use the IEEE code, *or* the FPU, you need the 68060/68040 library. Just "not using unimplemented instructions" does not help here at all - "unimplemented data formats" also exist.

Now, to make things worse, the 680?0.library is in general board specific because it uses, in general, a board-specific setup logic, and a board-specific MMU table. That's the whole reason why ENVARC:MMU-Configuration exists, why P5Init exists, and why the stuff must be reachable for the user, on disk. There is no clear "detection logic" that would work independently from the board the logic runs on.

IOW, if you want a stable setup, you must give the user a chance to install the libraries that are "the right ones for the board". Freezing them in ROM will just break some setups. Actually, some boards even have the 68060.library in their own extension space....

[olsen]

The problem with the math libraries is worse, actually. The math libraries do not work "out of the box", they require CPU specific support. Actually, using the FPU requires CPU specific support, this is what the 680?0.libraries are good for. It is more than adding support for unsupported instructions - it is support for "non-normalized" IEEE numbers. IOW, if you want to use the IEEE code, *or* the FPU, you need the 68060/68040 library. Just "not using unimplemented instructions" does not help here at all - "unimplemented data formats" also exist.

To add some more grist for the mill: there are several variants of the ROM-based mathieeedoubbas.library which need to be handled with care. One works on all 68k systems but does not use inline FPU operations, one works on everything that has an 68020 CPU or better installed but does not use inline FPU operations and one works on the A3000 where it assumes that both an 68020 CPU or better and an 68881 FPU are installed (no, it doesn't check if the hardware is there).

Take your pick: cramming all three into ROM is probably bad idea because it wastes lots of memory for no tangible benefit, and choosing just one of the three forgoes any optimizations that might be available on more powerful systems.

Then there's the collection of mathieeesingtrans.library, mathieeedoubtrans.library, mathieeedoubbas.library and mathtrans.library. All four normally reside on Workbench, and the first three automatically either use FPU operations or fall back onto software-based numeric operations. mathtrans.library is the odd one out here, since it complements mathffp.library in ROM. Both mathffp.library and mathttrans.library use Motorola's proprietary fast floating point math code, which used to be the only floating point support library which Commodore-Amiga could ship in 1986. The (roughly) portable IEEE math libraries followed with Workbench 1.3 in 1987.

What actually deserves to be in ROM is, for backwards compatibility reasons, is mathffp.library. There is no real benefit here except backwards compatibility for software built almost 30 years ago which wasn't updated in the last 28 years, and probably crashes today on a stock Kickstart/Workbench 3.1 anyway.

The remainder of the IEEE floating point libraries should be on disk for three reasons.

The first is that the quality of the implementation is not quite so good by today's standards. That code is actually more than 30 years old by now. If these libraries remain on disk you have at least a chance to replace them with better variants.

The second reason is that the operating system and the 68040.library and 68060.libraries need to patch the hell out of these libraries because they don't play nice with these CPUs. These patches are disk-based and kick in at SetPatch time with the CPU card boot roms plastering their own band-aids on the library in ROM. There are several kinds of 68040.library and 68060.library by various makers, and some are doing more patching than others. You can't cram all this into ROM or hope to catch them all under one umbrella.

The third reason is that older machines with old CPU/FPU accelerator boards (A2000 and friends) may do their own strange stuff to configure the FPU and hook into the operating system to do their own FPU state save/restore operations. These may even ship with their own specific versions of these libraries, and this stuff is easily broken.

In so many words, the math libraries are a sticky bundle of assorted troubles. Some of this could be resolved by testing and making changes as necessary, but I doubt it's a worthwhile exercise for so little gain. Anyway, if you're looking for trouble, look no further than these libraries

[Cosmos Amiga]

Hey, again I repeat : I wanna a full and complete Kickstart ready to yell at power on...

If you like waiting for loading Workbench from HD or CF, me no...

If you like the 68040/68060.library installation on HD, me no...

The Workbench, years after years, become like Windows with his updates KBxxxxxx now : you need to install MUI, 680x0.library, RTG system, some patchs like Birdie or MagicMenu, some datatypes, and other I forget...

Sorry, but I don't like that... I want a computer fully operational at power on... Final point !

[guest11527]

Sorry, but I don't like that... I want a computer fully operational at power on... Final point !

Well, as already said, there are multiple CPU libraries out in the world, and they are pretty hardware and vendor dependent. Olaf already said this.

But anyhow. Here's a deal. I'm happy to provide my versions, and make them even ROM-able if you can get them to work on *all* hardware variants you get. This is, in fact, the major show-stopper of placing anything of this in ROM since it creates a kickstart that will no longer work on some boards.

My current libs work on pretty many, but not all of them, mostly because some vendors did not publish what kind of support they need in their code. To give you some idea where the trouble is: All the P5 PPC boards do not play nice because their libraries include some vendor specific code that remained undocumented. Some SCSI controllers go directly to the MMU list, without using the appropriate Os functions (CachePreDMA, CachePostDMA), causing trouble with any other program working the same resources.

Thus, *IF* you really want to go this route, let me know. What I can certainly give you is the code of P5Init, which is only "half of the deal" (it performs *some* P5 specific initialization, but it does not include the P5 library interface, whatever this may be). Once you tell me that you understand the P5 interface logic and have a description ready how *that* works, I can give you even more.

[wawrzon]

Originally Posted by Cosmos View Post
Sorry, but I don't like that... I want a computer fully operational at power on... Final point !
Well, as already said, there are multiple CPU libraries out in the world, and they are pretty hardware and vendor dependent. Olaf already said this.

But anyhow. Here's a deal. I'm happy to provide my versions, and make them even ROM-able if you can get them to work on *all* hardware variants you get. This is, in fact, the major show-stopper of placing anything of this in ROM since it creates a kickstart that will no longer work on some boards.

aros 680x0.library has worked so far on everything i got. it isnt much but i have a choice of essential expansions here. the library isnt in rom, but setpatch loads automatically the necessary patches after hardware recognition. for me it is the closest to the one for all solution i see for amiga.

[Gulliver]

This is pretty much what I say. Nothing requires patching anything. What had to be written is only a small bootstrap loader that loads the libraries, devices and resources that are usually in ROM from the flash, and off you go. The bootstrap loader could be put in ROM, but would not require regular updating, unlike the system libraries which could be maintained independently. This is a much more flexible approach than any other "ROM update". It would boot rather quickly, and would allow system components to be upgraded without ever touching the ROM based bootloader. Simpler, easier, quicker...

This is an ideal solution. In these days of fast HDDs and SSDs it is not good to be relying in roms except for bootstraping. Not every user has an rom burner!

Anyway, I only see a minor fixable problem with this aproach. Certain old bootable Floppy disks that require accessing some rom modules for the running of their programs, and even when no HDD is available will fail. This could be solved by having an early boot menu option to softkick like Thomas Richter mentions, (this should be enabled by default) or to boot the built-in legacy kickstart rom (which could even be compressed to save precious space on rom).

Another missing feature in rom is the possibility of having a simple serial transfer program for the cases when users lack bootable workbench floppies. So that with this program they could connect thru rs232 to any pc terminal program and receive an adf/dms file transfer containing a bootable image that could be written back by this program to a new non formated floppy disk.

Well, one could dream

[kolla]

A plain and simple no-nonsense kickstart, with scsi.device and filesystems that grasp big disks, that is all that most people really want. To boot strap. Not the entire OS in a slow to read ROM chip! Luckily creating custom kickstarts has become easy (one could even offer a web service to do it), and with some luck, flash based ROM replacement kits will finally emerge too, so one can easily upgrade kickstart on real classic hardware too. Personally I am going the FPGA route.

[paul1981]

I had a quick look at Torsten Jager's "compactflash.device", and I think that there are no technical reasons why it could not be put into ROM.

The harder part is in mounting the file system (such as Torsten Jager's "fat95"), and mounting it early enough so that it becomes available at boot time.

As far as I can tell the "fat95" file system is not suitable for ROM use, but small changes might make it so. I did not check, but if I remember correctly the "CrossDOSFileSystem", which would serve a similar purpose, is not fit to be put into ROM because it was always intended to be loaded from disk. So a modified "fat95" file system suitable for ROM use might be the only option right now.

That leaves the somewhat nontrivial matter of mounting the "CF0:" device. It's doable, though: "carddisk.device" in the A600/A1200 ROM is capable of it, and you can even boot off the volume once it has been mounted, if I remember correctly.

Why do we have to use fat95 with compactflash.device? Why can't we use our CF cards with FFS, PFS or SFS? Am I missing something here? If I wanted to boot differing Amiga OS's/configs from differing CF cards then why would I want it to be using FAT? I don't want to use FAT, except when exchanging files with my Windows PC.

[kolla]

You are not missing anything, there's no good reason to use FAT unless you use a windows PC to prepare the card.

[guest11527]

For a quick moment, I want to come back to the math libraries. As Olaf already said, they are rarely used, but for floating point intensive applications, it does make a difference. FPU intensive: JPEG decoding is one nice example where a FPU is beneficial. I haven't had the time to compile my JPEG on Amiga, thus I took the freedom of choosing another benchmark to show the point - Mandelbrot computation. Here I have a program available (DMandel) which comes with various (assembler optimized) computing kernels, IEEE Doubbas, and FPU (and others). Everthing on my 68060@50, note that IEEEDoubBas *also* uses the FPU, but requires register ping-pong to do the work.

Numbers for a zoomed in Mandelbrot: With IEEEDoubBas: 5:15 minutes, with raw FPU, 1:15 min. I believe that's a non-neglibigle difference. I'm usually not much a fan of "optimizing pointless register moves away", but when it makes a difference, it makes a difference. It is probably an artificial benchmark, but it shows one thing: If you *need* to do numerics, it's probably best to go directly on the FPU.

[trekiej]

uaes  is the Ultimate Amiga Embedded System.
I would like to see amiga os not need the amiga chipset, maybe as  a separate os.