> Can't seem to find a picture of the SQ306 drive so I can identify one if I
> ever come across them..
took a while to find a picture from Nov, 82 Byte
http://bitsavers.org/pdf/syquest/SQ306.jpg
Anybody happen to have a Rasterops archive for Mac Nubus cards? I have a few older cards (Mediatime, 24stv, 24si, Acellerator II, etc) and was looking for drivers.
These seem to be harder to find then the common Supermac and Radius stuff.
----------Original Message:
Date: Fri, 20 Apr 2007 13:46:37 +0100
From: "Andy Piercy" <andy.piercy at gmail.com>
Subject: Micropolis 1355 ESDI hard drive "sticky bumpers" Fixed!
>I have now fixed the faulty internals of the two faulty Micropolis hard
drives by teasing out the black gooey mass that use to be the head park
rebound bumper / end stops for each drive.
>They had turned into a black sticky mush and as you correctly identified
were holding the heads from un-parking.
>Andy.
-----------------------------
I have a 1335 which so far is OK; does it look like this sticky mush could
separate and contaminate the heads or can I safely wait until I have this
problem (if I do) to open up the drive and remove it?
mike
Scott Quinn wrote:
> I recently acquired a SGI IRIS Indigo R4k machine that was
> nonfunctional. After a bit of troubleshooting I tracked it down to the
> PM2 (processor module daughtercard, R4400 + oscillator + 1MB cache),
> which has visible damage to two of the cache RAM chips (smoke holes and
> cracks). I am trying to trace back the likely sequence of events that
> lead to this happening so it doesn't happen again. AFAIK in the R4400SC
> the cache memory is attached directly to the R4400 with the exception
> of the power leads, and the R4400 has all cache control logic
> integrated. The PSU voltages have been checked and are within specs,
> with no excessive ripple.
>
> In my experience, chips do not blow up without an external cause that
> drastically increases the current flowing through the chip, however I
> also have zero experience with SRAM chips failing in a "spectacular"
> manner. Is this possible/likely? The other option seems to be the R4400
> dying and taking the cache with it. Any ideas on where to proceed from
> here?
The PM2 module is electriacally identical, and mechanically close enough to the modules used in the Indigo2, so if you can score a battered I2 with R4400SC150 module, you can stick that into the Indigo and have the fastest possible configuration of that model. Maybe removing the cache chips will result in a functional PC module, but I never tried that.
They are very nice machines. Built like tanks. Even a defunct one serves as a nice example of how workstations *should* be constructed.
,xtG
tsooJ
The H-9 was flakey even when it was introduced. It was not a reliable
product, and will probably be difficult to get working. Probably bad ICs
or, worse, bad IC sockets.
Do you have a complete H-8 (or several)? By complete, I mean chassis & CPU,
reasonable memory, disk controller, serial I/O card and the "CP/M Card" (a
tiny small card, only about 3 inches wide, that allows the computer to run
CP/M ... I think that the original name was "extended configuration card" or
something like that).
In my opinion, the best terminal for old PCs is an old laptop using a
terminal program through it's serial port.
>
>Subject: Re: CP/M survey
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Fri, 20 Apr 2007 01:03:36 -0700
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 19 Apr 2007 at 18:00, Allison wrote:
>
>> Was that Charlie or Ted? I'd like to see the report or erata mostly
>> since it would fit nicely in my NEC file.
>
>I believe my contact was Rich Naro, but I'll have to check my old
>correspondence to make sure I'm not hallucinating.
Sounds right as he replaced me more or less. Back in 82/83 the Natick
operation was merged with EA to become NEC Electronics USA and most of
the high level functions went west. I didn't, DEC was more interesting.
>> By time the V20 hit the street I was running hand upd780s at 8mhz
>> and had at least three s100 crates going.
>
>When did the Z80H hit the street? Now, you can get a VHDL version
>that runs in an FPGA at what, something like 40 MHz?
The z80H never got over 20mhz but, the 80S180 (z180) did hit the street
at 33mhz. When you consider thats an instruction execution rate around
4mips thats not so bad. The downside is memory has to be under 15ns
or one boatload of wait states! There are more flavours of the Z180
than carter has liver pills.
There are FPGA cells that run at truly amazing speeds and also beasts
like the eZ80 that cut the number of clock cycles needed for speed.
The fastest machines I have (z80 based) is 10mhz (no waits) using
Z80 CMOS and 12.5mhz running a Z280(version J). The latter screams
with the cache and MMU running with 16bit wide zbus. The standard
CP/M tools with raw speed and a harddisk makes for a very productive
system.
Allison
>
>Subject: Re: CP/M survey
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Thu, 19 Apr 2007 15:30:37 -0700
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 19 Apr 2007 at 13:07, Allison wrote:
>
>>> While the OS didn't do that it was easy to have your own FCB(s)
>and
>> the OS would not limit you.
>
>....unless you were porting to MP/M, in which case too-ambitious
>manipulation of FCBs could come back and bite you, since MP/M did
>track file opens
True but many applications ran well under it anyway.
>> CP/M was a big step up from OSs like NSdos that only did sequential
>> allocation and even more limited user interface.
>
>Sequential or consecutive? Consecutive allocation was not a bad
>thing, provided that it allowed for expansion of a file by adding
>additional extents. Indeed, it could be much faster than simple
>granular allocation when seek time is an issue. I've worked on a
>couple of mainframe allocation systems that used consecutive-with-
>extension allocation with no particular problems. I routinely run
>into them in conversion (e.g. IBM DIsplaywriter). A Smith-Corona
>typewriter uses sequential allocation in that each allocation unit
>is placed physically later on the disk than the previous one, but not
>necessarily adjacent to the preceding one.
Sequential and consecutive. However NSdos (like RT11) does not have
a way to allocate addional space. For example, in File A,B,C are in
place and A needs to be enlarged. Under NSdos you have to copy A to A1,
append the data to it and delete A and rename A1 to A. Now if you need
the space on the disk that A occupied you must compact the disk. This
was particulary nasty if the file was larger than half the disk size
as you run out of space. NSdos was a bag and tag file system.
>> CPM3 and MPM allowed for 512byte sectors and 32mb max logical drive size.
>
>You must be looking at MP/M I. The maximum drive size for MP/M II is
>512MB using 16K allocation units. The maximum file size, however is
>still 8 MB.
I was.
>> CP/M2 is non multitasking, V3 and MPM which are related (same filesystem
>> and bdos calls) it can be an issue. However, the non-multitask status
>> of CP/MV2 didn't prevent things like background printing or interrupt
>> driven IO though it meant the BIOS implmentor had to do the work.
>
>Didn't the CP/M SPOOL program simply hook the printer BIOS vector and
>install itself below CCP like the XSUB program? It's been a long
>time, so it might have been above the CBIOS also.
That was one of the few that did that. There was nothing to prevent many
apps from doing that.
>> Other oddities is there was no MBR or on disk partition tables for
>> large drives. The partition info was kept in the DPH/DPB inside the BIOS.
>
>I suspect that DRI considered that area to be an issue left to the
>implementor. We certainly allowed two OS-es to reside on the same
>drive by simply implementing our own partition table scheme and
>making the hard disk access routines aware of it. MS-DOS scarcely
>does anything much more elegant.
Back then two OSs on a disk would have been truly extravagant.
>> Only required for floppy or the uncommon removable harddisk
>> (CDC hawk anyone).
>
>....or Syquest removables (SQ100) which were around early enough,
>albeit after the PC, to find their way onto some Z80 CP/M systems.
My point of reference was pre PC. By post PC thre weree enough things
changing like the availability of inexpensive (under $1000) hard disks
and controllers to be significant. Prior to that (especially pre1980)
it was 8" and 14" fixed drives and a few 14" removeables.
I still ahve a Syquest270 (with parallelport adaptor) that both works
and I have about 15 disks for it.
>I seem to recall seeing an OS being advertised in one of the mags in
>the late 70's that offered CP/M functional compatibility, but also
>featured a hierarchical directory structure. I don't recall the
>name, but a friend was all fired up about it.
There may have been one but I never saw one in action. The idea of
hierarchical directory pre 1980 was pretty radical for a micro system.
Allison
>
>Subject: RE: Quick survey on equipment
> From: "Ade Vickers" <javickers at solutionengineers.com>
> Date: Wed, 18 Apr 2007 12:43:18 +0100
> To: "'General Discussion: On-Topic and Off-Topic Posts'" <cctalk at classiccmp.org>
>
>Dave Dunfield wrote:
>
>> > Some have questioned the number of people on the list who
>> have CP/M systems.
>> >
>> > Lets do a quick survey
>>
>> Way too many to list (or even remember), but you can see a
>> relatively up to date list (and photos etc) at:
>
>Damn, I was hoping to have the only Epson PX-8; as far as I know the only
>CP/M system to do (micro)cassette tapes.
I played with blcok structred microcasette back around 80-81. Also the
Coleco adam ram CP/M on casette. There were otehrs but none portable
and that was a big deal with the PX8.
>I also have an Osborne-1, and a C128 (which I think I have CP/M disks for);
>and IIRC used to have a set of CP/M disks for an Acorn Master - or was that
>GEM, can't remember now.
>
>Oh, and I've got a Sharp MZ-80B which I believe will run CP/M.
Yes it do.
>Shame I've not the foggiest how to use it. I can get Wordstar running on one
>of the PX-8s, but only because it's in ROM. I can do DIR and run a program -
>does it do anything else?
Excellent word processor (WS!). The base system has enough "ramdisk" argumented
by plug in roms (two) to be useful for many tasks. If you have one
of the wedges that added "ramdisk" its usefulness increases.
Mine has the 120k ramdisk wedge and I have the three most useful roms,
those being Wordstar, Basic and CP/M utilties. I keep a amateur radio
logging datadase on it (written in basic) both to prove usfulness
and also because the RFI output is far lower than many PC laptop beasts.
It doesn't hurt that the battery life (with good nicads) far exceeds a
lot of laptops.
Allison
>
>Subject: Re: CP/M survey
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Thu, 19 Apr 2007 09:25:46 -0700
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 19 Apr 2007 at 9:48, Allison wrote:
>
>> >Maybe, but it couldn't run JRT Pascal. AFAIK, the only commercial
>> >product that ever used the bizarre coding sequence:
>> >
>> > LXI SP, PROC-1
>> > CALL PROC
>>
>> JRT Pascal was Z80 code if memory serves. But LXI SP, value is
>> valid as the arithmetic is done at compile time not execution.
>
>Nope--8080. I've still got the 1.0 disk. One can precede this
>sequence with (and I think that JRT did):
I have V3 and never had a problem, guess they fixed it.
>
> LXI H,0
> DAD SP
Only way to get the SP on 8080. Liked the Z80 because they fixed that.
>to get the old SP value into the HL register pair prior to the LXI
>SP. And it is a V20 bug--I remember calling the NEC technical guy
>in Natick and getting about 10 words into the report and having him
>say "JRT Pascal, right?". If anyone's interested in the V20 errata,
>I've still got the stuff.
Was that Charlie or Ted? I'd like to see the report or erata mostly
since it would fit nicely in my NEC file.
>JRT was one of the earlier attempts at "virtual" 8080 code; it
>swapped procedures from floppy. Of course, it was miserably slow,
>but at something like $30 for a Pascal, it looked like a great deal.
>Of course it was buggy as the dickens. I think the oddball calling
>sequence was to keep the stack adjacent to the procedure for
>subsequent swapping, rather than having to deal with a single stack
>that might well overflow without special handling routines, given the
>"virtual" nature of JRT Pascal.
Doing anything on 8080 that was virtual was slow. V3 was still $30
and slow but it did work.
>> In the end running an 8080 (V20)
>> when I have Z80 or even fast(6mhz HmosII) 8085s is sort of
>> less than interesting.
>
>Maybe, but you use what you have at your disposal, even if it is an
>8080. And most professional apps for CP/M used the 8080 instruction
>set initially--only later did a bunch of Z80-specific (e.g. ZCPR)
>code come out. I never could understand this--in general, little to
>be gained in speed by using Z80 codes.
By time the V20 hit the street I was running hand upd780s at 8mhz
and had at least three s100 crates going.
>FWIW, I still use 22NICE on Win2K. It nicely integrates old CP/M
>apps into the Windows environment without having to create virtual
>disks or such stuff, so using apps under emulation is no harder than
>using native ones.
Still have it and use it, interesting tool.
Allison
I have around five P112 kits left and the question of making more has come
up in private email. How many of you would be interested in acquiring one
of these CP/M computer kits? See http://frotz.homeunix.org/ for a full
description and pics.
I'm still in the middle of things that prevent me from doing any shipping
and filling baggies with passives, so I'm not selling any of the kits I
still have for the time being. That's also why I haven't done anything
with the 8-inch drives.
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?