Another Java panel simulation for BlinkenBone is there, the classic
PDP-11/20.
In function and style it fills the gap between the PDP-8 and the later
PDP-11's.
The GitHub distribution starts the 1970 Paper-tape BASIC, download here:
https://github.com/j-hoppe/BlinkenBone/releases
Info
http://retrocmp.com/projects/blinkenbone/simulated-panels/253-blinkenbone-s…
and next page.
Now we have PDP-8/I, PDP-11/20, PDP-11/40, PDP-11/70 and PDP-10/KI10.
Not to mention the PiDP8 replica and soon the PiDP11.
Joerg
I tried starting up my AlphaStation 200 today. All I get is some beeps and
an LED diagnostic code that suggests the NVRAM test failed. I swapped the
battery, as the old one was dead, but it still refused to work. I have tried
connecting to the serial port and got nothing (although I could have a
problem with using the correct cable etc). I even tried flipping the jumper
that takes you to the mini console, to no avail.
Does anyone have any suggestions for reviving this machine?
Thanks
Rob
Dear Paul,
thanks for your email - I acquired the reader several years ago and
did quite a lot of experiments to figure out how to use it with the
original firmware SPTS11, 2.02, 5289 but I never got an answer from
the reader. So the project of Jim to read in the DG tapes was the
reason I needed to address this issue. For your (and the communities)
convenience I placed the original firmware (27C256 type EPROM)...
http://www.baigar.de/electronics/PTR-SPTS11-2.02-5289.bin
...and my new one (also 27C256)...
http://www.baigar.de/electronics/PTR-SPTS11-EB1.01.hex
...onto my server. My new firmware just sends out the data read via
the serial port at 9600, 8N1. A welcome messages tests the serial
communication on starting and during this time the red LED is on.
On getting ready the green LED takes over and the yellow one shows
the state of the sprocket input: For each byte read this LED
flashes. At 9600 the serial port is always faster than you can
pull the tape through the reader, so I do not expect the red
LED (indicate a buffer overflow, byte lost) come on during normal
operation...
The pinout of the Sub-D9 male plug is as usual on serial ports:
5: GND, 2: Data from reader to PC, 3: Data from PC to reader
(not used in my firmware, but original expects some start/config
command here) additionally 7: DC input to reader (in my case 9V).
Hope this helps,
best regards,
Erik.
On Tue, 26 Apr 2016, Paul Birkel wrote:
> Eric;
>
> Would you please share your firmware updates, and any other information that
> you've gleaned regarding the Vaisala SPT11A reader? I recently acquired one
> of these as well but haven't yet started on reverse-engineering it into
> something useful Would prefer to leverage your experience, if you please
> :->.
>
> Good health to You and Yours!
>
> paul
> (from Maryland, USA)
>
> -----Original Message-----
> From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Erik Baigar
> Sent: Monday, April 25, 2016 11:42 AM
> To: jim s; cctalk at classiccmp.org
> Cc: Sherman Foy
> Subject: Re: Data General Nova Star Trek
>
>
> Hi Jim,
>
> regarding reading the StarTrek paper tapes I spent some time on the weekend
> to rework my SPT11A manual reader - I got this from an eBay auction and it
> was an accessory for some military receiver (probalby to read in some
> codes). It had a fimrwaere which refused to communicate with a simple
> terminal program, so I reverse en- gineered the hardware and replaced the
> original ROM it by an own firmware which simply sends the contents read from
> PPT to the PC via its RS232C...
>
> http://www.baigar.de/vintage/SPT11A-mod-Internal.jpg
>
> So I'd offer sending this to you as an item on loan to read in your tapes
> and you return it afterwards? I tested it with some data and it works well
> (just slowly pull the paper tape through the reader and use e.g. putty to
> log the binary serial output). After turning on the reader there is a short
> welcome message to verify the serial connection (9600,8N1).
>
> The only question is, whether you can handle the EU style power supply shown
> in the picture...
>
> http://www.baigar.de/vintage/SPT11A-mod.jpg
>
> I ordered USB->RS232C converters and if you have some more time, I'd attach
> one of them to the reader not only doing conversion but also supplying the
> converter with power from the PC.
> Addidionally you should send me your physical address via PM so I can
> prepare for shipping...
>
> Best regards from Germany,
>
> Erik.
>
> -----
>
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
