hamilton@uxc.cso.uiuc.edu (05/24/87)
scotty@l5comp says: > In article <19350@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: > >All the install does is put about 32 bytes of object code into > >the 'boot' sector to call the DOS IN ROM. > Wrongo Chuck. Install puts about 20 bytes of code in the boot sectors and about > 1000 bytes of whatever is lying around in memory PLUS the required 12 bytes of > info dealing with 1. This IS a DOS disk 2. A checksum 3. Where the root node > is on the disk. Interestingly enough this seems to be the function of the > boot code as well, except it returns a pointer to the RootNode memory structure > which is not the same as the disk's rootnode :). It also doesn't call anything > except FindResident (OpenLibrary doesn't work at this point in the bootstrap) > and then returns to whomever called it. ie the boot code DOES NOT call the dog. well, just to pick nits... here's what a V1.1 boot block looks like (excluding the garbage): DiskType DC.B 'D','O','S',0 CheckSum DC.L $D9EDFE92 (for example) RootKey DC.L 880 Boot LEA DosName(PC),A1 FindResident("dos.library") JSR _LVOFindResident(A6) TST.L D0 NULL? BEQ 2$ yes, fail MOVE.L D0,A0 struct Resident * MOVE.L 22(A0),A0 rt_Init MOVEQ #0,D0 return OK 1$ RTS 2$ MOVEQ #$FF,D0 return FAIL BRA 1$ DosName DC.B "dos.library",0 [i think scotty misinterpretted that "22(A0)", thinking the 22 was hex (34 decimal) and that FindResident() returned a (struct DosLibrary *) in this case. also, there's nothing wrong with OpenLibrary() at this point, except that dos hasn't had a chance to subvert it to add the disk library support. this just means you're limited to openning the libraries that happen to be in ExecBase.LibList; ie, WCS-based libraries such as graphics.library.] a successful boot call returns with the rt_Init address for dos.library in A0. the calling WCS code then does some cleanup, and jumps to this address, which causes dos to be born. so, it's true that the boot block doesn't call dos, but it produces the dos entrypoint that gets called right away anyhow, which has the same effect. if you wanted a dos substitute, your boot block would load your dos from disk to ram and return a pointer to its init code. (hint hint :-)) wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,seismo,pur-ee,convex}!uiucuxc!hamilton ARPA: hamilton@uxc.cso.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton
scotty@l5comp.UUCP (Scott Turner) (05/27/87)
In article <172200057@uxc.cso.uiuc.edu> hamilton@uxc.cso.uiuc.edu writes: >in this case. also, there's nothing wrong with OpenLibrary() at this >point, except that dos hasn't had a chance to subvert it to add the I tried using OpenLibrary in a boot block to call the dog and I got a NIL pointer back... Hence my comment that OpenLibrary wasn't setup yet. Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)