Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!beartrk!ceilidh!dnichols From: dnichols@ceilidh.beartrack.com (DoN Nichols) Newsgroups: comp.sys.3b1 Subject: Re: "Floppy tape" Keywords: segment size, standalone boot Message-ID: <1991Feb20.030951.3963@ceilidh.beartrack.com> Date: 20 Feb 91 03:09:51 GMT References: <72@fbits.ttank.com> <1991Feb18.162005.15219@sci.ccny.cuny.edu> <73@fbits.ttank.com> Sender: dnichols@ceilidh.beartrack.com Organization: D and D Data, Vienna, VA. Lines: 63 In article <73@fbits.ttank.com> Mariusz@fbits.ttank.com (Mariusz Stanczak) writes: >The largest -T I tried so far was 0.5MB, but even with `dbuf''s double >buffering `gtar' (and for that matter all other processes) seem to be >prevented from working when the tape does its "seeks" (the MeterMaid's >kernel line goes 100%), so this whole idea turns kind of flat (the point >would be to keep the thing streaming. Then the resource use by the dri- >ver seems very low). All these handicaps seem to go together with the >rest of the implementation (23MB out of a 60MB media?!?), and the culprit >looks to be the I/F board (or is there more to it?). Anyways, looks like >another exciting (and very marketable ;-)) project for the 3B1 wizards-at- >-large, armed with the Technical-Docs-and-sources, and patience of us, >the-buyers-to-be. Are you listening? Can this thing be made to work >right? BTW, How is the reliability of the device as it is, i.e. working >VERY hard? All in all, I'll take it any day over floppies, if it doesn't >break too often. The capacity problem is caused by the choice of a floppy-tape interface drive. This drive requires the pre-formatted tapes, and second, uses only six tracks on the tape. The Archive drive which I use with teacat (tek 6130), is using nine tracks. (I forget which is the interface spec, and which is the format spec, I think one is QIC-24 and the other QIC-36). This is driven by a scsi interface through a Adaptec controller. The drive also DOES NOT require a pre-formatted tape, nor does it enforce a retension pass when the tape is loaded. (The retension pass is built into the firmware of the tape drive. Try disconnecting it from the computer, powering it up, and putting in a tape. It WILL retension.) Probably good idea to use a write-protected tape if there's anything on it, though I don't think that the drive will try to write while disconnected from the system. First, we want to use such a drive, second, if we don't make a scsi interface and driver for the drive, we want to make an INTELLIGENT controller to live in the slot. It should have a 6809 or better for intelligence, and a buffer memory of 512k or so. (Hmm, if we don't use fifo's for the buffer, then maybe we need to see that 6809 and raise it to a 68008. :-). The controller MUST be INTELLIGENT, so it can be transferring from its own memory to the tape drive while the system is building up the next buffer full Ideally, we want to have two full buffers, say two 256k buffers, and independent hardware transferring the first buffer to tape, while the system loads the second buffer. This would give the system a chance to keep the drive streaming. (Even if we can't keep it streaming, the Archive drive is much better about stopping the tape quickly, and re-starting it after re-positioning for the IRG.) Does anybody out there have a source for an extender card for the 3b1? I am reluctant to attempt any interface board design when I can't probe the board unless the system is stripped nude, and the backplane board is stressed by bending the board-under-test away from the cpu board. (No! I haven't tried this, and don't intend to!) Sounds like a good project, but like most others, the available time for the project is the limiting factor. (Maybe when I retire :-) Good Luck All DoN. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: --- Black Holes are where God is dividing by zero --- Brought to you by Super Global Mega Corp .com