New Kickstart 3.9.1 68k on the way

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

[kolla]

Whatever happened to pOS from ProDAD?

[slaapliedje]

Whatever happened to pOS from ProDAD?

Good question!  From everything I've heard/seen of it, it looked sweet.  I could have sworn I tried it out at one point.  I think I had seen a beta disk of it somewhere.  

I also think Scalos could use some improvements.

Back on topic; it would be SO nice to have a new kickstart so that there aren't so many BoingBags to install after an initial setup.  I had always wondered if it would be somehow possible to have a replacement ROM kit that added EEPROM capability.  I know on the old Atari ST, I would have killed for that.  

Then all we'd need is a firmware update program, and wouldn't have to patch things in startup-sequence, requiring a reset.

slaapliedje

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

[guest11527]

To make the story shorter: Either you use "floppy like" booting, no partitions, bootblock, and FFS/OFS on the device (booblock booting). That's as far as the device is concerned, the easier option.

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

Why FAT came up here I don't know. Bootblock booting is OFS/FFS all the way.

In either case, it would require one additional ROM module, namely one that hooks in before the Shell is bootstrapped, and the purpose of this module would be to replace the ROM "dummy" elements (intuition, gfx, layers, - you name it) by the software solutions from the boot device. Once these modules had been loaded and installed, booting would continue regularly.

The reason why such dummy modules would be necessary is because there are dependencies between the filing system and "seemingly unrelated" system components such as intuition. FFS requires intuition for requesters, for example, and the "dummy version" would probably just show a red screen if booting fails.

Anyhow, a "library hot swap" mechanism would then be needed, i.e. a method how the "dummy" ROM version could be replaced by the real version without going through a reboot. I haven't tried this, and it might require some care, but it might be 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

[kolla]

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

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

[kolla]

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

[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

[Cosmos]

The A3000 is very special .. the ONLY rom with real FPU-code inside !!!

I just checked the A3000 version of the mathieesingbas.library : it's the same than the A1200 version, without the integer part. Only the floats are present. So my new version is compatible with all Classics.

A3000/4000 includes "bonus" for onboard fastmem

I will include them in my exec.library

A600/A1200 includes some PCMCIA-code.

My exec.library is unified for all Classics since a very long time now. The specific PCMCIA code is skiped if A3000 and A4000 detected

[paul1981]

Blimey, one always gets something wrong

Yeah...maybe it's time you threw in the towel Olsen? :laughing:

[Cosmos]

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.

The first thing to do is to take the 68060.library and patch it if a 68040 is detected : stack frame, mul64 removed and div64 removed... Easy to do I guess : this little trick will save about the 43 precious Kb of the 68040.library...

After that, I have the specific 040/060 code from P5 : I will use it, I know the authors will yell, but I cannot see any other solution...

This new 68060.library will be packed of course and only depacked in ram if a 040 or a 060 is detected !

(the crunching ratio is very good with the 68060.library 43.1 : about 60,5%... Unpacked 64,8 Kb and packed about 25,6 Kb !!)



This new kickstart is for me the very last chance of the Amiga Classics. Must be fantastic. If I fail, it will be the very end of our beloved computer...

[kolla]

Explain again why you have workbench.library and icon.library in kickstart.

[kolla]

So if you fail, you will give up on Amiga?

[kolla]

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