rouaix@inria.UUCP (Francois Rouaix) (01/27/88)
By now, thanks to SCA ;-), you all know that we have some free space in the boot-blocks of DOS-bootable disks to write a small piece of code. How about launching a boot-block contest ? I propose some criterions : usefulness, grpahics, sound, fun ... Of course, boot process should continue properly after your code has terminated, and assembly source of the code should be provided. PS: does anyone know how to get the ViewPort adress of the "Workbench hand". It seems that the strap code does an AllocMem for the total amount of needed structures, and stores the pointers in a local stack (indexed by A5). and then proceeds to initializations (InitRastPort, ...), before actually drawing the picture.
amiguy@pnet01.cts.com (Sean Wolfe) (01/29/88)
rouaix@inria.UUCP (Francois Rouaix) writes: > >By now, thanks to SCA ;-), you all know that we have some free space in >the boot-blocks of DOS-bootable disks to write a small piece of code. >How about launching a boot-block contest ? >I propose some criterions : usefulness, grpahics, sound, fun ... >Of course, boot process should continue properly after your code has >terminated, and assembly source of the code should be provided. > You can't be serious, can you? Are you suggesting that everyone write a 'virus' ?? Sean Wolfe UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!amiguy ARPA: crash!pnet01!amiguy@nosc.mil INET: amiguy@pnet01.CTS.COM
haitex@pnet01.cts.com (Wade Bickel) (01/29/88)
amiguy@pnet01.cts.com (Sean Wolfe) writes: >rouaix@inria.UUCP (Francois Rouaix) writes: >> >>By now, thanks to SCA ;-), you all know that we have some free space in >>the boot-blocks of DOS-bootable disks to write a small piece of code. >>How about launching a boot-block contest ? >>I propose some criterions : usefulness, grpahics, sound, fun ... >>Of course, boot process should continue properly after your code has >>terminated, and assembly source of the code should be provided. >> >You can't be serious, can you? Are you suggesting that everyone write a > 'virus' ?? On the contrary. If the bootblock is occupied then there would be no room for a virus. Code in the bootblock is not a virus unless it propogates itself. As long as the code does not propogate itself and has no harmful side-effects (how will we confirm this???) and includes the source then what is the problem? Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
grwalter@watcgl.waterloo.edu (Fred Walter) (01/31/88)
In article <2442@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: > On the contrary. If the bootblock is occupied then there would be >no room for a virus. Code in the bootblock is not a virus unless it >propogates itself. As long as the code does not propogate itself and has >no harmful side-effects (how will we confirm this???) and includes the source >then what is the problem? The problem is that there may be people out there who would write virus's if they could, but they currently don't know enough. Giving them source to routines that patch into the bootblock would be like handing a flamethrower to an arsonist - not very bright. (Just look at the disk-wiping SCA virus mutantions; they didn't come out of thin air; somebody took the working example and made it deadly). Concerning occupied bootblocks with no room for a virus ... commercial software has occupied bootblocks; the virus just replaces the bootblock with its own. Le voila ! Room for a virus. fred -- CSNet: grwalter@watcgl.waterloo.edu UUCP: {ihnp4,decvax,allegra,utzoo}!watmath!watcgl!grwalter CDNnet: grwalter@watcgl.waterloo.cdn ARPA: grwalter%watcgl.waterloo.edu@csnet-relay.arpa
kb@dasys1.UUCP (Stan Ziel) (01/31/88)
This boot-block non-virus talk got me thinking about an idea I had for a phoney, non-propigating virus. You store an IFF sound of coughs and/or sneezes on the disk, and every time you boot, you would hear them! But don't worry... I won't write this virus, and I doubt anyone could (and sneak it by.) After all, a digitalized sound takes a lot of disk space. But is there really anything useful to put in the boot block? I mean if you want to do anything at boot time, there is the startup-sequence to use. (I know, CLI is awful, but what can you do, eh?) I'd think that any boot block stuff would all be along the lines of hacks, and anything good would take more space than what's in the boot block. (See above.) Maybe if you don't want your Amiga to have a 'virus', you could replace the coughs with some music. Now does anyone have a good suggestion for 'music to boot by'? -- ============================================================================== | kb (Stan Ziel) "We're cloudbusting, Daddy" | the Big Electric Cat | ..!cmcl2!phri!dasys1!kb
page@swan.ulowell.edu (Bob Page) (02/02/88)
kb@dasys1.UUCP (Stan Ziel) wrote: >an idea I had ... You store an IFF sound of coughs and/or >sneezes on the disk, and every time you boot, you would hear them! People/Link has a program in their library that makes your disk drive "GULP" when you insert a disk, and say "YUCK" (or something) when you eject the disk. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page "I don't know such stuff. I just do eyes." -- from 'Blade Runner'
darin@laic.UUCP (Darin Johnson) (02/02/88)
Actually, I would like to see how people use the bootblock. I have
benn thinking off and on about coming up with my own OS, but always
forget about it when I think of how to create a boot block, generating
code that will work there (I assume Lattice/Manx won't work - assembler
perhaps..), and how to put enough code in the bootblock to actually
read stuff from the disk to load in the rest of the OS.
So actually, there are more uses to the bootblock than Viruses and
neat demos.
--
Darin Johnson (...ucbvax!sun!sunncal!leadsv!laic!darin)
(...lll-lcc.arpa!leadsv!laic!darin)
All aboard the DOOMED express!langz@athena.mit.edu (Lang Zerner) (02/02/88)
In article <2581@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >People/Link has a program in their library that makes your disk drive >"GULP" when you insert a disk, and say "YUCK" (or something) when you >eject the disk. I've heard about this program here a number of times, and I'd really love to have it. Unfortunately, I can't find anyone around here who knows what I'm talking about. Hey, Mr. comp.binaries.amiga, can you get a hold of this for us? Be seeing you... --Lang Zerner langz@athena.mit.edu ihnp4!mit-eddie!athena.mit.edu!langz "To be clever enough to get a great deal of money, one must first be stupid enough to want it." -- G.K. Chesterson
ain@s.cc.purdue.edu (Patrick White) (02/02/88)
>>"GULP" when you insert a disk, and say "YUCK" (or something) when you >talking about. Hey, Mr. comp.binaries.amiga, can you get a hold of this for I've never heard of it either... does the author (or someone close to him/her) want to send it to us? -- Pat White (co-moderator comp.sources/binaries.amiga) UUCP: k.cc.purdue.edu!ain BITNET: PATWHITE@PURCCVM PHONE: (317) 743-8421 U.S. Mail: 320 Brown St. apt. 406, West Lafayette, IN 47906 P.S> sorry about truncating the origional articles to meaninglessness, but I have to or it won't be allowed off site.
cmcmanis%pepper@Sun.COM (Chuck McManis) (02/03/88)
In article <150@laic.UUCP> darin@laic.UUCP (Darin Johnson) writes: > Actually, I would like to see how people use the bootblock. I have > been thinking off and on about coming up with my own OS, but always > forget about it when I think of how to create a boot block, generating > code that will work there (I assume Lattice/Manx won't work - assembler > perhaps..), and how to put enough code in the bootblock to actually > read stuff from the disk to load in the rest of the OS. So why do you need to change the boot block to read in the O/S? Doing O/S development on the Amiga is very straightforward, you write your kernel in whatever language you propose, write little 'mini boot' that AllocMem's all of the available memory (or maybe just some big contiguous chunk) and loads your kernel image into it and starts it. I have seen several possible ways that MINIX (one of the more popular O/S' since all of the implementing has already been done) could run as an exec task. if you have 2Meg of memory you could even give MINIX it's own 640K address space and leave the rest for other things. The point here, is that not being knowledgeable enough to bash on the boot block should not be an impediment to doing os development on the Amiga. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
cthulhu@athena.mit.edu (Jim Reich) (02/03/88)
In article <2437@crash.cts.com> amiguy@pnet01.cts.com (Sean Wolfe) writes: >rouaix@inria.UUCP (Francois Rouaix) writes: >>By now, thanks to SCA ;-), you all know that we have some free space in >>the boot-blocks of DOS-bootable disks to write a small piece of code. >>How about launching a boot-block contest ? >You can't be serious, can you? Are you suggesting that everyone write a > 'virus' ?? NONONONONONO!!!! The trick is: these programs SHOULD NOT propagate themselves! If they do, MAKE THEM CHECK if the target disk has a normal boot block! Otherwise, you will have another virus on your hands, every bit as nasty as the SCA virus! -- Jim
rouaix@inria.UUCP (Francois Rouaix) (02/03/88)
In article <150@laic.UUCP>, darin@laic.UUCP (Darin Johnson) writes: > forget about it when I think of how to create a boot block, generating > code that will work there (I assume Lattice/Manx won't work - assembler > perhaps..), and how to put enough code in the bootblock to actually > read stuff from the disk to load in the rest of the OS. > Why, of course assembler is what you need. You also need to compute the checksum (this was posted some weeks ago here). You should also know that at boot-time, system is almost completly setup. You may open graphics.library and do some graphics for example. As for reading stuff from disk, it is quite simple. When the strap code loads the boot-block and start executing (at offset #$0c), you have in A1 a pointer to an IOStd ( I mean the special one for trackdisk.device - I don't have the full name in mind). Just fill it with your parameters and call BeginIO(). As far as I know, Psygnosis uses this scheme in their games. But this is not what we want. The boot-block code should always return so that set-up of the system could be completed by the strap code. If the code does not return, there may be some problems. At the moment I suspect that you will lose the memory used by the "workbench hand" picture. (View+ViewPort+RastPort+320x200 plane...). Other disks won't be validated (I think). For good uses of the boot-block (apart of Viruses ;-) ;-)), we already have StealMemBoot (posted in comp.binaries.amiga weeks ago) that installs a path of AllocMem in the boot-block.
kkaempf@rmi.UUCP (Klaus Kaempf) (02/13/88)
In <2798@dasys1.UUCP> kb@dasys1.UUCP (Stan Ziel) writes: > But is there really anything useful to put in the boot > block? I mean if you want to do anything at boot time, > there is the startup-sequence to use. Yes, there is. No, the startup-sequence might be too late. The following is untested, but it should work. Both the trackdisk.device and the AmigaDOS won't allocate buffers for unused drives, so it will give you a bit of extra MEMF_CHIP. Might be necessary for some games or if you don't have enough RAM. Never needed it because I got 4.5megs and I find programming much more fascinating than playing games. :-) Try inserting something like this in your bootblock: #include <resources/disk.h> /* ... whatever you want ... */ struct DiskResource *dr; if((dr = OpenResource(DISKNAME)) != NULL) { dr->dr_UnitID[1] = dr->dr_UnitID[2] = dr->dr_UnitID[3] = DRT_EMPTY; } /* ... fire up AmigaDOS ... */ !ralph Ralph Babel, Falkenweg 3, D-6204 Taunusstein, FRGermany