Re: Old MOS Mask-Programmed ROM forgetfulness?
On Mon, Feb 15, 2016 at 11:31 PM, John Robertson wrote: > Rick, if you want to archive these PROMs (highly recommended) you should be > able to find a Data I/O 29B and get one of the programming packs that > supports NS chips. I may have such a combination in my collection, but that > PROM is not listed in my DATA I/O library of readable parts. They're not PROMs, they are masked ROMs, and there is *NO* equivalent PROM, so it's unlikely that there's any support for reading them on any PROM programmer. > Part of the > problem with the early PROMs is they needed a Sync or Clock signal to be > able to be read. The MM4221/5221 is fully static, so it doesn't have that particular problem. It's PMOS, and needs +5V and -12V supplies. The outputs are TTL-compatible, but the inputs technically are not, due to Vih min of 3.0V. Could be driven by TTL with a pullup resistor, or by CMOS.
Re: Old MOS Mask-Programmed ROM forgetfulness?
On 02/15/2016 10:25 AM, Rick Bensene wrote: Hi, all, I have a question about old Mask-Programmed ROMs The part in question is the National Semiconductor MM5231. This part is a 2K-bit PMOS Mask-Programmed ROM, generally organized as 256x8, but also can be organized (via a MODE pin)as 512x4 bits. In this particular application, the parts are used as 256x8. I'm wondering if anyone knows if these particular ROMs (from the '72 timeframe) have a tendency for bit rot over the years? I know some of the early MOS ROMs had issues with metallization creep that would cause data loss/corruption. I have an old calculator that uses these ROMs as the micro and macrocode stores. The machine is catatonic, though the power supplies, master clock oscillator and divider circuitry, and the other obvious stuff are OK. I suspect it is probably stuck in some kind of microcode loop, just cycling around doing nothing. I have not yet put logic analyzer on the microcode latches yet, but that's probably my next experiment. Sadly, if one or more of these ROMs (there are 18 of them!) has failed, it likely means that the machine can't be restored to operation, as this is quite a rare machine, and there just aren't many of them left around. I have three different EPROM programmers, but sadly, none of them have the capability to read these parts. I was I had a Data I/O programmer, but alas, haven't come across one with all the Unipak modules I'd need at a price I can afford. Thanks, -Rick --- Rick Bensene The Old Calculator Museum http://oldcalculatormuseum.com Rick, if you want to archive these PROMs (highly recommended) you should be able to find a Data I/O 29B and get one of the programming packs that supports NS chips. I may have such a combination in my collection, but that PROM is not listed in my DATA I/O library of readable parts. Part of the problem with the early PROMs is they needed a Sync or Clock signal to be able to be read. If I think of it tomorrow I will go through my sets, but the best place right now is for you to post this request on the Data I/O mail list on Yahoo"Data_IO_EPROM" and see if someone there can give you better advice. John :-#)# -- John's Jukes Ltd. 2343 Main St., Vancouver, BC, Canada V5T 3C9 Call (604)872-5757 or Fax 872-2010 (Pinballs, Jukes, VideoGames) www.flippers.com "Old pinballers never die, they just flip out"
Re: VAX/VMS media
On Mon, Feb 15, 2016, Mark J. Blair wrote: > > > On Feb 15, 2016, at 17:46, Jay Jaeger wrote: > > > > > > Ah. I see I was too late. > > Me, too. Well, that's what I get for failing to keep on top of my personal > email while at work today. :) I would have claimed them based on proximity, but then I'd have had to worry about keeping them in a safe environment, so it's probably for the best. -- Eric Christopherson
Re: VAX/VMS media
> On Feb 15, 2016, at 17:46, Jay Jaeger wrote: > > > Ah. I see I was too late. Me, too. Well, that's what I get for failing to keep on top of my personal email while at work today. :) -- Mark J. Blair, NF6X http://www.nf6x.net/
Re: IBM (Sony) PowerDisplay 20
mån 2016-02-15 klockan 14:38 +0100 skrev Stefan Skoglund (lokal användare): > Howdy. > > I connected one of theese (i have two) to an PC last night. > > Blemishes: > the text is blurry > wrong color tones (a little bit red) > > so how much can i do with the display picture setting buttons ? > > I'm thinking about connecting one of them to a Sun 10 (but i do have a > bunch of RS 6000 PPC machines.) > I found the user manual for it and read up on convergence settings. I got a mostly good display (some work still to do concerning pincushion) but the text got good. Result: Windows 95 running in 1600x1280. Do anyone have the service dito (and would be willing to share) ?
Re: VAX/VMS media
On 2/15/2016 3:32 PM, Jon Auringer wrote: > Hello again, > > On 2016-02-15 2:41 PM, Jon Auringer wrote: >> Hello all, >> >> I have a bunch of VAX/VMS media that need a new home. I must move them >> very soon and I have little time for shipping. Pickup from 53714 >> (Madison, Wi) preferred. > > I have found someone to pick up the DEC stuff in a very timely manner. > Thank you for your attention. > > -Jon > Ah. I see I was too late. JRJ
Re: VAX/VMS media
On 2/15/2016 2:41 PM, Jon Auringer wrote: > Hello all, > > I have a bunch of VAX/VMS media that need a new home. I must move them > very soon and I have little time for shipping. Pickup from 53714 > (Madison, Wi) preferred. > > 16MT9: > VMS V5.3 BIN 1/2 & 2/2 in shipping box with docs > VMS V5.3.1 BIN > > 8" floppy media: > VAX/VMS 3.4 5 disks > VAX/VMS 3.6 > VAX/VMS 3.7 > VAX/VMS 4.0 3 disks > VAX/VMS V4.1 UPD BIN 4 disks > VAX/VMS V4.2 BIN RX01 MANDATORY UPDATE > VAX FORTRAN 3.4 > VAX PASCAL 2.3 > > Microfiche: > VAX/VMS 3.6 SRC LST > VAX/VMS 4.2 SRC LST > > -Jon > I am in Madison, and have the means to image them. I have fiche for VMS 3.6 and 4.2, though they are delta apparently, rather than complete listings. I think my VMS 3.0 and 4.4 fiche are complete listings. JRJ BCC: Jon
Re: Anyone have DIBOL-11, CTS-300, or CTS-500?
On Mon, Feb 15, 2016 at 5:54 PM, Eric Smith wrote: > Does anyone have the DIBOL-11 software, which was packaged for RT-11 > as CTS-300, and for RSTS as CTS-500? > > My immediate interest is for RT-11, though I have a DECdatasystem-570 > that I believe was originally sold with CTS-500, so it would be really > nice to get that as well. Can you process (image) 9-track tape? I have quite a few tapes with DIBOL-related packages on them. Whether any of them are actual DEC DIBOL, I don't know yet. I can work up a list of titles/numbers soon-ish. I do have a SCSI 9-track drive but it's not easily accessible at the moment (nor is the time to read them in.) I'd be happy to send them off to someone who could, though. Similarly, I haven't run across any DEC DIBOL documentation yet (though there is still much to look through.) I have scanned many MCBA manuals for their DIBOL products here: http://chiclassiccomp.org/docs/index.php?dir=%2Fcomputing/MCBA The tapes I have were originally for a DECDataSystem 11/34-based machine. The CTS-xxx moniker sounds familiar, though. -j
Re: Anyone have DIBOL-11, CTS-300, or CTS-500?
Wow! I’m sad to say, good luck with this one. I’ve not seen any sign of it having survived. As close as I can get is the binder I have for COS-310 v8.01, but that is for the PDP-8. I’ve always thought it would be interesting to check out DIBOL-11, so would be interested if you have any luck. My fear is this is like DECnet for RT-11, impossible to find. I hope I’m wrong. Zane > On Feb 15, 2016, at 3:54 PM, Eric Smith wrote: > > Does anyone have the DIBOL-11 software, which was packaged for RT-11 > as CTS-300, and for RSTS as CTS-500? > > My immediate interest is for RT-11, though I have a DECdatasystem-570 > that I believe was originally sold with CTS-500, so it would be really > nice to get that as well. > > It would also be nice to get scans of related documentation, if anyone > has it, including: > > AA-5519A-TC Introduction to CTS-300 and DIBOL > AA-5697E-TC CTS-300 Release Notes and Installation Guide > AA-5495A-TC CTS-300 Concepts and Facilities > AA-1760F-TC DIBOL-11 Language Reference Manual > AA-5972D-TC DECFORM User's Guide > AA-5025B-TC CDS-500 DIBOL User's Guide
Anyone have DIBOL-11, CTS-300, or CTS-500?
Does anyone have the DIBOL-11 software, which was packaged for RT-11 as CTS-300, and for RSTS as CTS-500? My immediate interest is for RT-11, though I have a DECdatasystem-570 that I believe was originally sold with CTS-500, so it would be really nice to get that as well. It would also be nice to get scans of related documentation, if anyone has it, including: AA-5519A-TC Introduction to CTS-300 and DIBOL AA-5697E-TC CTS-300 Release Notes and Installation Guide AA-5495A-TC CTS-300 Concepts and Facilities AA-1760F-TC DIBOL-11 Language Reference Manual AA-5972D-TC DECFORM User's Guide AA-5025B-TC CDS-500 DIBOL User's Guide
Re: Apple Lisa 2/10 for sale
Did you remove the battery >18 months ago and neutralize the damage? Cuz otherwise I wouldn't bank on it turning on again! :) On Mon, Feb 15, 2016 at 1:44 PM, Kevin Griffin < kevinwilliamgrif...@gmail.com> wrote: > I have two Lisas (2/5 and 2/10) - so I say Apple ///!! (obviously not > objective). > > On Mon, Feb 15, 2016 at 1:20 PM, Geoffrey Oltmans > wrote: > > > Slight threadjack... which is uglier... the Lisa or the Apple ///? > > > -- Ian Finder (206) 395-MIPS ian.fin...@gmail.com
Re: Apple Lisa 2/10 for sale
I have two Lisas (2/5 and 2/10) - so I say Apple ///!! (obviously not objective). On Mon, Feb 15, 2016 at 1:20 PM, Geoffrey Oltmans wrote: > Slight threadjack... which is uglier... the Lisa or the Apple ///? >
Re: VAX/VMS media
Hello again, On 2016-02-15 2:41 PM, Jon Auringer wrote: Hello all, I have a bunch of VAX/VMS media that need a new home. I must move them very soon and I have little time for shipping. Pickup from 53714 (Madison, Wi) preferred. I have found someone to pick up the DEC stuff in a very timely manner. Thank you for your attention. -Jon
Re: Apple Lisa 2/10 for sale
Slight threadjack... which is uglier... the Lisa or the Apple ///?
Re: Old MOS Mask-Programmed ROM forgetfulness?
On Mon, Feb 15, 2016 at 11:25 AM, Rick Bensene wrote: > I know some of the early MOS ROMs had issues with metallization creep > that would cause data loss/corruption. That would certainly do it, but it's the first time I've heard of it with regard to masked ROMs. > I have three different EPROM programmers, but sadly, none of them have > the capability to read these parts. I was I had a Data I/O programmer, > but alas, haven't come across one with all the Unipak modules I'd need > at a price I can afford. It's not obvious that even a Data I/O would read them. With at least "recent" Data I/O models, they often won't read masked-ROM microcontrollers because they detect that the supply current is out of range for EPROM parts. If I were going to read those, I'd wire them up to the pins of a microcontroller. I've been doing that lately for other non-standard ROMs, such as the Western Digital microcode ROMs used in the LSI-11, Alpha Micro AM100, and Pascal Microengine. Obviously you should try to read them by electrical means first. However, if you eventually become completely convinced that you haven't (or can't) get the correct data out of them in that way, it will be time to start thinking about decap. It seems fairly likely that it will be possible to optically distinguish the intended states of the bits, as opposed to the actual electrical connectivity. This has been done successfully with NiCr bipolar PROMs suffering from fuse regrowth, though the problem for masked ROMs isn't completely the same.
VAX/VMS media
Hello all, I have a bunch of VAX/VMS media that need a new home. I must move them very soon and I have little time for shipping. Pickup from 53714 (Madison, Wi) preferred. 16MT9: VMS V5.3 BIN 1/2 & 2/2 in shipping box with docs VMS V5.3.1 BIN 8" floppy media: VAX/VMS 3.4 5 disks VAX/VMS 3.6 VAX/VMS 3.7 VAX/VMS 4.0 3 disks VAX/VMS V4.1 UPD BIN 4 disks VAX/VMS V4.2 BIN RX01 MANDATORY UPDATE VAX FORTRAN 3.4 VAX PASCAL 2.3 Microfiche: VAX/VMS 3.6 SRC LST VAX/VMS 4.2 SRC LST -Jon
Re: Old MOS Mask-Programmed ROM forgetfulness?
The ones you have to watch out for as a rule are those made by Mostek. Not sure of the date when they changed to recipe. If your still in/near PDX I will be getting my Unisite+ back in March and I may have a working Model 29 that you can borrow. -pete On Mon, Feb 15, 2016 at 10:25 AM, Rick Bensene wrote: > Hi, all, > > I have a question about old Mask-Programmed ROMs > > The part in question is the National Semiconductor MM5231. This part is > a 2K-bit PMOS Mask-Programmed ROM, generally organized as 256x8, but > also can be organized (via a MODE pin)as 512x4 bits. In this particular > application, the parts are used as 256x8. > > I'm wondering if anyone knows if these particular ROMs (from the '72 > timeframe) have a tendency for bit rot over the years? > > I know some of the early MOS ROMs had issues with metallization creep > that would cause data loss/corruption. > > I have an old calculator that uses these ROMs as the micro and macrocode > stores. > > The machine is catatonic, though the power supplies, master clock > oscillator and divider circuitry, and the other obvious stuff are OK. > I suspect it is probably stuck in some kind of microcode loop, just > cycling around doing nothing. I have not yet put logic analyzer on the > microcode latches yet, but that's probably my next experiment. > > Sadly, if one or more of these ROMs (there are 18 of them!) has failed, > it likely means that the machine can't be restored to operation, as this > is quite a rare machine, and there just aren't many of them left around. > I have three different EPROM programmers, but sadly, none of them have > the capability to read these parts. I was I had a Data I/O programmer, > but alas, haven't come across one with all the Unipak modules I'd need > at a price I can afford. > > Thanks, > -Rick > --- > Rick Bensene > The Old Calculator Museum > http://oldcalculatormuseum.com > > > > >
Re: Apple Lisa 2/10 for sale
Nice 1 Ali! On Mon, Feb 15, 2016 at 12:16 PM, Ali wrote: > > When we powered it up for the last time 18 months ago, it appeared to > > be working (no nasty smells etc) but we didn't test it very much. What > > has happened since is anybody's guess. > > Well, why not power it up again and then no one has to guess "what has > happened since"? > > -Ali > >
RE: Apple Lisa 2/10 for sale
> When we powered it up for the last time 18 months ago, it appeared to > be working (no nasty smells etc) but we didn't test it very much. What > has happened since is anybody's guess. Well, why not power it up again and then no one has to guess "what has happened since"? -Ali
Apple Lisa 2/10 for sale
Hi, We at Hack42 have an Apple Lisa 2/10 for sale at http://www.ebay.nl/itm/121893065311. When we powered it up for the last time 18 months ago, it appeared to be working (no nasty smells etc) but we didn't test it very much. What has happened since is anybody's guess. Note: shipping to the US is *really* expensive, but within Europe is only slightly less painful (with packaging it'll reach 25kg easily). Pickup is an option. -- Andreas
Old MOS Mask-Programmed ROM forgetfulness?
Hi, all, I have a question about old Mask-Programmed ROMs The part in question is the National Semiconductor MM5231. This part is a 2K-bit PMOS Mask-Programmed ROM, generally organized as 256x8, but also can be organized (via a MODE pin)as 512x4 bits. In this particular application, the parts are used as 256x8. I'm wondering if anyone knows if these particular ROMs (from the '72 timeframe) have a tendency for bit rot over the years? I know some of the early MOS ROMs had issues with metallization creep that would cause data loss/corruption. I have an old calculator that uses these ROMs as the micro and macrocode stores. The machine is catatonic, though the power supplies, master clock oscillator and divider circuitry, and the other obvious stuff are OK. I suspect it is probably stuck in some kind of microcode loop, just cycling around doing nothing. I have not yet put logic analyzer on the microcode latches yet, but that's probably my next experiment. Sadly, if one or more of these ROMs (there are 18 of them!) has failed, it likely means that the machine can't be restored to operation, as this is quite a rare machine, and there just aren't many of them left around. I have three different EPROM programmers, but sadly, none of them have the capability to read these parts. I was I had a Data I/O programmer, but alas, haven't come across one with all the Unipak modules I'd need at a price I can afford. Thanks, -Rick --- Rick Bensene The Old Calculator Museum http://oldcalculatormuseum.com
Re: Tool to convert between Motorola FFP and IEEE754 float formats?
One way to do float format conversions (among a whole bunch of formats) is to use the arbitrary-precision and variable-format float machinery in the GCC compiler (file real.c). It probably doesn't quite give you what you need -- conversion from one format to another -- but I imagine that adding this wouldn't be all that hard. If you need to do exotic stuff, like convert from PDP-11 D format to IBM-360 double, that would be a way to do it. It can readily be extended to add formats it doesn't currently have. I added PDP-11 float to it in the past, that was pretty easy. I suspect stranger formats like CDC 6000 might be harder, but probably still doable. paul
Re: Stuck bits on 11/73 Clearpoint 4MB memory - how to repair?
> From: Jacob Ritorto > I struggled for hours with inadequate eyesight, tools and materials, > but I think I got this mod done! That was quick! I had an 11/23 on my workbench that had had that backplane mod, so I took it apart to take a picture, to help you, but I guess that's OBE... :-) > the machine's stuck in self-test at error 47, Memory CSR error. It's not clear that that's really a hardware problem. DEC makes assumptions about how many memory CSRs there will be, etc, and some third-party board 'fail' when they don't meet those expectations. I have a Clearpoint QED1 (I think that's the one, didn't check) that does that. > What I assume is the parity light on the third party "Clearpoint QRAM-2 > SPB-1 88B" lights during self test. I've found no documentation for this > sucker as yet.. I have a PDF of the "User Information Manual" for the Clearpoint Q-RAM 88B. (Oh, I see, later message says you found it.) No prints, alas. Anyone have any we can scan and put online? > I'll have to find my rl02 controller and build the system up some more > so I can run xxdp and find out what exactly died. I would tend to use diagnostics as 'help', not my main tool in diagnosing faults. This is particular true as really bad issues can prevent the diagnostics from loading/running, so if you get skilled at fault analysis without depending on them, you're better situated to deal with the failures that prevent using them. > Can anyone offer hints as to how to identify which component is broken > and how to go about repairing this? As other have said, lacking the prints, pulling chips (if they are socketed) ought to enable you to work out which chips goes where. (I'v worked out the chip layout for a number of un-documented memory cards this way.) I don't know about your 88B, but the one I have photos of, and my other Clearpoint cards, the chips are in sockets. With luck yours will be too... If not, ask if someone has one with sockets (alas, I don't have an 88B), who can do the mapping for you. Important: once you have worked it out, pass it along! I'm trying to upload all the data I've collected about cards for which no documentation is available to the Computer History wiki. > It's the only memory board in this machine, so I guess the problem > might actually be a bus or processor board, right? Could be. I have an KDJ11-B which has stuck bits, and that's the CPU board, so yours could be to. > I have no other q-bus memory to test with, so can't do swapping / > process of elimination to be sure. It's definitely worth having another small QBUS memory card to use in fault isolation when debugging. M8044's are readily available on eBay for about $20. They are only Q18, so not usable in the same machine as Q22 memory, but they are useful for debugging. I would definitely invest in one. (If you luck out and get a bad one, send it to me, and I'll swap it for a known good, tested, one. I've fixed a whole bunch of them, got to the point where the last one I did for someone I didn't even have to pull out my 'scope! I could tell from the symptoms exactly which chip to replace! :-) > From: Jay Jaeger > Well clearly it is only affecting certain address bits - or the > diagnostic would not run at all Well, like I said, I do have a KDJ11-B which will run the on-board startup diagnostic, but which has a bit stuck hard on the QBUS interface! So those machines seem to be pretty resilient. Although as you point out, if he can load and run the diagnostic, it's probably not the CPU. > note that it is starting at 01000, so that points to the memory Yup. If some locations work, and others don't, it's almost certainly the memory. And since he's only dealing with a single memory card, it's probably not the bus drivers/receivers on that card, either. One can use ODT on the KDJ11-B to poke around, and find the envelope of the problem. (See comments above about not relying on diagnostics! They are better for saying something's busted, than for accurately telling what _is_ broken.) With that, and a chip->memory map, it should be fairly easy to replace the offending chips. Noel
Re: Tool to convert between Motorola FFP and IEEE754 float formats?
On 2/14/2016 8:47 PM, Philip Pemberton wrote: 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... Hi; Back in the late 1980's I had a similar problem with reading data from a reel to reel tape created on a Z80 based Cromemco computer on a Vax 11/750. Had to convert the IEEE format floating point numbers from the Cromemco to Vax floating point format, did it in Fortran much like what you have done, except in the other direction. Doug
Re: QSIC update
> From: Al Kossow > Have you guys thought about a panel that would connect to the KM11 > connector slots of real rk11/tc11 controllers? Umm, Guy sells KM11 clones? (I just bought a pair, they look really nice.) Or did you mean something else? Speaking of things Guy has, Dave is talking about adding a switch that would turn a QSIC+indicator panel into a QAV-11... :-) Noel
Re: QSIC update
On 2/15/16 5:05 AM, Noel Chiappa wrote: Anyway, we think getting slave cycles working was a major milestone (for a couple of software guys :-) yay! Have you guys thought about a panel that would connect to the KM11 connector slots of real rk11/tc11 controllers? At one point, I thought about a cable that would let you run virtual KM11's on a laptop screen.
Re: Real tape drive densities
On 2/15/16 2:32 AM, Christian Corti wrote: I've added another picture of a closeup of the R/W head. In my opinion it's a 9 track read-after-write head. The geometry and gaps are identical to those of the adjacent 7970B 800bpi-only tape drive we have. I have two 7/9 track HP drives, and a bunch of head stacks. There is no erase head. The 7 and 9 track head stacks sit next to each other. I may have time to dig them out and take pictures at some point this month.
IBM (Sony) PowerDisplay 20
Howdy. I connected one of theese (i have two) to an PC last night. Blemishes: the text is blurry wrong color tones (a little bit red) so how much can i do with the display picture setting buttons ? I'm thinking about connecting one of them to a Sun 10 (but i do have a bunch of RS 6000 PPC machines.)
QSIC update
So here's a quick update on where Dave Bridgham and I are with the QSIC, since I think we have reached a significant milestone. We have the first of two wire-wrap prototype QBUS motherboards more or less (see below) done, and working to do slave cycles on the QBUS. (I.e. we implemented a simple register, and can write it, and read the contents back.) A test program to write all 2^16 possible values, and read them back and check them, ran several thousand complete passes with no errors. To get there, we (Dave, really - he bore the brunt of the work on this problem, and finally conquered it) had to tackle and fix some major noise issues: the way the prototype is done (a wirewrap QBUS mother-board with bus transceivers, level converters, etc, connected to an FPGA prototyping card with flat cables), we think we had cross-talk problems in the cables (since the connector pinout on the FPGA card, which we can't change, didn't alternate ground and signal lines). Anyway, it's working now; that means the hardware is 'mostly' working; most of the work from here on out will be FPGA, etc, programming. There _are_ a few additional QBUS lines used for bus master (DMA) and interrupts which we haven't used yet, and one of the first things done now is to get those two kind of bus cycles working; a) we have to get them done anyway, and b) that will verify that the QBUS interface hardware is full working. With that in hand, we can do the first controller (RK11), using memory in the FPGA to simulate a small disk. We'll then try and get to the larger RAM on the FPGA, to do full-size RAM disks. Next up after that is probably to hook up some SD cards (we already have produced the small PCB daughter-cards, which will mount on sockets on the wire-wrap mother-board, to hold the SD cards - we still need to add those sockets and wire them up, hence the comment that the wire-wrap mother-boards are "almost done"), at which point we'll have a fully-functional prototype. Dave has also produced prototype PCB's for the indicator panel, and one has been stuffed, and Dave's about to try and hook that up, and get it running; that will require yet a bit more work on the mother-board (install 3 sockets to hold the driver chips for the signal lines in the interface to the indicator panel). Blinkenlitz are a priority because, i) just because ;-), and ii) being able to display data from inside the FPGA will be a big debugging help. Anyway, we think getting slave cycles working was a major milestone (for a couple of software guys :-), And we think (_hope_ :-) that progress will now be pretty rapid, so hopefully more soon. Noel
Front Panels Update
Hi I had an email in from the screeners this morning. She is getting there. I suppose I should not expect automation speeds from a skilled hand process. Twenty boards not all the same with five passes per board, flush out time and drying time with the need for spot on registration aint gonna be that quick. More news as I get it Rod
Re: Real tape drive densities
On Sun, 14 Feb 2016, Jay Jaeger wrote: Looking at this manual for the 7970B / 7970E I see that dual 7/9 track heads did exist. Yes, but only in read-only configurations. 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 I've added another picture of a closeup of the R/W head. In my opinion it's a 9 track read-after-write head. The geometry and gaps are identical to those of the adjacent 7970B 800bpi-only tape drive we have. 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. I think it's the original sticker, the options listed on the manual (hand-written by HP on the cover page) match, and the date codes (1971) match, too. Christian
