Re: Real tape drive densities
On 2/13/2016 6:33 AM, Christian Corti wrote: > On Thu, 11 Feb 2016, Christian Corti wrote: >> I have a 7970B (-236) with options 127, 006, 007, 012 and 023. > > According to the HP 1000 Peripherals Selection Guide from 1982, page 16, > option 236 specifies an 800bpi master magnetic tape subsystem with one > drive and two-card 13181B interface. > > And you can't mix 800 and 1600 bpi on the same interface for the HP > 1000. You need either the 13181 for NRZI, or the 13183 for PE. That makes sense: different formatters would be required. > > So, apparently my NRZI 9 track drive has the density option included, > and I don't know if there were any other 200/556 bpi 9 track drives out > there. When we got the drive I had hoped it would be a 7 track drive, > but it isn't. > > Christian > I have never heard of 200bpi or 556bpi for anything other than 7 track. I cannot imagine why anyone would ever produce such a thing. The only density I have ever heard of as being available on both 7 track and 9 track is 800BPI NRZI, from any manufacturer, and I have seen quite a lot of them over the years. Nor have I ever seen a 9 track tape whose label on the exterior claimed it had been written at 200 BPI or 556 BPI. Your S/N has prefix 1124, so it looks like this manual is applicable: http://bitsavers.trailing-edge.com/pdf/hp/tape/7970/07970-90886_7970drws_Nov76.pdf Looking at this manual for the 7970B / 7970E I see that dual 7/9 track heads did exist. Yours has a plate that claims it has option 127 (as well as 6, 7, 12 and 23). The 127 implies a 9 track only head, but I suggest you pull the head cover off to see if you can find a part number. What the plate claims, and what the machine actually is can differ for all sorts of reasons. And the sticker is coming off at the edges as well - it may have been *moved* from one frame to another. Wouldn't be the first time - particularly in a university setting. The buttons clearly imply a NRZI drive (rather than 1600 BPI PE). JRJ
Re: Real tape drive densities
On 02/14/2016 02:08 PM, Jay Jaeger wrote: I have never heard of 200bpi or 556bpi for anything other than 7 track. I cannot imagine why anyone would ever produce such a thing. The only density I have ever heard of as being available on both 7 track and 9 track is 800BPI NRZI, from any manufacturer, and I have seen quite a lot of them over the years. Nor have I ever seen a 9 track tape whose label on the exterior claimed it had been written at 200 BPI or 556 BPI. That would agree with my own experience as well. 800 NRZI and 1600 PE; 6250 GCR.There may have been non-computer (e.g. data logging) drives in 9-track with lower densities, but I've not run into any. Some drives apparently *can* mix densities. I came across an AT&T distro tape recently for SVR4 that started with 6250 GCR and then after the first tapemark, switched to 1600 PE for the remainder of the tape. I managed to read it in two passes--the first is the drive set to 6250 at loadpoint, then with the drive set to 1600 at loadpoint. All data was complete, so it's a puzzlement. --Chuck
Tool to convert between Motorola FFP and IEEE754 float formats?
Hi, Does anyone know of a tool which can convert between Motorola's FFP (Fast Floating Point) float format and IEEE754? I'm trying to reverse-engineer some ancient 68k code which uses the FFP library, but a load of the floating point constants have been hard-coded as hex constants, which is making things hard to interpret... I've tried to convert the 68k assembler in FFPIEEE.SA to C, but I must have missed something because it just isn't working... Thanks, -- Phil. classic...@philpem.me.uk http://www.philpem.me.uk/
Re: Tool to convert between Motorola FFP and IEEE754 float formats?
On 14/02/16 23:56, Philip Pemberton wrote: > Hi, > > Does anyone know of a tool which can convert between Motorola's FFP > (Fast Floating Point) float format and IEEE754? > > I'm trying to reverse-engineer some ancient 68k code which uses the FFP > library, but a load of the floating point constants have been hard-coded > as hex constants, which is making things hard to interpret... > > I've tried to convert the 68k assembler in FFPIEEE.SA to C, but I must > have missed something because it just isn't working... Naturally, I figured out what I was doing wrong an hour or so after I hit send... Enjoy! // val is a FFP float, returns IEEE float format // basically a direct conversion of the motorola FFPTIEEE function. // comments are from there. // you are not expected to understand this horrendous mess. float ffpieee(const uint32_t val) { uint32_t x = val; union { float f; uint32_t i; } _fcast; x = x + x; // delete mantissa high bit if (x == 0) { // if zero, branch zero as finished return (float)x; } uint8_t k = x & 0xff; k ^= 0x80; // to two's complement exponent k >>= 1;// form 8-bit exponent k -= 0x82; // adjust 64 to 127 and excessize x = (x & ~0xff) | k; x = (x << 16) | (x >> 16); // swap for high byte placement x <<= 7;// set sign+exp in high byte _fcast.i = x; return _fcast.f; } -- Phil. classic...@philpem.me.uk http://www.philpem.me.uk/
Re: Real tape drive densities
On 2/14/2016 5:36 PM, Chuck Guzis wrote: > On 02/14/2016 02:08 PM, Jay Jaeger wrote: > >> I have never heard of 200bpi or 556bpi for anything other than 7 >> track. I cannot imagine why anyone would ever produce such a thing. >> The only density I have ever heard of as being available on both 7 >> track and 9 track is 800BPI NRZI, from any manufacturer, and I have >> seen quite a lot of them over the years. Nor have I ever seen a 9 >> track tape whose label on the exterior claimed it had been written at >> 200 BPI or 556 BPI. > > That would agree with my own experience as well. 800 NRZI and 1600 PE; > 6250 GCR.There may have been non-computer (e.g. data logging) drives > in 9-track with lower densities, but I've not run into any. > > Some drives apparently *can* mix densities. I came across an AT&T > distro tape recently for SVR4 that started with 6250 GCR and then after > the first tapemark, switched to 1600 PE for the remainder of the tape. I > managed to read it in two passes--the first is the drive set to 6250 at > loadpoint, then with the drive set to 1600 at loadpoint. All data was > complete, so it's a puzzlement. > > --Chuck > Yes, some drives can - ones that are not "smart" with their own microprocessor. My HP 9 Track drive is, unfortunately, "smart", and looks for recording bursts at the beginning of the tape and sticks doggedly to that. Maybe some yahoo decided to write over the first file of that SVR4 tape at higher density so as not to clobber the files after it. Smart, so as not to clobber the other stuff, but crazy. Or it may have been just a case of writing that first file, with no double-EOF EOT on it. Or maybe someone wrote the first file and then went "OH SH*T that was a DISTRO TAPE wasn't it..." ;) Anyway, I doubt AT&T would have written the tape that way intentionally. Curious: What processor was that distro for? Maybe donate the files to PUPS? JRJ
Re: Real tape drive densities
On 02/14/2016 05:36 PM, Chuck Guzis wrote: On 02/14/2016 02:08 PM, Jay Jaeger wrote: I have never heard of 200bpi or 556bpi for anything other than 7 track. I cannot imagine why anyone would ever produce such a thing. The only density I have ever heard of as being available on both 7 track and 9 track is 800BPI NRZI, from any manufacturer, and I have seen quite a lot of them over the years. Nor have I ever seen a 9 track tape whose label on the exterior claimed it had been written at 200 BPI or 556 BPI. That would agree with my own experience as well. 800 NRZI and 1600 PE; 6250 GCR.There may have been non-computer (e.g. data logging) drives in 9-track with lower densities, but I've not run into any. Some drives apparently *can* mix densities. I came across an AT&T distro tape recently for SVR4 that started with 6250 GCR and then after the first tapemark, switched to 1600 PE for the remainder of the tape. I managed to read it in two passes--the first is the drive set to 6250 at loadpoint, then with the drive set to 1600 at loadpoint. All data was complete, so it's a puzzlement. Well, that could be a malfunction. Some tape drive-formatter sets cannot do this without hardware problems. But, some had software-controlled density, and so the software could override the detected density when the tape was mounted. 800 NRZI had nothing recorded over the BOT marker, 1600 and 6250 had distinct patterns written over the BOT marker to ID the density. Once the density is identified, it SHOULDN'T allow you to change it in the middle of the tape. Jon
Re: Real tape drive densities
On 02/14/2016 06:13 PM, Jay Jaeger wrote: Maybe some yahoo decided to write over the first file of that SVR4 tape at higher density so as not to clobber the files after it. Smart, so as not to clobber the other stuff, but crazy. Or it may have been just a case of writing that first file, with no double-EOF EOT on it. Or maybe someone wrote the first file and then went "OH SH*T that was a DISTRO TAPE wasn't it..." ;) Anyway, I doubt AT&T would have written the tape that way intentionally. Well, the tape bears an AT&T label. The tape itself comes from UCB at about the same time that "ernie" was in use, so VAX or PDP11. It could be a copy of an AT&T distro tape with the duplicate label attached. It's a 2,222,000 byte cpio file that starts out with: # THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T # The copyright notice above does not evidence any # actual or intended publication of such source code. #ident "@(#)mk::mk 1.10" # # Shell script for rebuilding the UNIX System # trap "exit 1" 1 2 3 15 if [ "$ROOT" = "" ] then PATH=/bin:/etc:/usr/bin; export PATH fi That's the 6250 GCR file; the 1600 PE file that follows is a 37,432,320 byte cpio file that starts out in exactly the same way. The 2MB file was probably an "osh*t" file as it terminates prematurely at "usr/src/cmd/bnu/bnu.mk". I read it on my Fuji 2444 (Pertec interface). None of my SCSI drives could handle the mixed density. Just curious-- How many "smart" drives can handle multiple load points? Before the day of autothreading drives, it was convenient to have a "universal deadstart" tape to carry along, with various operating systems on it. Just keep hitting the "load" button until you get to the one you want, then push the button. --Chuck
Re: Babes at Bell Labs
On 02/14/2016 03:38 PM, James Gessling wrote: In honor of Valentine's day and all the great ladies that I've worked with over the years, I for one had a small part in a romance by setting up a VMS account for the geologist in our department after listening to his complaints about how useless computers were for years. Come to find out he wanted to email with one of my best programmers. Love ensued with marriage in a little while. Please enjoy. A bit later, but I remember a section manager at CDC who wore a powder-blue leisure suit. Clothes changed a lot then. --Chuck