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
(once more, from the correct email account...)
Hi guys,
Does anyone have any details on the control protocol for the keyboard on
the AT&T 3B1?
A command list and/or scan code list would be most useful... or even
actual driver source code :)
I'm about a third of the way there with my emulator -- it's running the
BootPROM, passes the MAPRAM, VRAM and Base RAM self tests, and I'm well
on the way to implementing memory mapping/protection and the UI
interfaces (keyboard, mouse and video)... I'm not sure how to go about
emulating the telephony hardware though; I might just leave that
"unemulated" for now.
Thanks,
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
On 12/01/10 23:55, Richard<legalize at xmission.com> wrote:
> In article<alpine.DEB.2.00.1012011116190.24432 at slate.spiritone.com>,
> "Zane H. Healy"<healyzh at aracnet.com> writes:
>
>> > On Wed, 1 Dec 2010, Richard wrote:
>> >
>>> > > Since it has a BSD kernel underneath, I'm guessing that all of the OS
>>> > > proper is written in C and that all the Apple stuff on top is written
>>> > > in Objective-Cish.
>> >
>> > It does not have a BSD kernel underneath. It uses the Mach Microkernel.
>> > It has a BSD layer on top of that.
> Sorry, my mistake. I knew there was BSD in there somewhere. Still, I
> doubt the Mach stuff is written in Objective-C, although I believe it
> originally came from NeXT, so who knows.
Well, technically, OS X is neither Mach, nor BSD. But a mix of both. See
http://en.wikipedia.org/wiki/XNU for more details. But I'd consider it
closer to BSD than Mach myself. There is not really much of the
microkernel left in there...
Johnny
At 11:04 PM 12/2/2010, Ethan Dicks wrote:
>On Thu, Dec 2, 2010 at 7:48 PM, Fred Cisin <cisin at xenosoft.com> wrote:
> > On Thu, 2 Dec 2010, Eric Smith wrote:
> >> > A[i++] = i++;
> >> I can't quote chapter and verse, but I'm fairly sure the standard will
> >> say that the result of that assignment is undefined.
> >
> > C can be pretty loose about letting you do such.
>
>There are many things that folks commonly do that are officially
>undefined... like strlen(NULL) (that returned 0 on an NCR box but
>segfaulted a SPARC - the NCR guys tried to claim it proved the Sun was
>broken, but I had to point out that it's undefined).
I remember this with a large potential customer with a bunch of
applications running on HP-UX that needed to be ported to ULTRIX.
lots of code like
strcpy(foo, NULL);
used to initialize strings and
strcmp(foo, NULL)
to see if a string is empty, etc. Apparently location 0 in memory had a
zero.
Fixing this required a lot of work, then we had to fix binary blobs
written to disk (big-endian) to fix them to little-endian.
All of this was used to demonstrate that the DEC platform was obviously
unusable.
Aren't sales reps fun?
Probably more relevant to the compiler optimization thread, another fun
with marketing incident was the Sun rep handing our customer a "simple
little benchmark" that their compiler apparently recognized and
optimized out. The SPARC ran it in seconds while our MIPS based machine
took quite a while. This was my first run-in with the benchmark
preprocessor that did "deep optimization" of the SPECmark benchmarks.
-Rick
SCSI to IDE
Joachim Thiemann joachim.thiemann
<mailto:cctalk%40classiccmp.org?Subject=Re%3A%20SCSI%20to%20IDE&In-Reply-To=
%3CAANLkTikac5TkJkKANRBy_tH4rvEUZPE0qfBfS%3DouSuJN%40mail.gmail.com%3E> at
gmail.com
Sat Nov 27 09:07:00 CST 2010
* Previous message: SCSI to IDE
<http://classiccmp.org/pipermail/cctalk/2010-November/294382.html>
* Next message: SCSI to IDE
<http://classiccmp.org/pipermail/cctalk/2010-November/294386.html>
* Messages sorted by: [ date ]
<http://classiccmp.org/pipermail/cctalk/2010-November/date.html#294385> [
thread ]
<http://classiccmp.org/pipermail/cctalk/2010-November/thread.html#294385> [
<http://classiccmp.org/pipermail/cctalk/2010-November/subject.html#294385>
subject ] [ author ]
<http://classiccmp.org/pipermail/cctalk/2010-November/author.html#294385>
_____
On Fri, Nov 26, 2010 at 11:48, joe lobocki <jlobocki at gmail.com
<http://www.classiccmp.org/mailman/listinfo/cctalk> > wrote:
> So what is our option? I have seen SCSI to IDE adapters around, but they
go
> up into the $100's to $200's, say you have a minimum 10 machines, that
> leaves you somewhere between $1,000 and $2,000 total, before the disk or
> devices. If we could design a simple SCSI to IDE interface, we could be
set
> for a good long while on storage for these devices for a decent amount of
> time. There are all sorts of adapters to IDE, there is CF to IDE, SD to
> IDE,
> SD to CF which could be placed in a CF to IDE adapter if need be, i'm sure
> one could also rig up a USB drive to SCSI if one tried, but I could be
> wrong.
>
>
I have previously proposed here a SCSI-to-SD interface; I've only done
preliminary brainstorming on it, but think it should not be too hard. The
SD card interface is very simple, both from a logic and electrical point of
view: if you don't care much about speed it can be done with SPI. (the speed
should be sufficient to keep up with 68k Mac, Amiga and Atari) All logic
can probably be done in a single AVR or even PIC chip, if you run that at
3.3V, the only additional hardware is the SCSI level shifters.
I do not know enough about low-level SCSI to start designing this yet, and
since I gave away my Amiga 3000 and classic Macs my interest in this project
has all but disappeared... still it'd be kinda fun, I think.
Joe.
--
Joachim Thiemann :: http://www.tsp.ece.mcgill.ca/~jthiem
-----REPLY-----
There was some room left on my SCSI to IDE converter board design so I added
an SD socket.
The SD circuit is very simple and is able to work with some left over inputs
and outputs from the UART.
I think this design would allow for a SCSI to SD converter as you mentioned.
The original intent was for SCSI to IDE converter but would also allow for
SCSI to CF via an IDE to CF adapter.
After a closer reading of the Z53C80 datasheet, I think it is possible to
implement both the polling mode and
a pseudo-DMA mode SCSI. The circuitry seems pretty straight forward and I
think an 8 MHz Z80 should be
able to get some fairly decent transfer speeds.
http://www.vintage-computer.com/vcforum/showthread.php?22906-SCSI-1-to-from-
IDE-drive-converter
Andrew Lynch
