test-drb April 2016

test-drb@ccmp.vtda.org

203 participants
299 discussions

by rodsmallwood52＠btinternet.com

Hi Guys Well I made it ! I now have the correct font for the address line in the masthead on PDP-8/e. As usual the combined wisdom of the list was the main source of answers. One point is that are in fact three different fonts in use. The one for the d i g i t a l name, one for the touching out line font of the letters pdp and finally that which is used for the address. The digital name logo sub master I already had left over from my DEC days. There's also a copy on a web site that has been referred to recently. The pdp logo I drew and the basis of the address line text was thanks to Paul Koning's handbook.ttf My view of the list is "Strength in numbers, Depth in knowledge and Band of Brothers in spirit". Thank you everybody Rod (Panelman) Smallwood

8 years, 7 months

OT: LED lighting configuration...

by elson＠pico-systems.com

On 04/29/2016 03:10 PM, Bill Sudbrink wrote: > I want a constant current supply that "pushes" 0.41 Amps. > A little more googling reveals that the above supply is > rated "1.67A output". This seems to support the W=AV > theory. So, do I want a PS labeled "15 watt 36vdc", > regardless of how many bulbs I want to drive? You say > "within limits". What specification do I look for to > understand the limits? Thanks LED lighting power supplies are generally rated in mA output, within a range of voltages, such as 350 mA within 24:72 V DC. Digi-Key stocks something like 10,000 models! Jon

8 years, 7 months

strangest systems I've sent email from

by jnc＠mercury.lcs.mit.edu

> From: Liam Proven >> I think it _became_ popular for two reasons: ... ii) C was a lot better >> than many of the alternatives _at the time it first appeared_ (for a >> number of reasons, which I won't expand on unless there is interest). > I am indeed interested. OK, have to wind my brain back a _long_ way to remember what it was like before I met C (which in my case was ca. '77). Leaving aside places where you absolutely have to have pointers (e.g. device drivers), the ability to allocate storage dynamically (whether via pointers, or some alternative if you consider pointers unsafe) is just really key for many uses, and not everything supported that. For system work, stand-alone applications, etc pointers are really, really useful (if not key), and there weren't that many languages with pointers. It was an absolute revelation to see device drivers written *completely* in higher-level language in Unix! Anyway, for languages with that kind of capability, there was PL/I, which although it was used for the Multics kernel, was rather a large pile; it included a lot of stuff intended for commercial use. There was BCPL, which is basically C without types (a _really_ major drawback) and less terse syntax. Definitely a very nice language (a lot of Alto software was written in it, for example), and probably the best alternative to C _at the time_. I think BLISS was just getting started then, and outside DEC I'm not sure many people knew much about it. Can't think of any others with pointers, but my memory is probably failing me. Algol didn't have (IIRC) pointers or structures - the latter are fantastically useful when writing network code (which is what I was doing at the time). Did BCPL have structures? I don't recall. It's just that a lot of things which we now take for granted, and will be in any 'reasonable' language (types, structures, dynamic allocation, etc) didn't exist in all the available alternatives back then. And some languages had more hairy mechanisms for some things than were probably really needed (e.g. 'thunks' in Algol, for complicated argument support - nobody seems to miss that semantics in later languages). C just seemed to hit a sweet spot for functionality versus complexity - in the syntax, in the semantics; all over. > Well, malloc() and free(), anyway. Especially free()! If you only let people call malloc(), a lot of bugs would go away! ;-) > Not everyone's a genius. And those who aren't, often don't know. See > Dunning-Kruger. Klutzes think they're gods; gods think they're klutzes. > ... > So we *need* safe languages for the non-geniuses who think they're > brilliant. > ... > So, keep everyone in the safe space, but offer power tools - like Lisp > macros - so the brilliant are not held back. There's a problem, though - the great people probably really need access to 'dangerous' capabilities, which they will use to create great software. Limit them to the tools you make available to the average programmer, and you might limit their effectiveness. But once those more powerful tools exist, everyone and their mama is going to want to use them, as you point out. With the inevitable result... I dunno, maybe there's a way to have only 'safe' tools, but do so in a way that doesn't limit the productiveness of the really good people. Noel

8 years, 7 months

strangest systems I've sent email from

by jnc＠mercury.lcs.mit.edu

