New Boot "Manager" insaneBOOT

[insane]

Hi everyone!
I've written an autoexec menu/boot program called insaneBOOT,
which allows you to select multiple boot configs consisting of multiple programs.
A bit like XBOOT and other Boot Managers but with one big difference:
insaneBOOT does not sort your auto folder on a config change.
In fact insaneBOOT does not write anything to your HDD/CF!
Classic boot managers always reorder the auto folder on each config change which means write cycles.
As I'm fully working with CF-cards in my Falcon I try to minimize those.
The cons: no way to change .acc, .inf or .cpx files. Not possible without write cycles.
If some of you find it useful then please leave some feedback so that I can release a v1.0 final.
Download 1.0 beta via ftp: ftp://untergrund.net/users/insane/atari/autoexec.zip
(ftp as long as my http://insane.tscc.de page stays down)

[marss]

useful

[insane]

Note that you can always run MinT tools like cp and mv with parameters (look at the autoexec.cfg for an example) to copy .acc, .inf or .cpx files
insaneBOOT can run programs with command line options

[simonsunnyboy]

Can I call things like NVDI from these sequences aswell?
Because then it would be truely flexible.

Neat idea in any cas, esp. the "no write to drive" policy.

[Eero Tamminen]

Bug: it tries to read CFG file from A:AUTO instead of from boot drive (C: in my case).

[insane]

@simon: yes- that's exactly what it is for. and i also use it this way
@Eero: weird; i use dgetdrv to get the current drive. Works fine on my Mega STE and Falcon
OTOH i only tested it with tos 2.06 and 4.04
Which TOS do you use?

[insane]

@Eero:
I've modified insaneBOOT to not ask about the "current" drive but rather simply use \AUTO\AUTOEXEC.CFG.
I think this still stems from testing. Can you please download it again - it should present itself as b20190228.0949.
If this doesn't work then I can try to use the boot drive set by the BOOTDEV $446.w Variable

[insane]

update 1.0beta build 20190315.1505:
- restructured code to not run inside supervisor mode
-> fixes no-keyboard-input when ran inside mint.cnf

get it on http://insane.tscc.de

[Beetle]

Awesome! You can easily use that to choose your desired screen resolution at boot time:

- make small textfiles, one file for each res in c:/screen.res/ folder:
640x480: 640.cfg

Code: Select all

video=0x401c

1280x720: 1280w.cfg

Code: Select all

video=0x441c

- make screen.cfg file from autoexec.cfg as template, save next to autoexec.cfg in auto folder

Code: Select all

...
.item 640x480
c:/mint/bin/cp.ttp c:/screen.rs/640.cfg u:/ram/screenres.cfg

.item 1280x720
c:/mint/bin/cp.ttp c:/screen.res/1280w.cfg u:/ram/screenres.cfg
 

and add line xaaes.cnf

Code: Select all

include u:/ram/screenres.cfg

right below

Code: Select all

video=0x(whatever you use most)/code]
which will be you fallback...

then add 
[code]exec c:/auto/autoexec.prg screen.cfg

to mint.cnf file

This example was for SuperVidel users and only covers 2 res, but i have like a dozen different
resolutions defined in my setup. InsaneBOOT makes it so convenient to choose!
What will you want to choose at boot? Network or without network? DHCP or static?
Run CDROM driver or not? You can easily config which Desktop to run, too!

Thank you Insane, the most versatile Bootmanager i came across!

[Eero Tamminen]

@Eero: weird; i use dgetdrv to get the current drive. Works fine on my Mega STE and Falcon
OTOH i only tested it with tos 2.06 and 4.04
Which TOS do you use?

Latest EmuTOS, with Hatari GEMDOS HD emulation.

I've modified insaneBOOT to not ask about the "current" drive but rather simply use \AUTO\AUTOEXEC.CFG.

This works fine, thanks! (and sorry for the late reply)

[wongck]

Awesome! You can easily use that to choose your desired screen resolution at boot time:

I been doing something similar to this since Helmut implemented MINT.CNF style include into XaaES.CNF, but by using STOOP.
In addition to video, I also made selections for Sparemint, AES and desktop as well. With STOOP I just pick these 3 items from different "board".
STOOP of course make writes to the HDD.

I am sure you can also do the same with Insaneboot, don't let the creative juices slow down!!

[ctirad]

In fact insaneBOOT does not write anything to your HDD/CF!
Classic boot managers always reorder the auto folder on each config change which means write cycles.
As I'm fully working with CF-cards in my Falcon I try to minimize those.

Why? Do you plan to reboot 1000x per day for next 100 of years?

