- test-drb@ccmp.vtda.org - classiccmp.org

by ajp166＠bellatlantic.net

From: Fred deBros <fdebros(a)verizon.net> >Is there an ISA card that has the IDE irq assignable to any IRQ? Older ones did. IDE IRQs were 15 and 14. >U guessed right: I'd like to stick a secondary ide drive (CDROM >obviously) into a 486 that has only one ide (IRQ14)drive, but no plug >for a secondary drive, and no, I cannot use the ide cable as it is a >laptop, but yes, it has the bus connected to a dockstation. And yes I yes you can. I've done it. one of my 486boxen has 3 CDroms and a 500mb IDE disk. It serves as a CD server running Win95. Some of the real early 486s the bios was a bit poor but most of the better ones it's been no problem. FYI: for the CDrom you simply do nothing at the bios level and it's the OS that has to find and install the CDrom. If the cdrom is a standard the win95 drivers will do though I've had a few oddballs that I had to use the driver supplied with the drive. Allison

24 years, 3 months

3
2
0 0

Anyone need 2112 RAMs

by mhstein＠canada.com

Yeah, I saw those (at Active, right?); in fact here they were 5 for 10 cents. Bought a couple packs myself but alas, I don't know of anything that uses them, not PETs anyway; I think you're thinking of 2114s, 1Kx4. There were 4 versions of the static RAM PETs: (6316 ROMs equivalent to 2316B) 320008: 6540 ROM, 6550 RAM & VRAM 320081: 6316 ROM, 6550 RAM & VRAM 320132: 6540 ROM, 2114 RAM & VRAM 320137: 6316 ROM, 2114 RAM & VRAM The Dynamic RAM PETs used 2114/6114s for VRAM. ROMS used include 2316/6316, 2332, 2364/6364. RAMS used include 5298, 4108, 4116 Parallel disk drives used 2114s. mike ----------Original Message----------- >Date: Thu, 02 May 2002 21:19:24 -0400 >From: Arlen Michaels <arlen.michaels(a)sympatico.ca> >Subject: Anyone need 2112 RAMs? >I was surprised to find a local supplier clearing old stock of 2112 RAMs. <snip> >I believe this was the chip used in late-model Commodore PETs <snip>

24 years, 3 months

2
1
0 0

APPLEVISION Monitor

by acme_ent＠bellsouth.net

> From: Richard Erlacher <edick(a)idcomm.com> > The problem is that the popular U.S. vendors expend entirely too much of their > resources on packaging, thinking, perahaps correctly, that it will help sales, > but they forget, oir perhaps not, that the individualized packaging will make > their systems difficult to upgrade over time, thereby making the long-term > usefulness of considerably less value. Dick, I believe they do this deliberately, to inhibit upgrades and repairs. I make a lot on upgrades and repairs of systems I originally built and sold, but the big names only make money when they sell a machine, so naturally they prefer that people replace their PCs instead of fixing them or beefing them up. When people come into my shop and I can get them to understand "total cost of ownership," they buy from me every time. Glen 0/0

24 years, 3 months

2
1
0 0

id these weird ics?

by rigdonj＠cfl.rr.com

Today I picked up a wire wrap card with some strange ICs. They're 16 pin dips with white ceramic bodies and gold lids and legs. They have the numbers 7552-1C and 7350 on them. I believe the 7350 is a date code. There are other ICs on the card and they're all date coded to 1973. There's also a note on the board that says that it was modified on 7/25/74. There's also a trademark symbol on the ICs that looks like a black box with a lower case "i" showing through in gold. I don't think I've ever seen this trademark before, does anyone know what company it's for? Anyone know what the ICs might be? Joe

24 years, 3 months

2
3
0 0

Documation M200/DEC CR11 card reader manual/info needed

by djg＠drs-esg.com

