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
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
> 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
> 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
> 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
> 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
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
> 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
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.
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
