November 2017 - vcf-midatlantic

Update your Festivus information
by Jeffrey Brace 23 Nov '17

23 Nov '17

Happy Thanksgiving everyone! I am thankful for having all my vintage computer enthusiasts in my life! Looking forward to enjoying myself at Festivus. Please look over the signup list to make sure everything is good for your entry. I will be assessing what's what next weekend: https://docs.google.com/spreadsheets/d/1odmPxfBK9BrR-NDZIx4_c-V2lZpt_-vU-3f… Thanks! Jeff Brace

2 1

Off Topic: Did someone try to text message me?
by Ian Primus 23 Nov '17

23 Nov '17

I got a text message recently, mentioning old printers. Problem is, I have no way of knowing who it's from, and no way of replying. Was it someone on this list? -Ian

3 2

apple /// cobol
by Herb Johnson 23 Nov '17

23 Nov '17

> I recently got my Uncle to write up his PDP-8 usage... > Trying to collect more first hand stories. Got one more so far. > David Gesswein Good work. This preserves the context of use for our minicomputers and microcomputers of the era. That understanding WILL be lost, is already opaque to those in the 21st century, if it's not captured and made available to read today and in the future. Herb Johnson -- Herbert R. Johnson, New Jersey in the USA http://www.retrotechnology.com OR .net

1 0

Happy Thanksgiving
by Evan Koblentz 23 Nov '17

23 Nov '17

Gobble, gobble everyone! Hope you all have a nice holiday. Looking forward to seeing many of you at Festivus in a couple of weeks. Evan Koblentz Director, Vintage Computer Federation evan(a)vcfed.org / (646) 546-9999 www.vcfed.org @vcfederation

1 0

Re: [vcf-midatlantic] apple /// cobol
by william degnan 22 Nov '17

22 Nov '17

On Wed, Nov 22, 2017 at 12:40 PM, Glenn Holmer via vcf-midatlantic < vcf-midatlantic(a)lists.vintagecomputerfederation.org> wrote: > > > ---------- Forwarded message ---------- > From: Glenn Holmer <cenbe(a)kolabnow.com> > To: vcf-midatlantic(a)lists.vintagecomputerfederation.org > Cc: > Bcc: > Date: Wed, 22 Nov 2017 11:40:31 -0600 > Subject: Re: [vcf-midatlantic] apple /// cobol > On 11/19/2017 12:28 PM, Herb Johnson via vcf-midatlantic wrote: > >> anyone use apple /// cobol, used it back when > > . ... Waterloo Cobol for the SuperPET > > > > There were a number of 8-bit COBOLs. CP/M versions in particular. I only > > used it on mainframes, and not much at that. > > There were at least two COBOLs for the Commodore 64: Abacus COBOL and > Nevada COBOL for '64 with the CP/M cartridge. > > -- > Glenn Holmer (Linux registered user #16682) > "After the vintage season came the aftermath -- and Cenbe." > > OK, if there are no people who used Apple /// Cobol, who here even used an Apple /// at all *back then (1980-1985) as their main PC. I am not expecting many. I could see being a student and using it to test code before uploading to the production environment, or in some cases for small business or consultants using a micro for Cobol. There were a number of Cobol applications for micros, I just never heard of anyone using the Apple /// version. Seems like it would have been nice, but I think I would have used an IBM PC version or a Tandy CP/M version, personally. Or, if possible access my production environment using a terminal. It was very popular for people at DuPont when I worked there to take home VT 220 terminals to access the servers from home. Mostly IBM stuff where I was. Bill

1 0

Re: [vcf-midatlantic] Museum report. / slide rules
by Evan Koblentz 21 Nov '17

21 Nov '17

>> Hows about sell a couple at festivus? Definitely! On Nov 21, 2017 10:53 PM, "Douglas Crawford via vcf-midatlantic" < vcf-midatlantic(a)lists.vintagecomputerfederation.org> wrote: Hows about sell a couple at festivus? On 11/20/2017 1:16 PM, Evan Koblentz via vcf-midatlantic wrote: > Will items from this new acquisition, or other slide-rule items already >>> >> acquired, be part of upcoming exhibits? > > Some are rare/proprietary (for calculating strange things or branded > company swag) and some are very common Pickett / K&E. General plan is to > keep most of the weird ones and a few of the common ones. Maybe we can > display them on a wall. We'll sell the rest of the common ones at VCF East. > > On Nov 20, 2017 12:57 PM, "Herb Johnson via vcf-midatlantic" < > vcf-midatlantic(a)lists.vintagecomputerfederation.org> wrote: > > John H. and his g/f Jen came for a tour along with Stefan who donated slide >> >>> rules. (He estimates there are 1,000 in the collection!) >>> >>> Also did a good amount of >> >>> cleaning and planning for some modest exhibit changes this winter/spring. >>> >>> Will items from this new acquisition, or other slide-rule items already >> acquired, be part of upcoming exhibits? - Herb >> >> -- >> Herbert R. Johnson, New Jersey in the USA >> http://www.retrotechnology.com OR .net >> >>