> From: Swift Griggs > even though there is *more* overall documentation on the Internet, the > docs you get with hardware and tools are nowhere near as good as they > were in the 80s AFAIK. I think that's partially because the speed of product cycles has sped up; there just isn't time to get good docs done and out. Also, there's more competitiveness/'efficiency', and good documentation costs money/overhead. Wonderful as e.g. DEC Technical Manuals were, I suspect producing their ilk nowadays is simply beyond the industry's capabilities (in the organizational sense, not the technical skill sense). > From: Liam Proven > C is popular because C is popular. Yes, but that had to start somewhere. I think it _became_ popular for two reasons: i) it was 'the' language of Unix, and Unix was so much better than 99% of the alternatives _at the time_ that it grew like crazy, and ii) C was a lot better than many of the alternatives _at the time it first appeared_ (for a number of reasons, which I won't expand on unless there is interest). > direct memory allocation, pointer manipulation and so on -- are > widespread /because/ of the C family influence. And I have a deep > suspicion that these are harmful things. Pointers, yes. Allocation, not really - a lot of languages have heaps. Did you mean manual freeing when you mention 'memory allocation', because technically even something like CONS allocates memory? And one could consider 'auto' variables as 'allocated' - but the 'freeing' is automatic, when the routine returns. As to whether those two are harmful - they can be. You have to have a 'clean' programming style to use them extensively without running into problems. (I personally have only rarely run into problems with them - and then mostly in very early C, before casts existed, because of C's wierd pointer math rules.) I would need to think about this for a while to really come up with a good position, but my initial sense is that these two are perhaps things that should be hidden in the depths of large systems, for use by very good programmers, that 'average' programmers should only be using higher-level constructs. (E.g. build a 'system' of routines to manage a certain kind of objects - like OO languages enforce in the language itself - and the average user only calls foo_allocate(), etc.) > I actually hugely admire Linux > ... > We are continuing to refine and tweak a 1970s-style OS -- a > technologically conservative monolithic Unix. FOSS Unix hasn't even > caught up with 1990s style Unix design yet, the early microkernel ones > .. It's roughly 2 decades behind the times. I'm a bit puzzled by your first thought, given your follow-on (which I agree with). I'd go further in criticizing Linux (and basically all other Unix descendants), though - your latter comment above is just about the _implementation_. I have a problem with the _basic semantics_ - i.e. the computational environment provided to user code. It was fantastic on a PDP-11 - near-'mainframe' levels of capability on a tiny 16-bit machine. On modern machines... not so much. Noel

8 years, 7 months

OT: LED lighting configuration...

by paulkoning＠comcast.net

> On Apr 29, 2016, at 4:10 PM, Bill Sudbrink <wh.sudbrink at verizon.net> wrote: > > Paul Koning wrote: >>> On Apr 29, 2016, at 3:32 PM, Bill Sudbrink <wh.sudbrink at verizon.net> >> wrote: >>> >>> ... The "bulbs" are labeled: >>> >>> 15F18120-45 15 watt 36vdc constant current >>> >>> I'd like to put four in a fixture and I'm trying to >>> understand what kind of driver I need and how to wire >>> it. I was thinking of using a Mean Well LPF-60D-36 >>> like this: >>> >>> http://www.ebay.com/itm/Mean-Well-LPF-60D-36-AC-DC-POWER-SUPPLY- >> Dimmable-LED >>> -DRIVER-36V-60W-CLASS2- >> /161857068172?hash=item25af6edc8c:g:9hQAAOSwA4dWHVn5 >>> >>> and wiring the "bulbs" in parallel to it. But after >>> realizing that I'm not completely sure what a "constant >>> current" power supply does and doing a little "googling" >>> I don't know if that's the right approach. >> >> A constant current supply is one that delivers a constant >> current to a varying load (within limits) just as a constant >> voltage supply delivers a constant voltage to a varying load. > > Ok, I figured that much. The problem/question is why there > are no Amp ratings on anything? Assuming the DC equation: > > Watts = Amps X Volts > > I want a constant current supply that "pushes" 0.41 Amps. > A little more googling reveals that the above supply is > rated "1.67A output". This seems to support the W=AV > theory. So, do I want a PS labeled "15 watt 36vdc", > regardless of how many bulbs I want to drive? You say > "within limits". What specification do I look for to > understand the limits? 15 watt 36 V is an odd spec for a device that needs constant current. What it seems to translate to is 400 mA device current, 36 volt nominal operating voltage. That's perhaps 10-12 LEDs in series, since each has a forward voltage around 3 volts, perhaps a bit more. If you have a supply rated for constant current operation, 36 volt or so, settable current, you could use that, crank the current setting down to 400 mA. If it's a fixed supply (36 volts 60 watts, i.e., 1.66 A) then that would not work. paul

8 years, 7 months

OT: LED lighting configuration...

by paulkoning＠comcast.net

