Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks  (Read 17192 times)

0 Members and 1 Guest are viewing this topic.

Offline kolla

Ah, and you know what "most users want"?
You know that I consider "most users" a myth, an excuse to cling on to when "developers" run out of real arguments :)
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS
 

Offline psxphill

This is neither related to SKick, as - again - SKick maps the ROM to RAM, though with relocation information - but mapping a compressed image to some place makes neither sense.

How is it not related? Both load the kickstart from somewhere into RAM, whether it's from floppy, hard drive or a compressed ROM. I'm not sure I'd bother compressing it into ROM, but I have and would load a kickstart from floppy and hard drive.

One way or another, this is not a good option. It requires more RAM, not just the decompressor, and as most users use hard disks anyhow, it is much simpler to load the modules missing in ROM from harddisk instead. It also makes the kickstart more flexible.

It's a good option if you want to be able to load different kickstarts but don't have an MMU or hardware that lets you load kickstart from disk in another way. It's more flexible than being limited to one version of kickstart.

For the limited use case that you are arguing against then I agree, but that doesn't mean that I wouldn't load kickstart into RAM in other situations.
« Last Edit: November 02, 2019, 01:32:59 PM by psxphill »
 

Offline paul1981

Yes, they even use Lha from what I recall. However, the Amiga kickstart, is not the equivalent of a BIOS, and when did you last see a BIOS that was 512kB? :)
Um... today? 512KB BIOS is common on 200x era PCs.
Quote
What I suggest is to keep the Amiga kickstart small yet functional - strip the "user interface" parts (shell, workbench.library and icon.library) to their bare minimums, enough to boot and work with legacy floppies. They can be replaced with feature rich on-disk variants when booting off hard drives.
This is also not a bad idea. In your list graphics.library and intuition are the biggest chunks, and their only use before booting is what, the early startup menu where you get to pick between NTSC/PAL, etc.?

No, their real use is after booting. Removing them will completely break nearly all existing AmigaDOS software when booting from floppy disk. I don't believe that would be much of a selling point.
Loading the modules from hard disk would have to be done before booting from floppy. I wonder if this 'list of modules' could be stored on a designated RDB? Or at least a flag on the RDB which tells Kickstart that 'Modules are on this drive/partition!' The Kickstart could then look for valid modules on that drive and load them, all before the system comes ready...so no reboot would be required and it's all done before even booting from the hard disk (ie. even before the Startup-Sequence). This way, from a cold boot you could still load that old floppy software up and it would work. I envisage the bootmenu could control these modules too (able/disable). If no hard disk is found (and thus no modules) then it could search for modules from floppy in 'Devs/Modules'. If that isn't found, then that's the users fault.
I wouldn't remove anything from Kickstart except something insignificant to make room to implement the above (Thomas has a few candidates, but I don't agree with audio.device being removed).
 

guest11527

  • Guest
Ah, and you know what "most users want"?
You know that I consider "most users" a myth, an excuse to cling on to when "developers" run out of real arguments :)
Then why do you come up with such a fake argument to begin with?
 
The following users thanked this post: Tygre

guest11527

  • Guest
How is it not related? Both load the kickstart from somewhere into RAM, whether it's from floppy, hard drive or a compressed ROM. I'm not sure I'd bother compressing it into ROM, but I have and would load a kickstart from floppy and hard drive.
Because it is an entirely different mechanism. SKICK attempts to guess how to relocate binaries, with an additional patch file that was "hand generated". LoadModule, and System-Startup work by standard HUNK files that carry relocation information within them. Thus, no MMU is needed for disk-based modules, and no guesswork is needed for relocation, and the format is a standard binary load format.

It's a good option if you want to be able to load different kickstarts but don't have an MMU or hardware that lets you load kickstart from disk in another way. It's more flexible than being limited to one version of kickstart.

For the limited use case that you are arguing against then I agree, but that doesn't mean that I wouldn't load kickstart into RAM in other situations.
LoadModule,SKick and System-startup have different purposes, so it is hard to compare. SKick replaces an entire kickstart blob (in a rather hacky fashion, requires hand-generated patch files). LoadModule replaces isolated modules from disk, requiring a reboot. System-Startup updates ROM modules from RAM without requiring a reboot, loading them from disk as needed.

Offline kolla

Ah, and you know what "most users want"?
You know that I consider "most users" a myth, an excuse to cling on to when "developers" run out of real arguments :)
Then why do you come up with such a fake argument to begin with?
I was not the one who brought “most users” into this, you did. And at the same time you use “low end systems” as an argument as well. Well, what do you know? Did you conduct a survey or something? I find the way 3.1.4 (and now 3.2) is being developed and delivered very questionable, lots of rather strange decisions are being made “behind closed doors” and that is why this very thread exists in the first place - if you cannot watch others having opinions about the project, then ignore this thread and stick to your own.