[simonsunnyboy]

If I would us this to load Emutos from harddisk (using the official emutos.prg) , how will the boot manager behave on its second call?
E.q. boot manager in AUTO, and Emutos will execute AUTO again on its initialisation.

Maybe something like .emutosquit could be added?

[ThorstenOtto]

Maybe something like .emutosquit could be added?

I may be wrong, but doesn't emutos.prg quits when it detects that it is already installed? If not, it should do so. At least if it is the same version as the one already running.

If it does not quit, that feature should be added. InsaneBoot is certainly not the only bootmanager that will be affected, so it does not make much sense to add a emutos-specific command there.

[simonsunnyboy]

Emutos.prg itself is probably not the problem but I don't know how well this program file version cleans the rest of the memory.

But If I selected Emutos, I probably don't want to end in a boot loop.

Any other useful ideas to have Emutos as an boot option and using Insane Boot? I like the "no write to disk" policy and do not intend to burn Emutos to EPROM yet.

[ThorstenOtto]

This is mainly a problem of emutos.prg, since it will execute the programs in the AUTO folder again. Other programs won't do that. It's actually similar to run MagC from the auto-folder, there you also boot twice, but the 2nd time magxboot.prg detects that Magic.ram is already installed and does not load it again. So you will see the bootmanager twice, but (hopefully) not in an endless loop.

[Rustynutt]

JoEven, could you comment on this setup with the AB drivers? Bit over my head.

[insane]

I have something planned regarding this. A kind of flag system - I already have the reset-proof (I hope; gotta check with emutos) remember-last-selection byte. I am planning to use something similar to allow "continuing" booting a certain selection.
But this'll still need some time. I'll keep you guys updated.

[simonsunnyboy]

Take your time, your work on this sleek little tool is very appreciated! Works fine already!

[joska]

JoEven, could you comment on this setup with the AB drivers? Bit over my head.

The AB driver will copy TOS to RAM, patch it (MMU setup, fast-RAM, cache etc) and jump to the new TOS image. TOS will then of course start again, and the AB driver will be run for a second time. But this time it knows that the AB has already been set up so it doesn't do anything (well, it does, but for simplicity...).

[Rustynutt]

JoEven, could you comment on this setup with the AB drivers? Bit over my head.

The AB driver will copy TOS to RAM, patch it (MMU setup, fast-RAM, cache etc) and jump to the new TOS image. TOS will then of course start again, and the AB driver will be run for a second time. But this time it knows that the AB has already been set up so it doesn't do anything (well, it does, but for simplicity...).

Love simplicity. Haven't thought it through yet what implications a boot manager would have with the AB loading and patching. Still working in setting up Zoro
Honestly, my Afterburner set up is so tried and true, really never changing, thought having a bootable ROM would be less hazardous than a 20 year old flaking CD disk for storage
Still need to make an emutos boot rom to test the 060 and adapter on the AB.
If I were any further behind, I'd be kissing my own arse!

[mrbombermillzy]

Im guessing everyone here is using Mint for this? Im using plain TOS on a TT.

Ive got a NOVA card that I would love to setup different resolution boots for, but unfortunately, it seems Menu.prg cannot find Menu.inf unless its in the AUTO folder, which kind of defeats the whole point.

Unless theres an easier option, perhaps I can use some sort of GEMDOS utility to copy the files to the AUTO foler before the VDI card drivers need the files. Is there such a utility? Many thanks for any help here guys

[wietze]

Im guessing everyone here is using Mint for this? Im using plain TOS on a TT.

Ive got a NOVA card that I would love to setup different resolution boots for, but unfortunately, it seems Menu.prg cannot find Menu.inf unless its in the AUTO folder, which kind of defeats the whole point.

Unless theres an easier option, perhaps I can use some sort of GEMDOS utility to copy the files to the AUTO foler before the VDI card drivers need the files. Is there such a utility? Many thanks for any help here guys

To achieve this, I just took the move/copy binaries from mint and run them from insaneboot iirc.

[insane]

Whelp. Time to dust of that code - v1.0 20200429 is released.
This uses a "menu.cfg" file in the current directory if it can find it; else it will default to \auto\autoexec.cfg or whatever the commandline says.
Get it on my homepage, as usual.

[insane]

Just remember that you don't need the menu.cfg as possible default change if you simply cascade autoexec.prg:

Code: Select all

.item Submenu1
c:\auto\autoexec.prg c:\auto\submenu1.cfg
.item Submenu2
c:\auto\autoexec.prg c:\auto\submenu2.cfg