1 0

Museum report. / slide rules
by Herb Johnson 21 Nov '17

21 Nov '17

> John H. and his g/f Jen came for a tour along with Stefan who donated slide > rules. (He estimates there are 1,000 in the collection!) > Also did a good amount of > cleaning and planning for some modest exhibit changes this winter/spring. Will items from this new acquisition, or other slide-rule items already acquired, be part of upcoming exhibits? - Herb -- Herbert R. Johnson, New Jersey in the USA http://www.retrotechnology.com OR .net

3 2

Re: Digest, Vol 25, Issue 21, Message 4 "HAASOScope"
by SVCatITC＠aol.com 21 Nov '17

21 Nov '17

Thanks Very Much Herb for the technical lecture. Us old farts will agree with you on the analog scope versatility, and I also agree with the functionality of the new "finagled" stuff out there now. The latter makes capturing and documenting the triggered event (for later analysis) easy, rather than the Polaroid coupled cameras to the old Tektronix 548 fire breathing monsters' screen of the day. This feature is great for documenting screen shots in reports to customers. I find though that you have to sometimes "help" the new technology by "presetting" the "window" where you might want to look, otherwise trigger thresholds might lose the event. You may not know exactly where to find the "glitch" in the "haystack". >From my experience, analog gives you the "widescreen view" of the disturbance and you can then "zoom" in on the area of interest. The 20 MHz luggable that I bring into the museum does not have the bandwidth to check at what frequency the TR20 power supplies are oscillating at (as an example), however as you well noted, you do not necessarily care about the exact quantity to know you have to kill the "screaming" and make a quiet supply for analog work. The analog scope sets up easy for a quick GO/NOGO check. As always, many thanks for the thought provoking insight. Bill Inderrieden In a message dated 11/21/2017 12:04:17 P.M. Eastern Standard Time, Herb Johnson writes: Date: Mon, 20 Nov 2017 13:45:42 -0500 From: Herb Johnson <hjohnson(a)retrotechnology.info> To: vcf-midatlantic <vcf-midatlantic(a)lists.vintagecomputerfederation.org> Subject: [vcf-midatlantic] Open Hardware DSO - 100 MHz/250 Msa/sec - haasoscope Message-ID: <2320de34-08fc-86ff-33dd-8635edf667cd(a)retrotechnology.info> Content-Type: text/plain; charset=utf-8; format=flowed I agree with my old friend and colleague, mostly. But I'd put stronger emphasis on detecting "glitches". I prefer analog scopes, because they can show in some fashion glitches even above their bandwidth. The following lecture will be technical. This matters to me, as this is work I've done for decades. "Bandwidth as twice sampling rate" is fine for detection of repeated events. It's not fine for reconstructing the signal, or finding one-off events. Digital sampling limits aren't the same as the bandwidth rolloff of an analog oscilloscope amplifier (or probe). Many 20th C. brand-name analog oscilloscopes gave (still give!) good performance well past their nameplate bandwidth. also: scope trigger circuits have to respond to events far above bandwidth! Triggering is very important. A "glitch" is a signal where a logic state changes, not because of a change in logic condition, but because of a timing event such as "propagation" or a "triggering delay". These are very short pulses, on the order of several nanoseconds in TTL circuits. Or, they may manifest as nanosecond delays in signals. Power supply lines carry glitches, caused by literal "spikes" in DC power to logic-switching circuits; large currents plus fast changes produce L di/dt or C dv/dt signals. These matter, because they can trigger logic events. If you can't see the trigger, you don't know "why" you have such events. Old TTL designs, sometimes generated glitches due to poor design. Aging components may cause glitches, by increasing capacitance, or sagging DC voltages. Dead or absent bypass caps, fail to filter out power-supply-line glitches. Look at schematics of the IMSAI front-panel. They actually CREATE "glitches" with a series capacitor to turn a logic-level change into a triggering pulse! Ugly ugly ugly design. All that said, any scope beats none. Looking at logic-level signal activity (any activity) is a go / no-go test for logic chips. Many faults can be diagnosed with a 20Mhz analog oscilloscope and probe. (Probe bandwidth matters. Not today's lecture.) But some faults are design problems that finally came due, or non-logic component failures, or "tired" chips. TTL logic responds to signals and events of several nanosecond duration - that's hundreds of megahertz "bandwidth" technically. and even a 20Mhz scope, will trigger on much faster events - that at least "detects" them. and you can guess if an analog "bump" is actually a pulse above your bandwidth. End of technical lecture. In my 20th century view, a $100ish old toolbox-sized HP or Tek 100Mhz analog oscilloscope, will show more information about pre 1990's computer chips, than most users can appreciate. But a $300 "100Mhz sampling" digital oscilloscope you can carry in your pocket, likely performs little better than a 30-40Mhz no-brand-I-remember analog oscilloscope that you leave behind at a hamfest. Will a 1Ghz modern DSO do much better? (shrug) I lack that experience, ask an owner, faster is better but.... And a DSO is conveniently tablet-sized, and likely does other things too. So the answer for you is: what's in your wallet? Buy BOTH if you can afford it, choose otherwise. Herb "race condition" Johnson retrotechnology.com

