test-drb February 2013

test-drb@ccmp.vtda.org

185 participants
407 discussions

by rampaginggreenhulk＠yahoo.com

------------------------------ On Tue, Feb 5, 2013 5:11 PM PST William Donzelli wrote: >> In the 40s and 50s, I wonder if Hazeltine made more off their patents than >> actually selling product. > >No, probably not. Hazeltine was a pretty big defense contractor during >World War 2, the 1950s, and beyond. Grumman was a ginormous defense contractor on Long Island. Yet at some points every jamoke with a drill press was making parts for them. The final product was *all* Grumman though. They weeded a lot of their suppliers out over time.just in time to close up shop.

12 years, 1 month

strange Honeywell system

by rampaginggreenhulk＠yahoo.com

in reality even if it did have only a 386 or 486 I would still consider it interesting. I still miss my old HP 386 tower server thing.

12 years, 1 month

Hazeltine 1500 on ebay

by rampaginggreenhulk＠yahoo.com

>Hazeltine was a very old radio company, going back to the 1920s, although based around design/patents/licensing rather than manufacturing, originally at least. > >Terminals were an offshoot or sideline. Very little of which were likely made by them anyway. But what do I know. F'rinstance the Sperry ?/Leading Edge Model M was wholly a Mitsubishi product. Even the monitors were M*, and at least 1 model externally bore a striking resemblance to the TRS-80 CM-1 used w/the model.2000. Like anyone cares.

12 years, 1 month

Using two RL02 drives on OS/8? (was: cctalk Digest, Vol 114, Issue 4)

by rick＠rickmurphy.net

At 04:47 PM 2/5/2013, Bob Vines wrote: >Hopefully some of this helps. I have a couple of RL02 drives that I'd >like to try with my PDP-8/E one of these days. (Assuming that I can >get an "-8"-formatted pack.) There's no format difference. There's a bit called the "mode" bit (software selected) which selects 12-bit mode or 8 bit mode for the RL8A. In 12-bit mode, a sector contains 128 12-bit words or 256 8-bit bytes - 64 bytes are wasted in 12-bit mode. (Also, with 12-bit mode, you can't DMA more than one sector at a time.) I don't know for sure, but I'll bet that OS/8 runs in 12-bit mode. You *do* have to run a magic formatter program on the '8 that fixes up the bad block map into where OS/8 expects it. As far as the jumper Charles is referring to - there's a pair of jumpers on the RL8A that need to be configured. W8 is installed to support the RL02 (W8), W9 installed for the RL01. Only one of those jumpers are installed at a time. If the zero drive is working, W8 is installed. What this does (when W9 is installed) is to limit the track delta register to the RL01 size. -Rick

12 years, 1 month

Using two RL02 drives on OS/8? (was: cctalk Digest, Vol 114, Issue 4)

by bobvines00＠gmail.com

