Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!gatech!udel!mmdf
From: Dickson@pco-multics.hbi.honeywell.com (Paul Dickson)
Newsgroups: comp.os.minix
Subject: Re: Cross Compiling under TurboC Professional Package
Message-ID: <10847@louie.udel.EDU>
Date: 14 Mar 89 22:17:44 GMT
Sender: mmdf@udel.EDU
Lines: 52

Yes, the "Too many Relocations" does mean that some of the code you
compiled wasn't done in TINY model. Check you make file, that's were
Kevin and I had this problem.

Kevin Fleming and I are working on a port for the Slicer, but we've
first being updating our code on the PC (to get a standard 1.3 base to
work from).  For the past month (read as only two sessions...) we've had
the problem that when RAM disk was being loaded the system would stop,
but TTY would continue to echo typed characters.  Hitting F1 would show
us that FS was waiting for FLOPPY, while FLOPPY was IDLE.  In
desparation, we pulled out our original 1.1 disks and discovered that it
did the same thing.  So at 12:30 AM Sunday morning, I took the disks
into work and tried them on one of the ATs there.  The 1.3 disk we were
trying to boot worked fine on the AT, but wouldn't work on our original
machine.  We believe it is the floppy controller card, as that is the
only thing we can think of that has changed on the original machine
since we last booted Minix successfully (which was more than a year
ago).  Has anyone else had problems with floppy controllers?  I'll
followup this message when I learn the brand name of the controller.

We have put together quite a bit of tools on the DOS side for developing
Minix.  We have one that changes text files for Minix by changing ^J's
to ^M^J's and another to do the reverse.  We have another called
readdisk which will read the floppy disk and write it into one file on
the hard disk.  Then other programs (ie.  readfs?) can access the data
much faster.  We another program that does the reverse (writdisk).  (The
names of these programs are from memory and are usually invoke from make
files, so they may not match reality)

One of the most annoying features of DOS, is that if DOS can't read a
disk, it assumes that the disk is Single-Sided.  The most reliable way
around this problem, is to format each disk before writing on it.

Other problems that I'm aware of is that some of the kernel code is
dependant on the Minix Compiler.  We found a variable that was greater
than 8 characters that had different endings.  The Minix compile only
looks at the first 8 characters, the Turbo linker flagged these as
undefined.  They were fairly easy to find and fix.

Kevin and I a seriously thinking about writing a Minix booter for DOS,
so instead of writing a boot disk, the Minix code is loaded from the
hard disk into memory and then execution is tranfered to Minix.  This
would get rid of the formatting of the floppy disk from the debug cycle.

Now that we know that our 1.3 is good, we'll update to 1.4a and attempt
to find the answer to the floppy controller problem.  I'll also try to
compile a more complete list of tools that we use under DOS for Minix
development.

          -Paul Dickson

ARPA:     Dickson at PC-Multics.HBI.Honeywell.COM