What I can tell is that I have seen more than once people be confused about not being able to boot into workbench from floppies and disk images that worked well earlier, both programs and games. You can perhaps count on A4000T systems having hard drives, but for a500/a600/a1200/cd32 there are plenty of people who just swap between various cf or sd cards for “hard drives” and use gotek as floppy drive. And such systems are better off with plain old 3.1 kickstart at this point, as 3.1.4 introduces a number of problems.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS
 

guest11527

  • Guest
I was not the one who brought “most users” into this, you did.
Read your post #43.

And at the same time you use “low end systems” as an argument as well. Well, what do you know? Did you conduct a survey or something? I find the way 3.1.4 (and now 3.2) is being developed and delivered very questionable,
As in what? I gave reasons, you ignored them and washed them away because you like to complain? That technical experts make decisions in product development as all over the world, in all professional products, and your opinion isn't received? (Which is, by the way, a decision you made.) That software development is not a democratic process where you replace experience and workforce by a count of noses?

Kolla, I'm a firm believer in democracy, but I'm not a firm believer that this principle carries over into product development. This is not an open source product, and it is not supposed to be.  The market decides whether a product is good or bad, whether it sells or not. This is how the world works.

Don't like it? Then don't buy it.  That is how the world works. I can deal with that. Actually, every company would be happy to *not* have people like you as customer. If another compromize would have been made, you, yes *you in particlar*, have had other complains. I bet.

lots of rather strange decisions are being made “behind closed doors” and that is why this very thread exists in the first place - if you cannot watch others having opinions about the project, then ignore this thread and stick to your own.
If Microsoft develops windows, those decisions are also made behind closed doors. If Apple develops ios, those decisions are also made behind closed doors. For good reason - such discussions are made between developers that understand the technical background, and that are willing to work to make something happen.

It is good industry practise not to open up everything, because if you put every detail into discussion, you would end up nowhere or a pile of incompatible stuff that does not fit together, a lot of discussions (as this one) that do not drive the process, and does not help to get anyone anywhere.

It is of course also good industry practise to listen to customer voices, which happens here. Customers, note well! But it is also good practise to ignore whiners, complainers and nay-sayers - because you are complaining out of principle, and not out of the motivation to create a better product.

You don't like the product? Well, do not buy it. This is how the world works. I believe every serious company would be happy not to have a customer like you.

What I can tell is that I have seen more than once people be confused about not being able to boot into workbench from floppies and disk images that worked well earlier, both programs and games.
I already told you. It doesn't fit, and 1MB is not an option either because that also causes incompatibilities. It is neither an option for the ECS machines. I told that about 1000 times, you wash that away - you don't want to understand the reason. Compression is not an option either because it costs in the end 512K more RAM to begin with.

Every Os development is a matter of making compromizes of some sort. 3.1.4 is not different, and 3.2 is not different either. The compromize that was made was: You going to boot from harddrive, you have a little bit more RAM (1.5MB), you have the same computing power (68K is enough). This is in good tradition to the way how the A4000T ROM was built, and in that sense nothing new. We even offered two different upgrade paths, so left choices to the customer.
The compromize being made was a much smaller one than that of 3.9. Which required more RAM, a more powerful machine, a double boot, a 68020 at minimum.

Every other decision (1MB ROM, compression) would have meant *other* compromizes, with other drawbacks. There is no silver bullet that addresses e very need, and you cannot make everybody happy. And nobody can make you happy, but we know that already, don't we?

Concerning games: Games fall into two cases: Either, it boots directly into the game, then the workbench is not needed. Case closed. Or it uses the workbench - but then it is system friendly and hence has access to the harddrive. And, woha, by pure magic, it finds the workbench, even if you boot from disk.  Harddisk: Yes, that is part of the compromize.

So, in fact, the problem you claim to exist does not exist in realitiy, and I haven't heard about any user claiming that game XYZ did not run due to the decision of off-loading two ROM components (that have been off-loaded before). Except your "out of principle" whining.

Oh, just shut up...

You can perhaps count on A4000T systems having hard drives, but for a500/a600/a1200/cd32 there are plenty of people who just swap between various cf or sd cards for “hard drives” and use gotek as floppy drive. And such systems are better off with plain old 3.1 kickstart at this point, as 3.1.4 introduces a number of problems.
And yet, you can boot from disk, provided the workbench.library and icon.library are on it. So, nobody is harmed. And if those people feel more comfortable with 3.1, then so might it be. A 1MB kickstart would not fit into the ECS systems anyhow, and you cannot fit more features into the same ROM and RAM footprint. Just does not work.

 
The following users thanked this post: Tygre