> On Apr 29, 2016, at 3:32 PM, Bill Sudbrink <wh.sudbrink at verizon.net> wrote: > > ... The "bulbs" are labeled: > > 15F18120-45 15 watt 36vdc constant current > > I'd like to put four in a fixture and I'm trying to > understand what kind of driver I need and how to wire > it. I was thinking of using a Mean Well LPF-60D-36 > like this: > > http://www.ebay.com/itm/Mean-Well-LPF-60D-36-AC-DC-POWER-SUPPLY-Dimmable-LED > -DRIVER-36V-60W-CLASS2-/161857068172?hash=item25af6edc8c:g:9hQAAOSwA4dWHVn5 > > and wiring the "bulbs" in parallel to it. But after > realizing that I'm not completely sure what a "constant > current" power supply does and doing a little "googling" > I don't know if that's the right approach. A constant current supply is one that delivers a constant current to a varying load (within limits) just as a constant voltage supply delivers a constant voltage to a varying load. Constant voltage is the typical "regulated power supply". Constant current is needed for loads whose behavior is tied to a particular current, especially if those loads have negative dynamic resistance (such as gas discharge tubes, e.g., fluorescent tubes). If you have multiple loads that want the same constant voltage, connect them in parallel. If you have multiple loads that need constant current, connect them in series, NOT in parallel. The whole point of constant current applications is that the impedance of the loads is not consistent, and if you connect them in parallel, the current through each individual load will not be the correct value. paul

8 years, 7 months

Calling all typographers and introduction.

by wsudol＠freedom.com

I've been lurking on the cctech list for awhile and thought I would introduce myself. I hope I'm not breaking protocol by responding to the " Calling all typographers" topic I am truly amazed by the breadth of knowledge of the Classic Computers Community. I'm a computer programmer and have worked for a few major metropolitan newspapers for most of my working life. In college @ Cal State Los Angeles, I worked with PDP 11/45, and, If my memory isn't failing me, CDC 3170 and Cyber 76 computers and the ITS timesharing system. Even worked with PLATO when it was put on campus as a test system. First professional job was as an assembly language programmer programming Zentek Zms-90 8080 based terminals for a Classified Ad order entry system in 1977. So I'm old... Next job was as the "system programmer"/system manager for a DEC shop running Pdp 11/70, VAXen 780, 785, 8600 and Microvax II with lots of RM05's and System Industries 9755 and 9775 RM05 look alikes. I went back to Newspapers when they started using DEC equipment in addition to IBM Mainframes. Electronics is my hobby and I am starting/trying to accumulate some vintage VAX and pdp 11 gear. Re: Typography... My recommendation would be to try Macromedia's (now Fontlab) Fontographer for font creation/modification. That was the staple in the Newspaper industryand was used to modify existing fonts. It runs on MAC/Win and with it you can take an existing font and easily modify it as needed. You can adjust glyphs, add kearning and basically design a whole new font and output it as Sun, Adobe type 1, Type 3, Opentype, Postscript, Win bitmap and other formats. I'm only familiar with the old Version 4. The MAC version had a few more output options that the Windows version so that was the preferred solution. Version 4 may be available as abandonware. -- Wayne -----Original Message----- From: cctech [mailto:cctech-bounces at classiccmp.org] On Behalf Of Paul Koning Sent: Friday, April 29, 2016 9:19 AM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Calling all typographers > On Apr 29, 2016, at 12:07 PM, Rod Smallwood <rodsmallwood52 at btinternet.com> wrote: > > ... > If anybody has found or made or knows a download URL of any dec font it would help me of I could get hold of it. My version of the DEC font that's on those bezels and on older handbook covers can be found here: http://www.dbit.com/pub/misc/handbook.ttf paul

8 years, 7 months

strangest systems I've sent email from

by jnc＠mercury.lcs.mit.edu