I forwarded this RL02 vs OS/8 question to Charles Lasner, his response follows the original question. [snip] > Date: Sun, 3 Feb 2013 13:45:46 -0600 > From: Charles <charlesmorris800 at centurytel.net> > To: cctalk at classiccmp.org > Subject: Using two RL02 drives on OS/8? > Message-ID: <7E1278E1-BA46-45AD-99F6-FB38443AC1A0 at centurytel.net> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > I'm trying to find a manual detailing the operation of an RL02 under > OS/8. The Bitsavers archive only has manuals new enough through the > RL01. > Can someone point me to the proper documentation? > > Meanwhile, although several years ago I did manage to build an OS/8 > system with two RL02's on SIMH and transfer that disk image to an RL02 > pack, and BUILD shows the appropriate device names, when the second > drive (1) is accessed, the data actually comes from the boot drive > (0). Just now getting around to playing with it again. > Version: OS/8 KBM V3T, CCL V3E. > > The relevant portion of the BUILD printout: (I didn't have enough > handlers to add the "leftover" E drives anyway) > > R2SY: *SYS R20A > RL20: *R2A0 *R2B0 *R2C0 *R2D0 > RL21: *R2A1 *R2B1 *R2C1 *R2D1 > DSK=RL20:R2A0 > > I can even unload the heads on Drive 1 and ask for a DIR of its > logical drives, and not only does OS/8 not hang or at least give a > "NOT FOUND" error, it gives me the data from the corresponding logical > drives on Drive 0! ASSigning DSK to the other drive doesn't make any > difference... > > What am I doing wrong? > thanks > Charles > [snip] > End of cctalk Digest, Vol 114, Issue 4 > ************************************** ********** >From CJL: I can't guarantee this is the problem, but I do see a potential driver head count problem here: Let's start with the weirdness that is OS/8 RL support in the RL01: To support the RL01, there is a controller card jumper to set. I never found out EXACTLY what it does, but I can describe that constrained to the only rational answers. The RL02 has twice as many tracks to manually seek over [! Wonderful for real-time, since it doesn't interrupt! Ask the -11 people about creating RL seek-check tasks.] Thus, on the RL01 [which I suspect cannot be supported on the DECmate I's obscure RL278 spec'd for RL02 generally] you have to make sure that the proper bits get to the controller, which apparently can stupidly step an RL01 into never-never land if you let it. The programming is such that you create the signed difference between where you apparently are and where you want to be and send out a step the head over the direction indicated and number of steps. Thus, the arithmetic high-order bit has to become ignored. Thus, what the jumper does is obviously one of the following: 1) Ignore it; you only see the rest of the bits in the drive. I think this is least likely. 2) Set the bit to the same value as the one immediately to the right regardless of what the instruction says to do. This is a signed quantity because it could be a seek to lesser or further out as required, etc. In any case, this is an RL02 question, so we can table that factoid; I just want to know because it does mean that software could be then written to work with mixed situations of RL01 and RL02 on the same controller the way the -11 does it. Obviously they were told to make the bit being ignored/adjusted the correct value from the beginning; I think many knew the RL02 was not that far in the future when the RL01 was released, so their software designs were cognizant of the then future, etc. Unfortunately, it is a known quantity that much of the RL software is sloppy and can be counted upon to not be counted upon regardless of what the correct thing to do is, thus this stupid compatibility jumper, etc. [I never wrote a P?S/8 handler for it, thus I don't know. Moreover, OS/8's handlers are probably the most compromised for R-L devices; any actual correct performance with the switch off for RL01 would be a happy accident; no effort was expended to get it right; the jumper was known the exist. In P?S/8, I don't have the handler limitations, thus could get that right as well as a whole lot of other things; OS/8 is an awful kludge and incompatible with all other usages of RL01 and RL02, etc.] All that said, here is how you get it to work: First of all, not only do you have to perform a general formatting diagnostic that then builds a collection of bad block tables. [I believe there is a "factory" master table to never erase, and then some newer table to add in found-in-the-field more bad spots, etc.] All of that is done in an 8-bit orientation. To my knowledge, it is difficult at best to access this data in byte mode in one pass, so clearly 2:1 interleave is part of the design discussion regardless. In any case, it is the case of OS/8 using 12-bit mode. OS/8 cannot access the real bad block tables. Thus, there is an OS/8 crutch secondary program. The RL01 is divvied up into "wedges" of unequal size. Two larger ones and another one 1/2 the size of the other two. I have no idea how they account for this; in OS/8 PIP there is supposed to be a table where by internal logical device number you patch in the device size for directory zeroing purposes, etc. Thus, I guess the small wedgie is considered a different logical device despite it possibly being part of a same or similar non-system handler set [system handler too tight] with the same general I/O code just handling a different wedge of the disk, etc. They got something that is viable, but I am not sure; it could be examined assuming you have a system where PIP knows what to do certainly, etc. The wedges and the little wedgie are each evaluated. As a logical set of sectors in order to handle itself, there is a restriction that is pretty stupid: They insist that the very highest sector of the entire wedge/wedgie is error-free else OS/8 cannot use the pack! However, only the inner-most tracks are guaranteed error free from the factory because that's where the *REAL* bad block table[s] is/are. Expecting a block to actually be good when it is potentially in the main table[s] marked bad is preposterous, And I have heard of packs hand-picked to allow OS/8 family versions to like it because you must relegate it to something else that knows how to play with the bad blocks the way the big boys do, etc. So, assuming that risky situation is somehow OK, that becomes a twelve-bit-oriented record of the bad blocks in the format of which logical sectors of that wedge/wedgie are known bad. This little table is written in the highest logical record of the wedge/wedgie. No handler is maximum size because the table is reserving that last one assuming all are error-free. I would also suspect that there is no way to support it unless a few of the first of them [again, in this logical order of where in the wedge/wedgie they are, etc.] are known good. Certainly applies to the bootable system device one[s]. The handler proceeds to calculate the sector the caller is accessing. For all entries in the table prior to that desired logical record, the record that is ultimately used is bumped by one to "straddle" the bad spot. Thus, we now have the corrected logical record in the wedge/wedgie we want. Notice that this process has to be repeated for any sector in the call since your neighbor could be on the other side of the sinkhole so to speak. [I can see that physically adjacent sectors could all be bad, even with a 2:1 interleave; physically 3 or 4 in a row for example.] Then the handler converts that to the physicality of actual track/head/sector and does the intended read or write operation, etc. Go back and repeat all of the above as necessary from the original caller's marching orders, etc. The ordering of the sectors is through a 2:1 interleave obviously, but remember, all the wedges/wedgie that you don't "own" are in the way in the rotational latency sense. One revolution traverses all physical sectors, but you only get at best 1/2 wedge's forward progress [or worse, one half wedgie, again I mean the one that is 1/2 the size of the two larger ones.] Thus, the overall overhead is gross as the throughput is far less than implied by 2:1 interleave. [Historical note: Instead of playing with this crap when it was released, I was using the DSD-240/Western Dynex drive. 5 MB cartridges removable looking like RL disks superficially, but not servo-driven, rather a better mechanism than an RK05 that admittedly needed alignment but held it quite well. More importantly, it was over another 5.0 MB fixed disk. Thus, with some "Tower of Hanoi" juggling, you can completely back up everything on two 5 MB packs and it is damn fast. DMA with 1:1 interleave, all sectors addressed truly in physical order, a smart controller, no bad blocks whatsoever, smaller logical sectors so each transfer was one or more PDP-8-sized page blocks so completely at home in either P?S/8 or OS/8 with elegant and easy to write handlers for both systems. The command as well as the data are initiated by DMA and then it just does it automatically with a done and error status after-the-fact so low interrupt overhead, etc. In short, absolutely no problems whatsoever. [Note: Part of the concepts that implemented the DSD-240 were incorporated in the MDC8 >from CESI; I wrote all the handlers and support utilities.] The media guaranteed to be error free and delivering the promise; what a comparison between elegance and DEC's awful crap; this was well on the way more than merely the begiinning of the end; it was already part of the accelerating slide to eventual oblivion.] So much for the RL01. Note that gets you three handlers for the entirety of one disk with one handler's range 1/2 the size of the other two. That gets you three handler entries in BUILD if this is an RL01. But what of the RL02? Well, the wedgie is still smaller than the other two, but it doubles in size to be the equivalent on the RL02 of a wedge on an RL01. However, the RL02 wedges are twice the size that OS/8 can handle. Thus, an analogy to the RK8E/RK05 can be drawn. Each pack cannot be addressed with one handler; you need two of them each about 2/3-3/4 of the maxed-out OS/8 size. In this case we are talking about a superwedge that has to be logical cut in half as well, back to the equivalent of one RL01 wedge each. Thus, the RL02 gets you FIVE handlers all each addressing the same amount of physical space. >From the BUILD output, it suggests groupings of four, not five. It would appear that there is potential anomaly there. The source code for the handler will reveal what BUILD is told about the device. Clearly that problem of logical device for PIP directory zeroing purposes goes away as they are all know the same logical size, just that there are more of them, thus there needs to be 5 build-oriented entries in these handlers as opposed to three as in the RL01 case. I suspect the confusion comes from there. Maybe you have some mixed RL01 and RL02 handlers confusing things, etc. P?S/8 has nearly NINE pages of code to handle system devices, as opposed to OS/8's only two where the first if a system handler is also not really a complete page with regard to code for the device as opposed to reserved locations "around" the handler code, etc. That concept applies pretty equally to both systems [but I think P?S/8 is slightly tighter.] The second page is actually not completely available either as the field 2 code reserves the last 4 words for OS/8 BATCH. [Come on, folks! The DS/8 people created what they called "HASP". Two attaboys to anyone who can explain the historical meaning of the name from an older non-DEC world. Houston, do we have a problem?] In any case, it got you a batch in 8K, so no reserved words and no 12K requirement at all, etc. And for those who may not have heard, P?S/8 BATCH is based on the original R-L Monitor System; both run BATCH in 4K!] But P?S/8 system handlers get EIGHT complete additional pages for their purposes alone. Clearly there is room to read the REAL bad-block tables and massage them as needed to allow sane bad-block handling. No wedge crutches, no dependency on iffy sectors, etc. As these packs age, I suspect OS/8-worthy ones will become less and less available physically. If you can honor the real tables, you can tolerate the true intended counts. In OS/8, I think each wedge/wedgie is limited to something like 16 total errors there, etc. In time, they will not be usable for the OS/8 kludge [admittedly eventually perhaps not usable at all!] ********** Hopefully some of this helps. I have a couple of RL02 drives that I'd like to try with my PDP-8/E one of these days. (Assuming that I can get an "-8"-formatted pack.) Bob

12 years, 1 month

Hazeltine 1500 on ebay

by rampaginggreenhulk＠yahoo.com

great price too ------------------------------ On Tue, Feb 5, 2013 9:00 AM PST Richard wrote: >Someone was just asking for one of these... ><http://www.ebay.com/itm/261165631166> > >-- >"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> > The Computer Graphics Museum <http://computergraphicsmuseum.org> > The Terminals Wiki <http://terminals.classiccmp.org> > Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

12 years, 1 month

Hazeltine 1500 on ebay

by legalize＠xmission.com

Someone was just asking for one of these... <http://www.ebay.com/itm/261165631166> -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

12 years, 1 month

Using two RL02 drives on OS/8?

by charlesmorris800＠centurytel.net

I'm trying to find a manual detailing the operation of an RL02 under OS/8. The Bitsavers archive only has manuals new enough through the RL01. Can someone point me to the proper documentation? Meanwhile, although several years ago I did manage to build an OS/8 system with two RL02's on SIMH and transfer that disk image to an RL02 pack, and BUILD shows the appropriate device names, when the second drive (1) is accessed, the data actually comes from the boot drive (0). Just now getting around to playing with it again. Version: OS/8 KBM V3T, CCL V3E. The relevant portion of the BUILD printout: (I didn't have enough handlers to add the "leftover" E drives anyway) R2SY: *SYS R20A RL20: *R2A0 *R2B0 *R2C0 *R2D0 RL21: *R2A1 *R2B1 *R2C1 *R2D1 DSK=RL20:R2A0 I can even unload the heads on Drive 1 and ask for a DIR of its logical drives, and not only does OS/8 not hang or at least give a "NOT FOUND" error, it gives me the data from the corresponding logical drives on Drive 0! ASSigning DSK to the other drive doesn't make any difference... What am I doing wrong? thanks Charles

12 years, 1 month

The VCFSE Press Release

by david＠classiccomputing.com

Hi there, If I might please share with everyone on these lists about our upcoming BIG show! - - - - - - - - - - - - - - - - - - - - - Announcing the First Ever Vintage Computer Festival Southeast The original Vintage Computer Festival was founded by Sellam Ismail and held in Pleasanton, California during October, 1997. Now, finally, the southeast region of the US gets its very own! ROSWELL, Georgia ? February 4, 2013 ? Vintage Computer Festival Southeast ? a public celebration of computer history and nostalgia ? will be held on Saturday & Sunday, April 20 & 21. Our mission remains the same as that very first show: The main mission of the Vintage Computer Festival is to promote the preservation of "obsolete" computers by offering attendees a chance to experience the technologies, people and stories that embody the remarkable tale of the computer revolution. We will educate and entertain! - A large premier exhibit will welcome each attendee as they enter the festival - The Apple Pop-Up Museum which tells the story of how a small start-up company, founded in a garage by two young friends, became the leading consumer electronics and personal computer company in the world. The exhibit displays an exclusive collection of game-changing Apple personal computers and consumer electronic products while presenting the history of the company since its founding in 1976 to the present. An Apple I, the first disk ][ and controller card, original apple ][, original Lisa and even a Xerox Alto are among the rare artifacts to be displayed, plus much, much more. Within the 6,000 square feet of display space that this premier exhibit occupies will be the following rooms: Pre-Apple Room, Apple I Room, apple ][ Room, Turmoil Years Room, No Founders Left Room, Jobs? Come Back Room, Ive?s Colors Room, iPod / iPhone / iPad Room, The Timeline Lounge and Apple?s Present to the Future Room. - Dozens of exhibitors will be present from all over the region, plus many from other parts of the country. A large variety of historic computers will be represented in the exhibit hall for live demonstrations by their owners. - A vintage game station will be available for children and adults to play classic games on classic computer and game console systems. - Two retrocomputing kit building classes will be held, plus continual, inexpensive introduction to soldering classes. - Many luminous speakers and special presenters are now being scheduled. The VCFSE is hosted and produced by the Computer Museum of America and the Atlanta Historical Computing Society. One-day adult tickets to the VCFSE are $10, with a two-day pass for $15. Children ages 17 and younger are admitted free when accompanied by a parent or guardian. For hours, location, and other details, please visit vintage.org/2013/southeast Contact: David Greelish, Director, Vintage Computer Festival Southeast 1.0 david at classiccomputing.com | 770-733-6702 Best, David Greelish - Computer Historian, Writer, Podcaster & Speaker - Founder of the Atlanta Historical Computing Society http://about.me/davidgreelish Director of the Vintage Computer Festival Southeast 1.0 - 4/20 & 4/21, 2013 http://vintage.org/2013/southeast/

12 years, 1 month

Commodore Superpet video problem -- ideas?

by rob＠bitscience.ca

Thanks for the suggestions. I've looked for visible arcs as carefully as I can, and have been unable to see any. I've cleaned and resoldered the connections to the transformer, and removed and cleaned the anode connection to the CRT. I don't know if you can remove the anode connection at the flyback end, so I haven't fiddled with that. Is it reasonable to assume at this point that the arc is *inside* the flyback cover? Is it possible that a component failure outside the transformer could cause arcing in the flyback, or does it mean that the flyback itself is at fault? The flyback transformer appears to be unobtainium (although if someone knows different, I'd love to hear about it). I guess I'm in the market for a PET video board.... Thanks again, Rob

12 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb February 2013