jack@csmunix.larc.nasa.gov (Jack Dunn) (02/21/89)
I don't think the problem is with using FIXKEYS. I have had the same problem with out using FIXKEYS. In my analysis, the booting program will never work with a correct .IMG file. The error is generated when, if I calculated the address right, the 16 bit word located at offset 508 ( wp[-2] ) is not zero or when the 16 bit word at offset 506 ( wp[-3] ) does not equal the 16 bit word at offset 510 ( wp[-1] ). It appears that wp[-1] is a check sum and wp[-3] is the start of the data segment. I can not see how these words would ever be equal. I have concluded that the MINIX.PRG is the not coded correctly. I have go any further into trying to correct the problem since it is just as easy to boot the system from floppy.
bammi@dsrgsun.ces.cwru.edu (Jwahar R. Bammi) (02/21/89)
In article <9222@louie.udel.EDU>, jack@csmunix (Jack Dunn) writes: >how these words would ever be equal. I have concluded that >the MINIX.PRG is the not coded correctly. I have go any further Please re-check if it is not an operator error. I use the MINIX.PRG route to boot up minix all the time. I have built several kernels this way, never had any problems. The steps i use are: in minix: - build a new kernel - cp minix.img /dev/fd0 - sync & reboot (CTRL+ALT+DEL) in TOS: - double click into c:\command.tos (in my small TOS partition) - fixkeys a: - rflop a: c:\minix 133000 (any number > sizeof(minix.img) will do) - exit - double click minix.prg hope that helps. usenet: {decvax,sun}!cwjcc!dsrgsun!bammi jwahar r. bammi csnet: bammi@dsrgsun.ces.CWRU.edu arpa: bammi@dsrgsun.ces.CWRU.edu compuServe: 71515,155
PKP88%DMSWWU1A.BITNET@cunyvm.cuny.edu (Rainer Perske) (02/21/89)
Hello, yesterday I wrote: >I've run into an installation problem with MINIX-ST: I want to start >MINIX from TOS w/o using a floppy disk. I followed the instructions in >the manual to create MINIX.IMG on my hard disk. There is no problem >starting MINIX this way if (and only if) I've created MINIX.IMG from an >unchanged boot disk. But I have a german keyboard, so I ran FIXKEYS.PRG >on a copy of my boot disk. If I create a MINIX.IMG from this changed >boot disk, MINIX.PRG stops with a message: minix.img: wrong format. >Why? Jack Dunn <jack@CSMUNIX.LARC.NASA.GOV> answered: >I don't think the problem is with using FIXKEYS. I have had the same >problem with out using FIXKEYS. In my analysis, the booting program >will never work with a correct .IMG file. The error is generated >when, if I calculated the address right, the 16 bit word located >at offset 508 ( wp[-2] ) is not zero or when the 16 bit word >at offset 506 ( wp[-3] ) does not equal the 16 bit word at offset >510 ( wp[-1] ). It appears that wp[-1] is a check sum and >wp[-3] is the start of the data segment. I can not see >how these words would ever be equal. I have concluded that >the MINIX.PRG is the not coded correctly. I have go any further >into trying to correct the problem since it is just as easy to >boot the system from floppy. Most of this is correct, but it is not the reason the fault originates from, as I've decovered now: If I make a diskcopy by dragging icon A on icon B, the bootsector will NOT be maintained exactly, if it is not in standard TOS format. At least five bytes changed, including the checksum. Because byte 510 (wp[-1]) is part of the checksum, MINIX.PRG will fail if MINIX.IMG is made from a copied disk, but it happens to success from the original disk. Proposed correction: Use a disk copy program instead of dragging icon A on icon B, or try (using the 08.TOS disk, see manual) RFLOP A: M:MINIX.IMG 1300000 read the original bootdisk image WFLOP A: M:MINIX.IMG write a copy on another disk Preferrable correction (Johan? Jost?): Change MINIX.PRG so that any other validity check is performed; and change the minix bootsector, so that it becomes a fully TOS compatible bootsector (one that will be maintained by the desktop diskcopy). Much fun with MINIX! Rainer Perske ------------------------------------------------------------------------ Rainer Perske EARN/BITNET: PERSKE@DMSWWU5P.bitnet Institut fuer Kernphysik der EARN/BITNET: PKP88@DMSWWU1A.bitnet Westfaelischen Wilhelms-Universitaet . Wilhelm-Klemm-Strasse 9 /|\ D-4400 Muenster | Federal Republic of Germany has recently changed ! ------------------------------------------------------------------------ Disclaimer: If not otherwise stated, all written above is my own opinion
jf@laura.UUCP (Jan-Hinrich Fessel) (02/22/89)
In article <504@cwjcc.CWRU.Edu> bammi@dsrgsun.ces.cwru.edu (Jwahar R. Bammi) writes: >In article <9222@louie.udel.EDU>, jack@csmunix (Jack Dunn) writes: >>how these words would ever be equal. I have concluded that >>the MINIX.PRG is the not coded correctly. I have go any further I do think that too! >Please re-check if it is not an operator error. I use the MINIX.PRG [...] >hope that helps. Nope! I personally can't get minix.prg to run correct. All I can see is the screen turning white (after the normal TOS-procedures) and then - whow - the Desktop again. Jan-Hinrich -- Jan-Hinrich Fessel jf@unido.uucp jf@unido.bitnet Universitaet Doertmund, IRB Telefon +49 231 755 2444 =============================================================================
fgbrooks@pnet01.cts.com (Fred Brooks) (02/23/89)
bammi@dsrgsun.ces.cwru.edu (Jwahar R. Bammi) writes: >In article <9222@louie.udel.EDU>, jack@csmunix (Jack Dunn) writes: >>how these words would ever be equal. I have concluded that >>the MINIX.PRG is the not coded correctly. I have go any further > >Please re-check if it is not an operator error. I use the MINIX.PRG >route to boot up minix all the time. I have built several kernels >this way, never had any problems. The steps i use are: > > in minix: > - build a new kernel > - cp minix.img /dev/fd0 > - sync & reboot (CTRL+ALT+DEL) > in TOS: > - double click into c:\command.tos (in my small TOS partition) > - fixkeys a: > - rflop a: c:\minix 133000 (any number > sizeof(minix.img) will do) > - exit > - double click minix.prg >hope that helps. >usenet: {decvax,sun}!cwjcc!dsrgsun!bammi jwahar r. bammi >csnet: bammi@dsrgsun.ces.CWRU.edu >arpa: bammi@dsrgsun.ces.CWRU.edu >compuServe: 71515,155 Hello I havn't heard from you in a million. I see you are into minix now. As soon as I get my atari back I hope to get into ST MINIX. Where is the GULAM shell for MINIX? UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!fgbrooks ARPA: crash!pnet01!fgbrooks@nosc.mil INET: fgbrooks@pnet01.cts.com
jack@csmunix.larc.nasa.gov (Jack Dunn) (02/23/89)
The proble is with the format of the disk that was used to hold the new version of MINIX. I went in with a sector editor and changed the GEM file of the MINIX.IMG so that the last 16 bit word of the first sector equaled the third from the last 16 bit word. There were no problems. ( The orginal disks I got from PH had $01D0 for this value ). The reason this problem comes up is that the last word in the first sector is a GEM/TOS check sum. GEM/TOS tries to creat a different serial number for each disk that it formats. (random number perhaps) This cause the last word to be different for each disk, even when an identical copy is made by draging the icon for one disk over the other. It is apparent that the first sector is not transfered. Note. that this problem does not happen if the formating program that was just relased over this net is used to format a disk from MINIX!!!
johan@nlgvax.UUCP (Johan Stevenson) (02/24/89)
In article <9222@louie.udel.EDU> jack@csmunix.larc.nasa.gov (Jack Dunn) writes: >I don't think the problem is with using FIXKEYS. I have had the same >problem with out using FIXKEYS. In my analysis, the booting program >will never work with a correct .IMG file. The error is generated >when, if I calculated the address right, the 16 bit word located >at offset 508 ( wp[-2] ) is not zero or when the 16 bit word >at offset 506 ( wp[-3] ) does not equal the 16 bit word at offset >510 ( wp[-1] ). It appears that wp[-1] is a check sum and >wp[-3] is the start of the data segment. I can not see >how these words would ever be equal. I have concluded that >the MINIX.PRG is the not coded correctly. I have go any further >into trying to correct the problem since it is just as easy to >boot the system from floppy. MINIX.PRG is correct. But it needs an exact byte-by-byte copy of the first 130Kbyte or so of the 00.BOOT floppy. The problem is caused by TOS copy programs that modify the contents of the first sector. They force a new random number as disk identification (not a real problem), but also adjust the checksum. Unfortunately, bytes 510 and 511 are used for this TOS checksum. And this coincides with three words of information MINIX stores at the end of the first sector of MINIX.IMG. MINIX-ST uses bytes 504 and 505 as checksum. If I had foreseen all these problems I would have used 510 and 511, but I haven't. Sorry. Please use copy programs that do not modify sector 0, for instance the programs RFLOP.PRG and WFLOP.PRG on diskette 08.TOS. -- Johan W. Stevenson johan@pcg.philips.nl Philips Research
zessel@incas.UUCP (Holger Zessel AG Nehmer) (02/28/89)
Hi !
I've got some other questions/bugs(?) with respect to booting
with MINIX.PRG:
- When I put MINIX.PRG in the AUTO-folder and reboot,the system is
loaded and then start's up. Minix asks for the rootdevice and
after answering that it announces a severe hd error
("... Push reset button"). I don't know the exact message
at this moment when I post this, I'll tell it later.
Interesting is the fact, that this only happens with MINIX.PRG
started from AUTO folder.
MINIX.PRG started from desktop shows no problems with respect
to disk.
I looked intensively at TOS-initialization before and after
AUTO folder is executed but found no hints. There must be a difference
between booting from floppy/desktop and AUTO folder.
The disk is a VORTEX HDPlus 20 (german product).
- Booting with MINIX.PRG always destroys resetvectors in as far that
typing ctrl-alt-del from MINIX or pushing reset just gives a black
screen and - dead machine. I must switch it off to reboot.
Any ideas, suggestions ?
Holger
--
----------------------------------------------------------------
Holger Zessel, uucp: ...!uunet!mcvax!unido!uklirb!incas!zessel
Fachbereich Informatik, SFB124-D1
Universitaet Kaiserslautern, FRG