Hans B Pufal wrote: >Vintage Computer Festival wrote: >> I need the pinouts of the card reader interface. Does anyone have this >> information? Is the service manual available online (in some nook I >> haven't looked into yet)? > >I found it on the web somewhere, I am putting a copy on line for you at >www.aconit.org/hbp/m200ref.pdf it is about 21Mb. Give my upload a few >minutes to complete. > The scan was from my site http://www.pdp8.net/query_docs/query.shtml If anybody knows of an extra card weight around I need one for my M-200. David Gesswein http://www.pdp8.net/ -- Run an old computer with blinkenlights.

24 years, 3 months

1
0
0 0

request for shipping help - PDP-11/34 from MA to MO

by jwest＠classiccmp.org

Greetings folks: Bob Shannon has a PDP-11/34 rack system for me in Massachusetts sitting in his garage. I can take care of having it shipped from any location that has a loading dock, so the shipping isn't a problem as long as it is shipped sometime within the next week or two at most. However, the shipper will want it banded to a pallet and shrinkwrapped and Bob doesn't have the stuff to do that, nor does he have a loading dock. Is there anyone who might be able to assist getting the system banded to a pallet and shrinkwrapped, and possibly to a loading dock that the shipper will pick up from? Any thoughts or assistance is greatly appreciated. Thanks! Jay West

24 years, 3 months

1
0
0 0

os/2 warp3 install disk showed up missing

by rhudson＠cnonline.net

must be 10 years old... mebe not... anyway my install disk has vanished, I have the whole rest of the .2x10^2 disks (thats about 20 right(^: ) can anyone help me out? ron.

24 years, 3 months

6
6
0 0

Ok, Floppy Experts...

by dquebbeman＠acm.org

Well, here is the pinout of the typical IBM external floppy drive (5.25) & interface: External Diskette Adapter -----------------------, unused 1 | Diskette Drive unused 2 | ,----------------------- unused 3 |----------------| 2 unused unused 4 |----------------| 4 unused | |----- alignment slot unused 5 |----------------| 6 Drive Select 4 Index 6 |<---------------| 8 Index Motor Enable C 7 |--------------->| 10 Drive Select 1 * Drive Select D 8 |--------------->| 12 Drive Select 2 * Drive Select C 9 |--------------->| 14 Drive Select 3 * Motor Enable D 10 |--------------->| 16 Motor On * Direction Select 11 |--------------->| 18 Direction Select Step 12 |--------------->| 20 Step Write Data 13 |--------------->| 22 Write Data Write Gate 14 |--------------->| 24 Write Gate Track 00 15 |<---------------| 26 Track 00 Write Protect 16 |<---------------| 28 Write Protect Read Data 17 |<---------------| 30 Read Data Head Select 18 |--------------->| 32 Head Select unused 19 |----------------| 34 unused -----------------------' `----------------------- Bottom Row Sockets 20 - 37 of the DB37S Connector are Ground Now, here is what Chris gave me earlier for the Type 9331 Model 011: External Signal Cable Connector Table 7-1. Pin Assignments for 37 Pin D Shell Cable Signal Name Signal Pin Ground Pin Reduced Write Current 2 20 Drive Select 0 8 26 Motor On (Head Load) 10 29 Direction Select 11 29 Step 12 30 Write Data 13 31 Write Gate 14 32 Side one Select 18 36 Ready 9 27 Index 6 24 Track 00 25 33 Write Project 26 34 Read Data 27 35 Diskette Change 19 37 Two Sided 7 25 8-Inch Drive Attached 5 23 5.25-Inch Drive Attached They look pretty compatible... Now, the next step would be OS support. I think I know how to make it work for an older DOS machine, but what about Windows? Anyone else done this yet? Regards, -doug q

24 years, 3 months

1
0
0 0

Ancient 6502 FOCAL source code

by jasonz＠issproinc.com

Hi .. I happen to have this Ancient 6502 Focal source code in Lisa format for the Apple II computer Jason Zinserling

24 years, 3 months

4
3
0 0

NABU! and VT180

by kenziem＠sympatico.ca

After hearing about them for quite a while I found them. I picked up a few NABU computers and the adapters still in the box. Also a VT180 with disks and manuals. I though last weekend was good when I grabbed a Sparcstation SLC, ELC, and a PSC-586VGA SBC for a buck each.

24 years, 3 months

1
0
0 0

Power Cords (Was: RE: Micro$oft Biz'droid Lusers (was: OT email response format)")

by dquebbeman＠acm.org

> On Fri, 26 Apr 2002, David Woyciesjes wrote: > > > Did someone say power cords??? I got a box of about 4 dozen if you need any. > > Heh. I can get you about 4 dozen boxes of 'em.... I have finally figured out what the dealieo is with this... I've got so many it's as if two or three came with every device. But I was the one who unpacked almost everything at the office for the last 6 years. So what's happening is that they are reproducing. I think you're safe with just two in a box, they're not bunnies, but when you put three or more together, they gain some kind of sexual critical mass and start reproducing. Everything that's been given away had a power cord, and almost nothing has been thrown away. So this has got to be the answer... ;)

24 years, 3 months

6
11
0 0

Mac SE PC Drive Card

by mythtech＠mac.com

>> I picked up another Mac SE today, and it's got a "Macintosh SE PC Drive >> Card" installed in it, with a big connector on the back of the SE. What is >> the card for? > >'A big connector'??? What is it really? How many pins, how arranged. Is >it, for example, a DC37 socket? I was going to say I thought it was a 27 pin from memory, but a 37 pin D shell sounds about right. Apple bundled the card with a drive, but that drive might just be a regular drive in an apple case. How would I be able to determine that? (I don't mind opening mine to check if it means the other guy can benifit from the info and assemble a drive to use with their card) -chris <http://www.mythtech.net>

24 years, 3 months

1
0
0 0

adflip.com

by vcf＠siconic.com

I wonder if this adflip.com site (the one that has the classic magazine advertisements) isn't setup by one of those guys that sells old magazine ad pages on eBay. It would make sense. -- Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org * Old computing resources for business and academia at www.VintageTech.com *

24 years, 3 months

1
0
0 0

Free DEC stuff, Washington DC

by dquebbeman＠acm.org

> Dave Woodman wrote: > > > > lee courtney wrote: > > > > > Damn, wrong coast! > > > > > > > Bugger, wrong continent! > > Dam! Wrong planet! Damn! Wrong incarnation!

24 years, 3 months

2
1
0 0

OT: Prankster selling?

by quapla＠xs4all.nl

Would this guy be a prankster or ..... http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2022001381 Ed -- The Wanderer | Politici zijn gore oplichters. quapla(a)xs4all.nl | Europarlementariers: zakkenvullers http://www.xs4all.nl/~quapla | en neuspeuteraars. Unix Lives! M$ Windows is rommel! | Kilometerheffing : De overheid '97 TL1000S | weet waar je bent geweest!

24 years, 3 months

7
6
0 0

PC CD-ROM drives

by acme_ent＠bellsouth.net

Richard Erlacher wrote: > While the logical replacement has never been a problem, the rounded front that > fits the case is a virtually impossible thing to replace by the time the drive > needs replacment. They seem to require a rounded drawer front with no bezel > of the drive. Whereas the bezel can be removed easily enough, finding a drive > with that rounded front that fits, precisely, the slot in the plastic > front-face of the box is a problem. The part number is seemingly never > available more than 90 days after the computer is no longer an off-the-shelf > item. I've seen very few HPs with this setup, but the Acer Aspire is famous for it. Fortunately the Aspire has a couple of "normal" 5.25" bays so I just leave the old drive in place and add a new one in an empty bay, or if I'm lucky I have a drive yanked from a dead Aspire. > > No ATAPI CDROM has ever been a problem to replace under Windows 9X, to my > experience. Unless Win9X is hosed. Yesterday I worked on a Gateway P-III running Win 98, which wouldn't boot, but hung on the splash screen. Yanked the IDE cable off of the CD-ROM drive and the system booted and all devices worked perfectly. Tested the drive in another box; the drive was fine. Put another drive in the Gateway -- no boot. Took CONFIG.SYS, AUTOEXEC.BAT, WIN.INI and SYSTEM.INI out of the picture. No boot. Moved the drive from master to slave. No boot. Replaced the IDE ribbon. No boot. Put the drive on the same ribbon as the hdd, hdd as master, CD-ROM drive as slave. No boot. Uninstalled and reinstalled the motherboard drivers. No boot. Pulled the hdd, put in a new one, loaded Win98, and the system booted and the CD-ROM drive worked. Put the original hdd back in -- no boot. Reset the BIOS to default settings and made sure both IDE ports were turned on. No boot. Verified that both ports were visible to Windows -- no boot. Turned DMA off in Windows -- no boot. Ran a virus check and didn't find anything. Did I miss anything? (serious question). Finally I wiped and reloaded the hdd and all was well. I've seen this five or six times in ten years. It's something deep down in the Windows goo . . . Apologies -- seriously OT. Glen 0/0

24 years, 3 months

2
1
0 0

Televideo Systems

by dquebbeman＠acm.org

> > We had 25 of the TS-803 at RETS, and I've been haggling > > for the only one I know is left from the guy who has it, > > so far, to no avail. I have manuals and lots of software > > for it, including TELE-WRITE and TELE-DRAW. We had a > > MouseSystems optical mouse on ours that worked with TELE-DRAW. > > Cool. I'm pretty sure the TS-806 and TS/TVI-800's were text-only, but if > the text-mode software still is compatible, that'd be awesome. Well, when you were running CP/M, these were text-only too. But they had 640 x 240 graphics, with primitives in ROM that sped things up quite a bit. DRI's GSX-80 came with the systems to provide a standard layer for the graphics support. Then DRI's CBASIC had language extensions for drawing lines and such. But the overhead was high, translating from a real-number world coordinate system to an integer normalized coordinate system and then to the integer physical device coordinate system. I bypassed all that using some assembly language interfaces I wrote and went straight to ROM. The application we'd written in CBASIC using its "native" graphics statements took 6 minutes to finish drawing the screen (an image of a prototyping board). The re-written version drew the same inage in six seconds on a 4MHz Z-80. -dq

24 years, 3 months

1
0
0 0

Z-100 parts

by acme_ent＠bellsouth.net

Does anyone have any spare Zenith Z-100 expansion cards? I'd particularly like to get some more RAM, the USR internal modem, and an RTC board. Cash or possible trade. Thanks, Glen 0/0

24 years, 3 months

1
0
0 0

Open firmware/Power Mac 7200/75

by csmith＠amdocs.com

Ok guys, so there was a problem in the terminal settings. (Hey, it's an IBM 3151(?) terminal, and mostly configures in Swahili) Open firmware does, indeed, work on this system. Don't ask why it didn't work earlier with the Wyse (which was set up properly, I'm sure, since it's in use on the machine which I used to finally get the IBM configured properly ;). Anyway, it will now boot into Open Firmware, even without keyboard, monitor, etc, attached. I'll attempt to install Darwin on the disk sometime soon. It may work, but at the moment, it has less RAM and less disk than they say is "required." Chris Christopher Smith, Perl Developer Amdocs - Champaign, IL /usr/bin/perl -e ' print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n"); '

24 years, 3 months

2
1
0 0

SunOS4 and Sun i386

by tarsi＠binhost.com

I have a friend who has a Sun i386 running SunOS 4 and is looking for documents/webpages related to either of them. Especially for SunOS 4 manuals. Anyone got any or can point me to information? Thanks! Tarsi 210

24 years, 3 months

4
6
0 0

Tape dumping programs for Unix/Linux...

by cdl＠proxima.ucsd.edu

> Date: Thu, 2 May 2002 21:23:26 -0500 (CDT) > From: Doc <doc(a)mdrconsult.com> > To: ClassicCmp List <classiccmp(a)classiccmp.org> > Subject: RE: Tape dumping programs for Unix/Linux... > In-Reply-To: <000501c1f245$6a304ca0$1aefffcc@Shadow> > > On Thu, 2 May 2002, Douglas H. Quebbeman wrote: > > > I just did a 'dd' of a bad QIC-80 tape; it read the entire tape > > as a single file, and didn't bail out. > > > > I've not done that with magtape, but ISTR someone else here > > saying that 'dd' does raw reads, bad blocks and all... > > > > My bad if not true. > > No bad, just an honest difference in perspective. I recently went > through this with a set of VMS-based diagnostics tapes. AFAIK, the > tapes are undamaged, but dd returns a valid read - of the first file on > the tape - and stops. I'm not that familiar with non-"streaming" > formats, so I just accept what is without knowing why.... > dd on a disk or raw filesystem ignores files. On a tape archive, even > using the raw device as the if, dd reads files and stops at the end of > the first record. I think you have your terminology mixed here. dd reads records and stops at the end of the first file. carl

24 years, 3 months

2
1
0 0

WTB: Ethernet Hub/Switch

by dquebbeman＠acm.org

> > You wrote... > > > I ran out of ports a few weeks ago so i am looking to buy a 4-5 port > > > 10mbit or so ethernet hub or switch. Contact me off-list. > > > > 10mbit OR SO? Let's see, I think I have a few 7mbit units, and maybe a few > > 14mbit ones. Wait - I know - I have a 18mbit unit and a 8mbit model - so if > > you daisychain them... voila - 10mbit. > > "Well, our [hub] goes to 11 [Mbit]." Yeah, but the synch has a tendancy to spontaneously combust... ;)

24 years, 3 months

1
0
0 0

Need IDT 7M624 Info

by Innfogra＠aol.com

I think we have it solved. I believe it could be a 1 Meg SRAM. Thanks for the info about IDT. The 16 pieces soldered on the top and bottom seem to have a solder pad pattern of 5 on the ends and 9 on the sides. Would this jibe with the 64KX8 configuration? Sorry for the "glamour" look to the pictures, it was accidental. I use my Sony 730 HI-8 videocamera hardwired to a framegrabber in the computer. I have two adjustable clamp on lights, one incandescent with a magnifier and one with a round fluorescent that I normally use for photography. The round light gives fairly even lighting but it was busy so I used the Incandescent. I was really surprised at the difference. Not only was it much warmer but the contrast was way up. These are the only pictures I have shot with that light. There is only one label on top of one of SRAMs. No other labels except IDT 7M624 plated in gold on top of the ceramic. You should be able to see both in the pictures. Thanks for the help. Paxton Astoria, OR

24 years, 3 months

3
2
0 0

Tape dumping programs for Unix/Linux...

by dquebbeman＠acm.org

> > > The emulator community is vigorously using a tape image container > > > format known as TAP for precisely this purpose. > > > > > > Each record from tape is written to file prefixed *and* suffixed > > > by a four-byte record length in little-endian format. A zero- > > > length record is represented by a 4-byte value of zero; although > > > intuition might call for 8-bytes (a prefix & suffix with nothing > > > in between), this is not the case. The convention appears to come > > > directly from FORTRAN 77's handling of unformatted sequential files. > > > > > > And EOF is represented by two consecutive zero-length records. > > > > Darn...sounds like a subset of what I use. I'd be interested > > in knowing more about TAP (with an eye towards adopting use of it), > > and would suggest some possibly missing features might be: > > Is there any more information on "TAP" other than the program that I > find with Bob Supnik's simh stuff, namely "mtdump" that produces > a "TAP" image given a list of files? It would be nice if someone else > had already written the program that reads a real physical magtape and > produces a "TAP" image. Not really any more information that I know if other than what you've seen here- it's a minimalist convention. But I can recommend Eric Smith's tapecopy program as far as other code to look at. It accompanies tapedump & t10backup in his package. You should be able to find his package here: http://www.36bit.org/dec/software/unix-util/ hth, -dq

24 years, 3 months

1
0
0 0

Anyone need 2112 RAMs?

by arlen.michaels＠sympatico.ca

I was surprised to find a local supplier clearing old stock of 2112 RAMs. This is an NMOS static RAM 256bit x 4. The chips are new, labelled SY2112-A (Synertek I think) and they're supposedly 350 nS devices. I believe this was the chip used in late-model Commodore PETs (after they designed out the earlier 6550 chips); maybe someone wants to confirm this for the list. I seem to recall the Heathkit micro trainer used a couple too, but I could be mis-remembering. Not as commonly needed as the 2102 or 2114 I know, but if anybody wants some I could pick them up. They're 5 for a buck, plus whatever it costs to mail them-- unless of course you want to offer me something extra for my trouble :) -- Arlen Michaels arlen.michaels(a)sympatico.ca

24 years, 3 months

7
7
0 0

2102 SRAM test circuit?

by tothwolf＠concentric.net

I just came across a large number of loose 2102 chips in a junkbox, and wondered if anyone has a schematic of a test circuit for these. I'm not sure how many of them there are yet, but they all appear to be from the same batch; AM9102BPC/P2102A-4 7632QD [32nd week, 1976]. An couple interesting facts I dug up on these chips is that the AM9102 was AMD's first RAM product, and it was first produced in quantity in 1975. I'm thinking these chips might be a good source of ram for a 6800 based homebrew system, especially since I already have the chips and lots of wirewrap (and patience)... -Toth

24 years, 3 months

5
5
0 0

Latest Finds

by dquebbeman＠acm.org

After a trip down to Asian Pearl, Al and I took a trip down to the local recycle place. He spotted an Apple 3.5 inch External drive, the 800k variety we were discussing recently on the list. He wasn't interested, so I snagged it, and it appears to be working fine on the Mac IIci, although I wasn't sure at first, as it took me a while to find any 800k disks. Outside, I found an IBM Type 9331 011 8 inch external floppy drive, a nice black enclosure with the IBM logo in the oval badge set at 45 degrees, like the PS/2 line logos were. The interface connector on the rear has 37 pins and so I'm hoping it's the same as the interface on the old IBM floppy interfaces that had a 37-pin external connector. Anyone know what these drives were used with, and will I luck out on the interface? It needs cleaning... Also, an IDE removable harddrive carry case & two mounting frames, so I can start carrying serious storage two & fro the orifice, er, office. No blinkenlights, although the poprietor indicated he'd dumped a bunch of old stuff six months ago. Oh well, the way he does this is he leaves a pallet out front for people to stack stuff on. I'll start checking more often. Anyway, total damage for the above: eight bucks; five for the Apple drive, two for the IBM floppy, and 1 for the IDE shuttles. -dq

24 years, 3 months

2
2
0 0

Latest Finds

by dquebbeman＠acm.org

> I got a type 9331 model 011 with an AS/400 system... I > think. When I get home, I'll look at it (and its //manual// :) > again. Excellent, and thanks in advance! -dq

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux...

by cdl＠proxima.ucsd.edu

> From: "Stan Sieler" <sieler(a)allegro.com> > To: cdl(a)proxima.ucsd.edu (Carl Lowenstein), classiccmp(a)classiccmp.org, > classiccmp(a)classiccmp.org > Date: Fri, 3 May 2002 12:10:42 -0700 > Subject: Re: Tape dumping programs for Unix/Linux... > Priority: normal > In-Reply-To: <200205030710.AA16219(a)proxima.ucsd.edu.UCSD.EDU> > > Re: > > > Look for a program named "copytape". It copies tapes including the > > block structure, file marks, etc. Unlike dd(1) which only really > > works if all blocks are the same size and there is only one file > > on the tape. It can copy tape-drive to tape-drive or tape-drive to > > disk file, and puts markers in the disk file to indicate the > > structure of the data on the tape. > > > > The versions I found do a fair job of copying a tape...but not > a complete job (particularly for DDS and DLT tapes). > > Why? > > It doesn't know about "setmark". > > On a DDS (DAT) drive, you can have a data record (of variable length, > not just multiples of 128 or 256 bytes, BTW), an EOF (end-of-file mark), > a setmark, or an end-of-tape indicator. OK. It _was_ written long before anything as smart as a DAT drive had been devised. Why do you stress "data record not just multiples of 128 or 256 bytes"? Oh, this is qualified by "on a DDS drive". Certainly 7-track and 9-track 1/2" drives could have fairly arbitrary data records. I have seen tapes with records as short as 14 bytes, and as long as 65535 bytes. Also pre-DLT tapes (DEC TK50) with 1MB records, but only to be read by a MicroVax not a PDP11. > >From "man mt" on HP-UX (since at least 1992, so it fits the 10 year rule, too > :) > DDS format devices also support setmarks which are hierarchically > superior to filemarks. A setmark is used to delineate a group (set) > of files. Reading a setmark is also returned as a zero-length read. > The two can be distinguished by unique bits in the mt_gstat field. > > (In fact, #$%^ HP took out the above text from the 10.20 "man mt" doc, leaving > just a bare reminder that setmarks exist) > > Who uses setmarks? Backup software that wants to be able to locate > files quickly. > > E.g., consider a modified tar/gtar that writes an EOF after every > file, and a setmark after every 1000 files, and also writes s table > of contents (list of files to be backed up) at the start of the tape. > If the user says "restore file FOO", the software can read the table of > contents and determine that FOO is file, say, 2349. It can then issue > two "forward setmark" commands, and then 349 "forward EOF" (or "forward > filemark" or "forward space file") commands to quickly get to the file. > > DDS drives can find a setmark very quickly, faster than they can find > an EOF. > > So....any software trying to *accurately* duplicate a tape should > record the fact a setmark was seen, as well as data record and EOFs > and errors :) As I recall, DDS tapes can also have two partitions, independently writeable. So the tape index can be written onto the first partition _after_ the data is written on the second partition. I don't know any common software that takes advantage of this. carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

24 years, 3 months

3
2
0 0

2102 SRAM test circuit?

by dwightk.elvey＠amd.com

Hi One could throw together a simple socket and connector circuit to put on a parallel printer port. Use a '273 to increase the number of outputs and use one pin as the input. The pins for the 2102 are 1,2,4,5,6,7,13,14,15 and 16 are address lines. 3 is MWR\. 11 is data in and 12 is data out. 10 is +5 and 9 is ground. You do need a bi-directional parallel port. Check out : http://www.lvr.com/jansfaq.htm for ideas on how to control the printer port of a PC ( I would do it with Forth, myself but most others would use C or something ). Write a March "C" and pause between passes for a few seconds to check retention. Dwight >From: Tothwolf <tothwolf(a)concentric.net> > >I just came across a large number of loose 2102 chips in a junkbox, and >wondered if anyone has a schematic of a test circuit for these. I'm not >sure how many of them there are yet, but they all appear to be from the >same batch; AM9102BPC/P2102A-4 7632QD [32nd week, 1976]. An couple >interesting facts I dug up on these chips is that the AM9102 was AMD's >first RAM product, and it was first produced in quantity in 1975. > >I'm thinking these chips might be a good source of ram for a 6800 based >homebrew system, especially since I already have the chips and lots of >wirewrap (and patience)... > >-Toth > >

24 years, 3 months

1
0
0 0

Looking for...

by vance＠ikickass.org

A power supply for an RS/6000 397. Peace... Sridhar -- "How do you fight such a savage?" "With heart, faith, and steel. There can be only one." -MacLeod and Ramirez, "Highlander"

24 years, 3 months

1
0
0 0

Available.

by vance＠ikickass.org

Anyone need a power supply for an RS/6000 380/390/390H/3AT/3BT/3CT? Peace... Sridhar -- "How do you fight such a savage?" "With heart, faith, and steel. There can be only one." -MacLeod and Ramirez, "Highlander"

24 years, 3 months

1
0
0 0

Mac SE PC Drive Card

by univac2＠earthlink.net

I picked up another Mac SE today, and it's got a "Macintosh SE PC Drive Card" installed in it, with a big connector on the back of the SE. What is the card for? -- Owen Robertson

24 years, 3 months

2
1
0 0

SunOS4 and Sun i386,, ifconfig -a plumb

by fmc＠reanimators.org

JP Hindin <jplist(a)globe.net.nz> wrote: > I see le0 a lot, but I picked up ie0 from my Sun 4/470, which I'm using on > the 386i. Is this an error on my part? Should I try and set up le0 > instead? Maybe. ie is the driver for an Intel Ethernet chip/card (I have vague recollections of the card being a Multibus card in a VME-to- Multibus frame in a Sun 4/370). le is the driver for an AMD LANCE chip. I can't remember what Ethernet hardware is in the 386i, but a LANCE-based design would not be surprising. Does your 386i boot at all? If so I would expect it to tell you at boot time what devices the kernel is finding. If you can log in, the dmesg command should replay those messages for you (if they're still in the kernel's buffer). -Frank McConnell

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux...

by cdl＠proxima.ucsd.edu

> From: "Stan Sieler" <sieler(a)allegro.com> > To: "Douglas H. Quebbeman" <dquebbeman(a)acm.org>, > "ClassicCmp List" <classiccmp(a)classiccmp.org> > Date: Thu, 2 May 2002 12:06:37 -0700 > Subject: Re: Tape dumping programs for Unix/Linux... > Cc: fmc(a)reanimators.org > In-Reply-To: <000701c1f1e2$a795cd80$e401a8c0(a)tegjeff.com> > Content-Transfer-Encoding: 7BIT > > Re: > > > The emulator community is vigorously using a tape image container > > format known as TAP for precisely this purpose. > > > > Each record from tape is written to file prefixed *and* suffixed > > by a four-byte record length in little-endian format. A zero- > > length record is represented by a 4-byte value of zero; although > > intuition might call for 8-bytes (a prefix & suffix with nothing > > in between), this is not the case. The convention appears to come > > directly from FORTRAN 77's handling of unformatted sequential files. > > > > And EOF is represented by two consecutive zero-length records. > > Darn...sounds like a subset of what I use. I'd be interested > in knowing more about TAP (with an eye towards adopting use of it), > and would suggest some possibly missing features might be: Is there any more information on "TAP" other than the program that I find with Bob Supnik's simh stuff, namely "mtdump" that produces a "TAP" image given a list of files? It would be nice if someone else had already written the program that reads a real physical magtape and produces a "TAP" image. carl

24 years, 3 months

1
0
0 0

APPLEVISION Monitor

by mythtech＠mac.com

>The problem is that the popular U.S. vendors expend entirely too much of >their >resources on packaging, thinking, perahaps correctly, that it will help >sales, >but they forget, oir perhaps not, that the individualized packaging will make >their systems difficult to upgrade over time, thereby making the long-term >usefulness of considerably less value. Apple has taken this to the extreme, >as only a vendor knowing he has a market segment to himself could do. Most of the system manufacturers WANT to make it hard to upgrade the system. They don't want you swapping parts to renew the life of your machine... they want you to just buy a whole new machine every few years. These upgrade impared designes are deliberate. -chris <http://www.mythtech.net>

24 years, 3 months

1
0
0 0

APPLEVISION Monitor

by mythtech＠mac.com

>While the logical replacement has never been a problem, the rounded front >that >fits the case is a virtually impossible thing to replace by the time the >drive >needs replacment. They seem to require a rounded drawer front with no bezel >of the drive. Whereas the bezel can be removed easily enough, finding a >drive >with that rounded front that fits, precisely, the slot in the plastic >front-face of the box is a problem. The part number is seemingly never >available more than 90 days after the computer is no longer an off-the-shelf >item. The last HP I had to do a CD swap on, I gave up finding a replacement "HP" drive, and just found the same model Mitsumi drive, then swapped the front bezel off the drawer. Of course, finding an 8x multi-year old Mutsumi CD drive was a challenge in itself (I tried other Mitsumi's, but on newer ones, and on every other CD drive I found, the drawer position and or mounting clips had changed, so there was no way to align it or put the old bezel on it). One more reason I build my own PCs these days. -chris <http://www.mythtech.net>

24 years, 3 months

3
2
0 0

Tape dumping, bad blocks.

by cdl＠proxima.ucsd.edu

> From: Raymond Moyers <rmoyers(a)nop.org> > To: classiccmp(a)classiccmp.org > Subject: Re: Tape dumping, bad blocks. > Date: Fri, 3 May 2002 01:01:59 -0500 > In-Reply-To: <200205030508.BAA32513(a)conman.org> > > > Funny, on the 9 track tape you dont confront this issue. > 9 track tape is 8 bits + parity right ? so here a bad bit dont > cause you to lose the ability to get the next byte and know > that its a valid byte, a physical superiority it has over the > serial streamers ?. > > Or am i assuming too much again. I think you are assuming that there will never be a dropout over the complete width of the tape. i.e. there will always be at least one "1" bit passing the read head. Data clocking is essentially done on the inclusive OR of all channels, so if they all drop out, you have lost your place. carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

24 years, 3 months

1
0
0 0

OT: WTB: Ethernet Hub/Switch

by torquil＠rockbridge.net

Sorry for being a bit off-topic.... I ran out of ports a few weeks ago so i am looking to buy a 4-5 port 10mbit or so ethernet hub or switch. Contact me off-list. Thanks, Torquil MacCorkle III Lexington, Virginia

24 years, 3 months

7
7
0 0

Tape dumping programs for Unix/Linux...

by erd_6502＠yahoo.com

So I finally got this TSZ07 that I've been wanting for a while so I can archive a mountain of magtape I have (including System III sources for the 11/780, on up to distro tapes of the 1990s). I can use dd to slurp stuff off of tape, but it's tedious. What tools are people using for tape archiving under Linux or Solaris? AIX seems to come with "tcopy" that essentially pulls everything off the tape until logical or physical EOT. I'm looking for something similar - point it at the drive and siphon it on down. At present, because of cable reach, I am talking to the tape drive through an Adaptec AHA1460 PCMCIA SCSI interface on a Dell Latitude LM running RedHat 5.2. I can address the drive fine and dump files with dd and cat. I'm looking for a bulk data slurper, source or RH RPM. I'm willing to throw this beast on the SPARCstation 5, but I'd rather not put it in that corner just yet. At the moment, the drive is several dozen times larger than the computer controlling it. -ethan __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com

24 years, 3 months

7
13
0 0

Tape dumping, Rays epiphany

by rmoyers＠nop.org

To Wit (about dd blocking handling) The original need for dd came with the 1/2" tapes used to exchange data with other systems and boot and install Unix on the PDP/11. Those days are gone, but the 9-track format lives. To access the venerable 9-track, 1/2" tape, dd is superior. With modern SCSI tape devices, blocking and unblocking are no longer a necessity, as the hardware reads and writes 512-byte data blocks. ( what i was familiar with ) However, the 9-track 1/2" tape format allows for variable length blocking and can be impossible to read with the cp command. The dd command allows for the exact specification of input and output block sizes, [[and can even read variable length block sizes, by specifying an input buffer size larger than any of the blocks on the tape.]] (Stan was right on target here eh ?) Short blocks are read, and dd happily copies those to the output file without complaint, simply reporting on the number of complete and short blocks encountered. Murphy's Law was postulated long before digital computers, but it seems it was specifically targeted for them. When you need to read a floppy or tape, it is the only copy in the universe and you have a deadline past due, that is when you will have a bad spot on the magnetic media, and your data will be unreadable. To the rescue comes dd, which can read all the good data around the bad spot and continue after the error is encountered. Sometimes this is all that is needed to recover the important data. Example dd bs=265b conv=noerror if=/dev/st0 of=/tmp/bad.tape.image Yup .. using cat to do the same thing, it gets the err signal and drops, but dd can be told to ignore it So in this case its clearly superior, and the *only* tool for 9 track tapes, ( due to the block handling ) So i stand before you better educated. thx to those that filled in the missing bits Raymond

24 years, 3 months

2
1
0 0

Tape dumping programs for Unix/Linux...

by cdl＠proxima.ucsd.edu

> Date: Thu, 2 May 2002 02:01:33 -0700 (PDT) > From: Ethan Dicks <erd_6502(a)yahoo.com> > Subject: Tape dumping programs for Unix/Linux... > To: classiccmp(a)classiccmp.org > Sender: owner-classiccmp(a)classiccmp.org > Reply-To: classiccmp(a)classiccmp.org > > > So I finally got this TSZ07 that I've been wanting for a while so I can > archive a mountain of magtape I have (including System III sources for > the 11/780, on up to distro tapes of the 1990s). I can use dd to slurp > stuff off of tape, but it's tedious. What tools are people using for > tape archiving under Linux or Solaris? AIX seems to come with "tcopy" > that essentially pulls everything off the tape until logical or physical > EOT. I'm looking for something similar - point it at the drive and > siphon it on down. Look for a program named "copytape". It copies tapes including the block structure, file marks, etc. Unlike dd(1) which only really works if all blocks are the same size and there is only one file on the tape. It can copy tape-drive to tape-drive or tape-drive to disk file, and puts markers in the disk file to indicate the structure of the data on the tape. Copytape is a "classic" piece of software, its source file begins as follows: /* * COPYTAPE.C * * This program duplicates magnetic tapes, preserving the * blocking structure and placement of tape marks. * * This program was updated at * * U.S. Army Artificial Intelligence Center * HQDA (Attn: DACS-DMA) * Pentagon * Washington, DC 20310-0200 * * Phone: (202) 694-6900 * ************************************************** * * THIS PROGRAM IS IN THE PUBLIC DOMAIN * ************************************************** * * July 1986 David S. Hayes * Made data file format human-readable. It should be available at numerous FTP sites. carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

24 years, 3 months

2
1
0 0

Tape dumping programs for Unix/Linux..

by cdl＠proxima.ucsd.edu

> From: Raymond Moyers <rmoyers(a)nop.org> > To: classiccmp(a)classiccmp.org > Subject: Re: Tape dumping programs for Unix/Linux.. > Date: Thu, 2 May 2002 20:15:37 -0500 > In-Reply-To: <3CD16EDB.31791.1013160B@localhost> > > On Thursday 02 May 2002 18:52, you wrote: > > > Someone had copied a tape whose records were 16 KB long using software > > that expected the records to be 8192 bytes longs ... and only asked > > for 8192 bytes in each read() request. > > Now i really do find this interesting > > Lets scope out some examples to illustrate my focus. > > On a floppy or a hard disk as examples you have > pad data inbetween its records these are usually > all FF's constant stream on 1's in other words > then an address mark like FE followed by the header data > Head Sector Cylinder ,, then some more FF's then a start > of data mark the block of data then the CRC .. then all > else is ignored ,, be it artifacts from a prev write ( hub speed jitter ) > or whatever .. the controller is looking for its string of a minimum > number of 1's then the FE and so it repeats all round the disk. > > During lowlevel formatting you are basically building an image > of this track .. complete with the between sector filler of FFs > amd dumping a whole track at once with the write track command. > > These devices are random access, but when you pull the image > off the device using it as a streamer, you are not getting > the filler bytes the address marks or the crc's your getting > only the content of the sectors (soft physical records) > back to back a raw spool off a unix device with a typical > device driver gives you the data without the controler > interested bits off the media. > > I would assume that any decent unix driver up to the minimal > expectations of behavior should act the same, including > that for a proper interface to a 9 track tape. > > If the record length is varible, then is not the record length > in the block headder ? and should not the driver read > that from the headder then xxx bits of data ? No. You haven't been around tape drives long enough. The tapes are not preformatted with block headers. They are written sequentially. In general, a tape drive can only record forward and add data beyond whatever has already been written. > it would seem that any tape used as a random access > block device, that ever had a record re written would > have garbage (from a prev update of that record) > in the block, > just like on a floppy where this happens all the time, > (jitter again) and the controller simply ignores looking > for its resetting minimal number of FF's and the next > address mark Only some very special tapes with extra tracks for tape mark information can be reliably used as random-access block devices. The classic example is DECtape, 3/4 inch wide on 3 inch reels. Pre-formatted into blocks of 129 12-bit words or other interesting combinations. > ( im ignoring the hard sector media with a hole for > every sector, but it would still apply in this scope > albeit a bit differently) > > Now .. excuse me, but ive been around this stuff > for a long time, and i think ive got a really firm grasp > of the minimal amount of things needed in place for > any data-to-media, data-from-media scheme to work. > > So, do i have this right ? No. > That if i spooled off a 9 track tape, and assuming no > non-recoverable media errors, that i would *not* > get all of the data from all the records and without > trailing garbage and the controler interested bits left out ? Your tape-reading program might truncate all block lengths to the length that it was "expecting". Or just quit after the first file instead of reading all the files on the tape. > Knowing the proper expected behavior of any unix > driver i could name ... i find this rather .... > well unexpected. Nobody has said that Unix has well-designed tape drivers. carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

24 years, 3 months

2
1
0 0

One-upsmanship (was: Secret Mac

by ajp166＠bellatlantic.net

From: Cameron Kaiser <spectre(a)stockholm.ptloma.edu> >> If a formula for determining classic computer cool factor gets finalized, >> I'd like to create a calculator script on the VCF website so that people >> can enter their parameters and have their score automatically computed. >> >> We need a unit or label for this number. > >The neuron. Feh! Too common, everyone has a few many don't use them. First it should be dimensionless, those are weird enough. If not then like DB (DeciBell) which will give it a log or exponential character though I'd be interested in seeing other oddly shaped numbers. A possible name? Calcula with a range of values from microcalcula (watch calc or smaller) to Kilo or maybe megacalcula(Sage! or other beast). Allison

24 years, 3 months

19
48
0 0

Tape dumping programs for Unix/Linux...

by fmc＠reanimators.org

> Here you are talking about a data tape with fields that make up records > where the records are all the same size and the fields being varaible > length inside the record but repeating in all the other records. No, I am talking about a data tape with a physical structure that can be interpreted as a sequence of physical records (each of which has a length) and end-of-file (EOF) marks. The physical records can be blocks of multiple logical records as well. There are also inter-record gaps that separate the physical records and EOFs from each other, and I suppose the information about how long those are may be of interest to someone too, it just hasn't been of interest to me yet and I certainly don't see an obvious way to get that information using common hardware and software. > But a tape like this, from the days when tapes was used as random > access devices is not the format of a system archive tape is it ? Just because tapes were used as random access devices, that doesn't mean they were always used that way or were particularly good for it. And a system archive tape didn't need to be structured for random access. So, take classic MPE :STORE format. I'm thinking that it defaults to having a maximum on-tape block (physical tape record) length of 8192 bytes, but that's overrideable by the user and variable in any case. A single-volume (single-reel) :STORE set has several parts: (a) two files that could actually contain useful bits if this is really a :SYSDUMP tape (each is followed by its own EOF, even if not present); if this isn't a :SYSDUMP tape then there are two consecutive EOFs at the start (b) a :STORE label, which is a single 80-byte tape block followed by an EOF (c) a :STORE directory, which is written as blocks of up to the maximum block length; each block contains a number of 24-byte logical records which give the names of the files to be stored on this volumeset; again, this is followed by an EOF (Note this presents the order in which the files are stored on the volumeset) (d) user files, each of which is written as one 256-byte block containing a copy of the MPE file label followed by more blocks of actual file data, and finished off with an EOF (Note I may be forgetting some things about how user files are written to the tape; in particular I can't remember how user labels are stored; Stan may know more) (e) a :STORE trailer label, which is another 80-byte tape block followed by three EOFs A multi-volume :STORE set makes for some additional complexity. Volumes after the first don't have the two files and EOFs and just start with the :STORE directory, plus once you get to multi-volume you also need to deal with whether a file was split across volumes. OK, maybe I could kinda sorta do this by cat'ing the tape files to disk files and writing some code to kludge around the lost physical-record boundaries. I'm not sure about the user files but I have some ideas to try. But frankly I'd rather have a container file format and tools to collect and preserve the information. Then I can treat the container file like a tape. If I can write some descriptive text in the container file as well, that would be like sticking a label on the tape to me. > If it was me i would spool the whole raw image to disk, and work > with it there ,, it can certainly be massaged into any format you > like after that ... That is what I want too. The problem is, the "raw image" includes information other than the bytestream. If you use bytestream-oriented tools like cat, you lose that other information. -Frank McConnell

24 years, 3 months

1
0
0 0

Hauppauge 4860 mboard question

by cpg＠aladdin.de

Hi, don't know whether this is appropriate for this list, but I'll ask anyway (it's over 10 years old). I've got a machine which has a 4860 motherboard, this a combi 80486/80860 with EISA slots. Overall it works fine, but there is a small problem enabling the cache. The battery is broken, so after turning off it loses it's BIOS and EISA configuration. When this happens I can go into the BIOS and setup everything, *enable the cache*, and boot from ide disk. Problem is since the EISA configuration is still invalid, the SCSI controller does not work. After I setup the EISA configuration with the DOS CF.EXE utility, the SCSI controller works, but the cache is disabled, and I cannot re-enable it in the BIOS menu (menu item is disabled). What can the problem be? Anyone experienced s/th similar? regards, chris

24 years, 3 months

1
0
0 0

Request for Help with the Definicon DSI-32 (NS32032 PC Coprocessor board)

by morgarws＠mh.us.sbphrd.com

I'm looking for any documentation and software for the Definicon DSI-32 (NS32032 PC/XT coprocessor board). ... anything would be useful! Thanks in Advance, Bill Morgart morgarws(a)Molbio.sbphrd.com

24 years, 3 months

4
4
0 0

Tape dumping programs for Unix/Linux..

by csmith＠amdocs.com

> -----Original Message----- > From: Raymond Moyers [mailto:rmoyers@nop.org] > If i might use the 1991 mips 3k sysVr4 unix thats on my old sony > NeWS again as an example, its tar program cant write > or read from a file. its only provided function is to/from > the tape device to the file system,, how absurd ! Absurd? It is for making "tape archives..." :) On the other hand, I'm sure there must be some way to make it work, though, if you wanted an on-disk archive, I'm sure they would have expected you to use ar. ;) Chris Christopher Smith, Perl Developer Amdocs - Champaign, IL /usr/bin/perl -e ' print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n"); '

24 years, 3 months

1
0
0 0

Need IDT 7M624 Info

by Innfogra＠aol.com

In a message dated 5/3/02 2:22:42 AM Pacific Daylight Time, tothwolf(a)concentric.net writes: > http://members.aol.com/innfogra/idt624a1.jpg > > Based on looks alone, I'd guess it is some type of RAM. IIRC, IDT did make > some RAM, but also made quite a few other special purpose chips. > > > http://members.aol.com/innfogra/idt624a2.jpg > > This link didn't work btw. > > Fixed the broken link, thanks Toth. The bottom is the same as the top, 8 more small gold caps. I remember something about them being 1 Meg something or other. That something or other is what I am trying to figure out of course. I wonder if they could be an EEPROM like another smaller chip I have. That one is listed on ebay at the moment as a SEEQ EEPROM. It uses a similar but smaller IDT chip like this as a controller. <A HREF="http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=1728103123">eBay item 1728103123 (Ends May-09-02 12:53:43 PDT ) - Unusual Gold SEEQ 1 Meg E</A> Maybe these are a 1 Meg EEPROM based on 64K cores? Anyone got a book out there? Thanks for the help. Paxton Astoria, OR

24 years, 3 months

3
2
0 0

Mac SE PC Drive Card

by mythtech＠mac.com

>I picked up another Mac SE today, and it's got a "Macintosh SE PC Drive >Card" installed in it, with a big connector on the back of the SE. What is >the card for? Apple made a PC compatible drive that worked with the SE and the Mac II. It needed a special card to connect to the computer (why they couldn't just use the already present Floppy port I have no idea). There was an SE PDS slot card (the one you have), and a NuBus version for the Mac II. They made this for the era before they were shipping the "SuperDrives" that could read/write 1.44 disks, and PC format disks. It ONLY works with the SE or the Mac II. I don't know if it will work with the SE FDHD. If you had the Mac II NuBus card, I would ask you for it, but I already have the SE version. -chris <http://www.mythtech.net>

24 years, 3 months

1
0
0 0

Need IDT 7M624 Info

by Innfogra＠aol.com

I bought 6 of these chips about 8 or 9 years ago, IIRC. However I have exhausted all of my resources to identify them at the moment. I would like to know what they are. The numbers are: IDT 7M624 S45C (Delta symbol) 8738G1 Pretty chip, 8 gold caps mounted on a large purple ceramic substrate. 40 pin wide DIP. 7/8 inch by 2 7/16 inch in size, large like a 68000 but not as long. Pictures at: http://members.aol.com/innfogra/idt624a1.jpg http://members.aol.com/innfogra/idt624a2.jpg Paxton Astoria, OR

24 years, 3 months

3
2
0 0

pdp 11/44 terminating UNIBUS

by huglhuglhugl＠gmx.net

Hi! Now that my pdp11/44 is talking to me (switched from current loop to rs232), i'd like to use it, of course. But i'm missing a unibus-terminator. Does someone have a spare one ? i do have some cards (unibus and qbus) to trade... btw. i live in Belgium / Europe. Or is there a way to make a unibus-terminator, AFAIK they only contain resistors. Did someone do this before, or maybe someone has scematics of a terminator ? regards, lothar. -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux...

by cdl＠proxima.ucsd.edu

> From: Raymond Moyers <rmoyers(a)nop.org> > To: classiccmp(a)classiccmp.org > Subject: Re: Tape dumping programs for Unix/Linux... > Date: Thu, 2 May 2002 21:56:13 -0500 > In-Reply-To: <000501c1f245$6a304ca0$1aefffcc@Shadow> > > You really have me going about the 9 track behavior tho > null portion of tape as record delimiters "crap in the gap" > problems of the past, and other such things. > > So far what ive learned about those things is nothing as > many years around this stuff conditioned me to expect. > > If i spool the whole raw tape using a driver that knows > nothing of any null gaps and simply spool all bytes that > are bytes to a file .... could not i then pull the desired content > out of the spool if i knew the format of the data ? > > If random access is what they are doing, how did they deal > with a rewritten record, pad the unused portion of the record > to overwrite trailing garbage ? or was the bytecount in a rewritten > headder so that the controller knew the valid byte count ? By its physical nature, a magtape is a sequential-access device. One can of course keep track of position on the tape and use it as a "random-access" input device. Standard magtapes as block-replaceable devices were not at all common, and were really sort of a stunt, "see what I can do" phenomenon. > a tape with blank as delimiter/filler and records with no or > painfully terse descriptors seems to me very .... um something. That's the way it is when hardware is not very clever. Back in the olden days. However, the record mark delimiter was more sophisticated than just blank tape. It was actually a pair of characters surrounded by blank tape, a two-character record, that could be detected by analog circuitry. carl

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux...

by cdl＠proxima.ucsd.edu

> From: Raymond Moyers <rmoyers(a)nop.org> > To: classiccmp(a)classiccmp.org > Subject: Re: Tape dumping programs for Unix/Linux... > Date: Thu, 2 May 2002 16:37:30 -0500 > In-Reply-To: <200205021718.g42HI9X7086853(a)daemonweed.reanimators.org> > > On Thursday 02 May 2002 12:18, you wrote: > > > > Whats wrong with cat ? > > > > What's wrong with cat (and dd, and arguably the whole Un*x concept of > > files-as-bytestreams for that matter) is that it loses information. A > > magnetic tape is not an ordered stream of bytes, it is an ordered > > stream of files of records, and each record has a length. > > Here you are talking about a data tape with fields that make up records > where the records are all the same size and the fields being varaible > length inside the record but repeating in all the other records. > > But a tape like this, from the days when tapes was used as random > access devices is not the format of a system archive tape is it ? > > > So you are forced to result to multiple disk files to maintain the file > > structure. > > (which adds to your hassle because now you need to manage collections > > of files instead of a single tape), > > Like with a tarball ? > > > and as you are copying the files to bytestreams you lose the record > > length information. > > Unless you are going to resurrect some old general ledger program > why is this important ? For the same reason it is important to resurrect old computer hardware. I thought that would be obvious to people who read this mailing list. carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

24 years, 3 months

1
0
0 0

dd for err recovery

by rmoyers＠nop.org

cat /dev/floppy > /test1 cat: /dev/floppy: Input/output error -rw-r--r-- 1 root root 18432 May 3 02:09 test1 Bad floppy right ? So time for dd, noerror tells it not to quit sync tells it not to aggregate a short read with the good ones, but to fill the remainder of the short read with zeros so ... dd conv=sync,noerror if=/dev/floppy of=/test2 ( bs=defaults to 512) -rw-r--r-- 1 root root 1474560 May 3 02:18 test2 and we have the whole image of the proper size but including bad sectors filled in with zeros Raymond

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux...

by cdl＠proxima.ucsd.edu

> From: Raymond Moyers <rmoyers(a)nop.org> > To: classiccmp(a)classiccmp.org > Subject: Re: Tape dumping programs for Unix/Linux... > Date: Thu, 2 May 2002 14:08:41 -0500 > In-Reply-To: <20020502200530.E35218(a)MissSophie.unixag-kl.fh-kl.de> > > On Thursday 02 May 2002 13:05, you wrote: > > On 2002.05.02 18:25 Raymond Moyers wrote: > > > Whats wrong with cat ? > > [...] > > > I see most are using dd when cat is all they need > > cat(1) and dd(1) do not read / recognize the _physical_ block size of > > the tape. > > At the portion of the work where you just want to get the stuff > spooled to a file, you dont care about "block size" yet, you > just need to get it pulled off. > > Unix will treat any device as a stream of bytes > > On my old sony, mkboot is broken, you cant use the OS to > create a bootable volume of itself > > so ... you hang the old scsi disk off your linux box and > cat /dev/sdb > /files/sonyhdimage.img > > hang the new scsi disk off your linux box > > cat files/sonyhdimage.img > /dev/sdb > > Put new disk in sony, look mom it boots !! > > Now you redo the disklabel and shove everything > except root up to a new volume above the footprint of the old disk > redo the middle volumes to suit ... move the stuff back down > mount the new space as /usr/local whatever > > Now you have a 1g bootable disk in a machine that cannot create > one for itself... > > Do you see what im getting at here ? hello ? > > and guess what ... i never even bother to involve myself with > any "block sizes" even as the multiple volumes on > that image uses a mix of logical block sizes. Guess what. You aren't dealing with structured magtapes. And it's a very rare disk drive that has a mixture of block sizes. carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux...

by cdl＠proxima.ucsd.edu

> From: Raymond Moyers <rmoyers(a)nop.org> > To: classiccmp(a)classiccmp.org > Subject: Re: Tape dumping programs for Unix/Linux... > Date: Thu, 2 May 2002 11:25:19 -0500 > In-Reply-To: <5.0.0.25.0.20020502090947.02f88e30@pc> > > > > At 02:01 AM 5/2/2002 -0700, Ethan Dicks wrote: > >I can use dd to slurp > >stuff off of tape, but it's tedious. What tools are people using for > >tape archiving under Linux or Solaris? AIX seems to come with "tcopy" > >that essentially pulls everything off the tape until logical or physical > >EOT. I'm looking for something similar - point it at the drive and > >siphon it on down. > > Whats wrong with cat ? > > use the /dev/nst0 device, its the one that dont rewind > ( use mt commands for that kind of stuff ) > > cat /dev/nst0 > file1.tap > cat /dev/nst0 > file2.tap > > and so on You have just thrown away all of the data structure on the tape. No more clues about block lengths, file marks, etc. Some original software is going to need that information to work properly with whatever else is on the tape. carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux...

by cdl＠proxima.ucsd.edu

> Date: Thu, 2 May 2002 06:25:24 -0700 (PDT) > From: Ethan Dicks <erd_6502(a)yahoo.com> > Subject: Re: Tape dumping programs for Unix/Linux... > To: classiccmp(a)classiccmp.org > In-Reply-To: <Pine.LNX.4.44.0205021957030.15892-100000(a)floodland.tved.net.au> > Sender: owner-classiccmp(a)classiccmp.org > Reply-To: classiccmp(a)classiccmp.org > > > --- cvisors(a)carnagevisors.net wrote: > > there is also dump & restore, if the Sparc is running solaris there is > > ufsdump and ufsrestore, and finally if all else fails tar > > these programs should allready be (dump and restore) on the redhat box. > > You misunderstand the direction I'm going. I have magtape with data > already on it. I want to extract that data into a file or set of > files on the disk that I can then burn to CD-R. I can use dd to move > raw records, but I would like to also know what the block size was > for a particular file so I could reconsitute the tape later if > necessary. I'm not so worried about the VMS BACKUP tapes I need to > spin off - I want one saveset per file. If I want to dup any install > tapes (non-VAX), the blocking becomes more critical. > > Essentially, a physical backup that is primarily for data recovery, > but secondarily for later restoration. Yes, that is what "copytape" was written for. Works quite well, especially now that disks are (again) much larger than tapes. The balance keeps shifting back and forth over the decades. carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux...

by cdl＠proxima.ucsd.edu

> Date: Thu, 2 May 2002 05:34:09 -0500 (CDT) > From: Doc <doc(a)mdrconsult.com> > To: classiccmp(a)classiccmp.org > Subject: Re: Tape dumping programs for Unix/Linux... > In-Reply-To: <Pine.LNX.4.44.0205021957030.15892-100000(a)floodland.tved.net.au> > > On Thu, 2 May 2002 cvisors(a)carnagevisors.net wrote: > > > there is also dump & restore, if the Sparc is running solaris there is > > ufsdump and ufsrestore, and finally if all else fails tar > > these programs should allready be (dump and restore) on the redhat box. > > I'd be very interested to know if RedHat dump/restore will fly on > those magtapes. Linux' version only works on ext2 filesystems on the > dump side, but since the tape archive (_IF_ it was generated by unix > dump) isn't exactly a filesystem.... My bet would be a big no go, but > now I'm curious. > BTW, Jochen turned me on to the maketape utility from PUPS a while > back. It works very well. By their nature, dump and restore (or ufsdump and ufsrestore) are operating-system specific. Dump in particular works on the raw disk image and must have intimate knowledge of the way the operating system constructs a file system. On the other hand, I was once successful at restoring a dump tape made on a MicroVax Ultrix system using "restore.old" on a NeXT. I was rather astonished that it worked. carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

24 years, 3 months

1
0
0 0

APPLEVISION Monitor

by acme_ent＠bellsouth.net

> From: Richard Erlacher <edick(a)idcomm.com> > What's always annoyed me with "brand-name" PC's is that the packaging ALWAYS > deviates from the "norm" established by the DIY market. Consquently, your > DELL, Gateway, or Compaq was never upgradable, because the CPU or hard disk > wasn't supported by the BIOS, or some peripheral wouldn't fit in the system > because of address conflicts. Simple things like the on-board video caused > problems when they failed because one couldn't disable them, or, if one did, > the now-broken native video interfered with the replacement. Even printer > ports posed such problems. Many times the packaging itself was the problem. > Have you ever tried to replace or upgrade the CDROM drive in an HP PC? Actually I've found that CD-ROM drives are among the easiest components to replace in HPs. Often the floppy disk drives and power supplies have a weird form factor, and when it comes to motherboards, forget it. I have found HP and Compaq units where, in order to replace the CD-ROM drive (or *any* drive) I had to pull the motherboard, which seems pretty bizarre in itself. Glen 0/0

24 years, 3 months

2
1
0 0

Googling and "egg-sucking" (was Re: "Toy" computers...)

by cdl＠proxima.ucsd.edu

> Date: Wed, 1 May 2002 19:52:05 -0500 (CDT) > From: Doc <doc(a)mdrconsult.com> > To: classiccmp(a)classiccmp.org > Subject: Re: Googling and "egg-sucking" (was Re: "Toy" computers...) > In-Reply-To: <3CD004D7.3282.A8CC01B@localhost> > > On Wed, 1 May 2002, Stan Sieler wrote: > > and, re: > > > Hey, guys. Simplify. A Google search on the phrase "suck eggs" leads > > > to a clear explanation of the historical use of the phrase, dating > > > back to the 16th century in English, and older in other languages. > > > > > > < http://www.quinion.com/words/qa/qa-tea1.htm > > > > > Nice try, but it doesn't address what I think most people are interested > > in learning about (for that phrase, anyway :) ... sucking eggs. > > It address, instead, the concept of teaching people something they > > already know. > > Well, I dunno what most people are interested in learning about, but I > know that referral to "teaching people something they already know" was > the point of my original use of the phrase. I thought people on this list were interested in historical stuff. An investigation into the antiquity of the expression seemed appropriate. On the same Web page one finds a much more antique version of the same idea in Latin, which can be translated as "Don't teach a fish to swim". carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux...

by dquebbeman＠acm.org

> > The emulator community is vigorously using a tape image container > > format known as TAP for precisely this purpose. ... > Darn...sounds like a subset of what I use. I'd be interested > in knowing more about TAP (with an eye towards adopting use of it), > and would suggest some possibly missing features might be: > > - ability to flag if the current tape record had a recovered read > error (obviously, not all hardware/OS's support getting that information) No. And I see no useful purpose in including that in the format. If the read was recovered, you have the data; surely you would *not* want to recreate a tape and make a previously marginal block, marginal again on a clone? > - ability to flag if a particular tape record had a hard error > while reading it No (I can say this even though I'm about to ask): do you mean an unrecoverable error, or one that was corrected by the hardware (as opposed to being corrected by software)? Either way, if the error was corrected, see my response above. > - ability to flag if an End-of-tape marker/indicator was seen > while reading the the current record (again, not all > hardware/OS's support getting that information) No, and again, I can't see how this data would be used to recreate the tape or would be needed by an emulator. It's kind of like asking if a particular hardware emulator also emulates memory parity errors so that you can see memory parity errors in the logs. Why?? > - overall header at start of file, recording information about the tape No, although I did consider suggesting some extensions like this. One problem I have encountered with some old CDC tape formats dealt with how blocking got handled. But my current feeling on this is that if its blocked on taped, then the records will come off the taoe with their proper lengths (I encountered this not trying to read a tape, but trying to create an image of a tape that no longer exists by a desctiption of its contents). Anyway, I encode that kins of descriptive information (what kind of computer, encoding, #tracks, etc) in the filename, or in the name of the directory containing the file, or in a README. > I have a program called "tapedisk", which reads an arbitrary tape > and "copies" it to a single disk file (or set of files, if the size of the > output file exceeds the maximum disk file size). The purpose of > tapedisk is to allow a future exact copy of the tape to be recreated > on another tape (of equal or larger size). (That future copy would be > made with the companion program, disktape.) Additionally, most of > my other tape-reading utilities know how to read a tapedisk format > disk file as though it were a tape. This sounds familiar... is it on the web somewhere? > This is what I store on a per-tape-record basis: ... So you really do want to recreate bad tapes as bad tapes... Why? > This is some what I store as a "header" at the start of the > overall output: ... Yeah, this info is README fodder... why on earth program that? > As you can see...a lot of info, but all necessary to faithfully > reproduce the tape later and/or to understand *why* the file might > (or can't) be used to completely reproduce the tape. Uh, again, can't understand why you'd need to recreate bad tapes. As to the understanding, README.DOC... etc... > This is part of a product we sell on MPE/iX systems, but I'd be happy > to document the structures and/or work with other people on standards > in this area. > > There's room for potential improvement. For example, is it worthwhile > to have a table at the front of the output file that specifies where > the first N EOFs are? You just used that nasty, bad word "standard"... TAP is a convention, not a standard. ;) However, I'm not King of this Kingdom, we're a collective (right out of Monty Python's Search for the Holy Grail). You might try hooking up with the emulator community and ask your questions there. Regards, -doug q

24 years, 3 months

5
5
0 0

Anyone need 2112 RAMs?

by acme_ent＠bellsouth.net

> From: Lawrence LeMay <lemay(a)cs.umn.edu> > I could use some 2114's and C2109-4's. These are used in Teraks for Video > memory and System memory. Just in case anyone knows of a source ;) Jameco sells the 2114N for $1.49. Glen 0/0