Offline kolla

What is your goal with these essay long rants here Thomas, closing down this thread? I was requested to open my own thread about my issues, so I did, only to find it littered within a few hours about rather irrelevant discussions about booting from CD drives and 1MB kickstart roms...

It is perfectly doable to fit variants of workbench.library and icon.library in a 512kB rom. Note that I didn’t argue for 1MB rom, I just find some of your arguments a bit far fetched.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS
 

Offline kolla

I was not the one who brought “most users” into this, you did.
Read your post #43.
Read your post #42.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS
 

guest11527

  • Guest
It is perfectly doable to fit variants of workbench.library and icon.library in a 512kB rom. Note that I didn’t argue for 1MB rom, I just find some of your arguments a bit far fetched.
No, it is not. There is not enough ROM space. Not even close. With all other extensions, we have currently about 16 to 32K free, depending on the machine. This is not remotely enough to fit anything close to a workbench into the ROM. The scsi.device grew by quite some amount (>4GB support) the FFS grew for the same reason. The shell grew. Graphics grew (consistent code for all machines), utility grew (68060 support), mathieeesingbas grew (same reason), intuition grew (window movement). Even with original 3.1 workbench and 3.1 shell and 3.1 icon and shell, and without wbfind/system-startup (which you would need to load a new workbench from, so one cannot get rid of it), the code does not fit anymore, so please do not make anyone believe it might.

You have probably no idea how tight the 3.1 ROM is. It only worked because CBM added some additional tweaks (open libraries by tags, OpenDevice(NULL...), only 68020 code for some machines), and it did not work for the A4000T at all.

guest11527

  • Guest
when booting from floppy disk. I don't believe that would be much of a selling point.
Loading the modules from hard disk would have to be done before booting from floppy.
Well, this is pretty much what System-Startup does in 3.2. The problem is, you cannot really load anything from harddisk without the modules initialized you need to run the harddisk, which is already quite a bit. Actually, exec, expansion, timer, misc, disk, utility and dos are needed, also graphics and intuition (and probably some other minor ones I forgot).

I wonder if this 'list of modules' could be stored on a designated RDB? Or at least a flag on the RDB which tells Kickstart that 'Modules are on this drive/partition!' The Kickstart could then look for valid modules on that drive and load them, all before the system comes ready...so no reboot would be required and it's all done before even booting from the hard disk (ie. even before the Startup-Sequence).
I wonder what the benefit of this would be. The only additional module you need to load them from the regular file system is the file system, and *that* can sit in the RDB anyhow by tradition. The drawback of having modules in the RDB is that you do not see them, you also need dedicated tools to manipulate them there, and you run into potential compatibility issues with the firmware of the drive - which is responsible for handling the RDB (and not the kickstart, note well!).

So, in a sense, we are with 3.2 exactly where you propose us to be, except that there is a "default module" in  ROM as well, which can be overridden by a RAM module. This only works for modules that are not initialized for accessing the harddrive, of course (intuition is some special exception, but the 3.2 intuition received a new feature, namely it is able to be shut down afterwards for getting replaced). And except that the modules are stored in the regular file system, so they are easy update and manipulate.

The only components you could remove from ROM because they non-essential for booting are mathffp,mathieeesingbas and audio, but again, some firmware might depend on them being available for their boot process because they have been in ROM, so I was really hesitating to make the change. They can be updated by System-Startup, of course.

There is no fine-control for this, but there will be an on-off switch in the boot menu to avoid trouble in case you accidentally trashed one of the replacement modules on disk, i.e. there is a fail-safe fall-back mode "rom boot only" mechanism. User programs could jump in to create a per-module switch, simply by renaming compoents on disk.

Offline psxphill

Because it is an entirely different mechanism. SKICK attempts to guess how to relocate binaries, with an additional patch file that was "hand generated". LoadModule, and System-Startup work by standard HUNK files that carry relocation information within them. Thus, no MMU is needed for disk-based modules, and no guesswork is needed for relocation, and the format is a standard binary load format.

I think you misunderstood my post. You appeared to be saying that skick wasn't related to compressed kickstart, I was saying it was.
Without MMU you would need to allocate ram to decompress kickstart and so it would need to be relocated.

LoadModule,SKick and System-startup have different purposes, so it is hard to compare. SKick replaces an entire kickstart blob (in a rather hacky fashion, requires hand-generated patch files). LoadModule replaces isolated modules from disk, requiring a reboot. System-Startup updates ROM modules from RAM without requiring a reboot, loading them from disk as needed.