> From: Mouse > It's true that C is easy to use unsafely. ... I suspect it is not > possible to eliminate the ability to do stupid things in C without also > eliminating the ability to do some clever things in C. Oh so true. Computer science progress seems to be all about improving on getting the most bang for the buck (i.e. it's really engineering, which is all about bang/buck ratios - as the saying goes, 'an engineer is someone who can do for $.10 what any fool can do for $1'). So assembly language is maximally flexible, but very easy to screw up. Something like C gives you 93% of the flexibility, but with only 40% of the chances to screw up. (Numbers only approximate, after 2 seconds of consideration.) So further language development has had to improve on that ratio; ideally, one should decrease the latter with impacting the former, if possible - a non-trivial problem. And of course the optimal flexibility/screwage ratio will differ from programmer to programmer, and even from project to project. (I once wrote a condition handler package for C, and elected to do it in assembler - even though others have done in it C, using longjump(). But there are very few things where assembler seems a better choice, to me.) > Note that PDP-11 autoincrement and autodecrement exist only when > ... the pointers are in registers. Of course, clever programmers will make sure their code is arranged (not warped into an non-understandable maze, mind, just... arranged properly) to do that! :-) But to really do that effectively, you have to be able to control which variables are in registers, etc, etc. Modern optimizing compilers like to do this all for you - and do an incredibly good job, most of the time, to the point where for most programmers, the compiler does a _better_ job than they could. So, for 97% of programmers, probably the right thing. For those who are writing real-time code, know exactly what instructions any piece of code will compile into, and how many memory references are involved, not so much. (Back to different strokes for different programmers.) (Yes, yes, I know those optimizations often aren't portable - I wrote a fair amount of code that ran on several architectures at the same point in time. But what was optimal on one was usually pretty good on the others, too.) Noel

8 years, 7 months

OT: LED lighting configuration...

by wh.sudbrink＠verizon.net

Sorry for the OT post but I'm pretty sure someone here will know how this stuff works... An office near me was recently demolished/remodeled. It had retrofitted LED lighting in fluorescent fixtures. The remodelers were smart enough to save the "bulbs" but not smart enough to save the "ballasts" (DC power supplies). Once they figured out that they couldn't easily use them, they gave a bunch to me. I'd like to use them but I'm having a little trouble figuring out how. The "bulbs" are labeled: 15F18120-45 15 watt 36vdc constant current I'd like to put four in a fixture and I'm trying to understand what kind of driver I need and how to wire it. I was thinking of using a Mean Well LPF-60D-36 like this: http://www.ebay.com/itm/Mean-Well-LPF-60D-36-AC-DC-POWER-SUPPLY-Dimmable-LED -DRIVER-36V-60W-CLASS2-/161857068172?hash=item25af6edc8c:g:9hQAAOSwA4dWHVn5 and wiring the "bulbs" in parallel to it. But after realizing that I'm not completely sure what a "constant current" power supply does and doing a little "googling" I don't know if that's the right approach. Any help greatly appreciated, Bill S.

8 years, 7 months

Gentoo (was Re: strangest systems I've sent email from)

by alexmcwhirter＠triadic.us

I can more or less agree with your sentiments, but given the choice of needing to maintain compatibility between many applications and being able to support multiple architectures such as SPARC and Power Gentoo is really the only choice. The only real close candidate would be FreeBSD which treats anything that isn't x86 as a second class citizen. I have my own issues with Linux as well, and as I said earlier I would much rather use illumos, but when it comes to business applications that always have to run and always maintain compatibility is new versions come out gentoo is as close to a BSD/Unix that I can get to and maintain compatibility with everything I need. Use flags can be cumbersome if you have tons of applications such as a desktop system. But that's generally not the case for servers which is really all I care about in this case. For me it's generally just maintaining a set of used flags for each application that I need which is generally pretty minimal per server / container. Profiles help make Use flags not as cumbersome, but it doesn't quite fix the issue. Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Swift Griggs <swiftgriggs at gmail.com> Date: 4/29/2016 12:10 PM (GMT-05:00) To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Subject: Gentoo (was Re: strangest systems I've sent email from) On Fri, 29 Apr 2016, alexmcwhirter at triadic.us wrote: > Gentoo is powerful because you get to chose your init system, kernel > options, and every other piece of software that runs on the box. Other than the swapping init systems, many OSS OS distributions have the ability to choose what you want to run. Not all are as granular as Gentoo (but some, say embedded distros, have even more control). There are dozens of Linux distros as you know, and this degree of control & granularity is one of the main variable. Ubuntu users want "just-worky-ness", Gentoo users often want tweakability in the extreme. It all depends on your needs and value system. > For example, dovecot on ubuntu pulls in ldap, sasl, etc... On gentoo you > choose what gets pulled in via USE flags. I guess there is no accounting for taste. I would not call USE flags a feature, my opinion is that they are painful in implementation (dragging around a list of way-too-many little keywords is not fun, IMHO), nasty to work with and have to look at (some giant wrap-around variables in the conf file), and make me feel dirty and disorganized. Plus, in my experience, if you accidentally put in two mutually exclusive or not-very-well-tested USE flags you are in for a hard time that might be difficult to track down (ie.. if the effects don't immediately surface). > CrossDev is also a great to that has helped me port gentoo to SPARC64 > with little to no issues. Cross compiling is neat, for sure. However, Gentoo doesn't have any unique claim on that (not that you implied that). Many other OSs have used the same methodology since long before Linux, much less Gentoo. -Swift

8 years, 7 months

← Newer
1
2
3
4
5
6
7
8
...
30
Older →

Jump to page:

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 April 2016