Path: utzoo!utgpu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!wuarchive!decwrl!waikato.ac.nz!comp.vuw.ac.nz!canterbury!chem194 From: chem194@csc.canterbury.ac.nz (John Davis) Newsgroups: alt.sources.amiga Subject: Re: EVERYONE-- DOWNLOAD Bootmenu! Message-ID: <1991Mar6.131022.192@csc.canterbury.ac.nz> Date: 6 Mar 91 00:10:22 GMT References: <1991Feb28.090928.1@happy.colorado.edu><1991Mar1.150946.150@csc.canterbury.ac.nz> Organization: Chem Dept, U of Canterbury, Christchurch, New Zealand Lines: 55 In article , mt87692@lehtori.tut.fi (Mikko Tsokkinen) writes: > > I also like this program. However as there were no cli switches I installed > them, I also added ability to kill only those autoconfig boards you want (this > is bit kludge since it allows you to kill boards from 1st slot to wanted slot > but cannot jump one slot). This skipping is usefull if you want just kill the > HD but leave the memory (for playing Lemmings which does not use the HD). Good to see people making use of the source code! The reason I didn't initially put cl switches in was a) I never though of it :-) b) I'd assembled it for my preferences anyway Since it seems a useful idea for other people I'll put it in. As for killing _only_ certain boards - I looked at it, but as you can only kill the first x boards it's of limited use. For instance, both on my 2630, and on the A590 the memory comes _before_ the hd, so if you want to nuke the ram, you need to kill the hd too. Short of rewriting expansion.library there's not much you can do... > Also there is some programming in it I did not like: It just kills 7 boards > but does not take in account that there can be more than one autoconfig > node in one board and it does not work with MoveSSP (like author suspects in > the docs). Also the basic idea of using system stack as it is allways reserved > is bit kludge. I also optimized it bit (dbra...). Otherwise however it is GOOD > program. I initially played around with logic that detected when the last a/c board had been found, but kept on finding machines where it just failed to work (and you ended up killing an infinite number of boards - this can take a while:-). In the end I settled on the 7 board brute force approach, on the basis that few machines would have that many device in it (I knew about multi device boards - but 7 is _Still_ a lot of a/c devices). I could make it bigger - I'd prefer some board detect logic that works (expansion device does it - anyone got a dissasembly?). As for the memory allocation system - I'm the first to admit sitting on the ssp is a BIG kludge - I only used it because it was easy (and if it's good enough for half the virii out there, it's good enough for me:-). As the program grows bigger it'll _have_ to go to a legal mem alloc method anyway (that's very high on my priorities) - in the interim all you can do if you've got an 030 is make sure you run BootMenu with ssp relocation off (I don't know about MoveSSP - I use SetCPU, and you can turn it off easily by issuing 'setcpu nofastrom') thanks for the words of encouragement - now to get BootMenu2 finished (if anyone's got suggestions for things they'd like in it, mail me!) ----------------------------------------------------------- | o John Davis - CHEM194@canterbury.ac.nz o | | o (Depart)mental Programmer,Chemistry Department o | | o University of Canterbury, Christchurch, New Zealand o | | o o | | o co-sysop AmigaINFO BBS,1200/2400 baud CCITT, o | | o 24 hours a day, ph NZ +3-3371-531 o |