>I've drawn the conclusion that the only real memory-hog is the Netscape
>browser.
>A couple of folks have advised me to install a 32MB simm for that purpose
>alone.
>It would certainly be a shame to make the system buckle when browsing just
>because it lacks RAM.
I would give iCab a try (www.icab.de), it is free, and works extremely
well. It uses way less RAM than Netscape, so it should work with just 8mb
installed (4mb might be tight). I am running the latest version right now
and it is taking up just 2.9mb of RAM.
It is also faster and more stable than Netscape in my experience... and
it is actively under development even for the 68k version, something you
won't get with Netscape (the 68k version is dead in the water for
Netscape).
-chris
<http://www.mythtech.net>
On Nov 20, 0:53, Tony Duell wrote:
> Since you can put options with top connectors anywhere in the backplane,
> there would seem to be little point in having special foam over the front
> slots only.
That reminds me... supplementary question: The machine had gaps between
some of the cards. It's over 20 years since I used a PDP-8 for real, and
in those days I wasn't usually allowed at the innards. The gaps don't
matter, do they? There's no grant chain like in a Unibus, AFAIR. The
-8/E is an Omnibus machine, of course.
--
Pete Peter Turnbull
Network Manager
University of York
> -----Original Message-----
> From: Richard Erlacher [mailto:edick@idcomm.com]
> It's the "quite a bit of extra work" that concerns me, as the
> boys at M$ haven't
> managed to do it right yet, and they've been at it to the
> tune of 100K man hours
> per year for a decade or so. Recording a bitwise image of
Well, I haven't got much faith in them to begin with. They could work for
1000 years on a 20 minute job and still mess it up. I'm not saying that it
might not actually take that long, just that m$ aren't competent enough to
be a good indicator.
> what you receive from
> the disk may or may not give you all the information you need
> to recreate the
> files, since you may or may not know how the OS deals with
> them. What's more,
I was assuming you'd know the filesystem type at the time of the backup. I
don't suppose it would be absolutely necessary. You might also recognize a
filesystem by magic number/signature, or the like.
[snip]
> which you write such an image must be an EXACT duplicate of
> the one from which
> the image was recorded. The second drive may otherwise claim
> to be identical
> but have a different number of sectors per physical track,
> use different mapping
> arrangements, etc, and, especially, have different bad
> blocks. Since you're
Well, "otherwise identical" is dangerous territory at any rate. :) You're
right, though, in that depending on the way the software components interact
with the drive, one or more of these things might really screw things up. I
suppose that would require one to know the internals of each system with
which you plan to use this method.
> going to send data that goes to where the drive sends it and
> not necessarily to
> the same physical location from which you got it because the
... which may be ok, depending on how the system interacts with the device
in question. Of course, if you find that the system depends on the data
being in some physical location, rather than in a logical location, you'd
have to correct for that or _just not do it_ ;)
[snip]
> sent, you may be disappointed with the results because IDE
> drives hide too many
> details from the end-user.
Yep. Tell me about it.
[snip]
> absolutely for certain, what
> the drive does with the data you send it, and what the OS
> does to process data
> to and from the drive, you're on thin ice.
That depends. For instance (This will now get very hypothetical), if the
O/S handles data in logical blocks, and doesn't care too much the actual
geometry of the drive, you might be ok with not knowing about the device.
That is, with the exception of bad blocks. (Really I guess I'm talking
about faking a standard interface even when it doesn't exist here)
[snip]
> all. Since SCSI is well established as to how it operates
> its data management,
> it yields more hope that you can process an image, though the
> vagaries of the OS
> are still a limiting factor.
On the other hand, as some friends of mine are wont to say: "Neither S in
SCSI means standard."
> Image recording should work fine with MFM- and RLL-encoded
> drives, even on a
> track-by-track basis, and those offer some hope that one
> could substitute one
> sort of drive for another but hte ones which use BOTH CHS and
> LBA addressing
> won't tolerate the sort of operations to which an
> incrementally developed OS
> like Windows could create.
Can't argue with that.
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");
'
Yes, I have a few of them. the part is nearly the same as the 372
with some minor tweeks and differences.
Allison
-----Original Message-----
From: Richard Erlacher <edick(a)idcomm.com>
To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
Date: Tuesday, November 20, 2001 3:27 PM
Subject: Re: 1771 floppy controller questions
>Yeah ... I wasn't sure about that, though I know they sold their
Intel-numbered
>version of the WD HDC chips (1010 and 2010).
>
>Didn't NEC also make a uPD371 that was for small tape drives? I know they
made
>something on that order, but I never got to play with them.
>
>Dick
>
>----- Original Message -----
>From: "Allison" <ajp166(a)bellatlantic.net>
>To: <classiccmp(a)classiccmp.org>
>Sent: Tuesday, November 20, 2001 10:56 AM
>Subject: Re: 1771 floppy controller questions
>
>
>> Intel never did a 1771 compatable chip. They did do the 8271 that was
>> FM only but totally incompatable with the 1771 socket.
>>
>> The second source that did ship parts is SMC. The other supplier was
>> National Semi.
>>
>> NEC Started with the D372, that was a hard/soft sector single density
>> controller that did find it's way into the first version of the IMSAI
floppy
>> controller.
>>
>> Allison
>>
>> -----Original Message-----
>> From: Richard Erlacher <edick(a)idcomm.com>
>> To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
>> Date: Tuesday, November 20, 2001 12:05 PM
>> Subject: Re: 1771 floppy controller questions
>>
>>
>> >I don't know right offhand of any second sources, except for Intel,
which
>> did,
>> >IIRC, make a 1771-equivalent/compatible for a time. They went the NEC
>> route
>> >when MFM became popular, however.
>> >
>> >WD also made a 1781 which was M2FM capable, and, as some folks will tell
>> you,
>> >THAT's a hard modulation scheme to support.
>> >
>> >As I mentioned before, it might be worthwhile to communicate with Tony
>> Duell
>> >regarding the expansion interface, as he recently admitted he'd actually
>> made
>> >the model-1 disk interface work as it was designed to work. A lot of
>> folks
>> >couldn't get reasonable reliability until they bought a third-party
>> enhancment
>> >for the floppy interface.
>> >
>> >Dick
>> >
>> >----- Original Message -----
>> >From: "Tothwolf" <tothwolf(a)concentric.net>
>> >To: <classiccmp(a)classiccmp.org>
>> >Sent: Tuesday, November 20, 2001 8:51 AM
>> >Subject: Re: 1771 floppy controller questions
>> >
>> >
>> >> On Tue, 20 Nov 2001, Richard Erlacher wrote:
>> >> > From: "Tothwolf" <tothwolf(a)concentric.net>
>> >> > > On Tue, 20 Nov 2001, Richard Erlacher wrote:
>> >> > >
>> >> > > > What is it that makes you believe that the 1771 s the problem?
>> >> > >
>> >> > > Well, I accidentally plugged the chip in backward when
>> troubleshooting the
>> >> > > floppy interface right after I got it. It turned out that the
floppy
>> >> > > ribbon was bad, just due to age I guess. I don't think the chip
let
>> out
>> >> > > its magic smoke, but it certainly does not work now ;)
>> >> >
>> >> > OK ... I can believe you'd reach that conclusion from what you
>> describe.
>> >I've
>> >> > done that on one of those "late nights" on more than one occasion.
>> It's
>> >> > reasonable to assume the part is toast, given that there are several
>> >supplies,
>> >> > each of which has been applied to the wrong pins. Too bad ...
>> >>
>> >> I'm really not too worried about it, since the 1771 does seem to be
>> >> available and I have the technical reference book for the expansion
>> >> interface. I don't think there are any unusual or proprietary chips
used
>> >> in the expansion interface with the exception of the floppy
controller.
>> If
>> >> it took out any other logic chips with it, I should be able to replace
>> >> those easily.
>> >>
>> >> It appears that my local vendor may have just assumed the part he has
in
>> >> stock is a National, since I can't find any references to National
ever
>> >> manufacturing a 1771, and the -B01 is a WD suffix.
>> >>
>> >> -Toth
>> >>
>> >>
>> >
>>
>>
>
>
> -----Original Message-----
> From: Greg Ewing [mailto:greg@cosc.canterbury.ac.nz]
> Richard Erlacher <edick(a)idcomm.com>:
> > Of course, MAC OS may not be so virus friendly, but I don't know
> > about that.
> But even then, the virus can't jump *off* the disk onto a previously
> clean system without running something from the disk, and that won't
> happen unless you explicitly tell it to. If there's some way for that
> to happen on Windows, then Windows is definitely more virus-friendly!
There's at least one worm that takes advantage of a Quicktime feature (why
on earth did they put this in Quicktime?!) that will automatically run some
program on a volume when the volume is mounted. Don't remember the name of
this "feature," but it is akin to the windows "autorun," and just as bad.
Regards,
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");
'
Intel never did a 1771 compatable chip. They did do the 8271 that was
FM only but totally incompatable with the 1771 socket.
The second source that did ship parts is SMC. The other supplier was
National Semi.
NEC Started with the D372, that was a hard/soft sector single density
controller that did find it's way into the first version of the IMSAI floppy
controller.
Allison
-----Original Message-----
From: Richard Erlacher <edick(a)idcomm.com>
To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
Date: Tuesday, November 20, 2001 12:05 PM
Subject: Re: 1771 floppy controller questions
>I don't know right offhand of any second sources, except for Intel, which
did,
>IIRC, make a 1771-equivalent/compatible for a time. They went the NEC
route
>when MFM became popular, however.
>
>WD also made a 1781 which was M2FM capable, and, as some folks will tell
you,
>THAT's a hard modulation scheme to support.
>
>As I mentioned before, it might be worthwhile to communicate with Tony
Duell
>regarding the expansion interface, as he recently admitted he'd actually
made
>the model-1 disk interface work as it was designed to work. A lot of
folks
>couldn't get reasonable reliability until they bought a third-party
enhancment
>for the floppy interface.
>
>Dick
>
>----- Original Message -----
>From: "Tothwolf" <tothwolf(a)concentric.net>
>To: <classiccmp(a)classiccmp.org>
>Sent: Tuesday, November 20, 2001 8:51 AM
>Subject: Re: 1771 floppy controller questions
>
>
>> On Tue, 20 Nov 2001, Richard Erlacher wrote:
>> > From: "Tothwolf" <tothwolf(a)concentric.net>
>> > > On Tue, 20 Nov 2001, Richard Erlacher wrote:
>> > >
>> > > > What is it that makes you believe that the 1771 s the problem?
>> > >
>> > > Well, I accidentally plugged the chip in backward when
troubleshooting the
>> > > floppy interface right after I got it. It turned out that the floppy
>> > > ribbon was bad, just due to age I guess. I don't think the chip let
out
>> > > its magic smoke, but it certainly does not work now ;)
>> >
>> > OK ... I can believe you'd reach that conclusion from what you
describe.
>I've
>> > done that on one of those "late nights" on more than one occasion.
It's
>> > reasonable to assume the part is toast, given that there are several
>supplies,
>> > each of which has been applied to the wrong pins. Too bad ...
>>
>> I'm really not too worried about it, since the 1771 does seem to be
>> available and I have the technical reference book for the expansion
>> interface. I don't think there are any unusual or proprietary chips used
>> in the expansion interface with the exception of the floppy controller.
If
>> it took out any other logic chips with it, I should be able to replace
>> those easily.
>>
>> It appears that my local vendor may have just assumed the part he has in
>> stock is a National, since I can't find any references to National ever
>> manufacturing a 1771, and the -B01 is a WD suffix.
>>
>> -Toth
>>
>>
>
am listening to a radio shack conference call from july on aol right now
most of what they r talking about is parts sales and how that is there main
business pride and joy. pillar of the business .
hummm
Joe
> -----Original Message-----
> From: Richard Erlacher [mailto:edick@idcomm.com]
> medium, and subsequently writing them back to a physically
> identical (not just
> logically identical) target, without consideration for
Why not just logically identical, then? ... assuming, of course, the same
o/s would handle devices which are logically identical in an identical
manner. (This may not be a safe assumption)
[snip]
> The bitwise image transfer from disk=>tape can be done
> without knowledge of
> either the compression scheme or of the OS/file system used
> on it. It does
> require, however, that the entire image be recorded so it can
> be restored in its
> entirety. The result is that you can use a different OS to
> do that task though
> it's not required, and the penalty is that you have no access
> to the file data,
> though you could, I guess, go to the trouble of deciphering
> the bitwise image
> into a logical file system if one originally existed. You
> can do that under any
> circumstances, but it's a lot of trouble and requires you
> know a great deal
> about the low-level processes of converting the data on the
> orginal drive into
> the files comprising it.
I think you've just summed up my previous point. That being, of course,
that if you can record a bit-by-bit image, you should also be able to
interpret this image (with quite a bit of extra work), and find the
component files. In fact, I'd add that depending on the amount of extra
work you're willing to do, you can likely restore the image in a "logical"
fashion to a volume that is completely different from the one on which it
originally resided.
Regards,
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");
'
> Digi-key always seemed to expensive for my tastes -- at least for
> everything that I need, Mouser seems a lot less expensive & I can attest
> that they have *very* helpful and quite clueful staff, but when you need
> that *weird* part, JDR & Jameco seem to keep a lot of older stuff in
stock...
I love the way Digi-Key kits their parts. That plus, 7805 and 7812
regulators sold by Rat Shack have a tendency to pop quicker when
presented with too-great a load...
-dq
> Radio Shack has been slowly diminishing the individual parts and goin for
> the glamour sales of consumer electronics mostly anymore. Won't be long and
> the days of RS/Lafayette/Olson being in the nearby neighborhood strip malls
> for those that want to "do it themselves" will be totally gone.
Now you gone and done it. I'll be up all night reading my nearly
30-year old Lafayette catalogs tonight... I don't think any of
the Olson catalogs survived. We never had a Lafayette store here,
but we did have a Tape Centre that merged with Olson...
-dq