1 0

Re: [vcf-midatlantic] Cobol on micro
by Jeffrey Jonas 20 Nov '17

20 Nov '17

> anyone use apple /// cobol, used it back when it was current? I did not but I think my experience with CP/M C and PL/1 are relevant. 1) I used Whitesmith's "C" compiler on CP/M in 1982. It was very slow and almost painful to use - so many phases with constant floppy disk access. And it was not quite the full language or environment. A friend gave me a substitute printf() with more options than the standard library. 2) I used PL/I "F" on IBM mainframes in high school (early 80s). The PL/I subset for CP/M was just too weak to use for much. And like the "C" compiler, was horribly s l o w to compile and link. -- jeff jonas

1 0

Open Hardware DSO - 100 MHz/250 Msa/sec - haasoscope
by Herb Johnson 20 Nov '17

20 Nov '17

David Gesswein: > It all depends on that you want to do with it. This is written assuming you > are troubleshooting old computers. > > You need sufficient bandwidth > to view your signal of interest and sufficient sample rate to make it look > reasonable. Sampling twice the frequency of a sine wave captures the > information but it doesn't look like [the original signal]. > > I think the sample rate will be the biggest limitation. You will need to > see the character of signals you will want to look at. > > For troubleshooting old equipment the degradation of the signal edges > is normally not as big an issue. The faults are normally not that subtle > but I have run across glitches on signals causing trouble that the low sample > rate can hide. I agree with my old friend and colleague, mostly. But I'd put stronger emphasis on detecting "glitches". I prefer analog scopes, because they can show in some fashion glitches even above their bandwidth. The following lecture will be technical. This matters to me, as this is work I've done for decades. "Bandwidth as twice sampling rate" is fine for detection of repeated events. It's not fine for reconstructing the signal, or finding one-off events. Digital sampling limits aren't the same as the bandwidth rolloff of an analog oscilloscope amplifier (or probe). Many 20th C. brand-name analog oscilloscopes gave (still give!) good performance well past their nameplate bandwidth. also: scope trigger circuits have to respond to events far above bandwidth! Triggering is very important. A "glitch" is a signal where a logic state changes, not because of a change in logic condition, but because of a timing event such as "propagation" or a "triggering delay". These are very short pulses, on the order of several nanoseconds in TTL circuits. Or, they may manifest as nanosecond delays in signals. Power supply lines carry glitches, caused by literal "spikes" in DC power to logic-switching circuits; large currents plus fast changes produce L di/dt or C dv/dt signals. These matter, because they can trigger logic events. If you can't see the trigger, you don't know "why" you have such events. Old TTL designs, sometimes generated glitches due to poor design. Aging components may cause glitches, by increasing capacitance, or sagging DC voltages. Dead or absent bypass caps, fail to filter out power-supply-line glitches. Look at schematics of the IMSAI front-panel. They actually CREATE "glitches" with a series capacitor to turn a logic-level change into a triggering pulse! Ugly ugly ugly design. All that said, any scope beats none. Looking at logic-level signal activity (any activity) is a go / no-go test for logic chips. Many faults can be diagnosed with a 20Mhz analog oscilloscope and probe. (Probe bandwidth matters. Not today's lecture.) But some faults are design problems that finally came due, or non-logic component failures, or "tired" chips. TTL logic responds to signals and events of several nanosecond duration - that's hundreds of megahertz "bandwidth" technically. and even a 20Mhz scope, will trigger on much faster events - that at least "detects" them. and you can guess if an analog "bump" is actually a pulse above your bandwidth. End of technical lecture. In my 20th century view, a $100ish old toolbox-sized HP or Tek 100Mhz analog oscilloscope, will show more information about pre 1990's computer chips, than most users can appreciate. But a $300 "100Mhz sampling" digital oscilloscope you can carry in your pocket, likely performs little better than a 30-40Mhz no-brand-I-remember analog oscilloscope that you leave behind at a hamfest. Will a 1Ghz modern DSO do much better? (shrug) I lack that experience, ask an owner, faster is better but.... And a DSO is conveniently tablet-sized, and likely does other things too. So the answer for you is: what's in your wallet? Buy BOTH if you can afford it, choose otherwise. Herb "race condition" Johnson retrotechnology.com -- Herbert R. Johnson, New Jersey in the USA http://www.retrotechnology.com OR .net preserve, recover, restore 1970's computing email: hjohnson AT retrotechnology DOT com or try later herbjohnson AT retrotechnology DOT info

1 0