SCSI to SD/IDE
Phill Harvey-Smith afra at aurigae.demon.co.uk
<mailto:cctalk%40classiccmp.org?Subject=Re%3A%20SCSI%20to%20SD/IDE&In-Reply-
To=%3C4CFAF40D.30108%40aurigae.demon.co.uk%3E>
Sat Dec 4 20:08:13 CST 2010
* Previous message: SCSI to IDE
* Next message: SCSI to SD/IDE
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
________________________________
Ok guys,
The Good bit....
All this talk of SCSI to whatever got me curious so I started experementing.
What I have so far :
An AVR ATMega1284 (DIP40), connected to an SD card by SPI and to the
SCSI bus via 4 LS chips (1xLS273 and 3xLS240). I currently have
implemented just a few of the SCSI command set, Identify, read, write,
test ready and request sense.
Thist is enough to be able to connect to a PC SCSI card, format the
drive and read and write files to it....heheh I can even boot off it !
I'm using Chan's FatFS, and in this way the drive seen by the SCSI is
actually a large image file on the SD card, I did this as it will make
backing up the drive *MUCH* easier if the target system is not a PC, as
you can simply take the SD card out and copy the image file without
worrying about it's internal structure. In theory this will also make
sharing data between the target system and an emulation running on
something more modern.
There's a couple of pictures here :
http://www.stardot.org.uk/forums/viewtopic.php?f=11&t=3646
The bad bit......
Whilst this all works it's SLOWWWW, using Norton utilities SI, reports
that the disk is 0.2x the speed of an original PC, cirtainly bootup
times are much more akin to what I would expect from a floppy drive :(
So I would sugest that for replacing hard disks that using SCSI->SD is
probably not going to be fast enough.
My next experements are going to center on replacing the SD with an IDE
drive, hopefully this will provide a suitable speed increse, asuming
that this works it should be easy enough to use a CF->IDE adapter board
to use a CF drive instead of an IDE, which will allow the media to be
removable and easiliy swapable.
The other thing I want this to support is 256 byte sectors as some old
machines rely on this, a feature which is supported by some of the early
SCSI/SASI to MFM/RLL boards but very few native SCSI drives, this would
be of perticular intrest to some of the Acorn 8 bit machines.
Comments & sugestions welcome.
Cheers.
Phill.
--
Phill Harvey-Smith, Programmer, Hardware hacker, and general eccentric !
"You can twist perceptions, but reality won't budge" -- Rush.
________________________________
* Previous message: SCSI to IDE
* Next message: SCSI to SD/IDE
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
________________________________
More information about the cctalk mailing list
<http://www.classiccmp.org/mailman/listinfo/cctalk>
________________________________
-----REPLY-----
Huzzah! Good for you! Glad to see *something* coming out of all of this.
Congratulations! Have a nice day!
Andrew Lynch
Hi! Thinking about this some more, we already have simple Z80 with RAM/ROM
circuits and 8255 PIA for I/O including circuitry for 8255 to IDE.
The only new element of this design would be converting a pair of 8255 PIAs
to SCSI-2. Looking at a pin out of a SCSI-2 pin out of the 68 pins, 34 are
grounds and a few more are power related. Basically it is about 30 pins
which actually do anything and of those 24 are data lines. This does not
appear to be a difficult interface to "bit bang" and would be somewhat akin
to the 8255 to IDE circuits.
Yes, performance would just OK and not fast. I think it would probably work
and be fairly cheap to make. I am willing to support other approaches but
would like to just help with the schematic capture, PCB design, and
prototype board development. The key to success is to keep it simple and
easily understood. Adding a bunch of unnecessary complexity just dooms the
project IMO.
Please contact me if interested. Thanks and have a nice day!
Andrew Lynch
>Date: Fri, 03 Dec 2010 19:13:08 -0800
>From: Eric Smith <eric at brouhaha.com>
>Dyslexia strikes again. I thought you were looking for the 85C30, not
>the 53C80. Sigh.
>
>I doubt that anyone makes the 5380 or 53C80 anymore.
Not quite the 53C80, but perhaps the next best thing:
I have three 53C94 and three 53CF94 in 84 pin PLCC packages which I will
happily ship (for free) to anyone who wants to dabble on this project.
They are untested, and I'm looking at my inventory trying to figure out
whatever possessed me to buy them in the first place. Perhaps I got them
with a larger lot. I only ask that you actually be about to experiment
before you ask me to send them to you. It's too easy to acquire stuff
with the intention of doing a project and then for various reasons never do
it.
I also have a brick of 660 NCR 53C96 chips. Unfortunately, these are a
(IIRC) 100 pin QFP (30 X 20?), which is more difficult to work with than a
DIP or socketable PLCC. I am reluctant to open the (sealed) brick to pull
out one or two, but if someone wants to develop this project with the 53C96
in mind I'd be happy to supply 53C96s for the production at a nominal cost;
certainly no more than $1 per chip. Again, not quite sure what I was
thinking when I bought them....
If these are usable and not too modern for this project that should help
keep the cost down as compared to paying $5 - $10 per SCSI chip.
Finally having a written inventory really helps to bring home all those
items that I just can't imagine any realistic future use for....
I put the datasheets for the AMD 53C94/96 and the 53CF94/96 as well as the
Zilog 53C80 up at:
<http://www.io.com/~trag/DataSheet/>
Jeff Walther
SCSI to IDE
Alexandre Souza - Listas pu1bzz.listas at gmail.com
<mailto:cctalk%40classiccmp.org?Subject=Re%3A%20SCSI%20to%20IDE&In-Reply-To=
%3C04B9CB3C0CBB4169A8660B24014CB7FB%40portajara%3E>
Sat Dec 4 14:50:26 CST 2010
[snip]
Time to define DOWN TO EARTH specs and begin working :)
Greetings from Brazil,
Alexandre SOuza
[snip]
Alexandre,
The work on a SCSI to IDE and SD bridge has already started. I have a
schematic, parts list, and PCB layout ready for prototype board up on the
N8VEM wiki. Check out the thread on vintage-computer.com forum. It has the
Z80 controller, Z53C80, and IDE plus the SD interface. An 8 MHz Z80 will
push the data plenty fast enough for early microcomputers. We've seen it
first hand with XT-IDE board, the N8VEM DiskIO board, and the S-100 IDE
interface. Connect an IDE to CF adapter and it will be a fast drive on most
any vintage system.
Low cost commercially available SCSI to IDE bridges are already available
for those with Ultra-SCSI and later so there is no need to help them. I
think the need is for the older SCSI format which *classic* computers use,
not the fancy modern stuff. An Ultra-SCSI interface does no good for an
early microcomputer with a SCSI-1 interface which I think should be the
"classic computer" audience since they need a SCSI to IDE bridge the most.
The mailing list is called "CCTALK" for a reason. That's what's pretty much
the only thing done here. I agree with your sentiment -- I to would like to
see less "talk" and more "do". Don't listen to the naysayers or those who
set unrealistically high expectations but refuse to actually do anything
except complain. I've been offering to help design a KiCAD schematic and/or
PCB board and/or prototype PCBs based on *anyones* design since the start of
this thread and have only gotten flamed and ignored. Maybe you'll have
better luck.
Andrew Lynch
PS, if you are planning to offer a PCB or kit, I advise you not use SMT or
you'll be assembling nearly all of them yourself. A lot of hobbyists
especially those with diminished vision struggle with even DIP/PLCC
soldering and SMT parts will just make you the assembler as well as the
designer.
----- Original Message -----
From: <ma.locksmith at juno.com>
To: <amateur-repairs at yahoogroups.com>; <freebay at mailman.qth.net>
Sent: Saturday, December 04, 2010 7:59 PM
Subject: [Amateur-repairs] Computer drives
>I don't expect anyone wants one of these, but I've "got" to ask anyway.
>
> Have box of various computer drives.... floppy (all types), hard (SCSI),
> and even a CD-RW.
>
> Of course, no drivers.
>
> Free for postage
>
> Ed
>
> .
> ____________________________________________________________
> Explosive Stock Secrets
> Learn the Secret art of picking penny stocks before they spike
> http://thirdpartyoffers.juno.com/TGL3141/4cfaba0b5b184f28c1st05duc
>
WANTED: A good home for my last three RACK'O'CD boxes by MDI.
MUST GO, need space, need basement floor and drain tile repaired. PLEASE
some take these, or some of the drives, soonest. Price: FREE (you pay
shipping.)
These are nifty 7 inch high rack mount boxes about 20 inches deep, each
containing seven SCSI CD-ROM drives, a power supply (4 voltages, including
+5 at 23A, +12 at 15A) assorted cabling, and a SCSI LUN controller widget.
The boxes have two SCSI conncectors each, the large "centronics" type
(50-pin?) and a SCSI address selector.
The CD-ROM drives are Toshiba XM-5401B, each mounted to a sort-of sled,
more like drive rails, with spring-loaded thumb screws holding them in.
Each has connectors for Audio Out (L and R), SCSI ID and termination, SCSI,
and power.
The boxes have a hinged door on top for access to the rear of the drives.
With the thumb screws on the drives, tool-less removal is possible.
If you need the terminating resistor packs, specify you want drive a #7
(first-come, first served.)
You can get the entire box, or two, or three, or some drives (specify
quantity) but I don't really want to disassemble these enough to extract
the power supply. If I do that, I'll keep a power supply. They look like
old style AT type, without the motherboard connection.
-----
135. [Computing] Was it Ritchie or Thompson who said about X: "Sometimes, when
you fill a vacuum, it still sucks"?
--... ...-- -.. . -. ----. --.- --.- -...
a50mhzham at gmail.com (Email) N9QQB (amateur radio)
"HEY YOU" (loud shouting) WEB: http://www.mixcom.com/tpeters
43? 7' 17.2" N by 88? 6' 28.9" W, Elevation 815', Grid Square EN53wc
WAN/LAN/Telcom Analyst, Tech Writer, MCP, CCNA, Registered Linux User 385531
[snip]
2) I don't want a pre-built board with peripherals I don't need on it. I
am a great believeer in actually designin the hardware to suit the
problem I am solving
-tony
-----REPLY-----
Hi,
Please check this approach to a SCSI to IDE and SD interface
My design for the SCSI to IDE and SD interface is just the basics:
Z80, RAM, ROM, UART, IDE, SD, and SCSI controller.
http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder¶m=SCSI2IDE
Everything fits comfortably on a Eurocard PCB.
All the part are commonly available for about $20-$30 total.
Thanks
Andrew Lynch
Is the Z53C80 still available new ? If so from where ?
Cheers.
Phill.
-----REPLY------
Try findchips.com
Digikey, Quest Components, Area51ESG, eBay, etc.
You might need to get an RFQ.
Thanks!
Andrew Lynch
PS, if you or anyone else is interested in helping/developing on making this
project a reality, please join me on vintage-computer.com forums. I am
assessing interest in this as an N8VEM project and need some volunteer
builders to launch the project. The schematic, PCB layout, and parts list
is ready for a prototype order which will happen once there is enough
builders involved to sustain the project.
Coming a bit late into this, but anyway...
On 11/18/10 08:39, "Jerome H. Fine"<jhfinedp3k at compsys.to> wrote:
> >Antonio wrote:
>
>>>> >>>Having (many years ago) recovered data from a borked RT-11
>>>> >>>filesystem, I can certainly confirm that.
>>>> >>>
>>> >>However, I don't understand how you can use TECO to actually
>>> >>repair an RT-11 filesystem. For that purpose, I can only see
>>> >>SIPP as being able to
>>> >>change or repair
>>> >>
>> >I'm pretty sure I didn't say "repair"; I merely recovered data.
>> >
>> >I don't recall exactly what went wrong, but essentially I went
>> >in with TECO and found the right blocks for the various source
>> >files I needed, loaded them into TECO and wrote them out
>> >to floppy. Needed some minor tidy up as I recall but that's about all.
>> >
>> >
> OK!! I understand completely!! If anyone else who is interested does not
> understand, please ask some questions.
>
> If the ASCII data in question was not in the first buffer, than I assume
> that
> something like the TECO command:
> <ASstring$:;J9999K>$$
> was what you used to find the start of the file which you had lost.
Well, yes and no.
What you actually do is:
ERfilename$_string$$EWnewfile$HPW$EC$EX$$
(assuming that all the data you are interested in are in the buffer,
otherwise include P commands in there to the appropriate amount, before
the HPW.)
If you really want to use A to append more data from the disk, you
should probably not use 9999K to dump the current buffer, but use HK
instead.
Also, if a search fails, you'll aready be at 0, so no reason for the J
command.
> By the way, KED can do the same, but is limited to devices (I assume that
> you must have done a non-file-structured open, i.e. ERdev:$$) that are less
> than 32768 blocks. Since I have never had occasion to edit a full MSCP
> device of 65535 blocks, I just never noticed the limitation. This
> restriction
> for KED also applies to files. So KED can INSPECT a logical device which
> is 32767 blocks or less or an RL02 device, but no physical device or file
> larger than 32767 blocks in total.
TECO itself will not care, so that would be a limitation from the RT-11
point of view, in that case. TECO will serially read a file (or device)
>from start to finish, and don't really care about the file position
information as such.
>>> >>Can you describe how you used TECO to recover data from a
>>> >>borked RT-11 filesystem (assuming that you did more than just
>>> >>READ the text contents
>>> >>of the files
>>> >>in the same manner that KED would also allow using a
>>> >>non-file-structured edit
>>> >>of the whole device)? Otherwise, if you just used TECO to
>>> >>just READ the
>>> >>text
>>> >>strings, please confirm that as well.
>>> >>
>> >I didn't fix a corrupt system back to a working system. I read
>> >blocks from disk into TECO (as you say, in a non-file structured
>> >mode), somehow found the root directory and worked out where the
>> >files I cared about lived, read each of those and saved them to floppy.
>> >Then either the disk was reformatted or it went back to whoever we
>> >bought it from for a replacement- I just don't remember.
>> >
> More than likely, you just found the source ASCII text you were looking
> for and wrote
> that to the floppy file using something similar the the TECO command
> that I suggested.
> TECO is not designed nor able to show individual words of a specific
> block as SIPP
> is able to do.
Not sure what SIPP is, but TECO can handle, and display, anything. It
was designed to be able to deal with any kind of information, not just text.
>> >TECO can certainly read disk block N, and having done that it can surely
>> >mangle that disk block; what I'm not sure of is whether it can then
>> >write that block out to the required disk block.
>> >
> I really don't think so. TECO can, as far as I know, work only with
> ASCII text strings.
No. TECO works perfectly fine with any kind of binary data.
> Binary data can't be managed easily, if at all, by TECO such as what
> SIPP can do.
No. TECO handles binary data just fine.
Whenever you enter text, all characters are allowed. And by all
characters, I really mean all characters. Control characters are just as
welcome as printable ones. A few characters have special meaning in
TECO, such as ESC, ^C, and a few more. ESC can be used by instead
setting another character as the delimiter for the search string. Other
special control characters can be inserted by prefixing them with ^Q,
which means that the next character should be taken literally, and not
be interpreted. For most characters though, nothing special is needed at
all, and you can just enter them in your search string.
In the case you don't really want to type the control characters as
such, you can create the search string before using it, and then just
suck it into your search string as well.
In addition to this, you also have the powerful pattern matching of
search strings, that TECO gives you. So you can say that any character
should match at a specific position, and then match whatever comes after
more specifically as well (or any number of other potential pattern
matching schemes you can think of).
Johnny