I understand the difference between skick and loadmodule.

The files necessary for skick could be machine generated, no matter how hacky you consider it.

skick support would be great
 

guest11527

  • Guest
The files necessary for skick could be machine generated, no matter how hacky you consider it.

skick support would be great
Yes, it certainly could (the information is in the relocation information generated by the compiler), though I wonder why I should invest time into it, given than LoadModule can do that as well, without requiring additional information. Also note that SKick will have problems with autoconfiguring hardware as the system has to go through a second autoconf scan.
 

Offline paul1981

when booting from floppy disk. I don't believe that would be much of a selling point.
Loading the modules from hard disk would have to be done before booting from floppy.
Well, this is pretty much what System-Startup does in 3.2. The problem is, you cannot really load anything from harddisk without the modules initialized you need to run the harddisk, which is already quite a bit. Actually, exec, expansion, timer, misc, disk, utility and dos are needed, also graphics and intuition (and probably some other minor ones I forgot).

I wonder if this 'list of modules' could be stored on a designated RDB? Or at least a flag on the RDB which tells Kickstart that 'Modules are on this drive/partition!' The Kickstart could then look for valid modules on that drive and load them, all before the system comes ready...so no reboot would be required and it's all done before even booting from the hard disk (ie. even before the Startup-Sequence).
I wonder what the benefit of this would be. The only additional module you need to load them from the regular file system is the file system, and *that* can sit in the RDB anyhow by tradition. The drawback of having modules in the RDB is that you do not see them, you also need dedicated tools to manipulate them there, and you run into potential compatibility issues with the firmware of the drive - which is responsible for handling the RDB (and not the kickstart, note well!).

So, in a sense, we are with 3.2 exactly where you propose us to be, except that there is a "default module" in  ROM as well, which can be overridden by a RAM module. This only works for modules that are not initialized for accessing the harddrive, of course (intuition is some special exception, but the 3.2 intuition received a new feature, namely it is able to be shut down afterwards for getting replaced). And except that the modules are stored in the regular file system, so they are easy update and manipulate.

The only components you could remove from ROM because they non-essential for booting are mathffp,mathieeesingbas and audio, but again, some firmware might depend on them being available for their boot process because they have been in ROM, so I was really hesitating to make the change. They can be updated by System-Startup, of course.

There is no fine-control for this, but there will be an on-off switch in the boot menu to avoid trouble in case you accidentally trashed one of the replacement modules on disk, i.e. there is a fail-safe fall-back mode "rom boot only" mechanism. User programs could jump in to create a per-module switch, simply by renaming compoents on disk.

From a cold boot, can 3.2 boot from floppy disk with hard disk modules already loaded? The flag (which could point to a volume where modules are stored) if not stored on the RDB, could be stored just after the RDB. Isn't there a 'reserved blocks' feature or something in HDToolbox I seem to recall? Upon cold boot the system could read this flag, load the modules and then boot from either DF0 or whatever else is available. The bootmenu for example (if the imaginary 'Modules button' is selected) could list the modules (from the designated volume) and the user could be given individual control over them (Module version number could also be listed). Regarding the flag again, if it's not found it wouldn't matter (ie. a 2.x or 3.1 drive attached).

Or, preferably perhaps, it could do all the same as above, but forget the flag, and just search for the modules from the disk with the highest boot priority (modules could even be searched for from floppy if a devs/modules drawer is found). Obviously , if no disk is inserted in DF0 it will next look in DH0 devs/modules (providing that DH0 has the next highest boot priority).

If, for some reason someone connects an additional hard disk or has an additional partition/volume with a higher priority and they don't want the modules loaded from there (ie. it has the devs/modules directory also), then there could be a little config file in devs/modules of the unwanted volume which could be read before the modules are loaded which simply has the the real volume/partition from which you want the modules to actually be loaded from - and this would also be reflected in bootmenu). Or, I suppose temporary control instead could be had from within the bootmenu if such a problem arises.

All of this I mention because I was thinking of the system being up-to-date and ready, ready even from cold booting into a floppy disk (or any other boot device).
 

guest11527

  • Guest
Sorry, I still fail to see how all this is related to the RDB? It is really the wrong place to store arbitrary binary data. To load data from another harddisk, you only need a file system, and *that* comes from the RDB. "Reserved blocks" are not really "reserved" for that - it is just a left-over of the two-blocks "boot block" of floppies.

Thus, I wonder, why do you want to hide the modules from the user by placing them into a non-accessible spot?