New Kickstart 3.9.1 68k on the way

[olsen]

Did AmigaInc. ever owned the rights?
I thought, they only owned the brand.

I'm sorry, this is not my field of expertise. I could only speculate that if a product is sold which requires the assent of the brand owner, then that assent must have been given. Whoever owns the brands and the trademarks must be public information, and is likely available online. I wouldn't where to start looking, though.

As a sideeffect, the rights and patents are still at escom (acquired by gateway, acquired by acer).

It's been more than 20 years since Commodore folded. Assuming that Commodore was granted patents in that final year, then these patents have likely expired by now.

Gateway was said to have bought the Commodore patents along with the other assets because it allowed them to save money on patent licensing.

How the Amiga's keyboard operates, and how it communicates with the main computer was covered by patents. The IBM PC design was covered by patents (probably still is), and if you wanted to build and sell an IBM PC compatible machine, you needed to pay IBM license fees. That was back when IBM was still building these machines. Funny thing, the way the 1990'ies incarnation of the IBM PC keyboard was connected to the main computer was covered by the Commodore patent for the Amiga keyboard. Instead of having IBM pay Commodore for the use of the patent, the companies traded licenses, and thus saved production costs. Gateway did the same thing as Commodore did.

That Amiga keyboard patent must have been filed in the 1980'ies when the Amiga was new. Which probably means that it has expired around 2005-2006.

There is likely no patent left Commodore used to control which is still valid today. Note that this is a layman's opinion and if you want to be certain, you should call upon an expert in this field.

[olsen]

Anyone willing to do 68000 KingCON ROMable? The things I want in kickstart are the things I want available when booting to shell without startup-sequence.

I do not know if this applies to KingCON, but not everything is fit for inclusion in a ROM. The libraries, devices, file systems and handlers in the ROM (obviously) cannot modify static data or code. However, if such software is loaded from disk then there are no such restrictions. Stranger still, the respective author may not even realize that his software modifies data intended to be read-only (buffer overflows, subtle bugs, etc.), and that his software stops working correctly if that data cannot be modified.

I take it that Cosmos has a solution for that problem. He mentioned that he uses compression to fit more components into ROM. This implies that he can unpack components into RAM as part of the bootstrapping process. Once those components are in RAM they are no longer restricted by the constraints of read-only memory.

So, maybe KingCON can fit into ROM after all, unchanged.

[olsen]

KingCON has been ROMable for quite some time, but only for 020+.

That might be more difficult to fix. Sounds like a partial rewrite/patch to me

[olsen]

WOuld it be possible to integrate CF card drivers somehow? I.E. a way to be able to detect and read CF cards right off the bat without requiring extras software on your boot disk and what not?

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.

