spa@fctunl.rccn.pt (Salvador Pinto Abreu) (09/28/90)
I know this was discussed some time ago, but I don't have the articles any more. What is the status on programs to produce ST-readable (2-sided) floppies on a SPARCstation, either fixes to the Sun programs or new ones would do. I seem to remember colas@avahi.inria.fr (Colas Nahaboo) had something along these lines, how are things coming along? /.salvador -- --- Salvador Pinto Abreu BITNET/Internet: spa@fctunl.rccn.pt +---------------------------------+ UUCP: spa@unl.uucp | Departamento de Informatica +----------------------------------+ | Universidade Nova de Lisboa 2825 Monte Caparica, PORTUGAL | +--------------------------------------------------------------------+
wilker@descartes.math.purdue.edu (Clarence Wilkerson) (09/30/90)
The sparc-mtools package from the sun archives at titan.rice.edu work on my sparc 1+ to read and write 3.5" 720k disks for my PC. Clarence Wilkerson
scott@tab00.larc.nasa.gov (Scott Yelich) (10/01/90)
>The sparc-mtools package from the sun archives at titan.rice.edu >work on my sparc 1+ to read and write 3.5" 720k disks for my PC. >Clarence Wilkerson Well, I have applied ALL necessary patches as well as received two binaries from a friend over the network, but I have yet to have a sparcstation format a 3.5" disk and have my 1040st (TOS1.0) read the disk without scrambling the data. I have tried formatting disks on the ST and the sparcstation and neither seems to make a difference. Next, I have yet to try to format a disk on a REAL IBM (clone! :-) ) but I don't think that will make a difference. If someone actually has this type of system working for them, I would LOVE to test your methods! Would you send me your binaries and the EXACT steps you use to read the disks? I think it's all a myth! It can't be done... [That ought to do it!] -- Signature follows. [Skip now] ----------------------------------------------------------------------------- Scott D. Yelich scott@[xanth.]cs.odu.edu [128.82.8.1] After he pushed me off the cliff, he asked me, as I fell, ``Why'd you jump?'' Administrator of: Game-Design requests to <game-design-request@cs.odu.edu> ODU/UNIX/BSD/X/C/ROOT/XANTH/CS/VSVN/ -----------------------------------------------------------------------------
ripley@opal.cs.tu-berlin.de (Hans-Ch. Eckert) (10/04/90)
In article <SCOTT.90Oct1000340@tab00.larc.nasa.gov> scott@tab00.larc.nasa.gov (Scott Yelich) writes:
Well, I have applied ALL necessary patches as well as received two
binaries from a friend over the network, but I have yet to have a
sparcstation format a 3.5" disk and have my 1040st (TOS1.0) read the
disk without scrambling the data.
Well, I have to admit, that I'm using TOS 1.4; the version of
mtools that is installed here works just fine for me.
I had no trouble, even when using 'mkdfs -f' to format a new disk.
Greetings,
RIPLEY
--
Greetings from RIPLEY | UUCP: ripley@tubopal.UUCP (ripley@opal.cs.tu-berlin.de)
Hans-Christian Eckert | ...!unido!tub!opal!ripley (Europe)
D-1000 Berlin 30 | ...!pyramid!tub!opal!ripley (World)
Regensburger Str. 2 | BITNET: ripley%tubopal@DB0TUI11.BITNET (saves $$$)ralph@laas.fr (Ralph P. Sobek) (10/08/90)
I have absolutely no problem in formating/reading/writing PC and ST
compatible floppies, using the mtools package which was posted to the
net (comp.sources.sun, I believe). I had to add another patch in
order to make the floppies readable under Gulam; Gulam does not seem
to like an all-blanks volume label.
Mtools is not perfect, but I use it very often. I've tried to
contact the author -- but no luck. For those that might
be interested I'll post my private `patch4' here. Just run it through
patch.
*** ./init.c Thu Jun 14 13:01:58 1990
--- 1.6.2/init.c Tue May 29 17:41:27 1990
***************
*** 11,17 ****
#include "devices.h"
#include "msdos.h"
! #define DUP_FAT
extern int fd, dir_len, dir_start, clus_size, fat_len, num_clus;
extern unsigned char *fatbuf;
--- 11,17 ----
#include "devices.h"
#include "msdos.h"
! /* #undef DUP_FAT */
extern int fd, dir_len, dir_start, clus_size, fat_len, num_clus;
extern unsigned char *fatbuf;
*** ./mkdfs.c Thu Jun 14 12:39:04 1990
--- 1.6.2/mkdfs.c Wed Jun 6 10:55:32 1990
***************
*** 95,108 ****
for( sec=fat_len; --sec ; )
Write(fd,buf,MSECSIZ) ; /* Rest of FAT */
}
! if (strncmp(disklabel," ",11) != 0) {
! strcpy(((struct directory *)buf)->name,disklabel) ;
! ((struct directory *)buf)->attr= VOLLBL ;
! Write(fd,buf,MSECSIZ) ; /* Root dir */
! bzero(buf,strlen(disklabel)) ;
! ((struct directory *)buf)->attr= 0 ;
! }
! else dir_len++ ;
for( ; --dir_len ; )
Write(fd,buf,MSECSIZ) ; /* Root dir */
}
--- 95,105 ----
for( sec=fat_len; --sec ; )
Write(fd,buf,MSECSIZ) ; /* Rest of FAT */
}
! strcpy(((struct directory *)buf)->name,disklabel) ;
! ((struct directory *)buf)->attr= VOLLBL ;
! Write(fd,buf,MSECSIZ) ; /* Root dir */
! bzero(buf,strlen(disklabel)) ;
! ((struct directory *)buf)->attr= 0 ;
for( ; --dir_len ; )
Write(fd,buf,MSECSIZ) ; /* Root dir */
}
--
Ralph P. Sobek Disclaimer: The above ruminations are my own.
ralph@laas.fr Addresses are ordered by importance.
ralph@laas.uucp, or ...!uunet!laas!ralph
If all else fails, try: sobek@eclair.Berkeley.EDU
===============================================================================
Reliable software should kill people reliably! -Andy Mickel, Pascal News #13,78bro@eunomia.rice.edu (Douglas Monk) (10/10/90)
In article <RALPH.90Oct8121408@orion.laas.fr> ralph@laas.fr writes: >I have absolutely no problem in formating/reading/writing PC and ST >compatible floppies, using the mtools package which was posted to the >net (comp.sources.sun, I believe). I had to add another patch in >order to make the floppies readable under Gulam; Gulam does not seem >to like an all-blanks volume label. There are three possible problems some people may encounter: 1) Minor problem: To compile, I had to change the source to rename a type to "union __wait" in the function formatit in file "mkdfs.c": some include file dependency no doubt. 2) MAJOR PROBLEM: as distributed, init.o *must* be compiled with DUP_FAT defined. (I believe your patch fixes that, but I can't read patch myself :-). I made DUP_FAT the default in my version: My Atari needed the second FAT to read disks correctly. Why leave some machines out? 3) Medium problem? : Just like MSDOS machines, these programs don't write a disk serial number like Ataris want. Your problem with Gulam may be related to that somehow: no serial number, and Ataris get confused as to when they need to re-read the disk FAT: all disks look alike. (But the volume label is a file, not in the boot sector banner where the serial number goes, so I am not sure this is your problem. I'll try gulam tonight to see if my version works OK.) Hitting <esc> rereads disks in which I have written serial numbers, so I think it is OK - I didn't have real good docs when I wrote this patch. Doug Monk (bro@rice.edu) Disclaimer: These views are mine, not necessarily my organization's.