Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.raspberry-pi > #11675 > unrolled thread

Direct digital I/O ?

Back to article view | Back to comp.sys.raspberry-pi

Contents

  Direct digital I/O  ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-09 14:47 +0100
    Re: Direct digital I/O ? GlowingBlueMist <GlowingBlueMist@blackhole.io> - 2016-06-09 11:22 -0500
    Re: Direct digital I/O  ? "Dave Liquorice" <allsortsnotthisbit@howhill.com> - 2016-06-09 19:56 +0100
      Re: Direct digital I/O  ? Paul <paul@pcserviceselectronics.co.uk> - 2016-06-10 19:55 +0100
        Re: Direct digital I/O  ? Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-10 22:27 +0000
          Re: Direct digital I/O  ? mm0fmf <none@invalid.com> - 2016-06-11 07:45 +0100
            Re: Direct digital I/O  ? Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-11 08:37 +0000
              Re: Direct digital I/O ? The Natural Philosopher <tnp@invalid.invalid> - 2016-06-11 09:41 +0100
                Re: Direct digital I/O ? "Dave Liquorice" <allsortsnotthisbit@howhill.com> - 2016-06-11 11:17 +0100
                  Re: Direct digital I/O ? Paul <paul@pcserviceselectronics.co.uk> - 2016-06-11 14:00 +0100
                  Re: Direct digital I/O ? cb@elaine.df.lth.se (Christian Brunschen) - 2016-06-11 16:12 +0000
                    Re: Direct digital I/O ? Paul <paul@pcserviceselectronics.co.uk> - 2016-06-12 22:00 +0100
                      Re: Direct digital I/O ? cb@elaine.df.lth.se (Christian Brunschen) - 2016-06-12 22:40 +0000
                        Re: Direct digital I/O ? Paul <paul@pcserviceselectronics.co.uk> - 2016-06-13 11:02 +0100
                  Re: Direct digital I/O ? Paul <paul@pcserviceselectronics.co.uk> - 2016-06-12 22:04 +0100
                Re: Direct digital I/O ? Paul <paul@pcserviceselectronics.co.uk> - 2016-06-11 13:49 +0100
              Re: Direct digital I/O  ? Rob <nomail@example.com> - 2016-06-11 09:23 +0000
                Re: Direct digital I/O  ? Ahem A Rivet's Shot <steveo@eircom.net> - 2016-06-11 10:47 +0100
              Re: Direct digital I/O  ? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-11 12:46 -0400
                Re: Direct digital I/O  ? mm0fmf <none@invalid.com> - 2016-06-12 09:20 +0100
                  Re: Direct digital I/O ? Michael J. Mahon <mjmahon@aol.com> - 2016-06-12 11:07 -0500
                  Re: Direct digital I/O  ? andrew@cucumber.demon.co.uk (Andrew Gabriel) - 2016-06-12 16:13 +0000
                    Re: Direct digital I/O  ? jeffj@panix.com (Jeff Jonas) - 2016-07-01 20:39 -0400
                      Re: Direct digital I/O  ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-02 10:40 +0100
                      Re: Direct digital I/O  ? Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-02 13:55 +0000
                        Re: Direct digital I/O ? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-07-02 19:22 +0300
                          Re: Direct digital I/O ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-02 17:47 +0100
                          Re: Direct digital I/O ? Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-02 17:07 +0000
                            Re: Direct digital I/O ? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-07-02 21:30 +0300
                              Re: Direct digital I/O ? The Natural Philosopher <tnp@invalid.invalid> - 2016-07-02 19:35 +0100
                              Re: Direct digital I/O ? Dave Higton <dave@davehigton.me.uk> - 2016-07-02 19:43 +0100
                                Re: Direct digital I/O ? The Natural Philosopher <tnp@invalid.invalid> - 2016-07-02 20:07 +0100
                      Re: Direct digital I/O  ? andrew@cucumber.demon.co.uk (Andrew Gabriel) - 2016-07-03 18:59 +0000
                        Re: Direct digital I/O  ? "Ivan D. Reid" <Ivan.Reid@ivan.fsnet.co.uk> - 2016-07-03 19:15 +0000
    Re: Direct digital I/O  ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-13 14:23 +0100
      Re: Direct digital I/O  ? Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-13 14:13 +0000
        Re: Direct digital I/O  ? Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-13 15:09 +0000
          Re: Direct digital I/O  ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-13 17:48 +0100
        Re: Direct digital I/O  ? mm0fmf <none@invalid.com> - 2016-06-13 17:45 +0100
          Re: Direct digital I/O  ? Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-13 17:04 +0000
            Re: Direct digital I/O  ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-13 19:13 +0100
        Re: Direct digital I/O  ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-13 17:47 +0100
      Re: Direct digital I/O  ? Paul <paul@pcserviceselectronics.co.uk> - 2016-06-13 17:49 +0100
        Re: Direct digital I/O  ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-13 19:07 +0100
        Re: Direct digital I/O ? rickman <gnuarm@gmail.com> - 2016-06-13 14:25 -0400
          Re: Direct digital I/O ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-13 19:45 +0100
            Re: Direct digital I/O ? Jim H <invalid@invalid.invalid> - 2016-06-13 20:14 +0000
              Re: Direct digital I/O ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-14 09:38 +0100
          Re: Direct digital I/O ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-13 19:57 +0100
            Re: Direct digital I/O ? Mike Fleming <{mike}@tauzero.co.uk> - 2016-06-14 10:48 +0100
              Re: Direct digital I/O ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-14 11:41 +0100
                Re: Direct digital I/O ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-14 11:48 +0100
              Re: Direct digital I/O ? rickman <gnuarm@gmail.com> - 2016-06-14 20:24 -0400
                Re: Direct digital I/O ? The Natural Philosopher <tnp@invalid.invalid> - 2016-06-15 08:13 +0100
                  Re: Direct digital I/O ? rickman <gnuarm@gmail.com> - 2016-06-15 03:26 -0400
                    Re: Direct digital I/O ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-15 08:54 +0100
                      Re: Direct digital I/O ? AndyW <Andy@nojunqmail.com> - 2016-06-15 16:48 +0100
                        Re: Direct digital I/O ? Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-15 21:02 +0000
                    Re: Direct digital I/O ? Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-15 11:21 +0000
                      Re: Direct digital I/O ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-15 16:21 +0100
                Re: Direct digital I/O ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-15 08:52 +0100
                Re: Direct digital I/O ? Gordon Levi <gordon@address.invalid> - 2016-06-15 18:57 +1000
                  Re: Direct digital I/O ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-15 10:28 +0100
                  Re: Direct digital I/O ? rickman <gnuarm@gmail.com> - 2016-06-15 10:57 -0400
                    Re: Direct digital I/O ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-15 16:23 +0100
                    Re: Direct digital I/O ? Paul <paul@pcserviceselectronics.co.uk> - 2016-06-15 16:46 +0100
                      Re: Direct digital I/O ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-15 17:04 +0100
                    Re: Direct digital I/O ? Rob Morley <nospam@ntlworld.com> - 2016-06-15 17:43 +0100
                      Re: Direct digital I/O ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-15 20:57 +0100
      Re: Direct digital I/O  ? Paul <paul@pcserviceselectronics.co.uk> - 2016-06-13 17:46 +0100
        Re: Direct digital I/O  ? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-06-13 19:06 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#11706 — Re: Direct digital I/O ?