24 years, 3 months

1
0
0 0

MP/M was CP/M-86

by acme_ent＠bellsouth.net

> From: Freek Heite <f.heite(a)hccnet.nl> > On what kind of hardware is this MPM (86?) running? Newbies that want to > experiment with MPM, would most likely want an implementation of MPM for > the IBM PC hardware - but is that available somewhere? The downloads that > were mentioned a week ago (mpm8621i.zip etc.) are for some compupro hardware. Actually, I'd like to get MP/M for my Zenith Z-100s. Anybody know if this is available?? Glen 0/0

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux...

by dquebbeman＠acm.org

> At 04:10 PM 5/2/2002 -0400, Douglas H. Quebbeman wrote: > >No. And I see no useful purpose in including that in the format. > >If the read was recovered, you have the data; surely you would > >*not* want to recreate a tape and make a previously marginal > >block, marginal again on a clone? > > Choosing between the loss of all the data, and a partial > copy, I'll take the partial copy. > > I have many 8-inch disks with bad blocks. I'd like to preserve > the data if at all possible. A simplistic 'dd'-style read > won't preserve everything; it'll bail out when it has a problem. ??? I just did a 'dd' of a bad QIC-80 tape; it read the entire tape as a single file, and didn't bail out. I've not done that with magtape, but ISTR someone else here saying that 'dd' does raw reads, bad blocks and all... My bad if not true. -dq

24 years, 3 months

3
3
0 0

Tape dumping programs for Unix/Linux..

by dquebbeman＠acm.org

> However, if I notice recovered-reads (or hard errors) on old 9-track > tapes, I often see fewer recovered reads (or hard errors) if I try > the tape one more time. I assume that going over the heads once > may have knocked off a bit of dust/dirt/something that affected > the tape the first time. Note that I don't discard the > results of the first run until the second run finishes... hey! Me too! > I've had one tape break during a second run :) Ouch! Acetate backing? > > > Go buy a 9-track drive and hang it on your *nix box. > > > Let me send you a 9-track tape. You read it any way > > > you want. You send me the tape back. > > > > > Then you go get a second tape, and put the data back on > > > any way you want. Then send it to me, and I'll tell you > > > if your technique works or not. > > BTW, the only way you can be *SURE* you got all the data on > the tape is if *EVERY* read-request returned fewer characters > than you asked for. E.g., if you did: > bytesread = read(fromfd, buffer, BUFSIZE); > and you get BUFSIZE bytes in, then there's a chance that that > tape record had BUFSIZE + 100 bytes ... and you've just lost > those last 100 bytes. I *just* recently discovered this, and will incorporate that into a utility I'll be hosting on the Prime. -dq

24 years, 3 months

3
2
0 0

S/36 OS?

by xds_sigma7＠hotmail.com

SSP... Why, do you need a copy or something? I have it on 8" floppies... SSP stands for System Support Program, FYI. Will J _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com

24 years, 3 months

1
0
0 0

New Finds for the Museum

by jrkeys＠concentric.net

This week has been a little slow and have to watch the cashflow. 1. 30 plus cartridges for the Intellivision (free) 2. hp 82901M Flexible Disc Drive excellent shape ($1.99) 3. IBM 3.5 FD external type 4865 ($1.99) 4. PowerBook 150 with adapter and case (Targus) ($20) 5. NCD ExploraPro x-terminal ($1) 6. Sun SPARCStation IPC ($1) 7. Two AppleCD 600e ($1ea) 8. Four AppleCD 300 ($1ea) 9. MicroScribe model 450/2013 ($1) 10.WYSE model WY-150-03-01 ($6) 11. TOMY robot ($1) 12. digital VT420-C2 (free) 13. AMT FormsWriter-242 (free) 14. AMIGA 500 (free) 15. digital VT240 model VS240-B ($8) That's it for this week the balance is too new to post.

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux..

by dquebbeman＠acm.org

> Fair enough, but remember my post was about cat vs dd, and > was not dealing with all these other issues being tossed > up, it was to point out that what he was doing would be easier > with a simpler tool > > It certainly didnt apply to preserving the information > needed to rewrite a new 9 track tape. > > I think your being a bit rough on me here, your givin me > a GI bath for things that was outside of the scope of my > focus. Ok, and fair enough... several of us detected that you might not quite grasp the scope of the issue, yet your dogged assertiveness was sending a different message. I apologize for any part of my remarks that came off like an attack. Regards, -doug q

