Kickstart Switch / Dual Boot

[craggus2000]

I know this has been banded about a few times in the past, but I've looked and can't find a definitive.....

Is there a way to dual boot WB1.3 and WB2.1 with a kickstart switcher? I've got coming a hacked 1.3 Kickstart with the scsi.device so will be able to boot from hard disk.

What I want to do is have it 'automatically' boot the correct version of Workbench depending on what Kickstart is used. I have 1.3 and 2.1 installed and working (tested in WinUAE) on 2 separate partitions (2.1 on DH0: and 1.3 on DH1: ) of a CF Card, but currently have to manually set the boot priority in HDToolBox before I reboot into the other Kickstart each time

I'm convinced that on the Amiga I had when I was 10 it was all automatic.................

Any ideas?

[FOL]

Originally Posted by craggus2000

I know this has been banded about a few times in the past, but I've looked and can't find a definitive.....

Is there a way to dual boot WB1.3 and WB2.1 with a kickstart switcher? I've got coming a hacked 1.3 Kickstart with the scsi.device so will be able to boot from hard disk.

What I want to do is have it 'automatically' boot the correct version of Workbench depending on what Kickstart is used. I have 1.3 and 2.1 installed and working (tested in WinUAE) on 2 separate partitions (2.1 on DH0: and 1.3 on DH1: ) of a CF Card, but currently have to manually set the boot priority in HDToolBox before I reboot into the other Kickstart each time

I'm convinced that on the Amiga I had when I was 10 it was all automatic.................

Any ideas?

We sell a kickstart rom switcher, that lets you switch via Ctrl A A.

Instead of altering boot priority, why not simply hold both mouse buttons on boot and selecting your desired boot partition.

Leave the partition you use the most with the highest boot priority. this way, you only have to hold down both mouse bottons and select only when you want other partition.

[Jope]

Instead of holding down your mouse buttons at boot, why not do it properly? ;-)

Just use the version command to check the version of some library at boot time. Then assign the system assigns to the right partition and jump to the s:startup-sequence on that partition?

Have a small boot: partition as your first partition that has a C dir that only contains the commands used in the startup-sequence and also have a system-configuration file in devs.

You'd have a 1.3 partition called WB_1.3 and a 2.1 partition called WB_2.1. (mimicing how the A3000's 1.4 rom does this)

The startup-sequence would look like this:

version >nil: graphics.library 37
if warn
  ;we're in kick 1.3
  assign sys: WB_1.3:
else
  ;we're in kick 2.0x
  assign sys: WB_2.1:
endif
assign c: sys:c
assign s: sys:s
assign l: sys:l
assign fonts: sys:fonts
assign devs: sys:devs
assign libs: sys:libs
assign t: ram:
cd sys:
execute sys:s/startup-sequence

You might want to use software like setprefs or whatever to read the system-configuration from the correct partition if you want 1.3 to have white on blue and 2.x to have black on grey.

However you could just keep the 1.3 system-configuration on the boot partition and let iprefs handle the colour change if you boot into 2.1.. Then you'd only suffer from 1.3 colours if you boot with no startup-sequence.

You don't even need to have separate partitions. You could install WB1.3 into dh0:wb1.3 and assign sys: there, but workbench use will suffer as a result.. Separate partitions work in a nicer way.

In the end you'll notice that 1.3 sucks and you'll never boot in there, but at least you had fun doing the multi boot setup.

Yada yada. The world is your oyster, we provide solutions, you get to select what you like.

[rkauer]

@Jope: that's almost what I did on my 3.1/3.9 A2000. I just "killed" the accelerator's IDE controller before loading GURU.ROM (binddriver) for the GVP SCSI+8, then on the "newer" startup-sequence I a selection choice to boot from 3.1 or 3.9.

The GVP_IDE device is loaded after with support for large drives & CD.

[craggus2000]

@FOL

I've actually got one of the KS switchers from you guys, and it works perfectly!
Re the Mouse buttons, I still want something that's 'Zero' effort, but will give it a try when the Miggy is out of the dishwasher... (Well, the case anyway!)


@Jope

This sounds like maybe what was on my Amiga when I was 10...
In a nutshell, would I basically have 3 partitions (boot:, wb2.1:, wb1.3: ) with boot: having the highest boot priority?
What would be in the system-configuration file in devs?
Why would the colours not be correct without running setprefs? Surely if everything is assigned, and the correct kickstart used then it would all be 'normal'? Could the version check, not check the kickstart version somehow and then use the correct partition in that way?
Would I be able to hide the boot: icon from workbench be just deleting the Disk.info file?

[Jope]

Originally Posted by craggus2000

This sounds like maybe what was on my Amiga when I was 10...
In a nutshell, would I basically have 3 partitions (boot:, wb2.1:, wb1.3: ) with boot: having the highest boot priority?

Only boot: would need to be bootable. WB1.3 can't select the boot partition anyway. You may want to opt WB2.1 to be bootable so you can jump directly there with the mouse buttons, but it's not necessary.

What would be in the system-configuration file in devs?

The system-configuration file holds the pointer shape, screen colours etc. You just copy this off your workbench disk.

Why would the colours not be correct without running setprefs? Surely if everything is assigned, and the correct kickstart used then it would all be 'normal'? Could the version check, not check the kickstart version somehow and then use the correct partition in that way?

Because system-configuration is loaded before the initial CLI is opened. Thus you'll either have 1.3 colours or 2.x colours in the initial CLI.

For 2.x the problem isn't that bad, as it only has the system-configuration for legacy reasons, the workbench preferences editors work on files in env:sys and those are read in from the startup-sequence when iprefs is run. Hence you could have the 1.3 system-configuration loaded when the machine is booted and just wait until iprefs is run, which fixes the colours.

