cgrazian@csserv2.ic.sunysb.edu (GRAZIANO) (02/20/91)
This message was posted some time ago: >I recently got the 1.5 Demo disk by FTP from ftp.cs.vu.nl in /minix. >This file is a disk image. My question is, how can I transfer this onto a >standard PC floppy? I was hoping a response to this would be posted, but haven't seen one, so any reply must have been by mail. Could someone post this information? Until I find out how to do this, the demo disk is a useless file taking up space on my disk... >Does anyone know if there is a utility available somewhere to copy a file onto >a DOS floppy, under DOS. Obviously it needs to copy from track 0, sector 0, i.e. >including the boot block. This isn't good enough to make a demo disk, is it? It needs to be non-DOS, right? >It might also be a good idea if Dr. Tanenbaum was to place this info in the >Read_Me file with the demonstration. Has this been done? Thanx in advance for any help. -- Christopher Graziano, Stony Brook, NY /-------\ <===+ cgrazian@ic.sunysb.edu (129.49.12.74) | O O | | Bitnet: CGRAZIAN@SBCCVM | \___/ | The Elder \_______/ Sign
steveq@syd.dms.CSIRO.AU (Stephen Quigg) (02/20/91)
In article <1991Feb19.182447.6756@sbcs.sunysb.edu> cgrazian@csserv2.ic.sunysb.edu (GRAZIANO) writes: >This message was posted some time ago: >>I recently got the 1.5 Demo disk by FTP from ftp.cs.vu.nl in /minix. >>This file is a disk image. My question is, how can I transfer this onto a >>standard PC floppy? > >I was hoping a response to this would be posted, but haven't seen one, >so any reply must have been by mail. > >Could someone post this information? Until I find out how to do this, >the demo disk is a useless file taking up space on my disk... > >>Does anyone know if there is a utility available somewhere to copy a file onto >>a DOS floppy, under DOS. Obviously it needs to copy from track 0, sector 0, i.e. >>including the boot block. > >This isn't good enough to make a demo disk, is it? It needs to be >non-DOS, right? > >>It might also be a good idea if Dr. Tanenbaum was to place this info in the >>Read_Me file with the demonstration. > >Has this been done? > >Thanx in advance for any help. >-- >Christopher Graziano, Stony Brook, NY /-------\ <===+ >cgrazian@ic.sunysb.edu (129.49.12.74) | O O | | >Bitnet: CGRAZIAN@SBCCVM | \___/ | The Elder > \_______/ Sign What I tried was the following; (were talking MSDOS here) debug demo_dsk.ibm -w 100,0,0,2d0 -q ( the "-" is the debug prompt.) What happens is that debug reads in the file, and then dumps the image in ram to drive a: ( command means "write from memory starting at CS:100 to drive a: (0), starting at sector 0; 720 blocks (sectors) to be written"). HOWEVER, when I tried to boot the disk (on several different machines), it started to load (got the welcome message), but it fell over before the prompt came up. I'm fairly sure that debug dumped the image properly, and the image has the correct CRC, so I don't know what the problem is. I'd like to hear from anyone else who tries the same. Thanks, Stephen Quigg. steveq@natmlab.dap.csiro.oz.au
wilker@gauss.math.purdue.edu (Clarence Wilkerson) (02/20/91)
Here's a couple of Turbo C hosted on PC programs I wiped up to
do the chore of writing the demo disk to floppy (RAWFILL)
and another one to read a 360k minix floppy ( VOLCOPY). I think
DEBUG may wrap around when you do the w100 0 0 number method.
I didn't get that to work either!
RAWFILL.C:
#include <stdio.h>
#include <dos.h>
char buffer[520];
main(argc,argv) int argc; char *argv[];
{ int drive, c, next,count;
char *s;
FILE * infile;
if ( argc < 3) {
fprintf(stderr,"RAWFILL file drive \n");
return(-1);
}
infile = fopen(argv[1],"rb");
if( infile == (FILE *)NULL ) {
fprintf(stderr,"Bad file name.\n");
return(-1);
}
s = argv[2];
c= *s;
drive = ( toupper(c) ) -65 ;
if ( (drive < 0) || ( drive > 1) ) {
fprintf(stderr,"Bad drive name.");
return(-1);
}
next = 0;
while ( !feof(infile) ){
count=fread(&buffer[0],512,1,infile);
abswrite(drive,1,next,&buffer[0]);
next++;
if ( next > ( 80*9 ) ) goto toomany;
}
toomany:
fclose(infile);
return(0);
}
VOLCOPY.C :
#include <stdio.h>
#include <dos.h>
char buffer[520];
main(argc,argv) int argc; char *argv[];
{ int drive, c, next,count;
char *s;
FILE * outfile;
if ( argc < 3) {
fprintf(stderr,"VOLCOPY drive filename \n");
return(-1);
}
outfile = fopen(argv[2],"wb");
if( outfile == (FILE *)NULL ) {
fprintf(stderr,"Bad file name.\n");
return(-1);
}
s = argv[1];
c= *s;
drive = ( toupper(c) ) -65 ;
if ( (drive < 0) || ( drive > 1) ) {
fprintf(stderr,"Bad drive name.");
return(-1);
}
next = 0;
while ( next < (9*80) ){
absread(drive,1,next,&buffer[0]);
count=fwrite(&buffer[0],512,1,outfile);
next++;
}
toomany:
fclose(outfile);
return(0);
}
If you get an abort/retry/ question from MSDOS, do a retry.
This on my AT clone did seem to write and read the demo disk.
Your mileage may vary!
Clarence Wilkersoncy5@cunixa.cc.columbia.edu (Conway Yee) (02/20/91)
In article <1991Feb19.182447.6756@sbcs.sunysb.edu> cgrazian@csserv2.ic.sunysb.edu (GRAZIANO) writes: >This message was posted some time ago: >>I recently got the 1.5 Demo disk by FTP from ftp.cs.vu.nl in /minix. >>This file is a disk image. My question is, how can I transfer this onto a >>standard PC floppy? > >I was hoping a response to this would be posted, but haven't seen one, >so any reply must have been by mail. > >Could someone post this information? Until I find out how to do this, >the demo disk is a useless file taking up space on my disk... ftp.cs.vu.nl contains a program which can do the transfer. This is for the PC-MINIX. The directory /minix contains the source and the executable. I tried it. The program works. Conway Yee, N2JWQ yee@ming.mipg.upenn.edu (preferred) 231 S. Melville St. cy5@cunixa.cc.columbia.edu (forwarded to above) Philadelphia, Pa 19139 yee@bnlx26.nsls.bnl.gov (rarely checked) (215) 386-1312
Griffiths_DN@cc.curtin.edu.au (02/20/91)
In article <1991Feb19.213539.7257@syd.dms.CSIRO.AU>, steveq@syd.dms.CSIRO.AU (Stephen Quigg) writes: > What I tried was the following; (were talking MSDOS here) > > debug demo_dsk.ibm > -w 100,0,0,2d0 > -q > > ( the "-" is the debug prompt.) What happens is that debug reads in the > file, and then dumps the image in ram to drive a: ( command means "write > from memory starting at CS:100 to drive a: (0), starting at sector 0; 720 > blocks (sectors) to be written"). > HOWEVER, when I tried to boot the disk (on several different machines), it > started to load (got the welcome message), but it fell over before the prompt > came up. I'm fairly sure that debug dumped the image properly, and the image > has the correct CRC, so I don't know what the problem is. I'd like to hear > from anyone else who tries the same. > Thanks, > Stephen Quigg. > steveq@natmlab.dap.csiro.oz.au > D I initially attempted to do the above without success. However, using the absolute write function of the Norton Utilities proved successful. Read the file in then use the menu to select absolute write on sector 0 etc. It worked for both a 360k 5.25" and 720k 3.5" disk. --------------------+-------------------------------------------------------- Don Griffiths | JANET munnari!cc.curtin.edu.au!Griffiths_DN@uk.ac.ukc Information Systems | UUCP uunet!munnari!cc.curtin.edu.au!Griffiths_DN Curtin University | Bitnet Griffiths_DN%cc.curtin.edu.au@cunyvm.bitnet GPO Box U1987 | PSImail psi%050529452300030::Griffiths_DN PERTH, 6000 | Internet Griffiths_DN@cc.curtin.edu.au Western Australia | ACSnet Griffiths_DN@cc.cut.oz.au --------------------+---------------------------------------------------------- Telex : AA-92983 CURTIN Fax : +61-9-351-3076 Telephone : +61-9-351-7691 -------------------------------------------------------------------------------
ast@cs.vu.nl (Andy Tanenbaum) (02/20/91)
In article <1991Feb20.035756.27904@cunixf.cc.columbia.edu> cy5@cunixa.cc.columbia.edu (Conway Yee) writes: >ftp.cs.vu.nl contains a program which can do the transfer. a Keep your pants on (trousers for readers in the U.K.) When I am done testing things I'll announce it. I won't forget. Honest. I'd like to get it reasonably debugged first. Please be a bit more patient. Andy Tanenbaum (ast@cs.vu.nl)
burgess%creek.decnet@hqhsd.brooks.af.mil (CREEK::BURGESS) (02/21/91)
Quoting: Stephen Quigg <steveq%SYD.DMS.CSIRO.AU> > What I tried was the following; (we're talking MSDOS here) > >debug demo_dsk.ibm >-w 100,0,0,2d0 >-q > >( the "-" is the debug prompt.) What happens is that debug reads in the >file, and then dumps the image in ram to drive a: ( command means "write >from memory starting at CS:100 to drive a: (0), starting at sector 0; 720 >blocks (sectors) to be written"). > HOWEVER, when I tried to boot the disk (on several different machines), it >started to load (got the welcome message), but it fell over before the prompt >came up. I'm fairly sure that debug dumped the image properly, and the image >has the correct CRC, so I don't know what the problem is. I'd like to hear >from anyone else who tries the same. Steve, & *, I am replying here since I can't get to a foreign host. This is a good start. Points to look for the next time: 1. Make sure the image size is represented properly. The file size will be the BX (high order word)*64K+CX (low order word). To compute the number of sectors to dump, take this value and shift right an appropriate amount (usually nine bits) to compute the correct number of sectors. Remember to add one to the final count if any bit in the first nine were not zero. 2. After the write, restart debug, fill the low end of the workspace with nulls, and use the load ('l') command to load the disk image back. With that accomplished, use the 'n' command to give this image a name, and 'w' it out to a new file. Compare these; they should be identical. For example: C:\> debug -ndemo_dsk.ibm (identify the file) -lcs:100 (no defaults for this boy) -r (dump registers) AX:0000 BX:0004 CX:F200 ... (for example. BX:CX >> 9 = 0x279) -wcs:100,0,0,279 (assuming 512 byte sectors, the default) -or- ( >--- These are examples. NOT VERBATIM) -wcs:100,0,0,4F2 (assuming 256 byte sectors, BX:CX >> 8 = 4F2) -q C:\> debug -fcs:100 L 1000 0 (fills memory with zeroes) -lcs:100,0,0,279 (number of sectors from before) -nsteve.ibm (name the default output file 'steve.ibm') -w (write the file) 4F200 bytes written -q C:\> dir *.ibm compare the sizes. use debug to compare the resulting files. Once loaded into debug, they should be identical. 3. Finally, make sure that the systems you are working on are really minimal configurations. It should work on an IBM-PC XT compatible, assuming you don't have an 'unoriginal' hard drive, video, keyboard, etc. The fact that it fails on many systems implies a problem with the image (IMHO). 4. BTW, good idea. I was writing a PROGRAM to do this. Silly me, I had a wheel here all along... TSgt Dave Burgess Armstrong Lab, Det 4 Brooks AFB, TX
Griffiths_DN%CC.CURTIN.EDU.AU@ricevm1.rice.edu (02/21/91)
>I initially attempted to do the above without success. However, using >the absolute write function of the Norton Utilities proved successful. >Read the file in then use the menu to select absolute write on sector 0 >etc. It worked for both a 360k 5.25" and 720k 3.5" disk. Hey folks, there's a *VERY* easy way to get the diskette; there's a program called RAWRITE.C that is sepcifically for the task of making the demo disk from the file... There's no need to go to all the trouble of using things like Norton's... Frank
nmsc202@lanl.gov (Victor C. Limary) (03/03/91)
Although I haven't gotten the demo disk to work yet, the article by clk@Splash.Princeton.EDU seems like it might get the demo to work on my system, since I get the same error message. From the manual, Minix seems pretty nice, for the price, but I have a lot of questions that I would like to know the answers to. 1) Does Minix V1.5 run in 386 protected mode? or do I have to buy Minix-386? 2) Is there such a program that lets me run MS-DOS programs from Minix. I don't quite understand the discussions here on that matter, but from what I could figure out, people have gotten Minix to work under MS-DOS. But what about the other way around? 3) Exactly how would I install Minix on a system with MS-DOS already installed? Would I have to reformat and repartition the hard disk? Or does Minix use a FAT, like MS-DOS? 4) Is it at all possible to run Minix from high density 5.25" and 3.5" floppy disks? 5) What exactly are the hardware requirements for Minix? The demo disk's manual made no mention of hardware reqquirements. I have a 386 with 2 megs of memory, 65 meg hd, with a total of about 7 megs free, SVGA, and high density 3.5" and 5.25" disks. 6) How much support is there for Minix? Could I find Minix software in stores or mail-order houses, or do I have to FTP everything? 7) I would assume that Minix cannot run Unix or Xenix software. Is there an X windows software package for Minix? Sorry if my list of questions is long, but before I spend my money on an operating system, I would like to know how strong the support for it is. Price wise, Minix seems like a better alternative to Unix or Xenix, for me, but I don't wantto end up with an operating system that is being kept alive by a handful of people. Thanks. Victor Limary nmsc202@beta.lanl.gov nmsc202@r.lanl.gov mimas!vcl@bbx.basis.com