Re: mac classic with scsi-ethernet?
Udo,
>El JoPe Magnifico <jope@n2h2.com> wrote me that there are license
>differences
>
Yeah, I saw that response too.
> wo> I have installed a minimal Debian/68k on an old SyQuest 44MB disk. The
> wo> Debian is just the base obviously, but it does work!
>
>Oh, then I'll move the 80M disk to the Classic and put a 1G (or so) disk
>in the Classic II so I can run macOS, Linux and maybe (open)bsd on it.
>
I'd do that too if I had a disk that large available, but having this
small
external drive with a working Linux for Mac on it makes it really easy to
try it on the variety of machines I have available here.
>
>Debian installation files go on the HFS partition.
>BTW: does the floppy work in some *bsd flavour?
>
Maybe someone that has figured it out and made it work will chime in.
>
> wo> I don't think the serial ports work either, but I hesitate to say that
>
>I can test that here. Enough cables and machines (PC's, mainly).
>
> wo> I'll try them again and let you know how it goes. This time with a
>
>Is there any difference (with regard to the serial ports) between the
>2.1.x and 2.0.x kernels?
>
Thats exactly what I want to find out myself. I'll get a chance to give
it a try later today, I hope. I'll let you know what I find.
>
> wo> One thing I really like is the handling of MacOS filesystems from the
> wo> Debian side. You just mount'em, and its there. Cool! And very nice
>
>Just like mounting MSDOS (FATxx) filesystems on the PC? Cool!
>
Yep, and it all works smooth as silk. Very nice.
>
> wo> I'm not sure if you realize this or not, but with the variability of
> wo> the Mac hardware, and in particular its ROMs and LSI chipsets being so
> wo> different from model to model, I'd say these guys have pulled off a
>
>I'm quite new to Macs so I don't know too much. ROMs shouldn't be used on
>PC's but Mac ROMs can be 32-bit clean, I read. This means they can also be
>used reentrant?
>
Well, yes. In the context of NetBSD for example, most of the Apple cards
(maybe all I guess) provide driver code in ROM that is used by NetBSD
directly
with only a layer of interface code between them to iron out the details
of
the call interface and returned parameters, etc, for many of them. So,
in
many cases, the very same code that would be executed in MacOS is also
used
by NetBSD. But, this gets messy...as you might imagine.
In other words, in many of these cases NetBSD uses the ROM code itself to
implement the functionality of the driver. The problem with many of them
is
the memory mapping of both the physical expansion slots, and on some
Mac's this
is virtual in the sense that there may be NO physical slots, but the code
maps
an interface (for video lets say) to a memory location that would
otherwise be
occupied in the memory map by real, physical expansion slots. This is
all
complicated by the fact that this changes in the onboard logic elements
from
Mac model to model, unfortunately! This is part of the issue with one
Mac using
the "Cuda" chipset and another using something different, for example.
It is
also part of why the internal video works properly for some, and not
other
models, that sort of thing.
I'm probably not saying this accurately, but this is the understanding
that
I have gained of the problems these guys have with reverse engineering
alot
of this, without the support of accurate info from Apple, for example.
It
all gets even worse when you mix in the changes that a vendor might make
in
their ROM code too, and I've been caught by that issue myself. The
difference
in ROM rev from one card to another of the SAME interface CAN upset the
whole
deal, as it did for me! Actually resulted in a kernel trap to the
debugger on
one card, while the other worked flawlessly with the same kernel.
>
>I run redhat on my PC and chose debian for my mac because they have these CD
>
I used to run nothing but Debian on Intel, but I only have one Intel box
on
the air these days, and I run RH on it. But thats only because I also
have
boxes at work that run RH. At the time I made that switch, the Debian 1.2
had been made available (I think it was) and it had some grief associated
with it. I tried to install it from an InfoMagic CD set, but that failed.
So, the switch was on. I ended up putting SuSE and RH on that box.
>
>images for FTP. Once we succeed in burning this image to CD-R I can try a few
>things. I suppose this image is plain ISO9660 with rockridge extensions? Maybe
>some Mac-like FS?
>
Mac's can, with the proper SW (MacLink I think they call it) use these,
yes.
However, I've tried repeatedly to mount an ISO9660 CD on my Debian/Mac
system
and it locks up the system, everytime! It crashes apparently, since
nothing
works. Can't switch to another console, Ctrl-Alt-Del does nothing. Its
dead.
The only recourse is the power switch. I can't say I've tried this on all
the kernels I have here or not however. I don't think I have. My CD is
an
Apple SCSI external. I do have another I could try, but this one is
already
cabled up in my SCSI chain, so its not really convenient to try the other.
>
>I already wrote that once my Classic II can connect to an ethernet everything
>is really OK: a truly portable linux box (and no plain laptop: i.e. a pc)!
>
Oh yeah, thats why I focused on getting the network going here. The
machine
no matter what it is, simply isn't very useful to me if that doesn't work.
>
>I read that there are already some initiatives for supporting SCSI <->
>Ethernet adapters but I couldn't find out what adapters are being worked on,
>by whom or what the status is. Does anybody have a clue about this?
>
I sure don't, and this list is so dormant that little info gets passed
here, certainly not that I've seen.
I've asked several questions here myself, that are still unanswered, and
thats not a good feeling. Such as whether or not I'm looking in the right
place for new kernel postings, etc. I'd really like to get hold of a 2.0
kernel that works with the Asante ethernet card, and then I can check out
the modules to see if they work or not; such as the ppp or others. Or, to
find module binaries for this 2.1.xxx that does work with the network
would
be just as appropriate as far as I'm concerned. But none of these
questions
got responses here.
Paul
Reply to: