Re: amiga 'native OS' install
Adam Di Carlo wrote:
>
> On Wed, 20 Jan 1999 19:32:39 -0800, Michael Schmitz <MSchmitz@lbl.gov> said:
> > 2.5: you're going to have a hard time finding any vendor selling
> > m68k Amigas, Ataris or Macs. If you're lucky you may find them
> > second hand. In this context, mentioning vendors that ship Debian
> > pre-installed on m68k machines is an Intelsim and can be deleted
> > without losing any information for the user.
>
> Saying it's an Intelism is wrong. Remember, we're releasing for Sparc
> and Alpha as well. I've added a note however.
Ok, got me there. I still live in the 'Intel vs. m68k' world :-)
> > In summary, I don't see the need to name the bad guys, and the
> > simple hint 'ask for Linux support when shopping for hardware'
> > should be enough.
>
> Well, I don't mind slamming them a little for it. Here's what I put:
>
> ... Another example is the proprietary hardware in the older
> Macintosh line.
>
> <![ %m68k [ In fact, no specifications or documentation have ever
> been released for
Insert here: any Macintosh hardware, most notably
> the ADB controller (used by the mouse and
> keyboard), the floppy controller, and all acceleration and CLUT
> manipulation of the video hardware. In a nutshell, this explains
> why the Macintosh Linux port lags behind other Linux ports.
Getting myself into a flame war here: 'Most information on the hardware
had to ble glanced from the NetBSD port for Mac (yikes)' (No, not serious)
> ]]>
>
> I think it doesn't hurt to explain some of the glitches in the Mac
> port of Debian.
Ok, but if we slam them we should get the facts straight.
> > 3.1: Add 'if you repartition the boot drive, prepare for
> > reinstalling the operating system from distribution media' ?
>
> Added:
>
> Even if you are installing a multi-operating system, make sure that
> you have on hand the distribution media of any other present
> operating systems. Especially if you repartition your boot drive,
> you might find that you have to reinstall your operating system's
> boot loader.
Not only the boot loader, for Mac it's the whole friggin' MacOS :-(
> > 3.2: The fdisk manpages all lead to nothing; at least the Atari man
> > page exists.
>
> This is a fact of how you setup your top-level Makefile variables.
> 'pathcmd' needs to be able to find {atari,amiga,pmac,mac}-fdisk_*.deb
> packages to extract the proper man pages.
I was talking about _your_ web pages :-) On that issue, I discovered that I
actually need to install 'man' to extract the man pages :-(((( The Atari man
page, at least, was found but failed to turn into something useful. Maybe I
just fudge around with groff there.
> > 3.3: the firmware section can be omitted; it's more relevant to
> > point out the operating system version requirements
> > here. I.e. AmigaOS patches or ROM versions (maybe in the FAQ)
>
> What FAQ? m68k FAQ? Or the amiga faq (URL needed for the latter)? I
> looked and couldn't find any stuff about Amiga patches or ROM
> versions.
The m68k FAQ. The only thing I recall is that 'setpatch' needs to run before
the bootstrap on some machines. Amiga experts are politely asked to fill in
the
details :-)
> > and
> > for Mac users the minimum MacOS version (>= 7.1 I think, system in
> > 32 bit mode recommended).
>
> Well, it's hard for me to omit a section for one architecture only,
> but I've added. I've stubbed out this section...
>
> Could someone look at
> <URL:http://www.netbsd.org/Ports/mac68k/faq/faq-3.html#ss3.7> and tell
> me what if any of the recommendations listed there are required?
> These don't seem to be mentioned in the Mac install guide.
>
> 1.Monitor Control Panel is set to 1-bit video. If you have more
> than one video card, make sure both are set to 1-bit (this is no
> longer necessary unless you will be using dt or monochrome X,
> but anything higher than 8-bit just might hang the machine).
Set to anything up to 8 bit (256 colors) video. (Mac users will have trouble
to
translate bits into colors so better give the number of colors). 1 bit
isn't necessary, we don't hardcode the bit depth in the kernel and handle
1,2,4
and 8 bit nicely (even 16,24 and 32 bit if we just use 2.1 kernels I think).
> 2.your machine prefers an FPU (M68881/M68882 or full 68040).
Currently: requries an FPU. FPU emulation works in 2.1.131 and 2.1.120 but
is
broken in 2.0.33pl1.
> 3.your 68020 machine has a PMMU (M68851).
Right.
Both are covered in the m68k FAQ.
> 4.32-bit addressing is turned "on" in the Memory Control Panel.
Not a must, but that's what I meant with 'runs in 32 bit mode)
> 5.Machines with 32-bit dirty ROMs have MODE32 installed with
> 32-bit addressing turned "on". (These machines are the Mac II,
> IIx, IIcx, and SE/30. There are others, but they will not run
> NetBSD.)
> 6.Virtual Memory is turned "off" in the Memory Control Panel.
Should all be covered in the mac68k FAQ, but I better double check.
> 12.You are booting without any inits (i.e. extensions), especially
> RAM Doubler. Mode32 is the exception. To disable extensions,
> hold down the Shift key during MacOS boot.
Not sure if that applies. Except in rare cases, people don't need to turn
extensions off. And a hint 'try extensions off and remove things like cache
cards etc.' is hopefully in the FAQ.
> 13.Your are running at least System 7.0. The current version of the
> Booter utility no longer works under System 6.x.x.
7.0 video drivers are buggy on some cards, better use 7.1. I've never seen
or tried 6.x, but as out booter's MacOS guts were derived from the BSD
booter
that caveat probably applies.
> 14.Remove any non-standard (i.e. non-Apple) hardware. Not all
> hardware is supported at the moment, and some may cause the boot
> to hang.
Cache cards and funny processor upgrades are the only things I can imagine
would give trouble. Apple hardware is in no way less prone to hang the boot
than third party stuff (remember, we have no docs on Apple HW either).
Better
remove the whole Mac and get a decent m68k machine :-)))
> > 4.5.x: Information on Atari and Mac partitioning is missing.
>
> Ugh; I know. I have to go through the install guides and add
> this. *SOB* *SOB* Can't someone send me patches? Michael, I love you
> but your rambling comments about completely lacking sections are a far
> cry from acceptable documentation. And other people are getting
> pissed at me since I'm lagging behind on getting changes implemented.
The problem is that I only know one disk tool that permits editing the
partition
type, so all I can do is describe that one. And only as far as I don't have
to
sacrifice a partition for it.
Similar for Mac, but I can trash a few Zip media for that.
If someone yells at you for lack of this documentation, please forward to
me.
I'd really like to explain to some people the specific conditions we m68k
porters work in: constant flow of new and updated packages to recompile,
occasional perks like yet another package that broke in some incompatible
way,
m68k pacthes not applied for the x-th time in a row (gdb), someone installed
incompatible binary-all data for a m68k package where the binary package is
stuck in incoming (kbd), things like boot-floppies have to be 'bootstrapped'
by repeatedly building and fixing new bugs as the build proceeds even though
part of these things should have been fixed by my patches to the previous
version.
The top of my list: apt-0.1.8 which is needed for upgrade-m68k trashed my
home build environment yesterday (installed in /usr/ instead of in
debian/tmp/usr
and roached ftp). I hate wasting my time on broken source packages like
that.
The list is incomplete, but then, Debian isn't the only thing I'm doing. The
bottom line is that things pile up on the TODO list faster than they are
removed,
and fixing documentation is (in my book, sorry) assigned a lower priority
than fixing the documented packages. I know it shouldn't be that way, but
it often turns out that way, sorry.
> I'm just going to start slapping this stuff in, I'm tired and your
> mail is long. ;)
Sorry for the long rants, I try to cut them short after the above one :-)
> > For all m68k machines, booting from an existing operating system is
> > the _only_ option. There's a LILO for Amiga and even for Atari but
> > no one has written the scripts to use these boot methods for
> > Debian/68k yet.
>
> I don't understand why you are building disk images then? Moreover,
> you are contradicting *at* least
> <URL:http://www.linux-m68k.org/debian-mac.html> where he goes on about
'he' == 'me'. I contradict myself quite a lot, given that the whole project
evolves. Haven't had time to update that.
> how you can build floppy images. In the Atari pages, he says "Note:
> initially, only the floppy install method is supported."
>
> I'm very confused.
Let me quote 'hysterical reasons' for that inconsistency. Both install
guides
were initially written at 2.0 release time, and the only thing available at
that
time were the Atari boot floppies, I did the install.lzh later on but never
touched the install guide after that.
For the Mac, the floppy images (resc1440.bin, drv1440.bin) have been built
solely to keep dinstall happy. My dirty little secret is that both were, in
fact,
identical to the Atari disk images initially :-) The floppy image that can
be
written to floppy was manually created from an Atari rescue floppy, where I
removed the Atari booter and replaced it with the Mac booter. That was all
hacked up on the fly and the documentation is a bit confusing.
Using a floppy image (MacOS format) has it's huge advantage in that I can
get the
path settings for kernel and ramdisk right only for the floppy, the user has
to
select kernel and ramdisk manually before booting off the disk install
system.
> > 5.3:
>
> > amigainstall.lha, install.lzh (Atari) and Install.sit (Mac) are
> > missing.
>
> Should it be:
>
> <url id="amiga/amigainstall.lha"> (Amiga), <url id="atari/install.lzh"> (Atari),
> or <url id="mac/Install.sit"> (Mac) -- Operating system installers
Sounds OK, but better 'model specific installers' :-)
Michael
Reply to: