test-drb May 2002

test-drb@ccmp.vtda.org

246 participants
947 discussions

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

22 years, 9 months

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

22 years, 9 months

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

22 years, 9 months

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

22 years, 9 months

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

22 years, 9 months

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

22 years, 9 months

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

22 years, 9 months

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>

22 years, 9 months

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"); '

22 years, 9 months

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

22 years, 9 months

← Newer
1
...
83
84
85
86
87
88
89
...
95
Older →

Jump to page:

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