Esteemed Electronics Experts: This may be on topic - it's for an old
piece of test equipment with an NEC V40, an Analogic 2030 function
generator.
Anyway it's blowing fuses - traced it to a shorted diode in a power
supply, marked
(Motorola Symbol)
ZP
1N
540
905
Don't think it's a 1N540 - top hat silicon - this one just looks like a
fat 1N4007 cylinder. Not a 1N5409. 1N540905 doesn't exist in
google-world. ---(==(---
Any tips, actually just want ratings for replacement TIA
--Chuck
>>DEC through the 'golden age' didn't go after that market. They tried
to
>>target scientific rather than corporate computing.
>
>One of the oddities is that the 36bit machines the 10s/20s were well
>known for their timesharing with huge nubers of users.
And they did put effort into front-end terminal concentrators on the
later
models of those systems.
TOPS-10 had a significant influence on the user interfaces of some of
DEC's
smaller operating systems (RT-11 and RSTS for example), as well as CP/M.
Google for discussions on alt.sys.pdp10 for why this wasn't true for
RSX and VMS.
I suspect that the driving force for tools (esp in TOPS-10) inside DEC
came about
because much of the software development inside of DEC for other CPU
families until
they converted to VAXen was done using cross-development tools on their
internal
timesharing systems (MACY11, etc.) and because 10's were THE machines
to have in
universities (MIT, CMU, etc, etc) if you wanted something that had a
lot of good
tools for a moderate amount of money.
--- On Tue 07/26, Brad Parker < brad at heeltoe.com > wrote:
From: Brad Parker [mailto: brad at heeltoe.com]
To: cctalk at classiccmp.org
Date: Tue, 26 Jul 2005 21:05:33 -0400
Subject: cctalk archive search?
<br>is the cctalk archive search broken?<br><br>I searched for "tiff" and "scsi" and got no hits (using any or all).<br><br>is it just me ? :-)<br><br>-brad<br>
Seems to work Ok from "www.classiccmp.org", but not from the
page listing the archives. I noticed this too.
Tim R.
_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
Jay West <jwest at classiccmp.org> wrote:
> The other other way - hook
> up a computer and send the image to the ram in the 29B. The protocol is not
> difficult at all. It's not Xmodem, but... easy nontheless.
But is it documented? Can I write the necessary software myself? As you
know I run my own operating system that no one else in the Universe uses
and I cannot run any software not written from scratch by me.
Is the interface EIA-232? It's the only interface that's Classic enough,
standard enough and universal enough for me to use. Oh, and can it work
with baud rates of 38400 or lower? I can't use higher baud rates because
they are not standard in the Classic (non-pee sea) world.
MS
Bruce Lane <kyrrin at bluefeathertech.com> wrote:
> I almost forgot to mention... All the Data I/O programmers I mentioned
> in my last note have a distinct advantage over many others: They will
> work with nothing more than a 'dumb' ASCII terminal attached to their
> serial port for control.
But how would you then get the image to be programmed into the box? Does
it support something like XMODEM/YMODEM/ZMODEM/Kermit on the terminal
port, or is an ASCII terminal not really sufficient, i.e., maybe they
can only use a terminal to control mass duplication, but initialing image
loading still requires a Losedows box?
MS
>From: ard at p850ug1.demon.co.uk
>>
>>
>> >On Jul 26 2005, 14:42, Jules Richardson wrote:
>> >
>> ...
>> >> I don't think there's a need to handle anything complex in the virtual
>> >> drive. I believe an ST506 drive's purely a data store/replay device and
>> >> it knows nothing of the actual data stored on it - most of the circuirty
>> >> on board is presumably just motor control and head amplifiers / filters.
>>
>> You'd need to encode the bits correctly so the data/clock seperator
>
>That's just what I'd not want to do. You can't make any asumptions about
>the clock/data encoding scheme if you want this emulator to be universal
>(after all, a real ST506 doesn't do anything to the pulse stream other than
>record it on the disk, unchanged [1]).
>
>That was the reason for the high (10*, 8* would probably be OK as well)
>sampling rate. Just record the pulses to memory, then play them back.
>Yes, it's wasteful of memory, but it means it should work with any ST506
>controller (and there are some very strange ones in classic computers).
>
>[1] THat is a simplfication. IIRC, a rising (falling?) edge of the write
>data line causes a flux transition on the disk. The opposite edge is
>ignored. On read, a flux transition on the disk causes a pulse on the
>read data line, the width of this pulse is fixed (determined by a
>one-shot on the drive logic board). There are restrictions as to how fast
>and how slowly you can send pulses, due to the design of the read
>amplifier/filter.
>
>-tony
>
>
Hi
This is my understanding as well. This means that you can't
just play back the signal written. The write signal
has compensation for the timing shift caused by signals
being close together on the disk surface. This tends to
alter the edge timing. This is the information that you are
trying to recover or play back. The sampling systems used
to read the data back would not work well with the unprocessed
write data going into them because of the compensation used.
You'd need to provide a filter that is the equivalent of
the writing and reading of data through the disk. Then you'd
need to find the leading edges and generate the pulses
that are read. I would say that 8X to 10X is a reasonable
sampling rate but you'd still need to process the data
before sending it back as read data.
Dwight
A friend of mine passed away last week, and I am in the process of
getting all the classic computer stuff from his house. Somewhere in all
of this I am told that he wrote quite a few utility programs for CP/M.
While I don't think it would make any difference, the executor of his
estate is willing to sign a document stating that anything he wrote is
now in the public domain. Question; what kind of document is available
to do this?
BTW, so far I've collected at least half a dozen Kaypros, one Osborne,
and a number of others. I will be going over to start on the garage in a
few minutes.
>From: "Al Kossow" <aek at bitsavers.org>
>
>
> I shouldn't be saying this because I'm not sure when
>I'll be able to look for it but I'm almost sure I have
>the schematics for a 5 Meg Seagate drive someplace in my piles.
>
>--
>
>
>Try
>
>http:/www.bitsavers.org/pdf/seagate/ST506_ServiceMan_May82.pdf
>
>or the National tech notes.
>
>
Hi AL
Thanks, I think those are the ones I have.
Dwight
I shouldn't be saying this because I'm not sure when
I'll be able to look for it but I'm almost sure I have
the schematics for a 5 Meg Seagate drive someplace in my piles.
--
Try
http:/www.bitsavers.org/pdf/seagate/ST506_ServiceMan_May82.pdf
or the National tech notes.
Hi
I shouldn't be saying this because I'm not sure when
I'll be able to look for it but I'm almost sure I have
the schematics for a 5 Meg Seagate drive someplace in my piles.
It might be a month or so before I come across it.
I, also, am almost sure I have a ST506 signal specification
booklet from Seagate as well.
I'll do some digging soon but I'm not where the piles are,
except on weekend ( but not this next weekend ).
Dwight
>From: ard at p850ug1.demon.co.uk
>
>> > Correct. Don't uou have at least one ST506/ST412-interfaced drive
schematic?
>>
>> Nope, unfortunately not :-( I've got various manuals for bridge boards,
>> which of course have the connector pin-outs in (and give some of the
>> theory), but nothing for a complete hard drive (I suppose I'mactually
>> surprised such schematics ever escaped the drive manufactuers to be
>> honest, as presumably ST506/412 units were never supposed to be field
>> servicable?)
>
>THe HDAs were not field-repairable, but the PCBs certainly were/are.
>
>The IBM PC series TechResf contain schematics of some such drives (which
>ones depends on exactly which version fo the TechRef amd which updates
>you have). I've traced out a couple more. In general these drives are not
>particularly complicated, although there may well be ASICs for things
>like head switching, motor control, etc.
>
>I must get at least one of the latter diagrems to you ay some point.
>
>-tony
>
