test-drb

test-drb@ccmp.vtda.org

101090 discussions

by lynchaj＠yahoo.com

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

15 years, 5 months

Atari SLM 804

by keylard＠ncidata.com

Could you let me know whether it comes with a manual and toner? What condition is it in? Much obliged, Robert keylard

15 years, 5 months

SCSI to IDE

by lynchaj＠yahoo.com

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

15 years, 5 months

SCSI to IDE

by trag＠io.com

>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

15 years, 5 months

SCSI to IDE

by lynchaj＠yahoo.com

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.

15 years, 5 months

Fw: [Amateur-repairs] Computer drives

by pu1bzz.listas＠gmail.com

----- 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 >

15 years, 5 months

Free SCSI CD-ROM drives -- last stop before the dumpster!

by a50mhzham＠gmail.com

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

15 years, 5 months

SCSI to IDE

by lynchaj＠yahoo.com

[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&param=SCSI2IDE Everything fits comfortably on a Eurocard PCB. All the part are commonly available for about $20-$30 total. Thanks Andrew Lynch

15 years, 5 months

SCSI to IDE

by lynchaj＠yahoo.com

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.

15 years, 5 months

TECO...

by bqt＠softjar.se

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

15 years, 5 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb