Re: papertape repair tape or kit wanted
On 11/29/2015 11:32 PM, simon wrote: what are the specs of the tape and glue? remember that using a lasercutter from a nearby fablab or hackerspace could produce the exact tape you need. On 30-11-15 02:40, william degnan wrote: NOTE: I will pay a generous price for a few inches of papertape repair tape if anyone has any! I am located in Landenberg, PA USAContact me privately if you can help. We repaired tape with contact glue and rubout tape punched on an ASR33. I guess it would depend on whether you were repairing paper, fiber or mylar material though whether the adhesive would work or not. I have a box of the repair material somewhere, but I suspect the adhesive would be useless with the material. Better to manufacture your own with Williams suggestion, or a simpler one like mine. BTW, we only used this method with tapes to be read on an ASR33. We didn't have high speed machines. You can use scotch tape sometimes on units with optical readers, and dupe the tape from what you read if you need to have a copy w/o a break in it. thanks Jim
Re: papertape repair tape or kit wanted
what are the specs of the tape and glue? remember that using a lasercutter from a nearby fablab or hackerspace could produce the exact tape you need. On 30-11-15 02:40, william degnan wrote: NOTE: I will pay a generous price for a few inches of papertape repair tape if anyone has any! I am located in Landenberg, PA USAContact me privately if you can help. -- Met vriendelijke Groet, Simon Claessen drukknop.nl
RE: papertape repair tape or kit wanted
> > I have a box of the repair material somewhere, but I suspect the > adhesive would be useless with the material. Better to manufacture your > own with Williams suggestion, or a simpler one like mine. BTW, we only > used this method with tapes to be read on an ASR33. We didn't have high > speed machines. > I remember there being the remains of a pinch roller from the KDF9 high speed tape reader that had been destroyed by a bad join in a tape in University of Newcastle data prep room. There was also a warning to re-punch tapes for that reader.. > You can use scotch tape sometimes on units with optical readers, and > dupe the tape from what you read if you need to have a copy w/o a break > in it. > > thanks > Jim
RE: papertape repair tape or kit wanted
Here is an idea I haven't tried, but might work: Take some unoiled paper or mylar tape and punch it with rubouts. Spray one side with spray-on photo mounting adhesive just before use. It would definitely leave a thick spot in the repaired tape, but I suspect it would hold up long enough to punch a copy. --Bill http://www.amazon.com/3M-Spray-Artists-Adhesive-MMM6065/dp/B6IFBF
Re: papertape repair tape or kit wanted
Back inthe early 70's one of my jobs was to repair and set up 4K core stores for ICT 4100 systems. The company I worked for were an off shoot of the big boat builders Camper & Nicholsons. It was an all paper tape system (no cards). There were two readers, two punches and two keyboardless golfball typewriters. I have forgotten exactly what types they were. I think the punch said something like BPRE on it and the readers did not match the rest of the system being painted a sort of PDP 8 Bezel white. To test the repaired core stores I ran an Algol program that did the handicapping for sailing boats. First you loaded the program (a reel of paper tape about three inches across.) I had a tape width wide perspex box with slots to put a pin through to locate the tape. . There was one switch to load and go. Centre was off, up loaded the tape to the start in the reader and down set it off. Boy was it quick! The tape shot through the reader and into a bin. Tape get tangled? Nope never did. At this point the printer would say Data? Of course you did not load the data tape. First you rewound the program tape so as not mix them up in the bin. My favorite trick was to grab the end of the tape before it got to the bin. The rewinder was just like a film rewinder. Next up load the data tape and then wait about 10-15 mins for the output to appear on the printer. Am I going to run a paper tape system on my 8/e Hell yes!! Rod On 30/11/2015 09:42, Dave Wade wrote: I have a box of the repair material somewhere, but I suspect the adhesive would be useless with the material. Better to manufacture your own with Williams suggestion, or a simpler one like mine. BTW, we only used this method with tapes to be read on an ASR33. We didn't have high speed machines. I remember there being the remains of a pinch roller from the KDF9 high speed tape reader that had been destroyed by a bad join in a tape in University of Newcastle data prep room. There was also a warning to re-punch tapes for that reader.. You can use scotch tape sometimes on units with optical readers, and dupe the tape from what you read if you need to have a copy w/o a break in it. thanks Jim
RE: papertape repair tape or kit wanted
> punches and two keyboardless golfball typewriters. I have forgotten > exactly what types they were. I think the punch said something like > BPRE on it and the readers did not match the rest of the system being Probably BRPE (normally pronounced 'Burpee') which is a high speed (something like 110 characters/second) paper tape punch from Teletype. IIRC the Teletype ones were in a grey all-metal cabinet with a lift-up lid. There was also a Data Dynamics version in a cabinet with a smoked perspex door and with a couple of pygmy light bulbs under the chad box to illuminate the front. That looks pretty but doesn't change the perfomance... -tony
RE: papertape repair tape or kit wanted
> NOTE: I will pay a generous price for a few inches of papertape repair tape > if anyone has any! I am located in Landenberg, PA USAContact me > privately if you can help. The official splicing tape I've seen is in little squares with all holes punched (probably covers 9 or 10 characters on the tape. I may still have some somewhere, but it was trasparent tape so the crack between the ends of the 2 bits of paper tape you were joining would confuse most optical treaders. In the end I would run out a bit of all-holes tape (the Facit 4070 punch I use has a switch for this!), cut off a bit and stick that over the join using paper glue (a Prit Stick or equivalent works OK for splices that don't have to last too long) -tony
RE: papertape repair tape or kit wanted
On Nov 30, 2015 7:29 AM, "tony duell" wrote: > > > NOTE: I will pay a generous price for a few inches of papertape repair tape > > if anyone has any! I am located in Landenberg, PA USAContact me > > privately if you can help. > > The official splicing tape I've seen is in little squares with all holes punched > (probably covers 9 or 10 characters on the tape. I may still have some > somewhere, but it was trasparent tape so the crack between the ends of the > 2 bits of paper tape you were joining would confuse most optical treaders. > > In the end I would run out a bit of all-holes tape (the Facit 4070 punch I use > has a switch for this!), cut off a bit and stick that over the join using paper > glue (a Prit Stick or equivalent works OK for splices that don't have to last > too long) > > -tony Tony/all, Yes, the little squares were what I have used before, they're pre-holed to make it easy to realign overtop. That si what I am looking to source, ideally comercially-produced if they exist. ASR 33 use. I'd be happy with a small qty if anyone has these for sale or trade. Maybe I will ask green keys list, just thought of that, doh! Someone there might be able to help. Regarding the tape in question I do have a previously-punched backup tape for "everyday" use, I do not plan to actually use the ripped original unless there is no other choice. I just want to repair it for archival purposes. Thanks Bill
Re: papertape repair tape or kit wanted
Hi Tony Did you say Data Dynamics? I certainly knew them. I used to sell them LA36 print mechs. It was run by two old guys called Tindale and Stabler. The factory was in Hayes and I used to drive there from the DEC office in Ealing via Bombay (sorry I mean Southall). Their stuff was very nice and the factory was always very tidy. Their KSR using the LA36 print mechanics and fitted with a reader/punch was really smooth in operation. Now that would really be a find. Rod Smallwood On 30/11/2015 12:22, tony duell wrote: punches and two keyboardless golfball typewriters. I have forgotten exactly what types they were. I think the punch said something like BPRE on it and the readers did not match the rest of the system being Probably BRPE (normally pronounced 'Burpee') which is a high speed (something like 110 characters/second) paper tape punch from Teletype. IIRC the Teletype ones were in a grey all-metal cabinet with a lift-up lid. There was also a Data Dynamics version in a cabinet with a smoked perspex door and with a couple of pygmy light bulbs under the chad box to illuminate the front. That looks pretty but doesn't change the perfomance... -tony
Re: "Bounce buffer" copyright [was Re: flash (or ide) storage for unibus 11?]
I wrote an interleave formatter for a friend to use on his H89. He had an enormous data file that took for ever to read in BASIC. He couldn't believe it could be made to work so much faster. Dwight From: cctalk on behalf of Chuck Guzis Sent: Sunday, November 29, 2015 1:56 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: "Bounce buffer" copyright [was Re: flash (or ide) storage for unibus 11?] There were a few systems (such as CP/M) that optimized (or attempted to) interleave depending on use. So, "boot" tracks were 1:1, "directory" may have been 2:1 and user data 3:1. Schemes varied widely. One or two even interleaved side-to-side in addition to "skewing track-to-track. Obviously written by a programmer tasked with the job of "Let's see how fast we can get data on or off this thing". --Chuck
Re: A stored collection piece is a Schrodinger's cat
On 28 November 2015 at 11:58, Adrian Graham wrote: > That's what I've been doing for the last 2 months, all centred around fixing > a PET4032. Is Sir aware of Tynemouth Software? http://blog.tynemouthsoftware.co.uk/2015/09/commodore-pet-8032-repair-overclocked-to-death.html http://blog.tynemouthsoftware.co.uk/2015/05/commodore-pet-romram-replacement-boards.html -- Liam Proven • Profile: http://lproven.livejournal.com/profile Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)
Re: A stored collection piece is a Schrodinger's cat
Wonderful fun...Note you need an arrow to the mental institution someplace, especially if you are trying to load programs from Teletype. -- Bill
RE: papertape repair tape or kit wanted
> Hi Tony > Did you say Data Dynamics? I certainly knew them. I used > to sell them LA36 print mechs. Yes, almost certainly the same company. They sold several teleprinters based on the Teletype Model 33. Same mechanics, but IMHO a nicer (all metal) case and different electronics. I have one which is a normal ASR33 typing unit, keyboard, and reader but in a case with bulbs to illuminate the printout and electronics to give both RS232 and current loop interfaces and a single-step button for the reader. > It was run by two old guys called Tindale and Stabler. The factory was > in Hayes and I used to drive > there from the DEC office in Ealing via Bombay (sorry I mean Southall). Ah, that Hayes, not the one just down the road from me across Keston Common. -tony
Re: A stored collection piece is a Schrodinger's cat
On 30/11/2015 16:14, "Liam Proven" wrote: > On 28 November 2015 at 11:58, Adrian Graham > wrote: >> That's what I've been doing for the last 2 months, all centred around fixing >> a PET4032. > > > Is Sir aware of Tynemouth Software? > All of this fixing I'm currently doing is all Dave's fault, so yes :) -- Adrian/Witchy Binary Dinosaurs creator/curator Www.binarydinosaurs.co.uk - the UK's biggest private home computer collection?
PDP 8 Timesharing
Hi, all, Just figured I'd post something about my tinkering yesterday. I got an M8830 from Paul Anderson. This is the crystal-contolled clock for the Omnibus PDP 8 machines. Yesterday, I had a chance to try it out. First, I checked the power supply pins to make sure no shorts or anything like that and all was good. A quick visual inspection showed no obvious issues. It was already jumpered for a 50Hz interrupt rate, so I went ahead and plugged it into the backplane. Powered the 8/e system up, and ran a few tests from the front panel to make sure the board was responding to its IOTs, and all seemed well. Booted up OS8 from RK05, and mounted up the multos8.rk05 drive via the serialdisk driver. Copied the MULTOS8 .SV files onto my SYS: volume, and although not configured exactly for my system, I figured they'd be close enough. I then stopped the serial disk server, and fired up Kermit on the laptop connected to the second serial port on the 8/e. Then, I typed R MULTOS on the console, and it said something to the effect that I needed to set the date first. I generally don't bother setting the date at boot time, so I set the date to a valid date, and tried again. This time it gave a welcome message. I checked the accumulator, and it was counting off time as it should. I checked the MQ register, and it was static, but then waited for the accumulator to overflow, and then the MQ incremented by 1, as it should. I pressed CONTROL-H on the console terminal and hit RETURN, and there was the . OS8 prompt! I went to the laptop connected to the other serial interface, and since there was no MULTOS 8 password file on the SYS: device, typed CONTROL-H there, got the login prompt, hit RETURN, and low and behold, another . prompt. I played around with it for a while, and found that because of some of the config differences in how MULTOS8 was built on the pack image, some things were acting strange but in general, it definitely was timesharing between the two users. I could run concurrent things on both terminals, and the response was quite acceptable. I intend to make a build of MULTOS 8 to match my system's configuration, and tinker with it some more when I get time. Next I want to replicate the ETOS Timeshare Board (thanks to Vince and Jack for reverse-engineering the board and making a nice schematic!) I'm accumulating parts to build one on an Omnibus prototype board. Once I get that built, then it'll be time to try out ETOS, which uses the improvements in trapping IOTs and dealing with field change instructions that really improve timesharing performance over MULTOS 8. I am also in the process of getting ready to image some old RK05 packs that belong to Paul Anderson that may hold some interesting ETOS stuff. The packs have been sitting around for quite a long time, and the platters are very dusty. They are going to require some good cleaning before they can be put in a drive, but hopefully, once I get them cleaned up, I'll find some good things relating to ETOS. I'll post updates here with my progress. -Rick -- Rick Bensene The Old Calculator Museum http://oldcalculatormuseum.com
RE: PDP 8 Timesharing
FYI - in the not too distant future I'm going to get back to my 8E rig. I'll be pulling out the TU10/TM11(unused, obviously) from the second cabinet and putting in an RX01 and RK05, and hopefully connecting up the TU56 and PC04 that are in the main cabinet. In any case, my goal is to run ETOS on the thing - so I too am closely following the progress of the group that is working to replicate the hardware board for it. J
Re: PDP 8 Timesharing
when I was young in the computer biz wanted to build a timeshare 8 system.. however ended up going down the HP route instead for the rest of my career . There was also something called TSS-8 as I remember. Ed# _www.smecc.org_ (http://www.smecc.org) In a message dated 11/30/2015 11:34:49 A.M. US Mountain Standard Tim, jw...@classiccmp.org writes: FYI - in the not too distant future I'm going to get back to my 8E rig. I'll be pulling out the TU10/TM11(unused, obviously) from the second cabinet and putting in an RX01 and RK05, and hopefully connecting up the TU56 and PC04 that are in the main cabinet. In any case, my goal is to run ETOS on the thing - so I too am closely following the progress of the group that is working to replicate the hardware board for it. J
RE: PDP 8 Timesharing
Ed wrote: > when I was young in the computer biz wanted to build a timeshare 8 > system.. > however ended up going down the HP route instead for the rest of my > career . > There was also something called TSS-8 as I remember. Ed# I'd *LOVE* to be able to have a real-hardware HP Timeshared BASIC system running here, but alas, those are a lot harder to come by than DEC stuff. I do have a 2000/Access system running under SimH hooked directly to an ASR-33, which emulates the experience relatively closely, but there's nothing like the real hardware. I cut my teeth learning programming on the HP Timeshared BASIC systems starting in 6th grade under the 2000C version. TSS-8 was indeed a timeshare system for the PDP 8, but it was written to run on DECs earlier fixed-head disk drives that are hard to come about today (compared to RK05's). I've heard that someone had made changes to TSS-8 to get it to run on an RK05, but the fact that it's a moving head disk drive versus a fixed head drive that TSS-8 was designed to run under, the poor RK05 gets thrashed pretty hard when timesharing. There are also the Edusystem timeshared systems that DEC developed for the PDP 8, but I haven't looked too deeply into these yet. -Rick
RE: PDP 8 Timesharing
Ed wrote... --- when I was young in the computer biz wanted to build a timeshare 8 system.. however ended up going down the HP route instead for the rest of my career . --- You chose the better path for a timesharing system *ducks & runs* J
RE: PDP 8 Timesharing
Rick wrote --- I'd *LOVE* to be able to have a real-hardware HP Timeshared BASIC system running here, but alas, those are a lot harder to come by than DEC stuff --- Contact me off-list :) J
Re: PDP 8 Timesharing
somewhere i have an edu system book. HA! yea the fixed head drives made better swapping media! for tss 8 as core was small in those days! In a message dated 11/30/2015 12:03:12 P.M. US Mountain Standard Tim, ri...@bensene.com writes: Ed wrote: > when I was young in the computer biz wanted to build a timeshare 8 > system.. > however ended up going down the HP route instead for the rest of my > career . > There was also something called TSS-8 as I remember. Ed# I'd *LOVE* to be able to have a real-hardware HP Timeshared BASIC system running here, but alas, those are a lot harder to come by than DEC stuff. I do have a 2000/Access system running under SimH hooked directly to an ASR-33, which emulates the experience relatively closely, but there's nothing like the real hardware. I cut my teeth learning programming on the HP Timeshared BASIC systems starting in 6th grade under the 2000C version. TSS-8 was indeed a timeshare system for the PDP 8, but it was written to run on DECs earlier fixed-head disk drives that are hard to come about today (compared to RK05's).I've heard that someone had made changes to TSS-8 to get it to run on an RK05, but the fact that it's a moving head disk drive versus a fixed head drive that TSS-8 was designed to run under, the poor RK05 gets thrashed pretty hard when timesharing. There are also the Edusystem timeshared systems that DEC developed for the PDP 8, but I haven't looked too deeply into these yet. -Rick
Re: PDP 8 Timesharing
On 2015-11-30 19:26, Rick Bensene wrote: Hi, all, Just figured I'd post something about my tinkering yesterday. I got an M8830 from Paul Anderson. This is the crystal-contolled clock for the Omnibus PDP 8 machines. Yesterday, I had a chance to try it out. First, I checked the power supply pins to make sure no shorts or anything like that and all was good. A quick visual inspection showed no obvious issues. It was already jumpered for a 50Hz interrupt rate, so I went ahead and plugged it into the backplane. Powered the 8/e system up, and ran a few tests from the front panel to make sure the board was responding to its IOTs, and all seemed well. Booted up OS8 from RK05, and mounted up the multos8.rk05 drive via the serialdisk driver. Copied the MULTOS8 .SV files onto my SYS: volume, and although not configured exactly for my system, I figured they'd be close enough. I then stopped the serial disk server, and fired up Kermit on the laptop connected to the second serial port on the 8/e. Then, I typed R MULTOS on the console, and it said something to the effect that I needed to set the date first. I generally don't bother setting the date at boot time, so I set the date to a valid date, and tried again. This time it gave a welcome message. I checked the accumulator, and it was counting off time as it should. I checked the MQ register, and it was static, but then waited for the accumulator to overflow, and then the MQ incremented by 1, as it should. I pressed CONTROL-H on the console terminal and hit RETURN, and there was the . OS8 prompt! I went to the laptop connected to the other serial interface, and since there was no MULTOS 8 password file on the SYS: device, typed CONTROL-H there, got the login prompt, hit RETURN, and low and behold, another . prompt. I played around with it for a while, and found that because of some of the config differences in how MULTOS8 was built on the pack image, some things were acting strange but in general, it definitely was timesharing between the two users. I could run concurrent things on both terminals, and the response was quite acceptable. I intend to make a build of MULTOS 8 to match my system's configuration, and tinker with it some more when I get time. Next I want to replicate the ETOS Timeshare Board (thanks to Vince and Jack for reverse-engineering the board and making a nice schematic!) I'm accumulating parts to build one on an Omnibus prototype board. Once I get that built, then it'll be time to try out ETOS, which uses the improvements in trapping IOTs and dealing with field change instructions that really improve timesharing performance over MULTOS 8. Fun stuff. However, I do not expect you'll see much impovement in performance in ETOS compared to MULTOS. You'll gain if you have code that do CIF n, followed by much code before the JMP/JMS, but that is not exactly a common pattern in most PDP-8 code. Also, MULTOS do some clever stuff. It actually will modify in memory code that do polled loops for example, to not do those. Unless ETOS do the same, that might actually hurt ETOS more. Also, MULTOS is the only timesharing system I know that actually also handles the TD8E controller, if you happen to have one of those. I only wish I knew where I have version 2 of MULTOS. I uploaded version 1 a long time ago, but only at a later date realized that it wasn't the latest version. I *think* I should have version 2 somewhere as well, but my memory might be wrong also. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Apple II+ repair details
Speaking of Schrodinger's feline, here are details of my recent Apple II+ repair for those who might be interested: http://www.classic-computers.org.nz/blog/2015-11-29-more-repairs-to-my-appleII+.htm Terry (Tez)
RE: PDP 8 Timesharing
Johnny wrote... Fun stuff. However, I do not expect you'll see much impovement in performance in ETOS compared to MULTOS. You'll gain if you have code that do CIF n, followed by much code before the JMP/JMS, but that is not exactly a common pattern in most PDP-8 code. Also, MULTOS do some clever stuff. It actually will modify in memory code that do polled loops for example, to not do those. Unless ETOS do the same, that might actually hurt ETOS more. Also, MULTOS is the only timesharing system I know that actually also handles the TD8E controller, if you happen to have one of those. I only wish I knew where I have version 2 of MULTOS. I uploaded version 1 a long time ago, but only at a later date realized that it wasn't the latest version. I *think* I should have version 2 somewhere as well, but my memory might be wrong also. - I would love to see some comparison between ETOS and MULTOS by anyone "in the know". I'd just like a nice timeshareing system for my 8E that is close to OS/8 and runnable with the hardware I have. Alternatively, TSS looks nice, but I am not sure that the full OS was ever found and is available? Hardware Reqs? J
Re: Apple II+ repair details
On 11/30/2015 02:18 PM, Terry Stewart wrote: Speaking of Schrodinger's feline, here are details of my recent Apple II+ repair for those who might be interested: http://www.classic-computers.org.nz/blog/2015-11-29-more-repairs-to-my-appleII+.htm Nice! My II+ needs a new escape keyswitch, keycap and encoder IC, just in case anyone reading this ever happens to be parting out a US-spec system (I'm guessing that a Europlus or J-plus encoder is very slightly different. Was also led to believe that there are a couple of different keycap styles for US-spec systems). The keycap's probably the critical thing - I think there may be other sources for the switches (at least there were until a few years ago), and I suppose that a PIC-based approach via a small plug-in carrier board would be an option for the encoder if needed, although it would be nice to keep the machine original if possible. cheers Jules
Re: Sector Interleave (Was: "Bounce buffer" copyright [was Re: flash
On Mon, 30 Nov 2015, dwight wrote:
I wrote an interleave formatter for a friend to use on his H89.
He had an enormous data file that took for ever to read in BASIC.
He couldn't believe it could be made to work so much faster.
Oversimplified remedial tutorial:
Ideally, the system reads a sector, does what it has to do with the
content, and goes back for the next one, and can read every sector of the
track in a single revolution.
But, if the system can't finish with a sector in time for the next sector,
then it's going to have to wait a full revolution of the disk, which would
be the worst condition. With 10 sectors per track, we are looking at a
simple file read taking 10 times as long. Well, OK, the system could take
hours to process the data from the sector, so there is no maximum possible
slowness. Maybe Microsoft knows what the maximum slowest is.
Most "modern" systems can keep up with simple numeric sequence, although
some software can slow things down enough to bring the problem back.
If it is just barely too slow to get the next sector in sequence, then a
simple rearrangement of the sectors on the disk could solve it.
Something as simple as arranging the sectors such as 1,6,2,7,3,8,4,9,5
The rest of the software doesn't even need to know about it. It still
asks for sector 1, then asks for sector 2, etc.
If that's still not enough, it can go something such as 1,4,7,2,5,8,3,6,9
1,3,5,7,9,2,4,6,8 etc.
Obviously, simply loading the content of a file into memory can be done
quicker than if some software is trying to process the incoming data.
Some of us have been crazy enough to use disks with different sector
sequences for data files of different programs (WORDSTAR V WEIRD
V WORDPERVERT V SUPERCALC, etc.)
In addition, depending on how long the drive takes to move to the next
track, you might need more time before reading the first sector of the
next track. So, in some cases, it may be more efficient to have the first
sector of the next track not be the first physical sector on that track.
The sectors of that track could be in the same pattern, but simply
starting at a different point in the cycle.
A computer system that rearranges sectors on the track can normally manage
OK with a disk formatted on a different system with a different physical
sequence. If you are writing a program to FORMAT disks for a machine, the
sector sequence will not necessarily matter, although it could result in
slower access.
When looking at an unfamiliar disk format, if the sectors are not in
sequential order, then it usually means that the OS uses them in numeric
order, but that the arrangement is out of numeric order for efficiency.
Sector sequence can also be done in software. With the physical sectors
still arranged sequentially and consecutively, the OS could decide that
the first "logical" sector(s) are in sector 1, and the next logical
sector(s) are in sector 3, etc.("deblocking")
If the sectors of an unknown disk are in numeric order, it could mean that
1) the system was efficient enough to handle consecutive sectors
2) the designer didn't care about that level of efficiency
3) the OS is not using the sectors in numeric order.
In that case, it calls for examining the content of sectors, looking for
information flow. If you encounter the first part of a word of text at
the end of one sector ("half a worm in the apple"), and the rest of the
word at the beginning of another sector, that helps determine the sector
sequence. If you aren't lucky enough to have text files in a language
that you can follow, look for source files (such as DUMP.ASM), and machine
language of processors that you can follow.
Tracks where some sectors have been over-written with other content can
make it more confusing to determine the sequence.
It is USUALLY the same on every track, but there are rare exceptions.
And different disk formats from the same manufacturer may be different.
Physical format may be different on boot or system tracks than on the
rest of the disk. Other than sector numbers the physical format is
usually the same on both sides of a DS disk. When you encounter one that
is not, it is likely to be a DS disk that has been reformatted to use on a
SS machine, such as re-using a PC disk for an Osborne.
--
Grumpy Ol' Fred ci...@xenosoft.com
Re: PDP 8 Timesharing
On 2015-11-30 21:34, Jay West wrote: Johnny wrote... Fun stuff. However, I do not expect you'll see much impovement in performance in ETOS compared to MULTOS. You'll gain if you have code that do CIF n, followed by much code before the JMP/JMS, but that is not exactly a common pattern in most PDP-8 code. Also, MULTOS do some clever stuff. It actually will modify in memory code that do polled loops for example, to not do those. Unless ETOS do the same, that might actually hurt ETOS more. Also, MULTOS is the only timesharing system I know that actually also handles the TD8E controller, if you happen to have one of those. I only wish I knew where I have version 2 of MULTOS. I uploaded version 1 a long time ago, but only at a later date realized that it wasn't the latest version. I *think* I should have version 2 somewhere as well, but my memory might be wrong also. - I would love to see some comparison between ETOS and MULTOS by anyone "in the know". I'd just like a nice timeshareing system for my 8E that is close to OS/8 and runnable with the hardware I have. Well, if you have a 8E with a clock, and you run OS/8, then you can run MULTOS. Then you need (of course) serial lines... MULTOS is like running OS/8, and most of the time you'll not even notice the difference, except you have to log in, and you might notice the "strange" device name on your system. Pretty much all OS/8 software runs just fine under MULTOS, and most of the time at about the same speed. Of course, it do depend on system load. But most systems are sitting idle most of the time anyway... :-) Programs that do direct I/O to strange devices will not work, though. Nor will general interrupt-driven code. FRTS do work, however. And you can write programs that use MULTOS specific features. Alternatively, TSS looks nice, but I am not sure that the full OS was ever found and is available? Hardware Reqs? TSS8 is a different beast. It's not related to OS/8, so you'll have to adopt to a different environment, and each job only have 4K to play in. And, as others mentioned, not sure if it works on an RK8E. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: PDP 8 Timesharing
On Mon, Nov 30, 2015 at 11:05 AM, Jay West wrote: > Rick wrote > --- > I'd *LOVE* to be able to have a real-hardware HP Timeshared BASIC system > running here, but alas, those are a lot harder to come by than DEC stuff > --- > Contact me off-list :) > > J If you have a 2113B and a 2117F could you use those as a base? What are the magic parts? Some special and rare interconnect boards? And a special and rare async mux? And particular disc requirements?
Re: Sector Interleave
> On Nov 30, 2015, at 3:45 PM, Fred Cisin wrote:
>
> Oversimplified remedial tutorial:
> Ideally, the system reads a sector, does what it has to do with the content,
> and goes back for the next one, and can read every sector of the track in a
> single revolution.
> ...
> It is USUALLY the same on every track, but there are rare exceptions. And
> different disk formats from the same manufacturer may be different.
Your writeup was aimed at floppy disks, but interleave may also appear on hard
drives. I don't remember it in reasonably modern systems, but it shows up on
CDC 6000 systems. There the same drive model may be either interleaved ("2:1
interleave") or not ("1:1 interleave" [sic]) depending on the CPU. The
original 6000 series CPUs (or more precisely, their PPUs and I/O channels) are
too slow for non-interleaved transfer with the stock CDC drivers, so
interleaving is used. The 170 series have PPUs and channels that go twice as
fast, so they can handle non-interleaved transfers without losing revolutions.
And clever programming such as used in PLATO enables non-interleaved access
even on the 6000 series.
Use of interleaving when not needed comes with a 2x performance penalty, which
is why PLATO did a bunch of magic to avoid using it.
paul
Re: PDP 8 Timesharing
Jay - yes I know and for hardware sales too. as I sold and troubleshot what I used and needed all the time in house so it was a perfect match. eventually the only DEC stuff that was there was in museum displays in the other suite the museum occupied. Ed# In a message dated 11/30/2015 11:58:08 A.M. US Mountain Standard Tim, jw...@classiccmp.org writes: Ed wrote... --- when I was young in the computer biz wanted to build a timeshare 8 system.. however ended up going down the HP route instead for the rest of my career . --- You chose the better path for a timesharing system *ducks & runs* J
RE: PDP 8 Timesharing
Glen wrote... -- If you have a 2113B and a 2117F could you use those as a base? What are the magic parts? Some special and rare interconnect boards? And a special and rare async mux? And particular disc requirements? -- 2113/2117 - yes. Off the top of my head For 2000E, you can get by with a single cpu, paper tape reader, and 7900 disc drive (non HPIB). That's the smallest config likely to be runnable by folks (unless you happen to have a drum unit or fixed head disc for prior versions). And the mux set below For Access (by far the best version), of course two cpus, mag tape (non-HPIB), and disc (again, non-HPIB) are required. 32kw in the main cpu, from 16kw to 32kw in the IO cpu depending on sysgen choices. I believe one of the processors needs FPP, have to check that. But the magic bits... 1) You'd need the IOP microcode. This is downloadable from bitsavers for 21MX/E and you can burn them. I can get people burned chips if they wish. For the M series, you need the microcode AND a daughterboard to put them in :) For the 2100, I have the microcode - and I'm not aware that those are available anywhere else. In most - possibly all - situations the iop firmware must be on a fab (E/F). Trying to put it in a FEM may (have to check, I think it will) cause issues with hard coded slot assignments in the IOP. 2) You'd need the processor interconnect kit. Basically this is 4 (two per cpu) 12566 boards and you'd have to build or find the cables for them. 3) MOST difficult... you need the 12920A or 12920B mux set (3 board set). These are unobtainium. 4) If you want to enable the IBM MRJE facility, you'd need the sync modem (2 board set). Pretty rare... J
Re: Sector Interleave
- Original Message - From: "Paul Koning" Sent: Monday, November 30, 2015 3:55 PM > On Nov 30, 2015, at 3:45 PM, Fred Cisin wrote: > > Oversimplified remedial tutorial: > Ideally, the system reads a sector, does what it has to do with the content, > and goes back for the next one, and can read every sector of the track in a > single revolution. > ... > It is USUALLY the same on every track, but there are rare exceptions. And > different disk formats from the same manufacturer may be different. Your writeup was aimed at floppy disks, but interleave may also appear on hard drives. I don't remember it in reasonably modern systems, but it shows up on CDC 6000 systems. - Reply - Definitely an issue with IBM PC/XTs and clones; I recall testing every new combination of HD and controller for most efficient interleave before I delivered to the client. m
Re: Sector Interleave
Oversimplified remedial tutorial: Ideally, the system reads a sector, does what it has to do with the content, and goes back for the next one, and can read every sector of the track in a single revolution. From: "Paul Koning" Your writeup was aimed at floppy disks, but interleave may also appear on hard drives. I don't remember it in reasonably modern systems, but it shows up on CDC 6000 systems. On Mon, 30 Nov 2015, Mike Stein wrote: - Reply - Definitely an issue with IBM PC/XTs and clones; I recall testing every new combination of HD and controller for most efficient interleave before I delivered to the client. 1) Are there any examples newer than PC/XT 5160? Although, obviously, completely hidden from the user, is it still used on anything "modern"? (Should ALL verbs be changed to past tense?) 2) Is it used on anything besides spinning rust? 3) Besides all of my examples being floppy, what else should be changed/corrected in what I wrote?
Re: Sector Interleave
Nothing wrong with what you wrote that I can see; excellent tutorial IMO. m - Original Message - From: "Fred Cisin" To: "General Discussion: On-Topic and Off-Topic Posts" Sent: Monday, November 30, 2015 4:45 PM Subject: Re: Sector Interleave >>> Oversimplified remedial tutorial: >>> Ideally, the system reads a sector, does what it has to do with the >>> content, and goes back for the next one, and can read every sector of the >>> track in a single revolution. > > From: "Paul Koning" >> Your writeup was aimed at floppy disks, but interleave may also appear >> on hard drives. I don't remember it in reasonably modern systems, but >> it shows up on CDC 6000 systems. > > On Mon, 30 Nov 2015, Mike Stein wrote: >> - Reply - Definitely an issue with IBM PC/XTs and clones; I >> recall testing every new combination of HD and controller for most >> efficient interleave before I delivered to the client. > > 1) Are there any examples newer than PC/XT 5160? > > Although, obviously, completely hidden from the user, is it still used on > anything "modern"? > (Should ALL verbs be changed to past tense?) > > 2) Is it used on anything besides spinning rust? > > 3) Besides all of my examples being floppy, what else should be > changed/corrected in what I wrote? > >
Re: Apple II+ repair details
On 11/30/2015 12:18 PM, Terry Stewart wrote: Speaking of Schrodinger's feline, here are details of my recent Apple II+ repair for those who might be interested: http://www.classic-computers.org.nz/blog/2015-11-29-more-repairs-to-my-appleII+.htm Terry (Tez) Terry, nice dialog on your repair job. On the last comment about the ground pin of the defective rom having a signal, if the apple board is a 4 layer board the ripple from the short to the internal signals from address current, or other signal current being propagated to the ground pin, I suspect the resistance in the pin itself may have provided the needed high resistance to show the signal. Unless you scrap the ground solder protect off and look at the voltage out in the actual ground conductor, I suspect the voltage went down to a very low level very close to the pin. Also where were the decoupling capacitors located with respect to the pin. I suspect that might have gotten rid of more of the voltage, but they were probably nearer the Vcc end of the chip. If you can track down the schematic, it might be that your missing pin doesn't do much unless you perform some special operation, such as some controller addressing or memory operation or such that you don't normally do. It may have also had a fit to the other part of the pin if it was present in the socket to actually work. I didn't hear if you found that, or maybe it fell off when you pulled the chip out? I suspect the short developed from your theory about stress, or perhaps the chip was programmed by a bad programmer. We had a programmer that we found developed a tendency to program eproms and like programmable chips and it destroyed the chips capability to actually reach ground again. The programmer made chips that verified, but when you ran them in a circuit and probed the lines with some sync to the system clock, rather than seeing the signals on the data lines going to zero on the datalines, you could see a hodgpodge of crap at 1.5 to 3 volts which is TTL la-la land. The chips programmed in such a programmer as a properly working Data I/O had clean lines as did reference chips from years earlier. Due to the fact we didn't program many chips, and I found a cheap programmer to hook to a PC, we never found out what broke in our programmer (which was a home design admittedly). But it was build to standard, but had something happen to start killing eproms. So that sort of fault may have been induced in your chip and got bad enough to kill off your Apple some years later. thanks Jim
RE: PDP 8 Timesharing
From: Jay West Sent: Monday, November 30, 2015 12:34 PM > I would love to see some comparison between ETOS and MULTOS by anyone "in the > know". I'd just like a nice timeshareing system for my 8E that is close to > OS/8 and runnable with the hardware I have. > Alternatively, TSS looks nice, but I am not sure that the full OS was ever > found and is available? Hardware Reqs? There is a TSS/8 system in a .zip file on the SimH software distribution page, consisting of a text file, a paper tape image, and an RF08/RS08 disk image. It's been there since 2005 (an probably earlier, but that's the year on the timestamp). Minimum hardware requirements: PDP-8/I or PDP-8 with KT08/I Time-Sharing Modifications MC8/I-A Memory Extension Control and 4096 words RF08 Disk Control RS08 Disk PT08 Asynchronous Line Interface, Dual (4) PT8/I High-Speed Paper Tape Reader KE8/I Automatic Multiply-Divider CAB 8/IA Option Cabinet Hardware options: The system can have a maximum of 32K core memory. With a minimum of 12K, up to 3 DECdisks can be attached, as well as up to 8 DECtape drives for the use of private DECtape by users. The OS uses the word-addressed nature of the RF08 or DF32 disk drives, which also makes trying to substitute something like an RK05 difficult. I'm told by a former operator of one that TSS/8 will also run on an 8/e, but I don't have independent confirmation that that is so. Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:ri...@livingcomputermuseum.org http://www.LivingComputerMuseum.org/
Re: A stored collection piece is a Schrodinger's cat
On 30 November 2015 at 18:43, Adrian Graham wrote: > All of this fixing I'm currently doing is all Dave's fault, so yes :) [Actual LOL] -- Liam Proven • Profile: http://lproven.livejournal.com/profile Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)
Re: Sector Interleave
On Mon, Nov 30, 2015 at 1:45 PM, Fred Cisin wrote: > Oversimplified remedial tutorial: >>> Ideally, the system reads a sector, does what it has to do with the >>> content, and goes back for the next one, and can read every sector of the >>> track in a single revolution. >>> >> > From: "Paul Koning" > >> Your writeup was aimed at floppy disks, but interleave may also appear on >> hard drives. I don't remember it in reasonably modern systems, but it >> shows up on CDC 6000 systems. >> > > On Mon, 30 Nov 2015, Mike Stein wrote: > >> - Reply - Definitely an issue with IBM PC/XTs and clones; I >> recall testing every new combination of HD and controller for most >> efficient interleave before I delivered to the client. >> > > 1) Are there any examples newer than PC/XT 5160? > > Although, obviously, completely hidden from the user, is it still used on > anything "modern"? > (Should ALL verbs be changed to past tense?) > > 2) Is it used on anything besides spinning rust? > > Probably outside the domain of the question: The DPS8-M had configurable core memory bank interleave (even/odd addresses); I would hazard a guess that this improved bandwidth on double word read/writes. -- Charles
Re: Sector Interleave
On 11/30/2015 02:09 PM, Mike Stein wrote: Nothing wrong with what you wrote that I can see; excellent tutorial IMO. The issue of "floppy interleave" pretty much went away when memory got cheap enough to buffer an entire track, provided the controller is capable of 1:1 interleave transfers. An A-B comparison with interleaved vs. track buffering is quite enlightening. I don't think that any modern hard drives use interleaved transfer, but I'm not certain. Interleaving core accesses goes *way* back, as does using extra-wide multi-word-at-a-time transfers. Did the IBM 650 interleave drum sectors? --Chuck
Re: Sector Interleave
On Mon, Nov 30, 2015 at 3:13 PM, Chuck Guzis wrote: > On 11/30/2015 02:09 PM, Mike Stein wrote: > >> Nothing wrong with what you wrote that I can see; excellent tutorial >> IMO. >> > > The issue of "floppy interleave" pretty much went away when memory got > cheap enough to buffer an entire track, provided the controller is capable > of 1:1 interleave transfers. > > An A-B comparison with interleaved vs. track buffering is quite > enlightening. > > I don't think that any modern hard drives use interleaved transfer, but > I'm not certain. > > Interleaving core accesses goes *way* back, as does using extra-wide > multi-word-at-a-time transfers. > > Did the IBM 650 interleave drum sectors? > > One of the drum computers had the address of the next instruction as an operand of the instruction; the programmer would scatter the instructions according to the execution time of the instructions; IIRC "assembler" referred to the process of converting the sequential source to the scattered arrangement. -- Charles
Re: Apple II+ repair details
Thanks for those comments Jim, Yes, something to think about. Peter Coghlan dropped me a note privately, saying the signal of the F8 ROM could also be caused by the pin not connecting properly. The replacement ROM could have had been sufficiently different in that the legs were at a slightly different angle etc. This would also make sense, as I couldn't understand why their wasn't anything on the earth rail (and why the PSU didn't shut itself off). So, there could be a socket problem still lurking which may come back to haunt me later so I'll check it out at some stage (In fact, I might just replace the socket). I'll have to fish that F8 ROM out of the rubbish bin and try it in another working Apple board. I did put it back in the first board at the time just as a double check and got the same result as before so I concluded it was toast. Terry (Tez) On Tue, Dec 1, 2015 at 11:20 AM, jwsmobile wrote: > > On 11/30/2015 12:18 PM, Terry Stewart wrote: > >> Speaking of Schrodinger's feline, here are details of my recent Apple II+ >> repair for those who might be interested: >> >> http://www.classic-computers.org.nz/blog/2015-11-29-more-repairs-to-my-appleII+.htm >> >> Terry (Tez) >> > > Terry, > nice dialog on your repair job. > > On the last comment about the ground pin of the defective rom having a > signal, if the apple board is a 4 layer board the ripple from the short to > the internal signals from address current, or other signal current being > propagated to the ground pin, I suspect the resistance in the pin itself > may have provided the needed high resistance to show the signal. Unless > you scrap the ground solder protect off and look at the voltage out in the > actual ground conductor, I suspect the voltage went down to a very low > level very close to the pin. > > Also where were the decoupling capacitors located with respect to the > pin. I suspect that might have gotten rid of more of the voltage, but they > were probably nearer the Vcc end of the chip. > > If you can track down the schematic, it might be that your missing pin > doesn't do much unless you perform some special operation, such as some > controller addressing or memory operation or such that you don't normally > do. It may have also had a fit to the other part of the pin if it was > present in the socket to actually work. I didn't hear if you found that, > or maybe it fell off when you pulled the chip out? > > I suspect the short developed from your theory about stress, or perhaps > the chip was programmed by a bad programmer. We had a programmer that we > found developed a tendency to program eproms and like programmable chips > and it destroyed the chips capability to actually reach ground again. > > The programmer made chips that verified, but when you ran them in a > circuit and probed the lines with some sync to the system clock, rather > than seeing the signals on the data lines going to zero on the datalines, > you could see a hodgpodge of crap at 1.5 to 3 volts which is TTL la-la > land. The chips programmed in such a programmer as a properly working Data > I/O had clean lines as did reference chips from years earlier. > > Due to the fact we didn't program many chips, and I found a cheap > programmer to hook to a PC, we never found out what broke in our programmer > (which was a home design admittedly). But it was build to standard, but > had something happen to start killing eproms. So that sort of fault may > have been induced in your chip and got bad enough to kill off your Apple > some years later. > > thanks > Jim > >
Re: Sector Interleave
On 11/30/2015 03:17 PM, Charles Anthony wrote: One of the drum computers had the address of the next instruction as an operand of the instruction; the programmer would scatter the instructions according to the execution time of the instructions; IIRC "assembler" referred to the process of converting the sequential source to the scattered arrangement. I know about the one-plus-one addressing scheme used on the 650--and the SOAP assembler, for that matter. What I was wondering was if the attached RAMAC (305?) used it. Perhaps I should have been more explicit. --Chuck
Re: PDP 8 Timesharing
On 11/30/15 2:20 PM, Rich Alderson wrote: I'm told by a former operator of one that TSS/8 will also run on an 8/e, but I don't have independent confirmation that that is so. It did. The University of Wisconsin - Milwaukee's system was an 8/e with custom mods that let you store files on an RK05 drive. Some of the sources for that system and the source for TSS/8 BASIC are on bitsavers.
Re: Apple II+ repair details
>Peter Coghlan dropped me a note privately, saying the signal of the F8 ROM could also be caused by the pin not connecting properly. The replacement ROM could have had been sufficiently >different in that the legs were at a slightly different angle etc. This would also make sense, as I couldn't understand why their wasn't anything on the earth rail (and why the PSU didn't shut >itself off). Incidentally, I did check when the machine was off to see if that F8 earth pin did connect to ground. It appeared to, but then I was putting some pressure on the pin when I was taking the measurement. It might have been enough to force a connection in the socket. Terry (Tez) On Tue, Dec 1, 2015 at 12:22 PM, Terry Stewart wrote: > Thanks for those comments Jim, Yes, something to think about. > > Peter Coghlan dropped me a note privately, saying the signal of the F8 ROM > could also be caused by the pin not connecting properly. The replacement > ROM could have had been sufficiently different in that the legs were at a > slightly different angle etc. This would also make sense, as I couldn't > understand why their wasn't anything on the earth rail (and why the PSU > didn't shut itself off). > > So, there could be a socket problem still lurking which may come back to > haunt me later so I'll check it out at some stage (In fact, I might just > replace the socket). I'll have to fish that F8 ROM out of the rubbish bin > and try it in another working Apple board. I did put it back in the first > board at the time just as a double check and got the same result as before > so I concluded it was toast. > > Terry (Tez) > > > On Tue, Dec 1, 2015 at 11:20 AM, jwsmobile wrote: > >> >> On 11/30/2015 12:18 PM, Terry Stewart wrote: >> >>> Speaking of Schrodinger's feline, here are details of my recent Apple II+ >>> repair for those who might be interested: >>> >>> http://www.classic-computers.org.nz/blog/2015-11-29-more-repairs-to-my-appleII+.htm >>> >>> Terry (Tez) >>> >> >> Terry, >> nice dialog on your repair job. >> >> On the last comment about the ground pin of the defective rom having a >> signal, if the apple board is a 4 layer board the ripple from the short to >> the internal signals from address current, or other signal current being >> propagated to the ground pin, I suspect the resistance in the pin itself >> may have provided the needed high resistance to show the signal. Unless >> you scrap the ground solder protect off and look at the voltage out in the >> actual ground conductor, I suspect the voltage went down to a very low >> level very close to the pin. >> >> Also where were the decoupling capacitors located with respect to the >> pin. I suspect that might have gotten rid of more of the voltage, but they >> were probably nearer the Vcc end of the chip. >> >> If you can track down the schematic, it might be that your missing pin >> doesn't do much unless you perform some special operation, such as some >> controller addressing or memory operation or such that you don't normally >> do. It may have also had a fit to the other part of the pin if it was >> present in the socket to actually work. I didn't hear if you found that, >> or maybe it fell off when you pulled the chip out? >> >> I suspect the short developed from your theory about stress, or perhaps >> the chip was programmed by a bad programmer. We had a programmer that we >> found developed a tendency to program eproms and like programmable chips >> and it destroyed the chips capability to actually reach ground again. >> >> The programmer made chips that verified, but when you ran them in a >> circuit and probed the lines with some sync to the system clock, rather >> than seeing the signals on the data lines going to zero on the datalines, >> you could see a hodgpodge of crap at 1.5 to 3 volts which is TTL la-la >> land. The chips programmed in such a programmer as a properly working Data >> I/O had clean lines as did reference chips from years earlier. >> >> Due to the fact we didn't program many chips, and I found a cheap >> programmer to hook to a PC, we never found out what broke in our programmer >> (which was a home design admittedly). But it was build to standard, but >> had something happen to start killing eproms. So that sort of fault may >> have been induced in your chip and got bad enough to kill off your Apple >> some years later. >> >> thanks >> Jim >> >> >
Re: A stored collection piece is a Schrodinger's cat
On 30/11/2015 22:30, "Liam Proven" wrote: > On 30 November 2015 at 18:43, Adrian Graham > wrote: >> All of this fixing I'm currently doing is all Dave's fault, so yes :) > > > [Actual LOL] When I say 'his fault' I mean his blog has inspired me to get down and dirty with all the dead PETs I appear to have accumulated over the years. The ROM/RAM replacement board he sells is an excellent 40 pin toolkit to help tracing faults in the vast majority of PETs so with the help of Dave and the good folk here I've got life back into my most dead 4032. It's also meant I've read a lot of datasheets to understand various chip behaviours and now I realise why the teachers at school in the late 70s wouldn't let me take electronics back then since I wasn't too hot at maths... -- Adrian/Witchy Binary Dinosaurs creator/curator Www.binarydinosaurs.co.uk - the UK's biggest private home computer collection?
Re: papertape repair tape or kit wanted
On 29/11/15 03:19, Mark J. Blair wrote: I found mine on eBay, probably around a year ago. I searched for a long time before I found it. Another hen's tooth that I would like to find is a magtape end clipper/crimper, but I'm even less likely to find one since I'm taking an eBay vacation. Good luck! I have a DEC 9-track tape crimper (part # 47-00038). There's one apparently on ebay now for $3.99 which sounds like a steal as the next hit is a website offering one for the low, low price of $126.97. -- Antonio Carlini arcarl...@iee.org
Re: Sector Interleave
> On Nov 30, 2015, at 4:45 PM, Fred Cisin wrote: > >>> Oversimplified remedial tutorial: >>> Ideally, the system reads a sector, does what it has to do with the >>> content, and goes back for the next one, and can read every sector of the >>> track in a single revolution. > > From: "Paul Koning" >> Your writeup was aimed at floppy disks, but interleave may also appear on >> hard drives. I don't remember it in reasonably modern systems, but it shows >> up on CDC 6000 systems. > > On Mon, 30 Nov 2015, Mike Stein wrote: >> - Reply - Definitely an issue with IBM PC/XTs and clones; I recall >> testing every new combination of HD and controller for most efficient >> interleave before I delivered to the client. > > 1) Are there any examples newer than PC/XT 5160? > > Although, obviously, completely hidden from the user, is it still used on > anything "modern"? > (Should ALL verbs be changed to past tense?) > > 2) Is it used on anything besides spinning rust? Not that I know of. I remember using interleave on SAN systems with (S)ATA drives, back around 2002-2004 or so when ATA and/or SATA did not yet support command queueing. So you could only issue one command per drive, then in the interrupt handler you'd have to handle the completion and issue the next. It turns out you could not do that without interleave, or something analogous. For example, you can leave the sector addressing unchanged but break transfers up into sectors, and issue them in interleaved order. Similarly, when sorting commands offered by applications, you can order them in this manner for the subset of commands for a given track. > 3) Besides all of my examples being floppy, what else should be > changed/corrected in what I wrote? The only thing I would change is to mention that this is/was found on hard drives also. paul
Re: PDP 8 Timesharing
On 11/30/15 3:34 PM, Jay West wrote: Alternatively, TSS looks nice, but I am not sure that the full OS was ever found and is available? Hardware Reqs? It's been found. http://www.heeltoe.com/index.php?n=Cpus.Pdp8Tss-8 The core o/s can be rebuilt from scratch and run in several forms. I did a (very simple) implementation of the PDP-8/I and the required mods to make it work on an FPGA. It's possible to emulate the behavior of the fixed head disks using an IDE and buffers. I had the pleasure of seeing it run live, many years ago in my misguided youth. I used it a lot and learned a lot from it. Gotta love all the blinking lights. It's an interesting study in both virtualization and operating systems. Well worth the time, IMHO. The UW version builds, but it requires rebuilt binaries of the basic apps. I don't think we've ever recovered all the sources to the userland components, so I could never create a working UW file system. Some day. But yes, TSS/8 exists and can be built and run. -brad
Re: Sector Interleave
On Nov 30, 2015, at 6:35 PM, Paul Koning wrote: > > >> On Nov 30, 2015, at 4:45 PM, Fred Cisin wrote: >> Oversimplified remedial tutorial: Ideally, the system reads a sector, does what it has to do with the content, and goes back for the next one, and can read every sector of the track in a single revolution. >> >> From: "Paul Koning" >>> Your writeup was aimed at floppy disks, but interleave may also appear on >>> hard drives. I don't remember it in reasonably modern systems, but it >>> shows up on CDC 6000 systems. >> >> On Mon, 30 Nov 2015, Mike Stein wrote: >>> - Reply - Definitely an issue with IBM PC/XTs and clones; I recall >>> testing every new combination of HD and controller for most efficient >>> interleave before I delivered to the client. >> >> 1) Are there any examples newer than PC/XT 5160? >> >> Although, obviously, completely hidden from the user, is it still used on >> anything "modern"? >> (Should ALL verbs be changed to past tense?) >> >> 2) Is it used on anything besides spinning rust? > > Not that I know of. > > I remember using interleave on SAN systems with (S)ATA drives, back around > 2002-2004 or so when ATA and/or SATA did not yet support command queueing. > So you could only issue one command per drive, then in the interrupt handler > you'd have to handle the completion and issue the next. It turns out you > could not do that without interleave, or something analogous. For example, > you can leave the sector addressing unchanged but break transfers up into > sectors, and issue them in interleaved order. Similarly, when sorting > commands offered by applications, you can order them in this manner for the > subset of commands for a given track. > >> 3) Besides all of my examples being floppy, what else should be >> changed/corrected in what I wrote? > > The only thing I would change is to mention that this is/was found on hard > drives also. > > paul > The TU58 was a block addressable using a cassette tape drive famously(?) called DECtape II. File placement on the two different linear tracks was a necessary art, especially if you were booting RT11 regularly. This helped it to stream or not rewind in sensitive places. The 1:2 interleave was “built-in” to the block formatting (see EK-0TU58-UG-001_TU58_DECtape_II_Users_Guide_Oct78.pdf). I used a late model device, pulling data from clinical diagnostic computers without too many challenges. However, compared to reliability of DECtape*, DECtape iI was not in the same class IMHO. Jerry *Yes - I skipped over DECtape. I’ve leave that one to the many experts on the list.
Re: Sector Interleave
On 2015-12-01 02:06, Jerry Weiss wrote: On Nov 30, 2015, at 6:35 PM, Paul Koning wrote: On Nov 30, 2015, at 4:45 PM, Fred Cisin wrote: Oversimplified remedial tutorial: Ideally, the system reads a sector, does what it has to do with the content, and goes back for the next one, and can read every sector of the track in a single revolution. From: "Paul Koning" Your writeup was aimed at floppy disks, but interleave may also appear on hard drives. I don't remember it in reasonably modern systems, but it shows up on CDC 6000 systems. On Mon, 30 Nov 2015, Mike Stein wrote: - Reply - Definitely an issue with IBM PC/XTs and clones; I recall testing every new combination of HD and controller for most efficient interleave before I delivered to the client. 1) Are there any examples newer than PC/XT 5160? Although, obviously, completely hidden from the user, is it still used on anything "modern"? (Should ALL verbs be changed to past tense?) 2) Is it used on anything besides spinning rust? Not that I know of. I remember using interleave on SAN systems with (S)ATA drives, back around 2002-2004 or so when ATA and/or SATA did not yet support command queueing. So you could only issue one command per drive, then in the interrupt handler you'd have to handle the completion and issue the next. It turns out you could not do that without interleave, or something analogous. For example, you can leave the sector addressing unchanged but break transfers up into sectors, and issue them in interleaved order. Similarly, when sorting commands offered by applications, you can order them in this manner for the subset of commands for a given track. 3) Besides all of my examples being floppy, what else should be changed/corrected in what I wrote? The only thing I would change is to mention that this is/was found on hard drives also. paul The TU58 was a block addressable using a cassette tape drive famously(?) called DECtape II. File placement on the two different linear tracks was a necessary art, especially if you were booting RT11 regularly. This helped it to stream or not rewind in sensitive places. The 1:2 interleave was “built-in” to the block formatting (see EK-0TU58-UG-001_TU58_DECtape_II_Users_Guide_Oct78.pdf). I wasn't aware that it did any block interleaving. But yes, file placement was extremely important. Are you sure it interleaved blocks? I used a late model device, pulling data from clinical diagnostic computers without too many challenges. However, compared to reliability of DECtape*, DECtape iI was not in the same class IMHO. Jerry *Yes - I skipped over DECtape. I’ve leave that one to the many experts on the list. DECtape never did interleaving that I know of. But there too, file placement was very important. I don't think it would even work if you interleaved the blocks, as the tape driver normally figured out which was to spool depending on the current block at the head, and which block you wanted to get to. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Sector Interleave
Jerry Weiss j...@ieee.org > On Nov 30, 2015, at 7:12 PM, Johnny Billquist wrote: > > On 2015-12-01 02:06, Jerry Weiss wrote: >> >> >> The TU58 was a block addressable using a cassette tape drive famously(?) >> called DECtape II. File placement on the two different linear tracks was a >> necessary art, especially if you were booting RT11 regularly. This helped >> it to stream or not rewind in sensitive places. The 1:2 interleave was >> “built-in” to the block formatting (see >> EK-0TU58-UG-001_TU58_DECtape_II_Users_Guide_Oct78.pdf). > > I wasn't aware that it did any block interleaving. But yes, file placement > was extremely important. Are you sure it interleaved blocks? See page 1-4 "Two tracks, each containing 1024 individually numbered, firmware-interleaved "records." Firmware manipulates 4 records at each operation to form 512-byte blocks" Also figure 1-5. Not only interwoven, but reversed for bi-directional r/w I believe. Jerry
Re: Sector Interleave
> On Nov 30, 2015, at 8:12 PM, Johnny Billquist wrote: > > ... > DECtape never did interleaving that I know of. Sure it does. The DOS format, which was adopted by RSTS, has 4 way interleaving. If you write a 500 block file, it writes every 4th block forward, then fills in one set of gaps reverse, then forward and backward again, resulting in finally all blocks used. This is a software function, of course, and actually implemented in the file system, but it's certainly interleaving. It doesn't apply to contiguous files (supported in DOS but not RSTS), which is why RSTS V4A sysgen with output to DECtape took so long -- writing a contiguous CIL file, in block order, madly seeking back & forth. The reason for the interleaving on DECtape is the start/stop time. To run non-interleaved at high speed you have to leave the tape running (no "stop" commands) and you have to issue the next command quickly. RT-11 could do that; DOS could not. paul
Re: Sector Interleave
On 2015-12-01 02:19, Paul Koning wrote: On Nov 30, 2015, at 8:12 PM, Johnny Billquist wrote: ... DECtape never did interleaving that I know of. Sure it does. The DOS format, which was adopted by RSTS, has 4 way interleaving. If you write a 500 block file, it writes every 4th block forward, then fills in one set of gaps reverse, then forward and backward again, resulting in finally all blocks used. This is a software function, of course, and actually implemented in the file system, but it's certainly interleaving. It doesn't apply to contiguous files (supported in DOS but not RSTS), which is why RSTS V4A sysgen with output to DECtape took so long -- writing a contiguous CIL file, in block order, madly seeking back & forth. Oh. You mean that the software decided to use blocks 0,4,8,12,... Yes, that would be doable. I was thinking of interleaving at the format level. But such interleaving means the software have to keep rather good track of things... The reason for the interleaving on DECtape is the start/stop time. To run non-interleaved at high speed you have to leave the tape running (no "stop" commands) and you have to issue the next command quickly. RT-11 could do that; DOS could not. Yes. Having run a PDP-8 booted from DECtape, I've seen plenty of rocking back and forth to start/stop. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Sector Interleave
>Paul Koning wrote: The reason for the interleaving on DECtape is the start/stop time. To run non-interleaved at high speed you have to leave the tape running (no "stop" commands) and you have to issue the next command quickly. RT-11 could do that; DOS could not. When I attempted to evaluate how well a backup to tape would work, I always included the verify portion to make sure that the tape had been written correctly in addition to making sure that the tape could also be read. For the PDP-11/83 under RT-11, there were essentially two choices: TK50 and TK70. Aside from the advantage that the TK70 had over the TK50 with respect to the capacity - (if I remember correctly) about 256 MB vs 32 MB, the other problem was that it was found to be impossible to steam the TK50 during a BUP verify operation. So in addition to the TK70 being much faster in the first place relative to the TK50, the verify operation was just not feasible. Somehow, the PDP-11/83 could read both the tape and the disk drive, then compare the two current buffers while the alternate buffers were being read, using, I presume, DMA requests to the two controllers to transfer the data to the next pair of buffers. Of course, RT-11 had special EMT requests to initiate the read requests and then go away and do something else. Obviously, I could have copied the BUP backup to a scratch disk and verified the scratch disk against the original disk and saved a great deal of time if the TK50 had been the only option. Jerome Fine
Re: papertape repair tape or kit wanted
Keston Common? There's one near Bromley. Oh well back to latest project - a TU58. Power OK and BOB shows P2/DB25 is live so TXD On 30/11/15 16:44, tony duell wrote: Hi Tony Did you say Data Dynamics? I certainly knew them. I used to sell them LA36 print mechs. Yes, almost certainly the same company. They sold several teleprinters based on the Teletype Model 33. Same mechanics, but IMHO a nicer (all metal) case and different electronics. I have one which is a normal ASR33 typing unit, keyboard, and reader but in a case with bulbs to illuminate the printout and electronics to give both RS232 and current loop interfaces and a single-step button for the reader. It was run by two old guys called Tindale and Stabler. The factory was in Hayes and I used to drive there from the DEC office in Ealing via Bombay (sorry I mean Southall). Ah, that Hayes, not the one just down the road from me across Keston Common. -tony