24 years, 3 months

2
1
0 0

Tektronix 4052A GPIB Programming Guide Item # 1727379522

by rigdonj＠cfl.rr.com

<http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=1727379522>

24 years, 3 months

1
0
0 0

Tektronix 4050 Series Basic Reference Guide HURRY!

by rigdonj＠cfl.rr.com

<http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=1726561113> It closes in 54 minutes!

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux...

by Lee.Davison＠merlincommunications.com

Engineers are great- they're like laser beams. They are intense and highly focusable. .. and they bounce around the room until you don't know which direction they're comming from. Lee. ---------------------------------------------------------------------------- ---- This email is intended only for the above named addressee(s). The information contained in this email may contain information which is confidential. The views expressed in this email are personal to the sender and do not in any way reflect the views of the company. If you have received this email and you are not a named addressee please delete it from your system and contact Merlin Communications International IT Department on +44 20 7344 5888. ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux...

by dquebbeman＠acm.org

> Keep in mind one thing: engineers who spend their lives working on tape > hardware thought it was important enough to be able to signal recovered > errors ... for a reason. Engineers are great- they're like laser beams. They are intense and highly focusable. But they don't illuminate a wide area when focused. OTOH, take the lowly, dim incandescent lightbulb. Not intense. Not very focused. But it lights up the whole room. Ok, now that everyone's got me pegged as the dim bulb in this group... (didn't think I was going to leave that one for someone else, did you?), let me finish my thought... Anyway, my point is that sometimes engineers are so focused that they don't see the big picture. But I'm not disagreeing about the need to know about read errors (or write errors for that reason). Regards, -dq

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux...

by dquebbeman＠acm.org

