1 Dec
2010
1 Dec
'10
7:47 p.m.
SCSI to IDE
Tom Gardner thomas.gardner
<mailto:cctalk%40classiccmp.org?Subject=Re%3A%20SCSI%20to%20IDE&In-Reply-To=
%3C5450F2940A10417780E426EC57A9C5E1%40tegp4%3E> at sbcglobal.net
Wed Dec 1 17:35:52 CST 2010
* Previous message: SCSI to IDE
<http://classiccmp.org/pipermail/cctalk/2010-December/294657.html>
* Next message: SCSI to IDE
<http://classiccmp.org/pipermail/cctalk/2010-December/294665.html>
* Messages sorted by: [ date ]
<http://classiccmp.org/pipermail/cctalk/2010-December/date.html#294658> [
thread ]
<http://classiccmp.org/pipermail/cctalk/2010-December/thread.html#294658> [
<http://classiccmp.org/pipermail/cctalk/2010-December/subject.html#294658>
subject ] [ author ]
<http://classiccmp.org/pipermail/cctalk/2010-December/author.html#294658>
_____
I haven't been following this thread too closely so I may have missed
something, but it seems to me that the proposed solutions are overly
complex. One simple solution that comes to mind is to define a set of
vendor unique SCSI commands, one for each of the registers in the IDE
command stack and then do all the emulation in the device driver on the host
side. The interface card is just then a simple state machine; really simple
if u make it a non arbitrating protocol implementation and use PIO for data
transfers (SCSI-1 lives :-).
Tom
_____
* Previous message: SCSI to IDE
<http://classiccmp.org/pipermail/cctalk/2010-December/294657.html>
* Next message: SCSI to IDE
<http://classiccmp.org/pipermail/cctalk/2010-December/294665.html>
* Messages sorted by: [ date ]
<http://classiccmp.org/pipermail/cctalk/2010-December/date.html#294658> [
thread ]
<http://classiccmp.org/pipermail/cctalk/2010-December/thread.html#294658> [
<http://classiccmp.org/pipermail/cctalk/2010-December/subject.html#294658>
subject ] [ author ]
<http://classiccmp.org/pipermail/cctalk/2010-December/author.html#294658>
_____
More information <http://www.classiccmp.org/mailman/listinfo/cctalk> about
the cctalk mailing list
_____
-----REPLY-----
I agree and have started a new thread for a SCSI to IDE converter board over
on Vintage-Computer.com forums. If you or anyone is interested in the
project stop on by and help out.
http://www.vintage-computer.com/vcforum/showthread.php?22906-SCSI-1-to-from-
IDE-drive-converter
The project is a Z80 CPU, NVSRAM, EEPROM, UART, 8255 PPI IDE, and Z53C80
SCSI-1 controller. The UART is for a serial port to program the converter
board and store parameters in the NVSRAM and allows for ROM reprogramming in
circuit. It is on a dual layer Eurocard and uses 14 ICs plus connectors,
passives, etc.
Thanks and have a nice day!
Andrew Lynch
18 Jan
18 Jan
7:18 a.m.
New subject: Long term publicly accessible backups [Was: Uncorrupted A/UX 3.1 Update]
For a while now I have been pondering Usenet as a long term, offsite,
distributed backup facility. Most of the premium servers are over two
years of archive, with pretty decent reliability. Spot checks of
files posted over two years ago still indicate 100% article availability.
Basically, I propose we select a low-traffic group which is available on
most premium servers, and start posting software/documentation to it in a
standard rar/par2 format. And somewhat standardized naming conventions.
If a file was posted two or three times over the span of a month, then
reposted every year we can be almost assured the files would be available
to enthusiasts for many years to come.
Comments?
Clint
Can someone
help me out with the above? All the copies I've been able to
find on the net have an md5sum consistent with a known-bad image.
Thanks in advance.
Steve
--
I imaged mine (original) a while back and uploaded it to a FTP site that was
supposed to be up forever (lasted a month). If you have some place to dump
it email me back and I will dig it up. 
8:57 a.m.
New subject: Long term publicly accessible backups [Was: Uncorrupted A/UX 3.1 Update]
Jay West makes server and disk space available for appropriate vintage
computing purposes. BitSavers also archives "bits" and not just
documentation.
The only reason why I'd imagine you don't want to use either of these
existing services is because you know the stuff you want to archive
violates someone's copyright and that they actually pursue violators.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
9:59 a.m.
New subject: Long term publicly accessible backups [Was: Uncorrupted A/UX 3.1 Update]
On 1/18/2011 11:57 AM, Richard wrote:
Jay West makes server and disk space available for
appropriate vintage
computing purposes. BitSavers also archives "bits" and not just
documentation.
The only reason why I'd imagine you don't want to use either of these
existing services is because you know the stuff you want to archive
violates someone's copyright and that they actually pursue violators.
Have you checked out Freenet? I need to play with it as well, but the
concepts are pretty interesting. And I think its quite applicable to
your requirement. At least from an academic perspective, as long as the
data is re-inserted regularly, or being downloaded by different people,
it should remain online forever.
http://freenetproject.org/faq.html
The anonymity and free nature makes it interesting.
I think from a practical perspective, simply seeding the data once with
bittorrent on a popular tracker usually works for rare stuff. The more
rare something is (provided there's still SOME interest) in it, the more
people will go out of their way to make sure it's available. You may
only have 1/2 dozen seeders at any given time, but that's usually
enough. Even for 10gb sized downloads.
While trying to avoid a personal attack from mr. grumpypants(which is
usually swift), I find it a damn shame that some people would rather
have this stuff fade into oblivion by not having it available for
distribution (and hence preventing one fairly strong method for
preservation/archiving) than allow many future generations to enjoy and
make further use of it.
Keith
11:35 p.m.
New subject: Long term publicly accessible backups [Was: Uncorrupted A/UX 3.1 Update]
On Tue, Jan 18, 2011 at 12:59:36PM -0500, Keith M wrote:
I think from a practical perspective, simply seeding
the data once
with bittorrent on a popular tracker usually works for rare stuff.
The more rare something is (provided there's still SOME interest) in
it, the more people will go out of their way to make sure it's
available. You may only have 1/2 dozen seeders at any given time,
but that's usually enough. Even for 10gb sized downloads.
We (a fellow admin and I) have been talking about mirroring bitsavers
(and perhaps other sources) "any day now". Perhaps setting up a tracker
and create torrents would be a more sensible use of bandwidth!
I see a few issues with it though.
1. On what level should I make the torrent? One per file, one per
subdirectory, one per manufacturer?
- I'm thinking both subdir and manufacturer. It is then easy to
select what files you want from a torrent.
2. How does one handle updates?
- I have no clue ... a whole new torrent for one new/changed/deleted
file in a directory? Is there such a thing as incremental torrents?
3. Would bitsavers and other agree to be a seed as well?
- A critical mass of users is ofcourse necessary.
Hmm.. perhaps I should just rsync it and use the existing ftp server.
Cheers,
Pontus
19 Jan
19 Jan
12:29 a.m.
New subject: Long term publicly accessible backups [Was: Uncorrupted A/UX 3.1 Update]
On 1/19/2011 2:35 AM, Pontus Pihlgren wrote:
We (a fellow admin and I) have been talking about
mirroring bitsavers
(and perhaps other sources) "any day now". Perhaps setting up a tracker
and create torrents would be a more sensible use of bandwidth!
I see a few issues with it though.
1. On what level should I make the torrent? One per file, one per
subdirectory, one per manufacturer?
- I'm thinking both subdir and manufacturer. It is then easy to
select what files you want from a torrent.
How big is the stuff you are talking about? I would imagine
documentation, which hasn't been converted properly, would probably take
up a bunch of room. If we are talking about binaries and such, then
space probably isn't a big concern.
This really comes back to size for manageability --- you could .rar each
manufacturer, and then distribute a torrent of multiple .rar's.
Don't make the mistake of having multiple torrents for the whole
project. I think that's a mistake. Have one big torrent, with the
individual files being selected/selected within the clients.
When sharing and redistributing this stuff, I much like to download one
huge mama file that contains EVERYTHING. Bandwidth and disk space is
pretty cheap these days. Plus, if this ever gets redistributed into the
wild, you don't want to end up splitting the content. Right? So maybe
they have IBM and DEC (or whatever) but no CPM or whatever. Then people
have to try to find the right torrents --- your collection is no longer
a full collection.
2. How does one handle updates?
- I have no clue ... a whole new torrent for one new/changed/deleted
file in a directory? Is there such a thing as incremental torrents?
Have you seen the TOSECs?
http://en.wikipedia.org/wiki/TOSEC
Not so much for naming per se, but how they distribute them? They
basically have a new torrent released for each update -- with each
update happening perhaps every 6 months or year.
You could just do quarterly updates or something, and release a new
torrent that contains the latest files. It's not too hard just to look
for the latest .torrent out there.
Mame ROMs distribution works the same way. Added a couple more roms to
the collection? bump version from .133 to .136 and release a new torrent.
Oh, and one last thing on this. You can download one torrent "on top"
of an existing directory of a completed torrent. The individual files
get hashed.... meaning
.133 contains ibm.rar dec.rar and cpm.rar
.136 is going to modify cpm.rar but not ibm.rar and dec.rar
As long as the directory structure between torrents is consistent, and
the download directory is the same --- ibm.rar and dec.rar will be
listed as finished with cpm.rar showing inconsistent. You would need to
delete the inconsistent(ie older) rar and then restart the download (so
the hash re-check occurs)
Obviously some of this is torrent-client specific, but I think you could
make this work.
3. Would bitsavers and other agree to be a seed as well?
- A critical mass of users is ofcourse necessary.
You likely need less than you think. I've seen torrents being kept
alive for years with just a handful of seeders. As long as you maintain
a couple "official" seeders, you should be fine.
Once again comes back to size.
Hmm.. perhaps I should just rsync it and use the existing ftp server.
Cheers,
Pontus
Yup.
Keith
18 Jan
18 Jan
3:01 p.m.
New subject: Long term publicly accessible backups [Was: Uncorrupted A/UX 3.1 Update]
cctech at vax-11.org wrote:
For a while now I have been pondering Usenet as a long
term, offsite,
distributed backup facility. Most of the premium servers are over two
years of archive, with pretty decent reliability. Spot checks of files
posted over two years ago still indicate 100% article availability.
I've been making that joke for years, but people normally don't find it funny ;-)
Comments?
The sheer amount of data will kill you, I suspect; I've always thought the
concept workable* for small amounts of data split over lots of messages on an
individual basis, but if lots of people are doing it and the 'files' being
posted are quite large, it'd become unwieldy and providers will start killing
messages (and accounts).
* from a technical point of view. I certainly wouldn't actually *do* it :-)
Even before the days of deja's archive, it would have been possible to
'refresh' data on a continual basis to get around issues of article expiry.
Sort of like a giant network-attached bank of DRAM.
cheers
Jules
3:07 p.m.
New subject: Long term publicly accessible backups [Was: Uncorrupted A/UX 3.1 Update]
On Tue, 18 Jan 2011 cctech at vax-11.org wrote:
For a while now I have been pondering Usenet as a long
term, offsite,
distributed backup facility. Most of the premium servers are over two
years of archive, with pretty decent reliability. Spot checks of
files posted over two years ago still indicate 100% article availability.
TWO YEARS is NOT what we would consider to be "long term"!
That is SHORT term.
Basically, I propose we select a low-traffic group
which is available on
most premium servers, and start posting software/documentation to it in a
standard rar/par2 format. And somewhat standardized naming conventions.
START your own group. Do NOT hijack and flood somebody else's group!
The few people using the low-traffic group might not enjoy having massive
amounts of off-topic stuff raining down on them. It is still SPAM, even
if it is not "commercial".
If a file was posted two or three times over the span
of a month, then
reposted every year we can be almost assured the files would be available
to enthusiasts for many years to come.
Reposting annually would, indeed, be needed. But, the current problem is
already that people don't follow up and maintain their data files years
later.
If you have people willing to make that kind of commitment, then a few
websites, plus distribution of CDs, DVDs, and whatever comes next would
accomplish the same thing, and would survive the total loss of any one
collection. Think Don Maslin (R.I.P.)
Usenet is not as readily available as it once was. Will that trend
continue? Do you really think that it will be publicly and commonly
available in 10 or 20 years? Look at gopher!
Other than those, it would at least be a start.
Howzbout: steganography within certain pictures, glurge, and urban
legends
--
Grumpy Ol' Fred cisin at xenosoft.com
3:14 p.m.
New subject: Long term publicly accessible backups [Was: Uncorrupted A/UX 3.1 Update]
Usenet is not as readily available as it once was.
Will that trend
continue? Do you really think that it will be publicly and commonly
available in 10 or 20 years? Look at gopher!
*pats Gopher server in rack*
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- 1-GHz Pentium-III + Java + XSLT == 1-MHz 6502. -- Craig Bruce --------------
3:59 p.m.
New subject: Long term publicly accessible backups [Was: Uncorrupted A/UX 3.1 Update]
On 1/18/11 6:14 PM, Cameron Kaiser wrote:
Bravo!
--
Dave McGuire
Port Charlotte, FL
Usenet is not
as readily available as it once was. Will that trend
continue? Do you really think that it will be publicly and commonly
available in 10 or 20 years? Look at gopher!
*pats Gopher server in rack* 
6:06 p.m.
New subject: OT looking for technical data on GE RTV 700
Hi,
I find this group very resourceful and having access to various documents.
I am questing for an old datasheet on GE Silicone RTV 700 (with Beta 1
or Beta 11). I would greatly appreciate getting a copy of the datasheet
or a catalog comparison of GE Silicones including RTV 700. Even an old
magazine ad would be helpful.
I tried GE and Momentive with no luck, As they don't "support" this
product any more.
I am interested in the technical feature and in particular the high end
temperature range.
Please forward any information directly to me at nanoman at stny.rr.com
Parameter
RTV 700 w/ Beta 1 or Beta 11
Mixture
10:1 wt%
Color
"White" + Blue
*Useful Temperature *
*
*
Hardness Shore A
Tensile Strength (psi)
Elongation (%)
Tear Strength (ppi)
Thank you in advance.
N. Man
5086
days inactive
5134
days old
10 comments
10 participants
participants (10)
-
cctech＠vax-11.org -
cisin＠xenosoft.com -
jules.richardson99＠gmail.com -
keithvz＠verizon.net -
legalize＠xmission.com -
lynchaj＠yahoo.com -
mcguire＠neurotica.com -
nanoman＠stny.rr.com -
pontus＠Update.UU.SE -
spectre＠floodgap.com