Would I be able to hide the boot: icon from workbench be just deleting the Disk.info file?

No. It would display a default icon then. You could say assign boot: dismount during some time of your boot process (like just before loadwb). However this is a pain if you want to modify the boot partition some time.

There might be a piece of software on Aminet that hides volumes from the WB screen, but I don't know the names of any. Happy searching.

[craggus2000]

Thanks Jope,

Will have a play when its back together!

[rkauer]

OK, a slightly different approach for the same idea:

Set only two partitions, one for each OS version. The trick goes here:

-One partition is formatted using OFS (Original File System, known as "old file system", nowadays) and have a boot priority of 0 to 3. This is the 1.3 partition and be the only recognized by 1.3 ROM;

-Second partition and all others you may want to create you'll have to use FFS (Fast File System) or other modern(ish) file system. The 2.x/3.x partition must have a higher boot priority than the 1.3 one.

This way the process is totally automagic (tm), you select the ROM and the Amiga will take care of the rest.

[craggus2000]

Originally Posted by rkauer

OK, a slightly different approach for the same idea:

Set only two partitions, one for each OS version. The trick goes here:

-One partition is formatted using OFS (Original File System, known as "old file system", nowadays) and have a boot priority of 0 to 3. This is the 1.3 partition and be the only recognized by 1.3 ROM;

-Second partition and all others you may want to create you'll have to use FFS (Fast File System) or other modern(ish) file system. The 2.x/3.x partition must have a higher boot priority than the 1.3 one.

This way the process is totally automagic (tm), you select the ROM and the Amiga will take care of the rest.

Me likey
What are the disadvantages to OFS though?
Will both versions of workbench see *all* the partitions, regardless of file system?

[Jope]

Originally Posted by rkauer

Set only two partitions, one for each OS version. The trick-One partition is formatted using OFS (Original File System, known as "old file system", nowadays) and have a boot priority of 0 to 3. This is the 1.3 partition and be the only recognized by 1.3 ROM;

Did you try this out? The later kickstarts also support OFS, else 99% of all dos floppies wouldn't boot.

[craggus2000]

Originally Posted by Jope

Did you try this out? The later kickstarts also support OFS, else 99% of all dos floppies wouldn't boot.

Must admit, I kind of thought that, then you would get WB2.1 still trying to boot with 1.3 KS?

[Jope]

Originally Posted by craggus2000

Must admit, I kind of thought that, then you would get WB2.1 still trying to boot with 1.3 KS?

If we're still talking about Rkauer's approach, then both kickstarts would respect the same boot priority order and you'd always get 2.x no matter what kickstart you are running. (and if the kickstart was 1.3, it would fail pretty close to the top of the startup-sequence)

[orange]

@jope

but the trick here is that KS1.3 cannot see FFS partition at all? and would presumably skip it and boot OFS.

[Jope]

Ah ok, now I see. You'd need to leave FFS out of the RDB in order for this to work. 1.3 can use FFS just fine, HDToolBox automatically copies it into the RDB when you're defining the drive type.

The drawbacks would be that you're stuck with the ROM FFS, and OFS is not a good filesystem.

The drawbacks with the boot partition method is that the boot partition doesn't have all the shell commands on it, so you need to run another script to make the assigns for you. (which is what I have in my a3000)

[Retro1234]

I think the first solution is good.

[thomas]

Originally Posted by orange

@jope

but the trick here is that KS1.3 cannot see FFS partition at all? and would presumably skip it and boot OFS.

Does not work. You will get "not a dos disk in drive dh1" or "no disk present in drive dh1" or something like that. Unreadable disks are not skipped.

[Jope]

Originally Posted by thomas

Does not work. You will get "not a dos disk in drive dh1" or "no disk present in drive dh1" or something like that. Unreadable disks are not skipped.

Are you sure? Unreadable is one thing, but unmountable is another..

I had a problem once where I was using PFS3 on a two harddrive system. PFS3 was installed into both RDBs, but I had typoed the dostype for PFS3 when I installed it into the 2nd hard drive's RDB.

The 2nd drive's partitions had the correct dostype and everything worked.

I moved all my stuff onto the second HD and removed the first one, only to be really weirded out when all the partitions disappeared.

I reattached the 1st drive and everything worked again.. After some time of banging my head against the wall, I realised the problem and reinstalled PFS3 onto the RDB of the second drive, this time with the correct dostype. :-)

But it was very strange, no error messages or anything. I could see the partitions in hdtoolbox but not in early startup or in info. Does 1.3 substitute OFS if it can't match up the partition's dostype with any filesystem installed into the RDB? My experience was with KS 3.0. (actually, isn't it scsi.device that builds up the exec devices?)

[thomas]

I tried it in WinUAE and I got a flashing power LED with red screen. I don't know why the ROM checksum should be affected from a non-existing file system. But it does not boot, that's what I wanted to prove.

In the case you describe you booted from another disk and the partitions with wrong dostype were not bootable. The problem arises only if the partition with the highest boot priority cannot be mounted. The point is that the selected boot partition is not skipped if something is wrong with it.

Other partitions are just ignored when they cannot be mounted, but if the boot priority says "boot from dh0" and dh0 does not exist, it crashes, it does not skip to the next bootable partition.

[Jope]

The partitions had the right dostype but the filesystem didn't. :-) I could actually try and set up this system since I have an a500 with an adide and i have a kickswitcher somewhere..

Edit: haha, I got so caught up thinking about this that I missed two stops on the bus.. Walking home now. :-)

[rkauer]

OK, that was an idea, not a tested one, unfortunately.

As 1.3 ROM try desperately to mount an "un-mountable" partition which have a higher boot priority (even if it is the second partition), my plan must be skipped.

Need to know more on how 1.3 works again. That was soooooooooo many moons ago.