Stan sayeth: > > No. And I see no useful purpose in including that in the format. > > If the read was recovered, you have the data; surely you would > > *not* want to recreate a tape and make a previously marginal > > block, marginal again on a clone? > > > NOOOO! It's *IMPORTANT* to know if there was a question about the > accuracy of the data! That's *WHY* some tape drives even *tell* > you there was a recovered error ... so the user could use that > information! I do that during the first dozen-or-so reads of the tape... > It's like getting a recovered parity error on memory. > Should you know about it? DAMN STRAIGHT YOU SHOULD! heh... for years, any IBM compatible PC would, on detection of a parity error, deliberately crash. Doesn't matter why, I just lots my stuff... > Without recording that information, you also can't answer > important questions like: is the orginal tape in good shape? Sure, *make note of it*, but I don't necessarily view the image file as the only correct place to put that info. But it's not a bad idea, just a bit Brobdignagian... If I was Tim Shoppa and was doing analog reads of tapes so far gone that you've got only one try to get it right, sure. But like I said before, traditional methods shouldn't be used on these tapes. > > > - ability to flag if a particular tape record had a hard error > > > while reading it > > > > No (I can say this even though I'm about to ask): do you mean an > > unrecoverable error, or one that was corrected by the hardware > > (as opposed to being corrected by software)? Either way, if the > > error was corrected, see my response above. > > If it was corrected, then there was no error (other than a > recovered read, already correct recorded via the earlier bit :) > > I meant a real, live, actual error. (E.g., missing oxide) > > When recording the contents of a tape it's **IMPORTANT** to know > that there was an error there. If you simply skip the erorr and > keep reading, you've lost data. > Did you lose original user data? Possibly, and you've definitely > lost data about the tape (i.e., the fact there was an error). > > By recording the fact an error occurred, along with any data > your tape drive/OS *may* have sent you, you preserve the ability > to act wisely in the future. For example, by recording the > fact there was an error at megabyte 100 in a 102 MB file, > the user would have confidence that when that file is eventually > extracted, the first 99 MB of it is in fine shape. Y'all must encounter a lot more marginal tapes than I do. The ones I can't read have gone all the way down to where they will require an analog read. If I can read it digital at all, I'll reread the dang tape until I get ever record error-free. The wet read is most useful in this application. > > > - ability to flag if an End-of-tape marker/indicator was seen > > > while reading the the current record (again, not all > > > hardware/OS's support getting that information) > > > > No, and again, I can't see how this data would be used to recreate > > the tape or would be needed by an emulator. It's kind of like asking > > if a particular hardware emulator also emulates memory parity errors > > so that you can see memory parity errors in the logs. Why?? > > With 9-track tapes, software writing to the tapes generally watches > for an indication that the end-of-tape marker (a short silver > reflective strip) has been seen. At that time, it can prepare > to do a reel-switch. Although some people feel they can backspace > and write reel-switch info prior to the EOT marker on a 9-track > tape, that's technically not safe (and opens up the possibility > of getting what's called (in 1979) "crap in the gap"). Anyway, > the ANSI (?) standard for 9 track tapes specifies a minimum length > of tape be available for writing after the EOT marker ... a length > that should be sufficient (even with modest multiple outstanding > write-ahead requests) to write the reel switch information. I think you're missing my point- I don't believe there are any 9-track drives that split physical records across reels of tape. If I'm wrong, please correct me. > On at least one OS, Burroughs MCP, one could detect that EOT at > read time. Then, if one is doing multiple read-ahead requests, > one can moderate them appropriately. Yes, yes, yes, of course the EOT is detected while reading. But it happens *between* records, not *inside* them. > Ok...the short answer: it's information. You don't throw away > information without a darn good reason. :) Hey, if physical records *can* be split bwteen reels, then you are absolutely right. > > > - overall header at start of file, recording information about the tape > > > > No, although I did consider suggesting some extensions like this. > > One problem I have encountered with some old CDC tape formats > > Sorry...if you want a professional program, not something like > that toy cptape, you *WILL* have this information. > > Been there, worked on that, for over 30 years. Trust me...you > *want* all the information you can get. Actually, all I want is that the system software and applications can use the data from the tape without detecting its coming from some place other than a physical tape. So far that goal has not required the extreme mesaures discussed here. > > Anyway, I encode that kins of descriptive information (what kind > > of computer, encoding, #tracks, etc) in the filename, or in the > > name of the directory containing the file, or in a README. > > If two items of data are separated, what happens to them? > Yep. Should be 'nuff said :) Well, Raymond and I agree that tarballs work well for this, as well as other such methods of encapsulation. > > > I have a program called "tapedisk", which reads an arbitrary tape > > > > This sounds familiar... is it on the web somewhere? > > The MPE V version was/is (can't recall which), and was free. > The MPE/iX version is a product from our company. I was thinking of some Linux thing... I've only a few hours of HP3000 experience. Looked like a nice extension of the 2000 Access system, at first... > > So you really do want to recreate bad tapes as bad tapes... > > > > Why? > > No...I want to know that a problem existed, and where that > problem was. > > Again...this is basic, vital, and indisputable. You *NEED* to > know if there was a problem with the tape, and if you're trying to > extract a particular file you need to know where any problems > are in that file. Otherwise, you'll be lying to the user. > > If you know where within a file an error was found, then you've > got a chance at recovering most of the rest of the data successfully. > If you know an error occurred *somewhere* in a file, but not > where, then you have a large pile of bits which *might* be trash, > and *might* be useful ... but neither you or the user knows. > And, if you don't know where the errors were (and how many there > were), you can't reliably restore the data. That data might > be banking information that your company is being audited on; > it might be data that could clear someone of a crime...you simply > don't know. > > Data is important...that's why we call it data and not junk :) We're not disagreeing about this, we just have a different time-and-place attitude about it. > > This is some what I store as a "header" at the start of the > > > overall output: > > > > ... > > > > Yeah, this info is README fodder... why on earth program that? > > Uh, 'cuz someone had to do it and build a reliable, thorough > program? I'm not arguing that it's of no value, but I'm looking at cost of effort expended vs. return on investment. I used to always believe in building for the worst-case, but these days it's rarely feasible. The people writing the checks don't want to pay for features they don't think they'll use. > > > As you can see...a lot of info, but all necessary to faithfully > > > reproduce the tape later and/or to understand *why* the file might > > > (or can't) be used to completely reproduce the tape. > > > > Uh, again, can't understand why you'd need to recreate bad tapes. > > Again...you're *NOT RECREATING BAD TAPES*. I understand. Recreating tapes from images is not a criterium. > > You might try hooking up with the emulator community and > > ask your questions there. > > This being ClassicCmp, I thought they might be here, too :) One or two of us, at least! > Besides, this isn't an emulator question so much as a data > preservation question. Related issues, to be sure, but not necessarily identical ones. I don't think we're really disagreeing here; you circle the block to the left, I circle to the right. We both make it to where we want to go. Regards, -dq

24 years, 3 months

1
0
0 0

Mainframe emulation and serial comms (was Re: "Toy computers)

by dquebbeman＠acm.org

> > There are/were apparently a number of Apple LocalTalk cards made > > for PC usage. One of them is the PC MacBridge by Tangent Technologies - > > now defunct - which is a short 8-bit card based on the Zilog Z8530APC > > chip. A google search will disclose multiple others also. > > I have a native Apple LocalTalk ISA card manufactured by Apple. It does an > excellent job and the PC communicates seamlessly with the Macs in the > apartment. Since the thrust of this topic is find a board that can be used to do IBM BISYNC communication, would you happen to know what chipset is used by the board? It would be hard to use it if no one knows how to write software for it... -dq

24 years, 3 months

4
3
0 0

Tape dumping programs for Unix/Linux...

by fmc＠reanimators.org

"Douglas H. Quebbeman" <dquebbeman(a)acm.org> wrote (after Stan): > > - ability to flag if a particular tape record had a hard error > > while reading it > > No (I can say this even though I'm about to ask): do you mean an > unrecoverable error, or one that was corrected by the hardware > (as opposed to being corrected by software)? Either way, if the > error was corrected, see my response above. This is useful -- if you are working with an only copy of a tape and it is marginal, this lets you record in the recovered image just which bits could not be reliably read. I'm not sure if "recovered read error" has such uses. Stan? Enlighten us? > > - ability to flag if an End-of-tape marker/indicator was seen > > while reading the the current record (again, not all > > hardware/OS's support getting that information) > > No, and again, I can't see how this data would be used to recreate > the tape or would be needed by an emulator. It's kind of like asking > if a particular hardware emulator also emulates memory parity errors > so that you can see memory parity errors in the logs. Why?? I can see some use for this if you want to use the recovered image file with an emulator -- you can provide the physical-EOT indication to the emulator. What's it good for? I don't know, but I wouldn't be surprised if there is some software that relies on seeing the physical-EOT mark while reading. > Anyway, I encode that kins of descriptive information (what kind > of computer, encoding, #tracks, etc) in the filename, or in the > name of the directory containing the file, or in a README. There is something to be said for keeping all the related bits together in a single container, it keeps them from getting separated. > However, I'm not King of this Kingdom, we're a collective > (right out of Monty Python's Search for the Holy Grail). > You might try hooking up with the emulator community and > ask your questions there. Where does one go to find "the emulator community"? I don't think there is one, I think there are several, just like there are at least two "TAP formats", both having to do with container files for tapes, only one is for proper serial magnetic media like I think we are discussing, and the other is for audio data cassettes on some 1980s bitty box (a Sinclair Spectrum I think). Are they going to care? Should they, so long as there's a reasonable way to down-convert a fancier tape container file format to their flavor of TAP format? -Frank McConnell

24 years, 3 months

2
1
0 0

Tape dumping programs for Unix/Linux...

by dquebbeman＠acm.org

> > > - ability to flag if an End-of-tape marker/indicator was seen > > > while reading the the current record (again, not all > > > hardware/OS's support getting that information) > > > > No, and again, I can't see how this data would be used to recreate > > the tape or would be needed by an emulator. It's kind of like asking > > if a particular hardware emulator also emulates memory parity errors > > so that you can see memory parity errors in the logs. Why?? > > I can see some use for this if you want to use the recovered > image file with an emulator -- you can provide the physical-EOT > indication to the emulator. What's it good for? I don't know, but > I wouldn't be surprised if there is some software that relies on > seeing the physical-EOT mark while reading. In my emulator, when I reach the end-of-file on the tape image file while reading it, the tape drive emulation returns the status code for physical EOT. > > Anyway, I encode that kins of descriptive information (what kind > > of computer, encoding, #tracks, etc) in the filename, or in the > > name of the directory containing the file, or in a README. > > There is something to be said for keeping all the related bits > together in a single container, it keeps them from getting separated. Absolutely- that's why I ZIP or TAR and GZIP the directory containing the image file(s) and a README. > > However, I'm not King of this Kingdom, we're a collective > > (right out of Monty Python's Search for the Holy Grail). > > You might try hooking up with the emulator community and > > ask your questions there. > > Where does one go to find "the emulator community"? Well, each emulator has its own community, but many of the players live in more than one, so that makes it more of a "meta-community". There is a mailing list for the SIMH people. I run a mailing list for the Cyber Reimplementor's Guild. I believe there is one for the Hercules crowd. It would be nice if comp.sys.emulators could provide the synergy to bring us all together. But it's saturated with game system emulator talk, which draws too much attention >from TLAs. Like I also wish the vintage computer department would not list toys, but I digress. > I don't think there is one, I think there are several, just like there > are at least two "TAP formats", both having to do with container files > for tapes, only one is for proper serial magnetic media like I think > we are discussing, and the other is for audio data cassettes on some > 1980s bitty box (a Sinclair Spectrum I think). Darn I really should read all the way before replying... Actually, yes, I noticed that someone is using a format for casette tapes, and also called it TAP. How tragic, they should not be confused with each other... > Are they going to care? Should they, so long as there's a reasonable > way to down-convert a fancier tape container file format to their > flavor of TAP format? Well, having a common format makes it easier to exchange stuff. -dq

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux..

by dquebbeman＠acm.org

> At the portion of the work where you just want to get the stuff > spooled to a file, you dont care about "block size" yet, you > just need to get it pulled off. > > Unix will treat any device as a stream of bytes And therein lies the problem. ... > Do you see what im getting at here ? hello ? No, I don't, because your entire example was disk-centric, which simply doesn't apply to tapes. Tell you what... how about an empirical test? Go buy a 9-track drive and hang it on your *nix box. Let me send you a 9-track tape. You read it any way you want. You send me the tape back. Then you go get a second tape, and put the data back on any way you want. Then send it to me, and I'll tell you if your technique works or not. You game? -dq

24 years, 3 months

4
3
0 0

Tape dumping programs for Unix/Linux...

by dquebbeman＠acm.org

> > No (I can say this even though I'm about to ask): do you mean an > > unrecoverable error, or one that was corrected by the hardware > > (as opposed to being corrected by software)? Either way, if the > > error was corrected, see my response above. > > This is useful -- if you are working with an only copy of a tape > and it is marginal, this lets you record in the recovered image > just which bits could not be reliably read. I did mean to add that I saw *some* value in this... -dq

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux..

by dquebbeman＠acm.org

> On Thursday 02 May 2002 14:51, you wrote: > > > At the portion of the work where you just want to get the stuff > > > spooled to a file, you dont care about "block size" yet, you > > > just need to get it pulled off. > > > > > > Unix will treat any device as a stream of bytes > > > > And therein lies the problem. > > You would rather work the drive to death ? When I break it, I fix it. I'm good at things like that. > You know, any really old tape you are attempting to recover > you really do not want to be running it thru the tape deck > very much For tapes that far gone, a digital read won't work. You have to build your own drive and sample the analog data coming off the heads using A/D and not using the digital-based discriminator. For tapes not that far gone (like the ones of mine that spent days under water and then months with stachybactris growing on them), I have a wet-read technique that prevents most shoe- shining. > disks are huge these days, and the content is best messaged > on a new disk rather than an old tape. Agreed, *that's why the TAP format exists*, as well as Stan Seiler's tapedisk/disktape system. > > > Do you see what im getting at here ? hello ? > > > > No, I don't, because your entire example was disk-centric, > > Wrong i used it as an example, the raw stream already fit > its intended destination in the hard drive case. If the structure of what is on a tape depending only on the bits written to tape you would be right. BUT IT DOESN'T!!! Record marks on a tape are lengths of tape where NO BITS ARE RECORDED. Your technique gets the bits, but misses the are-not-bits. > > Tell you what... how about an empirical test? > > Well since we already know the behavior, we already know > the results dont we ? Dictionary Definition of "Empirical" 1.a. Relying on or derived from observation or experiment. b. Verifiable or provable by means of observation or experiment. Verification. Proof. Why not put your money where your mouth is? > > Go buy a 9-track drive and hang it on your *nix box. > > Let me send you a 9-track tape. You read it any way > > you want. You send me the tape back. > > > Then you go get a second tape, and put the data back on > > any way you want. Then send it to me, and I'll tell you > > if your technique works or not. > > this is very predicatble if you know the raw behavior > of the devices isnt it > > the whole idea was to point out some of this raw behavior Crambe repitita. -dq

24 years, 3 months

2
1
0 0

Tape dumping programs for Unix/Linux...

by fmc＠reanimators.org

Raymond Moyers <rmoyers(a)nop.org> wrote: > > At 02:01 AM 5/2/2002 -0700, Ethan Dicks wrote: > >I can use dd to slurp > >stuff off of tape, but it's tedious. What tools are people using for > >tape archiving under Linux or Solaris? AIX seems to come with "tcopy" > >that essentially pulls everything off the tape until logical or physical > >EOT. I'm looking for something similar - point it at the drive and > >siphon it on down. > > Whats wrong with cat ? What's wrong with cat (and dd, and arguably the whole Un*x concept of files-as-bytestreams for that matter) is that it loses information. A magnetic tape is not an ordered stream of bytes, it is an ordered stream of files of records, and each record has a length. So you are forced to result to multiple disk files to maintain the file structure (which adds to your hassle because now you need to manage collections of files instead of a single tape), and as you are copying the files to bytestreams you lose the record length information. This may come across as a flame of Un*x, and maybe it is, but really my point is that the Un*x model of files as bytestreams is not an appropriate model for magnetic tapes. -Frank McConnell

24 years, 3 months

2
1
0 0

APPLEVISION Monitor

by mythtech＠mac.com

>> Because people WANT a Mac. How does BMW get away with charging a price >> premium when they only have a 5% market share. People will pay the price >> because they want the item. >> >I wouldn't go there ... BMW's are infamous "hangar queens." Having worked in >more than one group with several BMW owners, I've often driven people to the >shop in my Maxima. One time I noted that every BMW needed a day in the shop >every week. While I'm sure that was the exception rather than the rule, I'm >sure I'll never covet one of the things. Yes, but you are just re-inforcing my point. Sure YOU might never want one... but despite the fact that they may be built like crap (I can't say personally, but your experience seems to imply they might be), people will STILL buy them. BMW is no where near worried they will go out of business due to lack of sales. People will buy them, and they will pay the higher price for them, and they will take all the good and bad that comes with them, and do it with a smile... because they WANT one. If BMW doesn't suit your fancy as an example, replace it with any small market share high priced vehicle. Like maybe the Lotus, or Lambrogini, or Ferrari.... or for more mainstream, the Jaguar. People aren't buying these cars because they need them, they are buying them because they WANT them. That is what is going on in the Mac world for most of Apple's sales. They are sold for no other reason than people want one. It might be because they prefer the Mac, it might be because they think they look cool, it might be because they hate MS... for most of the sales... it is simply bought out of desire, NOT out of neccessity. Once you have an audience that buys from desire, you can safely raise your prices to the highest point that audience will bear. And for the most part... this is perfectly fine with Jobs... he isn't interested in ruling the PC world, he is interested in making stuff people desire. He WANTS to be the BMW or Jaguar of the computer world. MS, Dell, Gateway, et al can be the Ford or Chevy, let them deal with having the bulk of the sales churning out the same old tired but reliable designs at cut throat prices. -chris <http://www.mythtech.net>

24 years, 3 months

4
3
0 0

Info for IMS hardware needed

by csmith＠amdocs.com

> -----Original Message----- > From: Fritz_Chwolka(a)t-online.de [mailto:Fritz_Chwolka@t-online.de] > There is someone searching for infos about IMS - hardware. > Can you help ? > Answer only to: They must really be serious about getting help with this. ;) I count three emails about it so far -- or was that four? Chris Christopher Smith, Perl Developer Amdocs - Champaign, IL /usr/bin/perl -e ' print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n"); '

24 years, 3 months

4
3
0 0

Tape dumping programs for Unix/Linux...

by dquebbeman＠acm.org

> You misunderstand the direction I'm going. I have magtape with data > already on it. I want to extract that data into a file or set of > files on the disk that I can then burn to CD-R. I can use dd to move > raw records, but I would like to also know what the block size was > for a particular file so I could reconsitute the tape later if > necessary. I'm not so worried about the VMS BACKUP tapes I need to > spin off - I want one saveset per file. If I want to dup any install > tapes (non-VAX), the blocking becomes more critical. The emulator community is vigorously using a tape image container format known as TAP for precisely this purpose. Each record from tape is written to file prefixed *and* suffixed by a four-byte record length in little-endian format. A zero- length record is represented by a 4-byte value of zero; although intuition might call for 8-bytes (a prefix & suffix with nothing in between), this is not the case. The convention appears to come directly from FORTRAN 77's handling of unformatted sequential files. And EOF is represented by two consecutive zero-length records. I've got code samples I can throw at you in C, Modula-2, and F77. Regards, -dq

24 years, 3 months

3
2
0 0

Hagerstown Maryland Hamfest

by wh.sudbrink＠verizon.net

Is anyone on the list going to this hamfest? Has anyone gone before? Is it worth a 90 minute (each way) drive? The web page for it fails to mention what time it starts or what it costs to get in. Thanks.

24 years, 3 months

1
0
0 0

PowerMac 7200/75 and "Open Firmware"

by DAW＠yalepress3.unipress.yale.edu

> From: Chris > > >- Which makes me think, and yes my question here it OT, so reply > >directly... My OS X G4 has a modem port, but no other external serial > >ports... (those bastards at Apple! :) Is there a way to hook up my VT420 > to > >it, so I can log into Darwin? Maybe using an external modem hanging off > of > >the VT420? > > Get that Griffin G-Port if you aren't using the modem. It replaces the > modem card and gives you a standard Mac RS-422 serial/localtalk port. I > think they are about $40. > > Otherwise, what about a USB to Serial adaptor? > > -chris > The G-Port is a neat idea, but since I'm poor at the moment, and have an external modem already, that's why I was thinking along that route... -- --- David A Woyciesjes --- C & IS Support Specialist --- Yale University Press --- mailto:david.woyciesjes@yale.edu --- (203) 432-0953 --- ICQ # - 905818 Mac OS X 10.1 - Darwin Kernel Version 5 Running since 01/22/2002 without a crash

24 years, 3 months

1
0
0 0

PowerMac 7200/75 and "Open Firmware"

by mythtech＠mac.com

>> >I have tried to hit command-pretzel-o-f at bootup >> >> Control-Command-O-F (the pretzel/cloverleaf/open apple is the command >> key). I'm glancing at that link for info of 7200 to Linux... and it mentions the keys to hold are Command-Option-O-F... not Control-Command-O-F. I do however assume that you were already holding the correct keys, since you said the screen blanked when you did it... but I figured it bears pointing out just in case. -chris <http://www.mythtech.net>

24 years, 3 months

1
0
0 0

PowerMac 7200/75 and "Open Firmware"

by mythtech＠mac.com

>> didn't think they started that until PPC's... but I'm not really sure > >PPCs? If you mean PowerPC, I'm sure it's got a PowerPC core ;) But I >assume you mean something else. Yeah, I dropped the word "later" ("until later PPC's")... caused by over editing what I wrote first, which was something along the lines of "I didn't think they started doing OF until the later model 603e/604's that came out around the time of the first G3s, in the era of motorola clones". And when I diced that down to simplify my statement, I diced a little too much. Sorry about that. -chris <http://www.mythtech.net>

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux..."

by dquebbeman＠acm.org

> > And EOF is represented by two consecutive zero-length records. > > Thanks, I've been curious about this spec for a while and had little > luck turning up a concise description of the format. > > One question, if I want to write multiple consecutive EOFs (I'm > thinking of classic HP3000 MPE :STORE format tapes here) do I write > two zero-length records for each, or do I "compress out" the > zero-length records in the middle? Say I want to write two EOFs, > do I write {0,0,0,0}, {0,0,0,0}, {0,0,0,0}, {0,0,0,0} or > {0,0,0,0}, {0,0,0,0}, {0,0,0,0}? I'm hoping it's the former. My first attempt at understanding the format was wrong (see my comment re intuition). I would side with you on it being the former, but that's my intuition speaking to me... ;)

24 years, 3 months

1
0
0 0

PowerMac 7200/75 and "Open Firmware"

by mythtech＠mac.com

> According to this link, it states that OF on the 7200 doesn't >drive the display and that a serial cable must be constructed to >access it by terminal. It doesn't give specifics on the connection >though. > > http://homepages.ihug.com.au/~aturner/7200boot.html > > There are also other links there that may be useful. It >looks like OF on the 7200 has quite a few bugs. Hum... I happen to have a 7200 logic board sitting here on my desk. I think the power supply is under my desk... maybe I'll hook them up and see what I can get into. -chris <http://www.mythtech.net>

24 years, 3 months

1
0
0 0

PowerMac 7200/75 and "Open Firmware"

by mythtech＠mac.com

>- Which makes me think, and yes my question here it OT, so reply >directly... My OS X G4 has a modem port, but no other external serial >ports... (those bastards at Apple! :) Is there a way to hook up my VT420 to >it, so I can log into Darwin? Maybe using an external modem hanging off of >the VT420? Get that Griffin G-Port if you aren't using the modem. It replaces the modem card and gives you a standard Mac RS-422 serial/localtalk port. I think they are about $40. Otherwise, what about a USB to Serial adaptor? -chris <http://www.mythtech.net>

24 years, 3 months

1
0
0 0

PowerMac 7200/75 and "Open Firmware"

by csmith＠amdocs.com

> -----Original Message----- > From: Jeff Hellige [mailto:jhellige@earthlink.net] > According to this link, it states that OF on the 7200 doesn't > drive the display and that a serial cable must be constructed to > access it by terminal. It doesn't give specifics on the connection > though. I have such a cable. As I said, it hooks a terminal into a SPARC, with the same kind of port, perfectly well. For some reason I still can't get OF to talk to me on the terminal (either with or without a null-modem). Chris Christopher Smith, Perl Developer Amdocs - Champaign, IL /usr/bin/perl -e ' print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n"); '

24 years, 3 months

1
0
0 0

PowerMac 7200/75 and "Open Firmware"

by csmith＠amdocs.com

> -----Original Message----- > From: Chris [mailto:mythtech@mac.com] > I assume you researched it already, so I won't get into > asking if you are > sure the 7200 will go into open-firmware. I thought it predated OF. I I'm not sure, but most of the places I've checked seem to think it has it. > didn't think they started that until PPC's... but I'm not really sure PPCs? If you mean PowerPC, I'm sure it's got a PowerPC core ;) But I assume you mean something else. > (and seeing as the 7200 is PCI, it is a good candiate to be > an early unit > with OF). I've read that it was the first. With a version of 1.0.5 or something like that. I also have a PDF from apple (specifically regarding the 7200 series) which says this: The system software for the Power Macintosh 7200 computer includes the following new features: large partition support Drive Setup transport-independent networking (Open Transport) Open Firmware startup enhanced power management software > >I have tried to hit command-pretzel-o-f at bootup > > Control-Command-O-F (the pretzel/cloverleaf/open apple is the command > key). .../splat. Chris Christopher Smith, Perl Developer Amdocs - Champaign, IL /usr/bin/perl -e ' print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n"); '

24 years, 3 months

1
0
0 0

PowerMac 7200/75 and "Open Firmware"

by csmith＠amdocs.com

> -----Original Message----- > From: David Woyciesjes [mailto:DAW@yalepress3.unipress.yale.edu] > - Have you tried setting the terminal at 9600/8/n/1? That seems to > work for about everything, assuming someone hasn't changed the default > settings... Yes. Chris Christopher Smith, Perl Developer Amdocs - Champaign, IL /usr/bin/perl -e ' print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n"); '

24 years, 3 months

1
0
0 0

Tape dumping programs for Unix/Linux...

by fmc＠reanimators.org

"Douglas H. Quebbeman" <dquebbeman(a)acm.org> wrote: > The emulator community is vigorously using a tape image container > format known as TAP for precisely this purpose. > > Each record from tape is written to file prefixed *and* suffixed > by a four-byte record length in little-endian format. A zero- > length record is represented by a 4-byte value of zero; although > intuition might call for 8-bytes (a prefix & suffix with nothing > in between), this is not the case. The convention appears to come > directly from FORTRAN 77's handling of unformatted sequential files. > > And EOF is represented by two consecutive zero-length records. Thanks, I've been curious about this spec for a while and had little luck turning up a concise description of the format. One question, if I want to write multiple consecutive EOFs (I'm thinking of classic HP3000 MPE :STORE format tapes here) do I write two zero-length records for each, or do I "compress out" the zero-length records in the middle? Say I want to write two EOFs, do I write {0,0,0,0}, {0,0,0,0}, {0,0,0,0}, {0,0,0,0} or {0,0,0,0}, {0,0,0,0}, {0,0,0,0}? I'm hoping it's the former. -Frank McConnell

24 years, 3 months

1
0
0 0

PowerMac 7200/75 and "Open Firmware"

by DAW＠yalepress3.unipress.yale.edu

> From: Chris > > >I have tried to hit command-pretzel-o-f at bootup > > Control-Command-O-F (the pretzel/cloverleaf/open apple is the command > key). > > -chris > Actually, that's probably a tongue-in-cheek reference to the shape of your hands, when you try to hit those key combinations when starting up the Mac... -- --- David A Woyciesjes --- C & IS Support Specialist --- Yale University Press --- mailto:david.woyciesjes@yale.edu --- (203) 432-0953 --- ICQ # - 905818 Mac OS X 10.1 - Darwin Kernel Version 5 Running since 01/22/2002 without a crash

24 years, 3 months

1
0
0 0

PowerMac 7200/75 and "Open Firmware"

by mythtech＠mac.com

>Now, first, let me ask: Might the control panel not function properly >if it's not in the "control panels" folder? I've just got it setting >around on the drive, but it _seems_ to work. Not that I can actually >see the "open firmware" stuff to make sure it's actually doing anything. If the control panel loads anything at startup (which I would guess it might), then no, it will NOT work under OS 8 unless it is in the control panels folder (and you have rebooted). But not all control panels load anything, many just change settings read from someplace. Those kinds need not be anywhere in particular. (but since you are having problems... toss it in the CP folder anyway) I assume you researched it already, so I won't get into asking if you are sure the 7200 will go into open-firmware. I thought it predated OF. I didn't think they started that until PPC's... but I'm not really sure (and seeing as the 7200 is PCI, it is a good candiate to be an early unit with OF). >I have tried to hit command-pretzel-o-f at bootup Control-Command-O-F (the pretzel/cloverleaf/open apple is the command key). -chris <http://www.mythtech.net>

24 years, 3 months

2
1
0 0

PowerMac 7200/75 and "Open Firmware"

by DAW＠yalepress3.unipress.yale.edu

> From: Christopher Smith > --.. > I've been trying really hard to get the thing to give me an > "open firmware" prompt, but have had no success. > > Right now I have a "converted" vga monitor plugged in, a Mac ADB > keyboard/mouse, and an IBM terminal connected to the "modem" port, > set to 38400bps, 8 data, 1 stop bit, no parity. The cable has > been used recently on a SPARC, so I'm pretty sure it's good. > - Have you tried setting the terminal at 9600/8/n/1? That seems to work for about everything, assuming someone hasn't changed the default settings... > ..... > > Now, first, let me ask: Might the control panel not function properly > if it's not in the "control panels" folder? I've just got it setting > around on the drive, but it _seems_ to work. Not that I can actually > see the "open firmware" stuff to make sure it's actually doing anything. > - I believe it has to be in the Control Panel folder to work properly, and reliably... - Which makes me think, and yes my question here it OT, so reply directly... My OS X G4 has a modem port, but no other external serial ports... (those bastards at Apple! :) Is there a way to hook up my VT420 to it, so I can log into Darwin? Maybe using an external modem hanging off of the VT420? -- --- David A Woyciesjes --- C & IS Support Specialist --- Yale University Press --- mailto:david.woyciesjes@yale.edu --- (203) 432-0953 --- ICQ # - 905818 Mac OS X 10.1 - Darwin Kernel Version 5 Running since 01/22/2002 without a crash

24 years, 3 months

1
0
0 0

PowerMac 7200/75 and "Open Firmware"

by csmith＠amdocs.com

Ok guys, I'm pretty sure this isn't quite on topic yet -- but it is somewhat old for a PowerPC model. I have a 7200/75 which was given to me because it had a problem with its video. I cleaned the mainboard with isopropyl, and got all of the dust bunnies out, and it's worked fine since then. :) I've been trying really hard to get the thing to give me an "open firmware" prompt, but have had no success. Right now I have a "converted" vga monitor plugged in, a Mac ADB keyboard/mouse, and an IBM terminal connected to the "modem" port, set to 38400bps, 8 data, 1 stop bit, no parity. The cable has been used recently on a SPARC, so I'm pretty sure it's good. I have tried a Wyse-50 terminal, too, which I know is good. (However, I'm not completely certain that the IBM terminal works as I imagine -- I have it in ADM5 emulation mode right now. I may try to put the Wyse back on it.) I installed OS 8.1 on the disk yesterday. I got it to fit in a 50M partition (barely -- what ever happened to being able to fit MacOS on a floppy?), and I got a copy of the "boot variables" control panel. I have tried to hit command-pretzel-o-f at bootup. It works, but the screen just stays black, and I can't get anything from the terminal. I have tried with and without a null-modem adaptor, since I'm not sure which way the serial port goes. I also tried setting the input device and output device with the "boot variables" control panel. I've tried: Input: ttya Output: ttya Input: kbd Output: screen Input: kbd Output: /chaos/control Now, first, let me ask: Might the control panel not function properly if it's not in the "control panels" folder? I've just got it setting around on the drive, but it _seems_ to work. Not that I can actually see the "open firmware" stuff to make sure it's actually doing anything. Next: Any ideas what I'm doing wrong? Has anyone else ever gotten this to work? Eventually I want to install Darwin on this system, and use the terminal on the "modem port" for all console operations. Chris Christopher Smith, Perl Developer Amdocs - Champaign, IL /usr/bin/perl -e ' print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n"); '

24 years, 3 months

1
0
0 0

APPLEVISION Monitor

by csmith＠amdocs.com

> -----Original Message----- > From: Cameron Kaiser [mailto:spectre@stockholm.ptloma.edu] > However, security through obscurity should never be > considered optimal. :-/ Yep, I hope they're well configured, since the chance of a security-problem-causing bug being cross platform among unix systems is certainly there. > Unfortunately, as Microsoft products make an inroad in the > Macintosh market, > this will eventually change. I see Mac owners running Outlook > *without* a > virus checker, and I just cringe and hug Elm tightly. Anybody who runs outlook deserves what they get. Yes, that sounds strange coming from me -- and it includes me. I fully expect that this system -- poorly configured as it is with ridiculously terrible software -- will some day catch a "cold." I will just laugh and call in the corporate windows weenies when it happens. "No my job. man." That said, I am quite a bit more careful than the average person, and maybe that helps. Chris Christopher Smith, Perl Developer Amdocs - Champaign, IL /usr/bin/perl -e ' print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n"); '

24 years, 3 months

1
0
0 0

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