mm0fmf <none@invalid.com> wrote:
> On 11/06/2016 17:46, Dennis Lee Bieber wrote:
>> On Sat, 11 Jun 2016 08:37:09 -0000 (UTC), Martin Gregorie
>> <martin@address-in-sig.invalid> declaimed the following:
>> 
>>> However, my main point still stands: that compared to the IMSAI 8080,
>>> PDP8, PDP11, or any of the late 60s mainframes, a similar panel for an
>>> RPi would need a ridiculous number of LEDs and switches simply due to the
>>> register and address widths.
>> 
>> And another processor just to handle the interface... Is an address bus
>> even exposed on these SoC? (I suppose for DRAM). Most of the peripherals
>> are either internal to the chip, or are using some serial protocol for data
>> transfer. Address width could be handled via HIGH/LOW inputs (still want
>> lots of LEDs for readback). Similar for data input.
>> 
>> Altair/IMSAI mostly needed a set of tri-state latches with the
>> switches/LEDs... Set switches for address, momentary contact switch to
>> latch (address bus is now locked) -- maybe automatically pulse the data
>> read line and latch to display. Set data switches, momentary contact to
>> latch/write to memory. Tri-state turned off when RUN switch activated so
>> LED just flicker whatever the processor was emitting...
>> 
> 
> Proper computers with "blinkenlichts" used low current filament bulbs 
> and not LEDS as they predated the LED's invention by many years. Such as 
> my old Data General Nova 1200.
> 

