test-drb December 2010

test-drb@ccmp.vtda.org

154 participants
208 discussions

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.

13 years, 4 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 >

13 years, 4 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

13 years, 4 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

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

13 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

13 years, 5 months

AT&T 3B1 keyboard protocol

by classiccmp＠philpem.me.uk

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

13 years, 5 months

OS X (was: what was VMS/OpenVMS written in?)

by bqt＠softjar.se

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

13 years, 5 months

Obscure C code (was Re: Excessive optimization)

by rick＠rickmurphy.net

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

13 years, 5 months

SCSI to IDE

by lynchaj＠yahoo.com

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

13 years, 5 months

Jump to page:

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