Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!batcomputer!munnari.oz.au!metro!natmlab.dap.csiro.au!ditsydh.syd.dit.CSIRO.AU!evans
From: evans@syd.dit.CSIRO.AU (Bruce.Evans)
Newsgroups: comp.os.minix
Subject: Re: Amiga Minix Questions (Floppy drives)
Keywords: floppy 68000 compatibility
Message-ID: <1990Sep25.140832.8572@syd.dit.CSIRO.AU>
Date: 25 Sep 90 14:08:32 GMT
References: <7583@star.cs.vu.nl> <1453@targon.UUCP> <669@philica.ica.philips.nl>
Organization: CSIRO Division of Info Tech, Sydney, Australia
Lines: 15

In article <669@philica.ica.philips.nl> adrie@beitel.ica.philips.nl (Adrie Koolen) writes:
>(720KB) diskettes. But Minix doesn't consistently use int's or short int's
>to describe the zone and inode bit-maps. Because in 32-bit mode int's are
>not the same as short int's, this presented problems. I decided to use
>int's, but I later discovered that this made the 68000 and Sparc diskettes
>incompatible. I just left it that way. You can read an 68000 diskette on

Actually, this is a byte-order problem and not an int-size problem. Minix-386
file systems are compatible with Minix-PC file systems because the byte order
agrees with the bit order. However, big-endian machines like the ST are
incompatible with themself when different sizes of ints are used! The problem
should be fixed by using unsigned chars for the bit maps, not shorts. Then
the bitmaps will be the same for ST and PC file systems too.
-- 
Bruce Evans		evans@syd.dit.csiro.au