Or, in the vacuum tube days, neon bulbs. ;-)

My favorite was the Burroughs B220, which had over 200 neons on its
console, and twice that when its console "maintenance panels" were opened.
Each lamp was accompanied by a pushbutton that allowed setting or resetting
that bit. 

It had so many lights that, refitted with incandescents for filming, it was
a favorite "computer" in numerous films and TV shows--perhaps most
famously, Batman. ;-) (Batman also had a smaller computer in some earlier
episodes, which was the console of the B220's older, littler brother, the
Electrodata 205.)

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#11707

In article <njj60p$9ql$1@dont-email.me>,
	mm0fmf <none@invalid.com> writes:
> On 11/06/2016 17:46, Dennis Lee Bieber wrote:
>> On Sat, 11 Jun 2016 08:37:09 -0000 (UTC), Martin Gregorie
>> <martin@address-in-sig.invalid> declaimed the following:
>>
>>> However, my main point still stands: that compared to the IMSAI 8080,
>>> PDP8, PDP11, or any of the late 60s mainframes, a similar panel for an
>>> RPi would need a ridiculous number of LEDs and switches simply due to the
>>> register and address widths.
>>
>> 	And another processor just to handle the interface... Is an address bus
>> even exposed on these SoC? (I suppose for DRAM). Most of the peripherals
>> are either internal to the chip, or are using some serial protocol for data
>> transfer. Address width could be handled via HIGH/LOW inputs (still want
>> lots of LEDs for readback). Similar for data input.
>>
>> 	Altair/IMSAI mostly needed a set of tri-state latches with the
>> switches/LEDs... Set switches for address, momentary contact switch to
>> latch (address bus is now locked) -- maybe automatically pulse the data
>> read line and latch to display. Set data switches, momentary contact to
>> latch/write to memory. Tri-state turned off when RUN switch activated so
>> LED just flicker whatever the processor was emitting...
>>
> 
> Proper computers with "blinkenlichts" used low current filament bulbs 
> and not LEDS as they predated the LED's invention by many years. Such as 
> my old Data General Nova 1200.

Yep - I used to use a GEC 4080 minicomputer from the front panel.
With some 80 or so filamant lamps, some were inevitably dead, so
there was an art to being able to use the front panel in spite of
some of the lamps not working. Circular shifting a register from
the front panel was one way (and then shift it back). The other
was to pinch spare lamps from indicators you didn't care about and
fit them in the ones you needed (or pinch them from another machine
if there was one).