[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.

[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.

[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

[olsen]

Why do we have to use fat95 with compactflash.device?

I am sorry, I did not mean to imply that the "fat95" file system were mandatory. It just so happens that it is used in the default setup for "compactflash.device", as available from Aminet.

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.

Short answer: the operating system makes the "default ROM file system" responsible for a volume mounted on a storage device, and changing this default behaviour to pick a file system of your choice instead does not work out of the box.

Long answer coming up

The "compactflash.device" written by Torsten Jager, as available from Aminet, currently cannot be used to boot the system off a CF card. One reason for this is that the "compactflash.device" is not a component of the AmigaOS ROM, and thus does not get initialized as part of the system startup. If you want to access your CF card, then you have to boot the operating system off a floppy disk, a PCMCIA memory card that uses the CC0: device, or a hard disk drive.

Booting off a floppy disk, a PCMCIA memory card or a hard disk drive have something in common.

The operating system knows that floppy disk drives may be available (up to four; could be none) and sets up records which allow the system to boot from them when a disk is inserted: if that disk contains a boot block, it is loaded into memory and is started.

The same basic process happens for PCMCIA memory cards, only there is no boot block (the operating system asks the card "can you bootstrap the system?", and if it says that it can, then it will be treated like a floppy disk with a boot block on it).

A hard disk drive is connected to a controller, and the controller software (say "scsi.device") will begin by checking which storage devices are available, and if they contain partitioning information which tells the operating system where the individual volumes on disk are stored and how large they are. This partitioning information also tells the operating system which file system should be used for the respective volume (FFS, PFS3, you name it). Furthermore, the partitioning information can reference a fully functional file system that is stored along with it, which enables you to boot from a disk which uses a file system that is not already in ROM. The controller software ("scsi.device") collects all the volume information, makes the file systems ready and sets up the records necessary for mounting and booting from the designated volumes.

Which volume or device the operating system can boot from is decided in an operating system module called "strap". This is where the boot priorities of the volumes are checked, and the highest priority boot volume wins (by the way, the "strap" module is the one which shows the "insert disk" animation). When you boot your system, "dos.library" will take control, mount the volumes and disks whose records were prepared before, set up the assignments for the boot volume ("C:", "L:", "S:", "Devs:", "Fonts:", "Libs:"), and starts executing the "S:Startup-Sequence" script, if available.

This is the standard procedure, and if you wanted to boot off a CF card, then the following would be necessary:

- The storage device driver, let's say it is "compactflash.device", needs to be either in ROM or otherwise available at early system startup time.
- "compactflash.device" needs to check early on if a CF card is present, and which record should be used to make it suitable for bootstrapping the system using it. This involves figuring out the CF card size, which file system should be used, and which priority for booting the system from it would be appropriate.
- When the system startup process reaches the "strap" module, both the "compactflash.device" and the file system assigned to the CF card need to be ready to allow the system to boot from it.

That is basically it. This is how CC0: device booting works (hm... does this actually work? I never tested this myself), which the operating system treats like a big floppy disk: it has a fixed size, and it uses the default ROM file system (this would be the FFS). You cannot actually tell the operating system to use a different file system to access the volume at boot time because there is no way to do so (it's a closed design). This is what prevents you from using PFS3 or any other file system to boot from the PCMCIA memory card.

Why does this matter? It would be the same situation for booting off a "compactflash.device" in ROM: the storage device could easily set up the CF card as a bootable volume as long as it makes sure that it uses the default ROM file system.

If you wanted "compactflash.device" to support different, specific file systems of your choice, then it would have to work very much like "scsi.device" in that it would have to support partitioning of the storage medium. That is rather complicated (I wrote hard disk driver software which did this, some 25 years ago), and maybe not what the original author wanted, but it's doable.

[olsen]

Or you need to add additional code which reads the RDB (Rigit Disk Block) from the device, interprets it, bootstraps the filing system, and boots the device this way.

Some more context in case the term "Rigid disk block" does not ring a bell: this is what the "HDToolBox" program in "SYS:Tools" is for. It allows you to manage the partition information, which file systems should be installed, etc. This information is written to hard disk in a specific layout and structure.

This is more complicated, allows partitionas, alternative filing systems... Interestingly, this work has to be done by the device driver, it's not part of the strap functionality.

Yes, and that's a bad thing. The documentation for the partition data, how to read the contents correctly, etc. is quite good and robust, but it's possible to introduce your own subtle or less than subtle bugs if you have to write the code all by yourself. To the best of my knowledge there exists no reference implementation for processing the "Rigid disk block" contents at the device driver level.

Looking at how popular writing device drivers and file systems in 100K+ lines of 68k assembly language seems to be today I'm getting somewhat worried about somebody trying to do this and getting lost in testing the implementation

[olsen]

How does booting from CD drives work, in comparison? CDTV and CD32.

It's the same principle as for booting off a floppy disk. The "strap" module does more work here, though. It shows a much more elaborate "insert disk" animation, for a start  Hey, it even has a built-in screen saver.

Instead of just polling "trackdisk.device" and "carddisk.device", the "strap" module also watches for CD medium change events. For the CDTV and CD32 that would be "cdtv.device", if I remember correctly.

If a CD medium change is detected, "strap" talks to "cdtv.device" in order to figure out if the disk is a CD-ROM or an audio CD.

If it's an audio CD, then the player GUI is opened which tends to the playback operation (with can include MIDI audio output or CD+G animation for disks which support this).

If it's a CD-ROM then "strap" asks "cdtv.device" whether the disc is bootable. For this purpose the "cdtv.device" accesses data on the disk without going through the ISO 9660 file system, if I remember correctly.

For a CDTV or CD32 disk the "cdtv.device" expects to find data which was woven into the disc layout through the ISO image mastering process using proprietary software. That data shows up as the "CDTV.TM" file located at the root directory level of the disk. If that file checks out (merely copying it to the root of an ISO image file is not sufficient), then the CD-ROM is deemed bootable, the "CDTV.TM" file is loaded and run. I believe its purpose is more or less equivalent to the boot block of a floppy disk.

Anyway, the "strap" module itself associates the ISO 9660 file system with the CD-ROM drive, just like it sets up the "carddisk.device" and "trackdisk.device" mount records.

I haven't looked at the documentation for a while, so I may not be exactly right about all the details. In any case, the overall design fits in with what the existing operating system (Kickstart 1.3 for the CDTV and Kickstart 3.1 for the CD32) already does. Aside from doing quite a bit more in the "strap" module, it's just "another day at the office"  I forget the details, but one of the driving forces behind the CDTV design and perhaps *the driving force* was Carl Sassenrath, who architected the original Amiga operating system. If you look at the CDTV system design, it's very elegant in how it builds upon what is already in the Amiga operating system, and the new CDTV-specific firmware is as clean and impressive an implementation as you should expect from Carl Sassenrath.

Not to gloat, but Philips had a much harder time building the CD-I using a standard real time operating system. The CDTV did much better, technically, even though Philips had very deep pockets and Commodore (in true Commodore fashion) kept its budget much, much smaller. Neither system, and not even the CD32 found their respective market at the time of release. That had to wait until Sony showed everybody how you *really* build and market a CD-ROM based home entertainment/game console.

[olsen]

Yes, thanks for history lesson Only want to point out that CD32 actually came with kickstart 3.1, it was the first and AFAIK only product before CBM collapsed with 3.1 from the day it shipped

Blimey, one always gets something wrong

[olsen]

Do you really intend to put entire OS in kickstart? And boot from what, a RAD disk?

Good question

There are actually did exist a modification of the Commodore "ram-handler" component dubbed "romdisk" (written by Mike Sinz).

It allowed you to put a preconfigured file system image into ROM. Unfortunately, this was a file system, not a "ramdrive.device"-like component, and thus did not support auto-booting. If this did exist (a "romdrive.device") then just maybe you might not even need a disk drive or CF card, just the Kickstart ROM.

Imagine that: you could just boot off the ROM itself, which could contain as much data as would be needed to run a minimal Workbench, space permitting.

[olsen]

I can think of one good reason - backwards compatibility with existing floppy based software (even some games).
Without those two library's these disks would not boot anymore...they would hang as soon as the LoadWB command is run and a requester saying something like "Unable to open workbench.library" would appear. Same goes for icon.library. It would only serve to confuse users...

The A4000T Kickstart ROM, which for lack of space does not contain a "workbench.library", contains a special component "wbfind" whose single purpose it is to locate "workbench.library" on any currently mounted volume at the time the system startup attempts to open that library. Thus, if you boot off a disk which does not contain "workbench.library", opening the library will trigger a search on your hard disk (unless you chose not to mount it through the early startup menu).

Leaving stuff out of the ROM which can be loaded on demand from disk is possible, at the expense of allocating additional memory for it. And it might take 2-3 seconds to load the library, which you probably won't notice because Workbench starting up causes additional disk accesses which take longer than loading the library itself.

[olsen]

Yes, I remember reading about that. I also vaguely remember some solution to boot off network filesystem, with one specific zorro NIC that had some boot functionality? Hmmm.

I believe that this was the Hydra Ethernet card, but I may be wrong.

Booting off the network is doable, but there are technical constraints. For a start, the network hardware needs to be operational very early on, which rules out almost all Amiga SANA-II drivers, since these expect to be loaded from disk (e.g. they check environment variables for medium/connection options, which requires that dos.library is already open).

If you can work around that problem (e.g. support only a single specific hardware) then your best chance to make the boot process work might be to use UDP datagrams to both configure the local network address (bootp is simple enough) and find the server to boot from. You'd also have to support ARP.

You'd have to implement client and server for the file system to use, which could also use UDP for communications. Commodore's peer-to-peer networking service "Envoy" did all of that (although the protocol for performing UDP retransmissions could have worked better).

Let's say all of this worked. Then you'd have diskless booting, from a file system server, at about 1MByte/s (probably less). No idea how fast your typical A1200 IDE drive performs by comparison, but I expect it's noticeably faster than what Ethernet can provide.

Now if all of this worked, you might have a problem with using a TCP/IP stack, since it would duplicate functionality of the networked file system and compete for UDP datagrams and ARP packets. This was a problem for Envoy, too. This problem could be worked around, though.

[olsen]

The reason why I'm against that ROM-idea is simply because it does not allow users to exchange components. If I have to fiddle-open my machine every time I'm updating a component, chances are better than even that I'll break the ROM socket at some time. A minimal bootstrap ROM could be very stable and would not require a lot of updating. Everything else can be placed on flash, and can be upgraded easily by writing on a regular file system.

The reason why I am skeptical of moving components and in an out of ROM space is that the approach is beholden to 1980'ies/1990'ies design constraints which no longer apply today.

When the original Amiga was designed RAM was still very expensive, the 68000 CPU was in the sweet spot of being both fast and not too expensive (as compared to the 68010/MMU or 68020/MMU combination which Sun Microsystems used in the Sun 2 and Sun 3 workstations), and the common storage medium was the Sony 3.5" double-sided floppy disk.

Loading the ROM operating system components from disk was expensive: the memory required (256 KBytes) cost real money back in 1986. Commodore had to work on producing a cost-reduced design, and switching to a ROM was inevitable.

Loading operating system components from floppy disk was slow (even on the original 64K Apple Macintosh, which arguably had even worse disk performance than the Amiga, at half the storage space -- did you know that it would either compress data in memory or swap it to disk in order to make that 64K memory budget possible, at the expense of killing system performance?), which meant that you could get a performance boost out of sticking as much into the Amiga Kickstart ROM as possible. And this is exactly what happened. Consequently, the Amiga had one of the largest ROMs for personal computers at the time.

Today we have much cheaper, and more RAM available. The primary storage device is no longer the floppy disk, but a hard disk or SSD. Thanks to the modular design of the Amiga operating system almost everything in the ROM can be replaced later at run time at the expense of committing it to RAM. It's technically possible to have your Amiga load replacements for the components in ROM once, reboot, and then run with all new components. This will survive a warm reboot, and it even works on a machine which has no MMU.

So... why cram everything into the ROM? To save the initial cold boot, load and reboot? Your Amiga can probably do this more quickly than you can say "Supercalifragilisticexpialidocious".

[olsen]

Haven't you been able to contact Heinz Wrobel? Jens spoke to him quite "recently".. well... two years ago. However, you might want to ask him for an email adress or a telefone number?

Contacting Heinz is not the problem, trust me. Having known Heinz since 1995 (we met on what developed into a consulting gig for what became Amiga International GmbH), I expect him to lend his support only to project work which proves to be legally and technically on sound foundations.

His work on the Amiga operating system components, which includes the FFS, the mass storage drivers and more, builds upon existing code which is not owned by him. How the rights of the owners affect what he could do with his work needs to be clear before he could be expected to lend a hand.