Many years ago, I wrote a GEC4080 emulator (which will run on the
Pi, although that wasn't the point). The front panel is implemented
using GTK+ as an X windows emulation of the original. I didn't think
to emulate dead lamps - maybe I should?

-- 
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

[toc] | [prev] | [next] | [standalone]

#12243

>> Proper computers with "blinkenlichts" used low current filament bulbs
>> and not LEDS as they predated the LED's invention by many years.

Several technologies were used for front panels:
miniature incandescent lamps, neon, nixie,
even DM160 (kinda like a magic eye tube: amplifier and display in one).

The wikipedia for Bi-quinary coded decimal
https://en.wikipedia.org/wiki/Bi-quinary_coded_decimal
shows many early computers' variations,
and the IBM 650 neon indicators.

Serial machines such as the LGP21 used a 3-line oscilloscope to show the registers.

>Yep - I used to use a GEC 4080 minicomputer from the front panel.
>With some 80 or so filamant lamps, some were inevitably dead, so
>there was an art to being able to use the front panel in spite of
>some of the lamps not working. Circular shifting a register from
>the front panel was one way (and then shift it back).

Clever workaround!
No lamp test?
Such buttons were usually hidden in the field/customer engineer's panel.

> The other was to pinch spare lamps from indicators
> you didn't care about

The "nice" panels had front-replaceable lamps.
Others required disassembly, even desoldering!

Some systems were clever and space-saving such as the Univac 1219
where the illuminated pushbuttons double as display and input!

[toc] | [prev] | [next] | [standalone]

#12254

"Jeff Jonas" <jeffj@panix.com> wrote in message 
news:nl72f4$h48$1@panix3.panix.com...
>>> Proper computers with "blinkenlichts" used low current filament bulbs
>>> and not LEDS as they predated the LED's invention by many years.
>
> Several technologies were used for front panels:
> miniature incandescent lamps, neon, nixie,
> even DM160 (kinda like a magic eye tube: amplifier and display in one).

On the original PDP11/20, the lamps were wire ended. Replacing them
was relatively easy, but the effort and mechanical shock involved in
plugging the card back in could make a few others fail!!!!!!!

[toc] | [prev] | [next] | [standalone]

#12267

On Fri, 01 Jul 2016 20:39:00 -0400, Jeff Jonas wrote:

>>> Proper computers with "blinkenlichts" used low current filament bulbs
>>> and not LEDS as they predated the LED's invention by many years.
> 
> Several technologies were used for front panels:
> miniature incandescent lamps, neon, nixie,
> even DM160 (kinda like a magic eye tube: amplifier and display in one).
>
I remember seeing DM160 on valve radios as tuning aids but don't recall 
seeing them any place else.

In my postgrad year I was using Philips crystallographic X-ray kit. The 
older system used decade counters with a fluorescent spot  - you looked 
at the top of the tube while the spot whizzed round against the number 
written on the panel alongside the tubes. The newer machine used nixie 
tubes.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#12275 — Re: Direct digital I/O ?

On 2.7.16 16:55, Martin Gregorie wrote:
> On Fri, 01 Jul 2016 20:39:00 -0400, Jeff Jonas wrote:
>
>>>> Proper computers with "blinkenlichts" used low current filament bulbs
>>>> and not LEDS as they predated the LED's invention by many years.
>>
>> Several technologies were used for front panels:
>> miniature incandescent lamps, neon, nixie,
>> even DM160 (kinda like a magic eye tube: amplifier and display in one).
>>
> I remember seeing DM160 on valve radios as tuning aids but don't recall
> seeing them any place else.
>
> In my postgrad year I was using Philips crystallographic X-ray kit. The
> older system used decade counters with a fluorescent spot  - you looked
> at the top of the tube while the spot whizzed round against the number
> written on the panel alongside the tubes. The newer machine used nixie
> tubes.


Your memory may have developed a drop here: The DM 160 is just a
digital on-off indicator. The tuning indicators have been some
other DM:s with analog pattern display.

The whizz-spot tubes were the counters at the same time. Each incoming
pulse moved the spot to the next anode.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#12285 — Re: Direct digital I/O ?

"Tauno Voipio" <tauno.voipio@notused.fi.invalid> wrote in message 
news:nl8pn8$d1$1@dont-email.me...
>
> The whizz-spot tubes were the counters at the same time. Each incoming
> pulse moved the spot to the next anode.

Digitrons, and if dispalying a digit instead of a rotating spot, Dekatrons.

[toc] | [prev] | [next] | [standalone]

#12289 — Re: Direct digital I/O ?

On Sat, 02 Jul 2016 19:22:00 +0300, Tauno Voipio wrote:

> Your memory may have developed a drop here: The DM 160 is just a digital
> on-off indicator. The tuning indicators have been some other DM:s with
> analog pattern display.
>
Then I've never seen a DM-160, only the magic-eye tuning indicators on 
valve radios. From the up-thread context I thought they were called 
DM-160s - my mistake.
 
> The whizz-spot tubes were the counters at the same time. Each incoming
> pulse moved the spot to the next anode.
>
Yes, I realised that and that the counters with nixie tube displays also 
needed a set of decade counters to (a) accumulate the counts and (b) 
drive the display tubes.

About a year later I was working with a Mossbauer spectrometer. This used 
a scintillation counter as its detector and a 400 channel multi-channel 
analyser to accumulate the counts that formed the spectrum. The analyser 
was based on solid state electronics but still used a CRT to display the 
spectrum.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#12292 — Re: Direct digital I/O ?

On 2.7.16 20:07, Martin Gregorie wrote:
> On Sat, 02 Jul 2016 19:22:00 +0300, Tauno Voipio wrote:
>
>> Your memory may have developed a drop here: The DM 160 is just a digital
>> on-off indicator. The tuning indicators have been some other DM:s with
>> analog pattern display.
>>
> Then I've never seen a DM-160, only the magic-eye tuning indicators on
> valve radios. From the up-thread context I thought they were called
> DM-160s - my mistake.
>


Look for DM70 or DM71, for example.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#12293 — Re: Direct digital I/O ?

On 02/07/16 19:30, Tauno Voipio wrote:
> On 2.7.16 20:07, Martin Gregorie wrote:
>> On Sat, 02 Jul 2016 19:22:00 +0300, Tauno Voipio wrote:
>>
>>> Your memory may have developed a drop here: The DM 160 is just a digital
>>> on-off indicator. The tuning indicators have been some other DM:s with
>>> analog pattern display.
>>>
>> Then I've never seen a DM-160, only the magic-eye tuning indicators on
>> valve radios. From the up-thread context I thought they were called
>> DM-160s - my mistake.
>>
>
>
> Look for DM70 or DM71, for example.
>
EM70..


-- 
A lie can travel halfway around the world while the truth is putting on 
its shoes.

[toc] | [prev] | [next] | [standalone]

#12295 — Re: Direct digital I/O ?

In message <nl918d$qgl$2@dont-email.me>
          Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:

>On 2.7.16 20:07, Martin Gregorie wrote:
>> On Sat, 02 Jul 2016 19:22:00 +0300, Tauno Voipio wrote:
>>
>>> Your memory may have developed a drop here: The DM 160 is just a digital
>>> on-off indicator. The tuning indicators have been some other DM:s with
>>> analog pattern display.
>>>
>> Then I've never seen a DM-160, only the magic-eye tuning indicators on
>> valve radios. From the up-thread context I thought they were called
>> DM-160s - my mistake.
>
>Look for DM70 or DM71, for example.

About fifty years afo I made a battery portable tape recorder that used
a DM71 (I think) as a recording level indicator - this was another use
case for "magic eye" valves.

Dave

[toc] | [prev] | [next] | [standalone]

#12297 — Re: Direct digital I/O ?

On 02/07/16 19:43, Dave Higton wrote:
> In message <nl918d$qgl$2@dont-email.me>
>            Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
>
>> On 2.7.16 20:07, Martin Gregorie wrote:
>>> On Sat, 02 Jul 2016 19:22:00 +0300, Tauno Voipio wrote:
>>>
>>>> Your memory may have developed a drop here: The DM 160 is just a digital
>>>> on-off indicator. The tuning indicators have been some other DM:s with
>>>> analog pattern display.
>>>>
>>> Then I've never seen a DM-160, only the magic-eye tuning indicators on
>>> valve radios. From the up-thread context I thought they were called
>>> DM-160s - my mistake.
>>
>> Look for DM70 or DM71, for example.
>
> About fifty years afo I made a battery portable tape recorder that used
> a DM71 (I think) as a recording level indicator - this was another use
> case for "magic eye" valves.
>
They were in the end cheaper than moving coil meters, and suited the 
high impedance valve circuits.

Once transistors arrived, MC VU meters were the obvious way to go, and 
stared to be churned out in millions

Then when LEDS turned up we used them as bar indicators.

Its all about what is cheap and does the job...




> Dave
>


-- 
Truth welcomes investigation because truth knows investigation will lead 
to converts. It is deception that uses all the other techniques.

[toc] | [prev] | [next] | [standalone]

#12369

In article <nl72f4$h48$1@panix3.panix.com>,
	jeffj@panix.com (Jeff Jonas) writes:
>>> Proper computers with "blinkenlichts" used low current filament bulbs
>>> and not LEDS as they predated the LED's invention by many years.
> 
> Several technologies were used for front panels:
> miniature incandescent lamps, neon, nixie,
> even DM160 (kinda like a magic eye tube: amplifier and display in one).
> 
> The wikipedia for Bi-quinary coded decimal
> https://en.wikipedia.org/wiki/Bi-quinary_coded_decimal
> shows many early computers' variations,
> and the IBM 650 neon indicators.
> 
> Serial machines such as the LGP21 used a 3-line oscilloscope to show the registers.
> 
>>Yep - I used to use a GEC 4080 minicomputer from the front panel.
>>With some 80 or so filamant lamps, some were inevitably dead, so
>>there was an art to being able to use the front panel in spite of
>>some of the lamps not working. Circular shifting a register from
>>the front panel was one way (and then shift it back).
> 
> Clever workaround!
> No lamp test?

Not on the original 4080.
Later machines had a lamp test, but only had a handfull of lamps
indicating running, halted, reset, i/o, and so on, not things like
register contents. That level of control moved to a serial (teletype)
console.

> Such buttons were usually hidden in the field/customer engineer's panel.
> 
>> The other was to pinch spare lamps from indicators
>> you didn't care about
> 
> The "nice" panels had front-replaceable lamps.

These were minature bin-pin lamps, which were replacable from the
front if you levered off the coloured cap. There was a special
extraction tool which gripped the lamp and pulled it out from a
deep recess. I never saw one of these in my 15 years there - we
used the barrel of a ball-point pen which mostly worked, but would
occasionally break the bulb. If you shorted the filament support
wires, that instantly blew the 75 series driver chips which had
no margin for any overcurrent, and that lamp then wouldn't work
without a board repair.

> Others required disassembly, even desoldering!
> 
> Some systems were clever and space-saving such as the Univac 1219
> where the illuminated pushbuttons double as display and input!
> 

-- 
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

[toc] | [prev] | [next] | [standalone]

#12372

On Sun, 3 Jul 2016 18:59:31 -0000 (UTC), Andrew Gabriel 
<andrew@cucumber.demon.co.uk>
 wrote in <nlbnaj$q9d$1@dont-email.me>:

> These were minature bin-pin lamps, which were replacable from the
> front if you levered off the coloured cap. There was a special
> extraction tool which gripped the lamp and pulled it out from a
> deep recess. I never saw one of these in my 15 years there - we
> used the barrel of a ball-point pen which mostly worked, but would
> occasionally break the bulb.

	I think we had one somewhere -- can't remember which computer... 
-- but a length of rubber or soft plastic tubing also worked often enough.

-- 
Ivan Reid, School of Engineering & Design, _____________  CMS Collaboration,
Brunel University.    Ivan.Reid@[brunel.ac.uk|cern.ch]    Room 40-1-B12, CERN
        KotPT -- "for stupidity above and beyond the call of duty".

[toc] | [prev] | [next] | [standalone]

#11714

"gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> wrote in message 
news:njbs2a$96b$1@dont-email.me...
> Inspired by Oscar Vermeulen's emulations of PDP8 and PDP11 front
> panels (I've used both processors, in my time over the past 40 years)
> but as yet inexperienced in the RPi world (despite getting Pi1 2
> years ago and Pi2 one year ago :-(  ),  I'd like to consider
> producing a similar front panel low-level access for the RPi itself.
> Is anyone aware of direct digital I/O facilities for the RPi, ie, in
> not going via the I2C bus?
> Or, even an I/O bus creation facility, perhaps much along the lines
> of the PDP8's Omnibus?
> Also, what of interfacing a hard disk into the SD card slot.?
> Apologies if I have posed these questions before, for it
> always takes me many months to come to a definite decision;
> never put off till tomorrow what you can put off till the day after :-)

Interesting that the above has fomented a lot of negative thinking
and defeatism, and, for the moaners in those categories, yes, I
agree wholeheartedly, that it wouldn't work out for you.

I had in mind a miniscult monitor program, with NMI being
driven from the ersatz Halt switch, and to use the built-in
debug instructions to perform single stepping.

[toc] | [prev] | [next] | [standalone]

#11715

On Mon, 13 Jun 2016 14:23:57 +0100, gareth G4SDW GQRP #3339 wrote:

> I had in mind a miniscult monitor program, with NMI being driven from
> the ersatz Halt switch, and to use the built-in debug instructions to
> perform single stepping.
>
I suppose you realise that in a RPi the GPU is started first and it in 
turn executes the first stage bootstrap, which in turn loads and boots 
the Linux kernel? That means you'll need to persuade the first stage 
bootstrap to load your monitor and then load the Linux kernel above it at 
a modified address so it doesn't overwrite your monitor? 

Doing that will almost certainly need access to proprietary information, 
so think license fees and NDA agreements, and you're still stuck with the 
problem of connecting switches and LEDs to a series of 32 bit wide items 
(address bus, data bus and registers). 

I have experience of using similar switches and lamps on a 24 bit word-
based bigendian mainframe. It was hard enough to get the settings right 
on that, but attempting the same trick on a little-endian 32-bit system 
seems like the perfect recipe for data entry mistakes. 

I've also written my own monitor for a 8/16 bit 6809, also a bigendian 
architecture. It never occurred to me to work at the bitstring level on 
that because inputting and reading hex via screen and keyboard was so 
much easier to use.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#11716

On Mon, 13 Jun 2016 14:13:52 +0000, Martin Gregorie wrote:

> I have experience of using similar switches and lamps on a 24 bit word-
> based bigendian mainframe.
>
Yes, I realise that describing a 24 bit word architecture as 'bigendian' 
may look a bit redundant, but it does emphasise where the MSB bit is and 
in any case, the machine could deal with multi-word integers, which used 
a bigendian word order.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#11722

"Martin Gregorie" <martin@address-in-sig.invalid> wrote in message 
news:njmib4$5lv$1@dont-email.me...
> On Mon, 13 Jun 2016 14:13:52 +0000, Martin Gregorie wrote:
>> I have experience of using similar switches and lamps on a 24 bit word-
>> based bigendian mainframe.
> Yes, I realise that describing a 24 bit word architecture as 'bigendian'
> may look a bit redundant, but it does emphasise where the MSB bit is and
> in any case, the machine could deal with multi-word integers, which used
> a bigendian word order.

Little endian makes more sense, because as you calculate, presumably
additions, you autoincrement up the addresses.

[toc] | [prev] | [next] | [standalone]

#11720

On 13/06/2016 15:13, Martin Gregorie wrote:
> I suppose you realise that in a RPi

He spends his life trolling in uk.r.a. and other groups Martin.

[toc] | [prev] | [next] | [standalone]

#11725

On Mon, 13 Jun 2016 17:45:05 +0100, mm0fmf wrote:

> On 13/06/2016 15:13, Martin Gregorie wrote:
>> I suppose you realise that in a RPi
> 
> He spends his life trolling in uk.r.a. and other groups Martin.

OK, thanks. I think a plonking is in order.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.sys.raspberry-pi

csiph-web