Tornado Computer Unit - Any info around?
Erik Baigar
Dear avionics and tornado enthusiasts,
Recently I came across an part of computer
equipment originating from a tornado aircraft.
The original avionics equipment of these aircraft
has been replaced by a more up to date one according
to several internet sites.
The item looks like a complete computer with
the size of a shoebox and contains core memory,
processor boards and interface boards as well as
some kind of power supply.
Since this was high tech in the 70ies and it should
be preserved as well as all information available.
Thus I'd highly be interested in learning more about
this unit (maybe it can be brought up to play a
ported version of the PDP8 chess game chekmo?)!
Therefore I describe what I know up to date and
perhaps someone has more info for me which can
be useful in any manner...
The label reads "Programmer electronic Control", manufactured
by Marconi Avionics with part number 51-019-02, NSN1680-99-652-3410.
There are lots of boards in it. Among them are boards dealing with
driving the core memory:
(1) Driver Board, 1680-99-646-6754 and
(2) Data Board, 1680-99-646-6755.
The core memory itself consists of a sandwich of two boards
by GEC-Computers. The capacity must be around 64k Bits:
(3) Core Memory, 5841-99-652-3386.
There is another driver board identical to (1):
(4) Driver Board, 1680-99-646-6754 followed by an
(5) Control Board, 1680-99-646-6753.
Next there follow boards which seem to be a kind of processor
(6) Data Register, 229-013909 and a second
(7) Data Register, 229-013909
(8) Control Register, 229-013551
The following board contains some kind of ROM (MMI5330-IJ) which
I suppose contain the micro-code, i.e. represent the machine
language of the device (concluding from pinput the ROMs maybe
512*4 or lower capacity):
(9) Function Decode, 229-013549
The next board contains several monoflops but if it is connected
to 5V (which seems to be its only supply) it drwas approx. 0.7A
but does not generate any signals. This board seems to generate
various timings but NOT the master clock:
(10) Processor Timing, 229-013547
Than there follows a group of boards, obviously dealing
with IO:
(11) RxTx Interface, 229-013545
(12) Serial Parallel Converter, 229-016304
(13) Decode and Interrupt, 229-013905
The last board is the only board to contain a crystal
running at 8MHz and several monofolps as well. Powered
(by obviuosly a single 5V supply, consuming 1.05A) this
board distrubutes some signals to the mainboard.
The most interesting things would be a schematic (of
course!) and a instruction set - any ideas?? Of course
reverse engineering would be possible, but it would
be extremely difficult: Multilayer boards, lots of 74xx
chips, everyting glued and protected by acryl coating...
So any hints (supply voltages, pinouts of the connectors)
are welcome...
Best regards,
Erik.
Simon Robbins
"Erik Baigar" <er...@baigar.de> wrote in message
news:41E419AB...@baigar.de...
> Since this was high tech in the 70ies and it should
> be preserved as well as all information available.
> Thus I'd highly be interested in learning more about
> this unit (maybe it can be brought up to play a
> ported version of the PDP8 chess game chekmo?)!
I don't know what the box is but I wouldn't expect it to still be in working
order. Onboard systems get a real beating and it's line-replacable cards go
unservicable all the time. If you can identify the interfaces you might
get lucky in trying to figure out what it connects to, but without detailed
interface specs you'll never be able to drive it, and those may well be
proprietary information, and protected to this day. (Of course, knowing the
RAF, it might well be servicable and still fitted to half the Tornado
fleet...)
You could always try and sell it on ebayski!!
Si
Alan Dicey
> Dear avionics and tornado enthusiasts,
>
> Recently I came across an part of computer
> equipment originating from a tornado aircraft.
> The original avionics equipment of these aircraft
> has been replaced by a more up to date one according
> to several internet sites.
>
> The item looks like a complete computer with
> the size of a shoebox and contains core memory,
> processor boards and interface boards as well as
> some kind of power supply.
>
> Since this was high tech in the 70ies and it should
> be preserved as well as all information available.
> Thus I'd highly be interested in learning more about
> this unit (maybe it can be brought up to play a
> ported version of the PDP8 chess game chekmo?)!
>
> Therefore I describe what I know up to date and
> perhaps someone has more info for me which can
> be useful in any manner...
>
> The label reads "Programmer electronic Control", manufactured
> by Marconi Avionics with part number 51-019-02, NSN1680-99-652-3410.
> There are lots of boards in it. Among them are boards dealing with
> driving the core memory:
This is a dedicated avionics box, from the FCS, and is perhaps
comparable to a modern automobile ECU; not in any way a general purpose
computer. Off the top of my head, the processor will be a proprietary
Marconi bit-slice machine. It is very specifically designed for
real-time safety-critical processing, taking inputs from the flight
controls and airframe sensors and providing outputs to the control
surfaces. Not even an RS-232 interface, no display functions. I think
the chances of making any use of it are very slim indeed, and it is most
likely that the insides are fried anyway. Where on earth did you get it
from?
> The most interesting things would be a schematic (of
> course!) and a instruction set - any ideas?? Of course
> reverse engineering would be possible, but it would
> be extremely difficult: Multilayer boards, lots of 74xx
> chips, everyting glued and protected by acryl coating...
> So any hints (supply voltages, pinouts of the connectors)
> are welcome...
I don't know for sure, but I suspect that such things will still be
classified. Good luck. Let us know if you find anything...
Erik Baigar
>
> "Erik Baigar" <er...@baigar.de> wrote in message
> news:41E419AB...@baigar.de...
> > Since this was high tech in the 70ies and it should
> > be preserved as well as all information available.
> > Thus I'd highly be interested in learning more about
> > this unit (maybe it can be brought up to play a
> > ported version of the PDP8 chess game chekmo?)!
>
> I don't know what the box is but I wouldn't expect it to still be in working
> order.
the components have all been very common 20 years ago and you
could find them all in discarded electronics.
> interface specs you'll never be able to drive it, and those may well be
> proprietary information, and protected to this day. (Of course, knowing the
You are absolutely right. Since the unit seems to be rather old and
the technology used, was obsolete 10 years ago, my hope is that some
information is already around. But if it is still classified, the
best would be not to waste any time and put the box apart and throw
it away...
> You could always try and sell it on ebayski!!
It's from there, but from .uk, not .ski ;-)
Thanks anyway,
Erik.
Erik Baigar
> This is a dedicated avionics box, from the FCS, and is perhaps
> comparable to a modern automobile ECU; not in any way a general purpose
> computer.
> surfaces. Not even an RS-232 interface, no display functions. I think
I did not expect a monitor interface and a linux port but maybe some
proprietary serial connection and boot process (I doubt that someone
would store vital software in core memory linke in ROMs).
> the chances of making any use of it are very slim indeed, and it is most
> likely that the insides are fried anyway.
I agree, that the chance of geting a unit one does not know anything
about and which is likely defective, back to do someting useful is very
small!
> Where on earth did you get it
> from?
Since one of my hobbies is to restore old computer hardware,
I regularly screen eBay for "core memory" and there I came
across these units. A company in the UK sold some of them
and they where rather cheap (compared to a PDP8 or someting
like this). Look at e.g. at item no. 2282449528 - there you
will find some photos, too. This company (abex) seems to sell
military surplus from time to time. Look at at their site
http://www.abex.co.uk/sales/sales.html for their sales page
and at http://www.abex.co.uk/sales/electronic/other/other.htm
for the military items.
> > be extremely difficult: Multilayer boards, lots of 74xx
> > chips, everyting glued and protected by acryl coating...
> > So any hints (supply voltages, pinouts of the connectors)
> > are welcome...
> I don't know for sure, but I suspect that such things will still be
> classified. Good luck. Let us know if you find anything...
Apart two answers no info up to date, but thanks a lot for
your explanations.
John Cook
then you'd have the complete set??.
Details of this of equipment tend to escape rather than be released,
someone who used to maintaine them may be of help, try
WWW.PPrune.org
Its stuffed full of people who know whats what!, and they could a
least tell you if its a bit erm!!! - 'sensitive' or not.
Cheers
John Cook
Any spelling mistakes/grammatic errors are there purely to annoy. All
opinions are mine, not TAFE's however much they beg me for them.
Email Address :- Jwcook@(trousers)ozemail.com.au
Spam trap - please remove (trousers) to email me
Eurofighter Website :- http://www.eurofighter-typhoon.co.uk
Simon Robbins
> I did not expect a monitor interface and a linux port but maybe some
> proprietary serial connection and boot process (I doubt that someone
> would store vital software in core memory linke in ROMs).
Actually it almost certainly is on PROM. The only stuff that's normally
loaded into volatile memory is mission specific files and any additional
data that is of a classified nature. There'll be a procedure for trashing
any such data upon enemy interception, forced landing on unfriendly soil,
etc. But from what someone else said, it doesn't sound like a mission
computer so probably doesn't have that kind of feature.
Si
Benjamin Gawert
> Recently I came across an part of computer
> equipment originating from a tornado aircraft.
> The original avionics equipment of these aircraft
> has been replaced by a more up to date one according
> to several internet sites.
>
> The item looks like a complete computer with
> the size of a shoebox and contains core memory,
> processor boards and interface boards as well as
> some kind of power supply.
>
> Since this was high tech in the 70ies and it should
> be preserved as well as all information available.
> Thus I'd highly be interested in learning more about
> this unit (maybe it can be brought up to play a
> ported version of the PDP8 chess game chekmo?)!
>
> Therefore I describe what I know up to date and
> perhaps someone has more info for me which can
> be useful in any manner...
>
> The label reads "Programmer electronic Control", manufactured
> by Marconi Avionics with part number 51-019-02, NSN1680-99-652-3410.
If I remember right this LRU is part of the Flight Control System
(Autopilot). It was interfaced to the Control and Stability Augmentation
System (CSAS) Control Unit.
It's probably from one of the EOL'd GR.1 that the UK did salvage. The FCS
however isn't really a confidential part, so it's imagineable that these
parts somehow might find hands on ebay from time to time.
> The most interesting things would be a schematic (of
> course!) and a instruction set - any ideas??
Forget it! These is not Your average old computer. It's a very specialized
device with limited capability. The processors aren't freely programmable
like the ones in general purpose computers. The interfaces are MIL-STD 1553B
with proprietary data word formats, barely suitable for anything You can do
with it...
Benjamin
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Alan Dicey
> Alan Dicey wrote:
>
>>This is a dedicated avionics box, from the FCS, and is perhaps
>>comparable to a modern automobile ECU; not in any way a general purpose
>>computer.
>
> OK, you mean some hard wired and optimized failsafe operations.
>
Not really. If, as I think, it is part of the FCS, it has no
general-purpose i/o, everything is dedicated. Inputs will be tailored
for the stick, pedal and throttle position sensors, pitot-static inputs,
etc. Outputs will expect to drive control surface actuators.
> I did not expect a monitor interface and a linux port but maybe some
> proprietary serial connection and boot process (I doubt that someone
> would store vital software in core memory linke in ROMs).
No serial interface: nothing will need it. This is a real-time system,
where dedicated, predictable, repeatable response times are paramount.
Someone upthread mentioned MIL-STD-1553: Tornado (if this was a Tornado
box) does use the 1553 bus, but not for the FCS. Too slow and
upredictable...
You do know that ferrite core memory is non-volatile, don't you?
However, there will have been a PROM with the clever bits in it somewhere.
No boot process. Nothing to boot. No OS.
>
> I agree, that the chance of geting a unit one does not know anything
> about and which is likely defective, back to do someting useful is very
> small!
>
About the only thing you could hope to use this box for is as part of a
Tornado simulator. And for that you'd need the control law maps, which
will not have been in the box, being MAv (and thus now BAE SYSTEMS)
proprietary.
>
>>Where on earth did you get it
>>from?
>
> Since one of my hobbies is to restore old computer hardware,
> I regularly screen eBay for "core memory" and there I came
> across these units. A company in the UK sold some of them
> and they where rather cheap (compared to a PDP8 or someting
> like this). Look at e.g. at item no. 2282449528 - there you
> will find some photos, too. This company (abex) seems to sell
> military surplus from time to time. Look at at their site
> http://www.abex.co.uk/sales/sales.html for their sales page
> and at http://www.abex.co.uk/sales/electronic/other/other.htm
> for the military items.
>
Interesting site. I have never seen an avionics black box described as
a work of art before. Makes me think that they want entirely too much
money for it...
Erik Baigar
> > The most interesting things would be a schematic (of
> > course!) and a instruction set - any ideas??
> Forget it! These is not Your average old computer. It's a very specialized
> device with limited capability. The processors aren't freely programmable
> like the ones in general purpose computers. The interfaces are MIL-STD 1553B
> with proprietary data word formats,
and the implementation of this standard, but this more advanced than
this
box. The box with its hundreds of pins in the connectors (see pics on
the
abex homepage mentioned in another posting) looks different - as Alan
Dicey
already mentioned.
Erik Baigar
quite a big amount of memory for those days. And compared
to the ROMS (DIL14, i.e. max 2kBits per chip) its huge.
> However, there will have been a PROM with the clever bits in it somewhere.
Maybe another box.
> About the only thing you could hope to use this box for is as part of a
> Tornado simulator. And for that you'd need the control law maps, which
> will not have been in the box, being MAv (and thus now BAE SYSTEMS)
> proprietary.
Since I do not know anything about this aircraft or avionics in general
this is no option. I think I'd best use the box for placing the nicest
looking part on my bookshelf and discarding the rest. ;-)
> > military surplus from time to time. Look at at their site
> > http://www.abex.co.uk/sales/sales.html for their sales page
> > and at http://www.abex.co.uk/sales/electronic/other/other.htm
> > for the military items.
> Interesting site. I have never seen an avionics black box described as
> a work of art before.
It is not directly art, but from an engineering point of view
it is nicely designed: Case milled out of a compact aluminium
body, cover has stuctures milled in, to make it more rigid.
Yes, I'd admit that the pictures at abex are nice to look at (the real
one has more damages). But on the other hand, e.g. it's missing
an electrical connection between the body and the cover - there is
a rubber seal inbetween. So I do not wonder why in Bavaria/Germany
Government had to declare the area around a strong broadcasting station
as a "do not fly in zone" after a military aircraft had trouble there...
> Makes me think that they want entirely too much
Compared to the prices one has to pay for a very common
core plane ripped from an IBM mainframe the 70pounds
are not so much. This was the main motivation for me to
bid.
Simon Robbins
news:41e6f327$0$91441$ed26...@ptn-nntp-reader03.plus.net...
> Interesting site. I have never seen an avionics black box described as
> a work of art before. Makes me think that they want entirely too much
> money for it...
I once spent an enjoyable hour throwing unserviceable old ruggedised ATR
boxes at a stack of old monitors that we'd lined up along the back wall of a
skip. Never occurred to us that we were committing artistic vandalism!
:^)
Si
Simon Robbins
> google-ing for 1553B one finds lots of documents describing the basics
> and the implementation of this standard, but this more advanced than
> this
> box. The box with its hundreds of pins in the connectors (see pics on
> the
> abex homepage mentioned in another posting) looks different - as Alan
> Dicey
> already mentioned.
Mil-Std-1553B describes the protocols for message interaction, not the
content of the messages themselves which would be specific to the
application, and likely proprietary. Like knowing how TCP/IP works doesn't
give you any clue about the content or purpose of emails traversing it.
1553B is generally used for low-priority mission data, i.e. radar contacts,
nav data, etc. not real-time control.
I'm guessing your "hundreds of pins" are huge, round, screw-in things, no?
These are a standard fitting, but not a standard interface. The pin-outs
will be specific to the application, and only the wiring diagrams and
Interface Control Documents will shed any light on what pins do what. Many
large connectors of his type carry multiple pin-out sets for multiple
interfaces. The wiring will then branch off in different cables from the
wiring harness to seperate other boxes.
If I were you, I'd be tempted to strip the guts out of the box and try and
build myself a nice little PC inside it, using the mini-PC motherboards and
stuff available these days. Then custom build myself some cable adaptors to
use those obscure connectors. Heck it'd make a great embedded PC box in a
homebuilt sim cockpit!!
Si
John Cook
I was involved in the driving over 50 nearly new computers in a
bulldozer......including the monitors,hdd,cpu,ram, then individually
making sure the ram, hdd, and cpu's were destroyed.
I can understand Hdd and monitors, but cpu's and ram!!!.
Made me very very sad as they were 10 times better than my old clunker
at the time...
Cheers
>
>Si
Erik Baigar
> Mil-Std-1553B describes the protocols for message interaction, not the
> content of the messages themselves which would be specific to the
> application, and likely proprietary. Like knowing how TCP/IP works doesn't
> give you any clue about the content or purpose of emails traversing it.
> 1553B is generally used for low-priority mission data, i.e. radar contacts,
> nav data, etc. not real-time control.
Yep, I see - therefore not present in the mentioned Flight Control box
since
it is realtime.
> I'm guessing your "hundreds of pins" are huge, round, screw-in things, no?
Exactly.
> These are a standard fitting, but not a standard interface. The pin-outs
> will be specific to the application, and only the wiring diagrams and
> Interface Control Documents will shed any light on what pins do what. Many
> large connectors of his type carry multiple pin-out sets for multiple
> interfaces. The wiring will then branch off in different cables from the
> wiring harness to seperate other boxes.
Ah, I see - so there will be the same type of connector in many
of the boxes (if the one box is so highly specific there must be 10
or more boxes like this aboard such an aircraft?). And pinouts are
different since the right connections are done by the branches
of the cable tree. So plugging everything in the service personnel
has to pay attention not to interchange the plugs, right?
> If I were you, I'd be tempted to strip the guts out of the box and try and
> build myself a nice little PC inside it, using the mini-PC motherboards and
> stuff available these days. Then custom build myself some cable adaptors to
> use those obscure connectors. Heck it'd make a great embedded PC box in a
> homebuilt sim cockpit!!
Hey, that sounds a good idea. I think it will only be rather difficult
to get the right connectors fitting into the plugs after all I have
learned form the postings ;-)
Erik.
Erik Baigar
>
> On Sat, 15 Jan 2005 00:34:39 -0000, "Simon Robbins"
> <si...@NOSPAMsjrobbins.demon.co.uk> wrote:
>
> >"Alan Dicey" <al...@removethis.diceyhome.free-online.co.uk> wrote in message
> >news:41e6f327$0$91441$ed26...@ptn-nntp-reader03.plus.net...
> >> a work of art before. Makes me think that they want entirely too much
> >> money for it...
> >
> >I once spent an enjoyable hour throwing unserviceable old ruggedised ATR
> >boxes at a stack of old monitors that we'd lined up along the back wall of a
> >skip. Never occurred to us that we were committing artistic vandalism!
> >:^)
>
> I was involved in the driving over 50 nearly new computers in a
> bulldozer......including the monitors,hdd,cpu,ram, then individually
> making sure the ram, hdd, and cpu's were destroyed.
>
> I can understand Hdd and monitors, but cpu's and ram!!!.
>
> Made me very very sad as they were 10 times better than my old clunker
> at the time...
>
> Cheers
>
can be thrown using a firmly connected VGA-cable. But the stuff
which was destroyed there was far much common and thus - in my
opinion - it was definitively not vandalism. But in the case of
such a black box . . . . . ;-)
Simon Robbins
> Ah, I see - so there will be the same type of connector in many
> of the boxes (if the one box is so highly specific there must be 10
> or more boxes like this aboard such an aircraft?). And pinouts are
> different since the right connections are done by the branches
> of the cable tree. So plugging everything in the service personnel
> has to pay attention not to interchange the plugs, right?
There could well be many similar connectors on multiple boxes but typically
the boxes will use connectors where the locating lugs on the outside of the
screw housing will be in different places, so even though several connectors
are the same size and number of pins, you can't screw the wrong one in.
You'll likely have numerics next to each connector socket, which will match
labels on the plugs on the loom. At least that's my experience of those
mil-spec connectors anyway. I don't know specifically about the box you
have, but most aircraft wll have several of those ATR/half ATR form-factor
boxes doing specific and different tasks, some may also be duplicate for
dual-redundancy in case of failure.
Si
Benjamin Gawert
> google-ing for 1553B one finds lots of documents describing the basics
> and the implementation of this standard, but this more advanced than
> this
> box. The box with its hundreds of pins in the connectors (see pics on
> the
> abex homepage mentioned in another posting) looks different - as Alan
> Dicey
> already mentioned.
I'm working with several avionics black boxes that contain "hundred of
pins". The No. of pins says nothing about the interface type...
The Tornado FCS is connected to the main computer over one of the IFUs
(Interface Units) using a 1553B (which btw. is also suitable for real-time
tasks like for FCS, but not used in the PA200 for the purpose of
transmitting control inputs)...
Alan Dicey
> Dear avionics and tornado enthusiasts,
>
> Recently I came across an part of computer
> equipment originating from a tornado aircraft.
> The original avionics equipment of these aircraft
> has been replaced by a more up to date one according
> to several internet sites.
snip
>
> The label reads "Programmer electronic Control", manufactured
> by Marconi Avionics with part number 51-019-02, NSN1680-99-652-3410.
> There are lots of boards in it. Among them are boards dealing with
> driving the core memory:
>
If as you suspect this was part if a Tornado Flight Control System, I'd
be looking for names like CSAS, SPILS, AFDS, ADC, whch are the
designations of the principal parts of the system. One other possiblity
is that it is part of the SMS (Stores Management System). I can't
decode the part numbers.
Erik Baigar
> Details of this of equipment tend to escape rather than be released,
> someone who used to maintaine them may be of help, try
> WWW.PPrune.org
beeing online there have been around 80 views but no reply yet.
By the way, this Rumor Network is a very interesting forum
where one can learn a lot if interesting things and where a
lot of highly actual information around aircraft and related
topics are available - Thanks for this hint!
Erik Baigar
>
> John Cook wrote:
> > Details of this of equipment tend to escape rather than be released,
> > someone who used to maintaine them may be of help, try
> > WWW.PPrune.org
> In the meantime I placed a posting there. After 24 hours of
> beeing online there have been around 80 views but no reply yet.
Took some pictures of the Programmer Electronic Control box
ant put them onto my homepage, since I was not allowed to
place a Link in my posting on PPruNe, see
http://www.baigar.de/TornadoComputerUnit/
John Cook
<patandch...@btinternet.com> wrote:
>Have you tried contacting Marconi Avionics in Rochester UK as they
>were probably the makers.
>
>
>http://www.enhanceproject.com/Presentation/partners-presentation/gecavionics.pdf#search='Marconi%20Avionics%20rochester'
>
>I remember visiting the test division there and see various units
>being tested in environmental chambers. They were testing to +100K
>feet and -200 feet, When questioned about the viability of the limits
>they said the plus value was in case it got that high with a AAM up
>it's "arse" and the minus in case the Israelis brought some and based
>them in under ground hangers by the Dead Sea!
>Blue Skies
>Pat Carpenter
I was at the college opposite, when two Tornado's did a Very low
flypast as a thank you!!, rattle every window in the building, and
scared us all to death as we were not expecting it!!
The return flypast was much better as we were ready for it...
Cheers
Pat Carpenter
<al...@removethis.diceyhome.free-online.co.uk> wrote:
Have you tried contacting Marconi Avionics in Rochester UK as they
Alan Dicey
>
> Have you tried contacting Marconi Avionics in Rochester UK as they
> were probably the makers.
>
>
> http://www.enhanceproject.com/Presentation/partners-presentation/gecavionics.pdf#search='Marconi%20Avionics%20rochester'
>
> I remember visiting the test division there and see various units
> being tested in environmental chambers. They were testing to +100K
> feet and -200 feet, When questioned about the viability of the limits
> they said the plus value was in case it got that high with a AAM up
> it's "arse" and the minus in case the Israelis brought some and based
> them in under ground hangers by the Dead Sea!
It hasn't been Marconi Avionics for a long time now. When I joined it
it was MEASLs (Marconi-Elliott Avionic Systems Limited), which then
became Marconi Avionics, then GEC Avionics. About five or six years ago
the Defence bits of GEC were bought by British Aerospace, the whole
becoming BAE Systems. The other bits of Marconi tried to make a killing
in networking and came ustuck in a big way.
So what was Marconi Avionics is now BAE Systems. The Rochester factory
is still there and still in the avionics business. It makes the
Eurofighter Typhoon FCS. If all else fails I'll go and see if I can
find any of the project staff left over from Tornado days - they might
recognise this box.
Erik Baigar
> So what was Marconi Avionics is now BAE Systems. The Rochester factory
> is still there and still in the avionics business. It makes the
> Eurofighter Typhoon FCS. If all else fails I'll go and see if I can
> find any of the project staff left over from Tornado days - they might
> recognise this box.
mentioned that the box might be classified even today. But in the
meantime
I know for sure that it is not mentioned in BAE's electronic databases
in
the tornado context. I am not very astonished about this since it must
be
around 25 years old and has serial number 42. It must originate from a
very early version and is not used today...
But if I imagine beeing asked in 2030 about things I have done today
I do not know how much I will be able to remember than... ;-)
Harry Andreas
> Alan Dicey wrote:
> > So what was Marconi Avionics is now BAE Systems. The Rochester factory
> > is still there and still in the avionics business. It makes the
> > Eurofighter Typhoon FCS. If all else fails I'll go and see if I can
> > find any of the project staff left over from Tornado days - they might
> > recognise this box.
> Hey, that sounds great. Somewhere in this thread the possibility was
> mentioned that the box might be classified even today.
If the unit was classified it would be marked as such on the front
panel of the unit.
> But in the meantime
> I know for sure that it is not mentioned in BAE's electronic databases
> in
> the tornado context. I am not very astonished about this since it must
> be
> around 25 years old and has serial number 42. It must originate from a
> very early version and is not used today...
> But if I imagine beeing asked in 2030 about things I have done today
> I do not know how much I will be able to remember than... ;-)
I worked on the pre-production units of the APG-65 radar for the
flight test F/A-18 aircraft back in 1978. I could recognize them in an
instant even today.
If he takes it to BAE the real question is whether there is still anyone
there who worked on it. With the aerospace industry turnover of
the last 25 years it's probable that everyone is at other jobs now.
--
Harry Andreas
Engineering raconteur
Erik Baigar
> > > find any of the project staff left over from Tornado days - they might
> > > recognise this box.
> > Hey, that sounds great. Somewhere in this thread the possibility was
> > mentioned that the box might be classified even today.
> If the unit was classified it would be marked as such on the front
> panel of the unit.
the pictures on Abex's web site there is no such label visible, too.
But obviuosly not beeing classified does not mean that information
is readily availablee :-(
> > very early version and is not used today...
> > But if I imagine beeing asked in 2030 about things I have done today
> > I do not know how much I will be able to remember than... ;-)
> I worked on the pre-production units of the APG-65 radar for the
> flight test F/A-18 aircraft back in 1978. I could recognize them in an
> instant even today.
Indeed it seems to be the last possibility that someone might
remember what this box was good for...
Alan Dicey
No positive identification yet. As far as can be told, from the guys
who remember that far back, this unit is not part of the FCS or the SMS.
The consensus is that it is most likely associated with the TV-Tab
displays in the rear cockpit, possibly to take the input from the
keyboard that surrounds the display and perform the switcing necessary
to route the correct display to the TV-Tab monitor.
Erik Baigar
> No positive identification yet. As far as can be told, from the guys
and for your help!!
> who remember that far back, this unit is not part of the FCS or the SMS.
I am impressed that you really found someone of those days still
beeing there.
> The consensus is that it is most likely associated with the TV-Tab
> displays in the rear cockpit, possibly to take the input from the
> keyboard that surrounds the display and perform the switcing necessary
> to route the correct display to the TV-Tab monitor.
OK, I see. Maybe I will have a closer look to the boards in order
to get a idea what it was good for. I am sure at the moment that it
does not contain any analog circuitry (apart from some kind of
internal power supply which seems to generate the voltages needed
for core memory and so on) like analog switches, amplifiers,
transformers (as often used according to the web links regarding
the MIL1533 standard). All logic is TTL and nearly all chips are
well known 54xx types.
The circuitry around the core memory looks somehow different (other
material of the boards, different style in numbering) as the rest
of the box. Maybe this is because the boardset was used in other
boxes, too?
During january (when there was most activity in this thread)
I powered up one board taken out of the box: In there is a
clock generator (crystal) and powered up the board generates
some signals which are sent to the backplane. They look like
the phase shifted clock signals often used in computers of
those days (Phi1, Phi2). Interestingly the timing is generated
by monostable gates which can be adjusted.
If it is true, that the PROMS on one of the boards (indeed these
are the only non well known chips) contain the operating program
as you stated in an earlier posting than I'd expect that there
will be activity (e.g. accesses to the core memory) within the
box if I'd power up the complete box. Of course I know: if
something is severely dead it will keep quiet. Since I am really
curious about this box I will hopefully find the time to put the
parts together again and give it a try...
BTW power is supplied to the box by a 6-pin plug called DPL06.
Any idea what voltages are usually used aboard an aircraft? -
Just to give, I will have to examine the internal supply anyway.
I will keep you up to date and all hints are highly welcome!
Thanks again for the time you spent on this curiosity,
Erik.
Erik Baigar
> who remember that far back, this unit is not part of the FCS or the SMS.
> The consensus is that it is most likely associated with the TV-Tab
> displays in the rear cockpit, possibly to take the input from the
> keyboard that surrounds the display and perform the switcing necessary
> to route the correct display to the TV-Tab monitor.
hint strongly supporting this theory: I carefully investigated
the layars of quality-assurance-stickers. Of course they are broken
and parts are lost but I was able to reconstruct them: Sticker applied
first reads "Marconi Avionics - Airborne Display Division - Rochester
Kent England". The sticker which was placed above the first one (maybe
during service or repair) reads "GEC Avionics - Airborne Display
Division
- Rochester Kent England"!!!
During investigating the internal power supply it became
evident that this unit has been changed at least once (severe
traces on the bolts holding the unit in place). The supply contains
a switch mode power supply made of OpAmps (747), comparators (LM111),
two gates, a flip flop and lots of discrete components. But the output
seems to be not more than four different voltages with one of them
beeing +5V (adjustable) and a lot of power for all the TTL chips.
There are two different types of connectors to the outer world.
Cables originating in connectors DPL01 to DPL06 unite to one
plug within the box (maybe they connect to the units delivering
information to be displayed). From there the cables go to the
backplane. The cables from DPL07 (beeing the plug with the most pins)
directly head to the backplane - they connect to the display unit I
suppose. Nearly all connections to the rest of the world seem
to end at boards 11, 12 and 13 (see my first posting). Only two
spread to the internal logic/memory and dataregister (maybe some
kind of reset).
I think displays of the 70ties where not raster displays like
todays, but they where vector displays (like analog oscilloscopes)
with the electron beam writing texts and lines directly?? Thus
the memory of the box may be some kind of graphics memory holding
the appropriate information which is than sent to the display.
The neccessary DACs for this seem to be outside of the box??!?
Alan Dicey
> I carefully investigated
> the layars of quality-assurance-stickers. Of course they are broken
> and parts are lost but I was able to reconstruct them: Sticker applied
> first reads "Marconi Avionics - Airborne Display Division - Rochester
> Kent England". The sticker which was placed above the first one (maybe
> during service or repair) reads "GEC Avionics - Airborne Display
> Division
> - Rochester Kent England"!!!
As I said earlier, Marconi Avionics was renamed to GEC Avionics. It is
possible that the unit has been back to Rochester for servicing at some
stage
>
> During investigating the internal power supply
-----
> But the output
> seems to be not more than four different voltages with one of them
> beeing +5V (adjustable) and a lot of power for all the TTL chips.
>
I'll take your word for it. :-) Power supplies are a black art. I
guess the ferrite core memory needs different voltages from the TTL.
> I think displays of the 70ties where not raster displays like
> todays, but they where vector displays (like analog oscilloscopes)
> with the electron beam writing texts and lines directly?? Thus
> the memory of the box may be some kind of graphics memory holding
> the appropriate information which is than sent to the display.
> The neccessary DACs for this seem to be outside of the box??!?
Thats a very big question. VDU computer terminals were first introduced
in the '70's, and initially consisted of a "glass teletype" - displaying
25 lines x 80 characters or so of alphamerics. They were raster
displays, derived from TV technology. There were a few graphic displays
(Tektronix being the manufacturer I associate with them) that were
vector-driven.
All the extant pictures of the TV-Tabs show alphamerics and lineart
graphics, but that doesn't mean that the displays were vector-driven.
The display driver hardware is likely to be in the TV-Tab unit itself.
Harry Andreas
> BTW power is supplied to the box by a 6-pin plug called DPL06.
> Any idea what voltages are usually used aboard an aircraft? -
> Just to give, I will have to examine the internal supply anyway.
Eric,
typical aircraft voltage is 115V, 3Phase, 400Hz and 28 Vdc.
I have never seen an aircraft of that vintage supply anything else.
Internally, the power supply probably converts to 270Vdc then
steps it down to +5Vdc, -5.2Vdc, and maybe + and - 15 Vdc for
the 1553 driver.
Good luck, keep us posted
Erik Baigar
> You do know that ferrite core memory is non-volatile, don't you?
> However, there will have been a PROM with the clever bits in it somewhere.
was able to analyze the type. They are 32*8, i.e. 256Bits.
I'd expect them to be interconnected to give a geometry like
256*8 by their open collector outputs. First I did not see the
scheme, but than I noticed the geometry of this memory seems
to be 128*16 where the order of the bits is changed from one
bank to the next. They must have compensated therefore during
the programming process...
> No boot process. Nothing to boot. No OS.
Yes, I see your point but it is hard for me to
believe that 128 words of code can do a substantial
job. And especially a job requiring >10000Bits of
memory.
Since the box was obviously no a mission critical part
(or was it?) is'nt it possible that the proms contain
some kind of bootloader?
Around the memory are chips I was not able to
get infos for - only numbers on them
214017
90073
8224
There is one of them per bank of prom memory. Maybe
I will find someting in an ancient databook from MMI
the proms are from...
Erik Baigar
> etc. But from what someone else said, it doesn't sound like a mission
> computer so probably doesn't have that kind of feature.
Maybe, it hast this feature: There is one line connecting from
an pin on an external plug straight to the driver board for
the core memory (No other line takes this way directly).
Very possible that this input tells the driver
to "flash" the memory by applying current to all lines. But
have still not looked at the driver board...
Erik Baigar
> I'm working with several avionics black boxes that contain "hundred of
> pins". The No. of pins says nothing about the interface type...
to another and so on. Of the >200 pins on the box's plugs "only"
100 are connected to the mainboard ;-)
> The Tornado FCS is connected to the main computer over one of the IFUs
> (Interface Units) using a 1553B (which btw. is also suitable for real-time
> tasks like for FCS, but not used in the PA200 for the purpose of
> transmitting control inputs)...
Is this protocol transmitted via differential 100Ohm lines, too? The
box seems to have got 4 serial interfaces with 3 transmiting and
3 receiving channels each. They reside RxTx interface...
Additionally there exists one optically insulated link the
the outer world via the ancient optocoupler 6N134...
Erik Baigar
> Erik Baigar wrote:
> > Kent England". The sticker which was placed above the first one (maybe
> > during service or repair) reads "GEC Avionics - Airborne Display
> > Division
> > - Rochester Kent England"!!!
> As I said earlier, Marconi Avionics was renamed to GEC Avionics. It is
> possible that the unit has been back to Rochester for servicing at some
> stage
the box from Abex is a sheet looking like a storage document. It
is dated from 1985 and states that the unit has been tested OK.
Maybe the box was taken out of service in this year...
> I'll take your word for it. :-) Power supplies are a black art. I
Especially supplies of those days: The transistors were rather fragile
and everything was built with discrete components. Looking at the
mechanics I noticed two locations where movable wires of power resistors
without insulation were seperated only by the epoxy coating
used to protect the boards against humidity. So I am not astonished
that these boxes must have failed rather often due to a problem
with the supply. Does every box have got its own supply? If yes,
than there are 50 or more of these aboard such an aircraft - ...
> guess the ferrite core memory needs different voltages from the TTL.
Yes, must be someting above 40 volts. At least in computers I
have seen befor.
> Thats a very big question. VDU computer terminals were first introduced
> in the '70's, and initially consisted of a "glass teletype" - displaying
> 25 lines x 80 characters or so of alphamerics. They were raster
> displays, derived from TV technology. There were a few graphic displays
> (Tektronix being the manufacturer I associate with them) that were
> vector-driven.
>
> All the extant pictures of the TV-Tabs show alphamerics and lineart
> graphics, but that doesn't mean that the displays were vector-driven.
I suppose yes!!! Let's calculate: For 25lines and 80chars you need
a minimum of 560*175pixels making more than 98000bits of information.
This is a rather big amount of core memory. BTW I think core memory
of those days was not fast enough to deliver a high enough data rate
for >5 frames per second??
> The display driver hardware is likely to be in the TV-Tab unit itself.
Yes, maybe. Perhaps the guys at BAE know a little more.
Alan, I am very happy that you have talked to them and
I am impressed, that it seems to be rather easy to get
in contact with them ;-) THANKS!
I commented some of the other postings with new information
I gained yesterday...
Erik Baigar
> > BTW power is supplied to the box by a 6-pin plug called DPL06.
> > Any idea what voltages are usually used aboard an aircraft? -
> > Just to give, I will have to examine the internal supply anyway.
> I have never seen an aircraft of that vintage supply anything else.
next week to learn which case is present in this box.
> Internally, the power supply probably converts to 270Vdc then
> steps it down to +5Vdc, -5.2Vdc, and maybe + and - 15 Vdc for
> the 1553 driver.
analog within there needing +-15V and the differential
line drivers on the RxTx board are powered by 5V directly.
-5.2V may well be possible for core memory but normally
-5.2V indicates ECL-chips. Definitively no ECL chips in there.
On the other hand I'd expect some higher voltage for the
core memory drivers...
> Good luck, keep us posted
Yes, I will do. I posted some replys to other postings
in this thread with rather technical details. Maybe no one
is interested in those but I hope to get more feedback in this
way.
Thanks again,
Erik.
Erik Baigar
> typical aircraft voltage is 115V, 3Phase, 400Hz and 28 Vdc.
> I have never seen an aircraft of that vintage supply anything else.
-> bingo, it's 3 phase. Only have got to figure out the pinout
of the input connector...
I am not sore wether to pull the boards before powering up
the unit. I do not want the power supply to toast the boards
in case of a problem in there. Do you know wether these
supplies can handle beeing turned on without load?
Cheers,
Erik.
Erik Baigar
> labels on the plugs on the loom. At least that's my experience of those
> mil-spec connectors anyway. I don't know specifically about the box you
> have, but most aircraft wll have several of those ATR/half ATR form-factor
> boxes doing specific and different tasks, some may also be duplicate for
> dual-redundancy in case of failure.
weight of such an aircraft must be the avionics boxes in there ;-)
Last weekend I was in a exhibition where one can view inside
several older aircraft and there are lots of boxes. My box
is about 12kg.... ;-)
Thanks for your comment!
Harry Andreas
Can't speak for Marconi, but all the boxes we've designed
can be powered up without boards installed, so that the box
can be tested stand-alone.
The cards are tested stand-alone on a purpose-built test
stand, then the cards and box are integrated and tested together.
Erik Baigar
> Recently I came across an part of computer
> equipment originating from a tornado aircraft.
The box was bought from Abex and such a box
was on eBay, too.
> The label reads "Programmer electronic Control", manufactured
> by Marconi Avionics with part number 51-019-02, NSN1680-99-652-3410.
Is someone out there reading this who has bought one
of those boxes, too? I am interested in buying another of
those to have spare parts in case I will toast something
during my experiments. You may keep the collectible core
memory if desired...
Erik Baigar
> > > typical aircraft voltage is 115V, 3Phase, 400Hz and 28 Vdc.
> > of the input connector...
Somehow strange is that the supply is not symmetric. Having
a closer look shows that there must be some small transformer
using only one phase for generating supply voltages for
the chopping circuitry. This is very ugly since I now can not simply
feed in an DC after the main rectifier to power up the supply:
400Hz 3Phase is absolutely not common for a hobbyist here in
Germany ;-) Perhaps the last resort will be to use audio amplifiers,
soundcard and an transformer to simulate it...
> > I am not sore wether to pull the boards before powering up
> > the unit. I do not want the power supply to toast the boards
> can be powered up without boards installed, so that the box
> can be tested stand-alone.
that the supply hast to be plugged into the box and connected to
the backplane. This is necessary because the supply seems to
measure the actual voltages on the mainboard via feedback
lines.
> The cards are tested stand-alone on a purpose-built test
> stand, then the cards and box are integrated and tested together.
Ahh, thats very positive to hear. I think it was
the same in the Marconi box.
BTW: The supply has been definitely been changed in my
box since it was manufactured in 1982...
Thanks again,
any hints and suggestions are welcome,
Erik.
Erik Baigar
> I'll take your word for it. :-) Power supplies are a black art. I
> guess the ferrite core memory needs different voltages from the TTL.
and the chance to power it up without having the required 400Hz
4 phase supply is near zero: Capacitors are to small for using
50Hz (the small helper transformer would be destroyed with 50Hz
anyway), built in test circuit for symmetry of input etc. etc. . .
But I figured out what voltages it generates so I should be able
to drive the mainboard directly. The only obstacle is that there is
a feedback: The supply measures the temperature of the ferrite
beads with an NTC and adjusts the driver voltage accordingly. I
can of course maesure the characteristics of the NTC which is
calibrated:
There are calibration resistors together with it on the
core plane (Thus one should be able to interchange the core planes
between
different boxes without needing to calibrate for temperature
coefficient).
But I cannot figure out the characteristics of the supply, i.e. dU/dR.
Does anybody know what the "standard temperature" in such applications
is?
I suppose the nominal driver voltage (which I know) has to be applied
at that standard temperature...
In a first try I will use a voltage for the drivers substantially
below the nominal voltage. In this way there will be enough voltage
to prevent that the drivers are damaged and on the other hand
the currents are to low to flip the magnetization in the cores.
...But memory organization is another interesting topic (seems to be
12bit words).
> > I think displays of the 70ties where not raster displays like
> > todays, but they where vector displays (like analog oscilloscopes)
> Thats a very big question. VDU computer terminals were first introduced
> in the '70's, and initially consisted of a "glass teletype" - displaying
> 25 lines x 80 characters or so of alphamerics. They were raster
> displays, derived from TV technology. There were a few graphic displays
> (Tektronix being the manufacturer I associate with them) that were
> vector-driven.
> All the extant pictures of the TV-Tabs show alphamerics and lineart
> graphics, but that doesn't mean that the displays were vector-driven.
I posted the fact that the box originates from the display section
in pprune.org - perhaps someone has interesting input on this topic...
Any piece of information is highly appreciated,
Cheers,
Erik.
P.S. Sorry for producing this lot of junk but analyzing the box
is somehow a very interesting thing and one can learn a lot
about vintage computer technology.
Erik Baigar
the opened core module which consists of a sandwich of
two modules. Maybe someone recognizes interesting details.
Erik Baigar
> > You do know that ferrite core memory is non-volatile, don't you?
> quite a big amount of memory for those days. And compared
> to the ROMS (DIL14, i.e. max 2kBits per chip) its huge.
PROMS are in fact 8 pieces, each 32 bytes of memory. But they
are not connected to make a usual geometry like 256*8 or 128*16
as I'd expect if i'd contain a program in the common sense.
Instead their outputs are e.g. connected disordered (making an
open collector "or"). Their address lines are connected semi-
ordered ;-)
> > However, there will have been a PROM with the clever bits in it somewhere.
more like some kind of action-coordination of an processor
than a hard wired program. Any suggestions?
Erik Baigar
> ...But memory organization is another interesting topic (seems to be
> 12bit words).
standard core memory technology (i.e. not two cores per bit).
Quite common drivers those days used in this one.
Alan Dicey
>
>>>However, there will have been a PROM with the clever bits in it somewhere.
>
> For me the PROMS on the Function decode board still look
> more like some kind of action-coordination of an processor
> than a hard wired program. Any suggestions?
I don't know anything about the TV-Tab other than that I was another
Marconi Avionics product, from a different Division than that which
built the Flight Controls. I suspect that the analog circuitry was kept
with the TV-Tab itself, in the large rectangular box that is such a
feature of the rear cockpit instrumentation, behind and to either side
of the pilots head. I think that the box you have is not much more than
a "keyboard processor". Any PROMs will contain the keycodes. The box
will have been designed to service two displays, so some of the
connectors should be paired.
If the guesses we have made so far are correct, the box is largely
performing the function of the 8048 (or whatever) microcontroller in
your PC keyboard.
Erik Baigar
> Marconi Avionics product, from a different Division than that which
> built the Flight Controls. I suspect that the analog circuitry was kept
> with the TV-Tab itself, in the large rectangular box that is such a
> feature of the rear cockpit instrumentation, behind and to either side
> of the pilots head. I think that the box you have is not much more than
> a "keyboard processor". Any PROMs will contain the keycodes. The box
> will have been designed to service two displays, so some of the
> connectors should be paired.
noticed (for a picture look at
http://www.baigar.de/TornadoComputerUnit/Connectors.jpg),
(1) that DPL06 is power (as mentioned in another posting).
(2) DPL01-DPL04 have the "same pinout" but are not really parallel.
The RxTX board contains differential line receivers and transmitters
and it is possible via multiplexers to switch three transmitter-lines
(i.e. 6 wires) and three receiver-lines (another 6 wires) to either
of the plugs DPL01-DPL04. Additionally there are some connected
between the connectors - always the same pin. But apart from the 12
differential data-lines there is no electrical connection to
the guts of the box (no GND, no power, no TTL-Signals).
(3) DPL05 is delivers two (again differential) transmit-channels
to the outer world and on one channel appear bursts of 24 rising
edges (originating from the Serial-Parallel-Converter) after powerig
on the unit on. The bursts are seperated by alternating 1.5ms of
high and 1.5ms of low level. These seem to be some kind of start-bit.
Furthermore this plug does not have GND, too. Some pins are
interconnected to DPL01-DPL04.
(4) DPL07 - the largest plug - connects to the guts of the box:
All levels TTL, power present, /reset as well. This is the only
plug supplied with a cover. The cover can be screwed onto the plug
and is attached to the box by a short piece of wire.
Questions arising from this are:
May the presence of a cover for DPL07 indicate, that the plug DPL07
was not used during normal operation? Maybe it was for diagnostic
purposes only? Or was it connected to a nearby box?
I suppose the differential lines of DPL01-DPL05 connect to remote
devices located several meters apart from the box?
Maybe DPL01-DPL04 connect to the displays and DPL05 to the Keyboard?
> If the guesses we have made so far are correct, the box is largely
> performing the function of the 8048 (or whatever) microcontroller in
> your PC keyboard.
But who is filling that big amout of memory? It is hard
for me to imagine, that there sould be 12k of memory for
pressed keys?
Thanks for discussion and input...
Erik Baigar
> Examining the connectors and their wiring in detail I
> noticed (for a picture look at
> http://www.baigar.de/TornadoComputerUnit/Connectors.jpg),
> (1) that DPL06 is power (as mentioned in another posting).
> (2) DPL01-DPL04 have the "same pinout" but are not really parallel.
> The RxTX board contains differential line receivers and transmitters
> and it is possible via multiplexers to switch three transmitter-lines
> (i.e. 6 wires) and three receiver-lines (another 6 wires) to either
> of the plugs DPL01-DPL04. Additionally there are some connected
one of the three differential signals shows short pulses <2ms
every 16ms. They occur on all plugs in parallel and do not
run via the multiplexer. The second output shows a clock signal
(approx. 2MHz) which can be gated on the plugs individually
via the multiplexer. Interestingly the default-value is that
the clock is on and thus appears on all plugs in parallel, too.
And last but not least the third signal can routed to either
plug wia the mutliplexer and shows no activity in idele mode.
Two if the inputs run via a demux so the box decides on
which of the plugs to listen and the third one is
converted to TTL for all plugs and these four signals
run to the IRQ-board.
So I guess that if on one plug the IRQ is activated it
causes the box to "look" at this plug and than some
kind of serial communication takes place using the
clock signal.
> (3) DPL05 is delivers two (again differential) transmit-channels
> to the outer world and on one channel appear bursts of 24 rising
> edges (originating from the Serial-Parallel-Converter) after powerig
> on the unit on. The bursts are seperated by alternating 1.5ms of
> high and 1.5ms of low level. These seem to be some kind of start-bit.
> Furthermore this plug does not have GND, too.
This plug does not have got any input at all - only output
functionality and some direct connections to DPL01-DPL04.
Most interesting questions from the last posting still
remain :-(
Erik Baigar
> So I guess that if on one plug the IRQ is activated it
> causes the box to "look" at this plug and than some
> kind of serial communication takes place using the
> clock signal.
signals within the box - regardless of what messages
I sent in via the per default selected DPL03's differential
receivers.
The only input lines to the box are the 4 IRQ-lines
(one on each DPL01-DPL04) and the two lines of
DPL03 which the MUX is looking at after power up.
One of these lines is even blocked by a gate signal
beeing high immediately after reset...
But so far I did not power up the memory section of
the box since the guess was that the intelligence
resides within the PROMS on the Function Decode Board...
Perhaps I will next power up the memory section
and monitor wether someting changes.
> Most interesting questions from the last posting still
> remain :-(
Especially the hypothesis that DPL07 - the only plug
which is supplied a cover fixed to the box - was not
connected during normal operation would be the most
interesting topic...
Erik Baigar
> I don't know anything about the TV-Tab other than that I was another
> Marconi Avionics product, from a different Division than that which
> built the Flight Controls. I suspect that the analog circuitry was kept
> with the TV-Tab itself, in the large rectangular box that is such a
> feature of the rear cockpit instrumentation, behind and to either side
> of the pilots head. I think that the box you have is not much more than
by usinng Altavista searching for pictures with "tornado rear cockpit".
> a "keyboard processor". Any PROMs will contain the keycodes. The box
> will have been designed to service two displays, so some of the
> connectors should be paired.
As stated in another posting - four connectors have identical
pinout.
> If the guesses we have made so far are correct, the box is largely
> performing the function of the 8048 (or whatever) microcontroller in
> your PC keyboard.
Having analyzed the boards a little more I found (aside a complete ALU)
three analog to digital converters (very nice made by using differential
line receivers as comparators) with different resolutions. My suspicion
is that they are the interface to the keyboard:
Hypothesis: The key switches have not been in a matrix as today but
- to reduce the number of wires needed - are used to bypass or short
resistors. Thus the DACs within the box can determine the key which
is pressed simply by measuring the resistance of the keyboard...
Have such keyboards been built for military use?
Best regards,
Erik.
Erik Baigar
Status-Report for whom may be interested:
Analyzed memory-interface: There is a 12bit-bus common for
adresses and data. Bit12 is seperate for addresses. On powering
up the unit and forcing it to read 0x000 as data one can see the
CPU running through the entire adress space.
So far identified a "relative jump command" and a "freeze"
command.
Thinking about how to simulate or read/write memory from extern
(maybe via the big plug, which at least features the
data/address-bus?)
in order to learn more about the language of the box.
Any feedback or discussion welcome...
Erik Baigar
> Erik Baigar wrote:
> >>>However, there will have been a PROM with the clever bits in it somewhere.
> > For me the PROMS on the Function decode board still look
> > more like some kind of action-coordination of an processor
> > than a hard wired program. Any suggestions?
> will have been designed to service two displays, so some of the
be a highly specific piece of hard wired processor: There is a 12bit
system bus connecting the different operational groups. There are
commands
(identified already few of them) which trigger certain operations if
read from
memory. The IO-part contains 24bit transmitter/receiver and 16 bit
(only 12 bits settable) transmitter and rceiver. Even a timer module
whose interval can be set, is present.
> If the guesses we have made so far are correct, the box is largely
> performing the function of the 8048 (or whatever) microcontroller in
> your PC keyboard.
Yes, that seems to be a very reasonable assumption. But still
I claim that the box has to be programmed from outside prior to
operation and that the program resides in the core memory (which
would not be a problem since I think the box was not essential for
flight, was it?). Maybe programming is done vie the large plug
supplied the a cover?
Next step is placing probes to critical points to monitor the dataflow
upon placing commands into memory in order to learn more about
the machine language of the box. But my logic analyzer is broken
at the moment so there will be some break now...
Setup see www.baigar.de/TornadoComputerUnit/DeviceUnderTest.jpg
Erik Baigar
> So far identified a "relative jump command" and a "freeze"
> command.
Freeze-Command is 000010000000 binary, relative Jump
1000rrrrrrrr where the offset is coded in rrrrrrrr.
BTW: the box consuimes about 6.5A at 5V and below 10W
at the other voltages. This is not that much, i.e. the
box does not get warmer than 30C
Still my HP1661A has a defunc floppy (!@^%&@#!$ proprietary
HP drive) and still needing time to repair this before
further investigation can be done...
Erik Baigar
> > So far identified a "relative jump command" and a "freeze"
> > command.
> Freeze-Command is 000010000000 binary, relative Jump
> 1000rrrrrrrr where the offset is coded in rrrrrrrr.
The box indeed seems to contain a general purpose
processor with program counter and one (or two,
I am not sure at the moment) accumulator registers.
There does not exist a hardware stack or priviledge
levels like on PDP11 or modern processors. The design
seems to me more like the PDP8 design.
Added rough schematic of the address generation and
program counter board SK10. Incrementing adresses is
done by setting carry. The adding engine allows
relative jumps as stated in the last posting
by adding contents of accumulator or memory the the actual
program counter:
http://www.baigar.de/TornadoComputerUnit/TornadoComputerUnitSK10.gif
Further analyzing die DataRegister boards now (SK8 und
SK9, both identical). They contain the ALU and
accumulator register...
... to be continued ....
Erik.
Erik Baigar
>
> Erik Baigar wrote:
> > > So far identified a "relative jump command" and a "freeze"
> > > command.
> > Freeze-Command is 000010000000 binary, relative Jump
> > 1000rrrrrrrr where the offset is coded in rrrrrrrr.
...in fact rrrrrrrr is drrrrrrr where d represents the
direction in which to jump, i.e. 10000000 and 00000000
will cause the unit to loop infinitely...
> I am not sure at the moment) accumulator registers.
...these registers reside on two boards (SK8 and SK9)
where each board manages 6 of the 12 bits.
By attaching a DIP switch to the memory system I am
able now to force the unit now to read certain values
from memory which can be entered via the switches.
Identified new command-groups:
1110000ddddd Causes the unit to wait for d+2 memory
cycles.
1111******** Is the group of IO-commands. There are
commands which allow me to transmit serial datagrams on
any of the plugs DPL01-DPL03 I want.
Next will be to (1) have a look at the memory system
again in order to prgram it remotely. (2) Identify
more commands.
Erik Baigar
> By attaching a DIP switch to the memory system I am
> able now to force the unit now to read certain values
> from memory which can be entered via the switches.
http://www.baigar.de/TornadoComputerUnit/Switches.jpg
> Next will be to (1) have a look at the memory system
> again in order to prgram it remotely.
Memory system is very similar to the core memory
of a PDP8 - only built much smaller and 128 X-lines,
not 64 as in the PDP8. Great survey is given in the
book "Computer Engineering" from Bell, Mudge and
McNamara. This book describes the evolution
of minicomputers in a view of DEC. Rough schematic of
memory structure copied from this book:
http://www.baigar.de/TornadoComputerUnit/CoreMemory.jpg
Erik Baigar
> > Next will be to (1) have a look at the memory system
> > again in order to prgram it remotely.
> Memory system is very similar to the core memory
> of a PDP8 - only built much smaller and 128 X-lines,
two banks with 4k words each. Without a connection to DPL07 the
machine always runs with A12=1 (pull up resistor). I.e. the second
bank can not be activated by the machine itself.
All pins necessary for accessingo memory appear on the large
connector DPL07 and the timing of the core memory is straight
forward (Can be seen here:
http://www.baigar.de/TornadoComputerUnit/PEC_SingleWrite.jpg).
In order to check wether there is still a 20 year old program
sitting in the core memory and to make further investigation easier
I built modified transputer based board which I want to be able to
read and write the core memory via DPL07. The diagram above
shows a single read-cycle initiated by a MEMRD pulse generated
from this external circuitry. Next step will be to write
programs to access a single core memory word first and
than to read and write the whole memory. Still I am not clear
how to prevent the machine from starting (and thus accessing
memory, too) during my external accesses. At the moment
pulling the timing generator is the way to go...
There exists a variety of complex commands for indirect
memory access which are similar to PDP8 commands. Analysis
will be easier, if testpatterns can be written to memory
via DPL07.
... may be to be continued ...
... or not.
Erik Baigar
> two banks with 4k words each. Without a connection to DPL07 the
> machine always runs with A12=1 (pull up resistor). I.e. the second
> bank can not be activated by the machine itself.
someting like a switch-bank-command which allows the
unit to access the upper 4k words of memory.
> read and write the core memory via DPL07. The diagram above
> shows a single read-cycle initiated by a MEMRD pulse generated
> from this external circuitry. Next step will be to write
> programs to access a single core memory word first and
> than to read and write the whole memory. Still I am not clear
> how to prevent the machine from starting (and thus accessing
> memory, too) during my external accesses.
Reverse engineered the memory interface and found some
kind of DMA (direct memory access) circuitry. This provides
the needed feature via DPL07: My transputer board is now
able to halt the Programmer-Electronic-Control's CPU, to
enable the DMA mode and than to read and write the core.
Upon supplying the unit with all voltages the transputer
board allows to test the unit's core memory and to find the
optimum current for the core circuitry. Investigations show,
that the memory needs higher current to flip the cores if
it is cold and lower current in warm state (ther exists some
kind of feedback to the power supply, doing this automatically
but I do not use the built in supply since it needs 110VAC
three phase at 400Hz). Core memory seems to be OK, all
cells can be read and written.
Happy new year to all readers,
Best regards,
Erik.
Erik Baigar
>> Reverse engineered the memory interface and found some
> kind of DMA (direct memory access) circuitry. This provides
> the needed feature via DPL07: My transputer board is now
> able to halt the Programmer-Electronic-Control's CPU, to
> enable the DMA mode and than to read and write the core.
discovered:
int i = 23 ; 1 23
int j = 0 ; 2 1
clear ACCU ; 160 1536
x: add i,ACCU ; 161 257
mov ACCU,j ; 162 1282
goto x ; 163 2178
^ core memory location
^ core memory content
The program clears the accumulator and uses indirect
accesses to memory locations 1 and 2 (i and j) to
repeatedly add 23 (stored in i) to the accumulator
and store each result in j (location 2). This program
runs fine loops for many hours if desired.
So, the story is solved in principle. Maybe the last
thing to add is, that the unit consumes approx. 35W on
+5V, 1W on -5V and 35W for the core memory...
... "Live Long and Prosper" ...
Erik Baigar
> Wrote a first simple program with the commands I already
> discovered:
>
> int i = 23 ; 1 23
> int j = 0 ; 2 1
> clear ACCU ; 160 1536
> x: add i,ACCU ; 161 257
> mov ACCU,j ; 162 1282
> goto x ; 163 2178
> ^ core memory location
> ^ core memory content
exists automatically generating the program binary
from mnemonics (2-pass-assembler).
Elaborated analysis-cycle is now like this:
(1) Write code in mnemonics for known commands + binary
for test-patterns.
(2) Assemble program to generate memory-map.
(3) Write core memory using transputer and Sparc Station
(4) Start the unit for approx. 100us and monitor
50 signals using HP1661a.
(5) Transfer timing diagram to SGI workstation
(6) Look what the unit does -> GOTO (1)
Next steps will be to hunt branch-commands and trace
down how the index register works...
... "Live Long and Prosper" ...
Erik.
Erik Baigar
> For easier debugging now a tcl/tk based assembler
> exists automatically generating the program binary
> from mnemonics (2-pass-assembler).
assembler. Now the following commands work:
SUB, ADD (subtracts or adds a memory location to
accumulator register)
CLRA (clear accumulator)
STA (stora accumulator to memory location)
SHL, SHR (shift accumulator left or right one
or more bits. This command includes some
strange arithmetics which I have not jet
fully understood)
INC (increment memory location by one)
RJMP, RJAN(relative jump and relative jump if
accumulator is not negative, i.e. bit11=0)
OUT (transmit data via MIL-STD bus, i.e. plugs
DPL01-DPL04)
LDI (load index register, the next instruction is
done relative to this register - thereafter
the register is set to zero again).
Especially access al comands the first 127 memory words.
If one wants to access higher words one has to load the
index register with the desired offset. Accesses to the upper
half of the memory cause the box to freeze -> I still do not
know where the problem is...
...still looking for spare boards/information...
Ciao,
Erik.
Erik Baigar
> OUT (transmit data via MIL-STD bus, i.e. plugs
> DPL01-DPL04)
The bus on this plugs is not really MIL-STD-1533. It is some
kind of SPI-communication with seperate clock and data lines.
End of message is signaled by dropping one clock cycle where
clock runs continuously on 2MHz otherwise.
Messages seem to something like a composite from data and
command: Each message consists of 12 data bits (originating
from accumulator in the OUT command) and a 4 bit command
passed to OUT in its lowest 4 bits. Last but not least
there are 2 additional bits which can well be influenced
but only "11" can be sent to DPL01 and DPL04 whereas
"00", "01", "10" can be sent to DPL02 and DPL03. Thus
the unit is not fully symmetric in plugs DPL01-DPL04.
What might have been connected there?
Now need to figure out how to read... DPL05 has it's own
receiver/transmitter circuitry which is much more complex...
Bye,
Erik.
Ian
"Erik Baigar" <er...@baigar.de> wrote in message
news:440543D4...@baigar.de...
bet its a Panlink - Tornado is full of them prior to the MLU programme.
Erik Baigar
> Can't remember exactly what box you thought it was, but I'd be willing to
> bet its a Panlink - Tornado is full of them prior to the MLU programme.
Summary of what i know about the box: It's name is "Programmer
Electronic Control" and it was manufactured by Marconi Avionics.
An early maintenance sticker reads "Marconi, Airborne Display Division".
I got hints that it's purpose might have been the control of the
displays in the rear cockpit of an early panavia tornado GR1 - but
I do not know for sure. My investigation further shows that it
is a general purpose computer with 12bit word width, 1.2us cycle
time and an accumulator dominated architecture. Memory is 8k words
of core memory. Something seems to be wrong with the box - it freezes
rather often - but it does not matter...
Thanks for your hint - MLU means Mid-Life-Update, right? The type
of electronics contained within the box is obsolete for >15 years
but, it is a nice puzzle for bad weather days.
Google is not really helpful regarding panlink - except that
it is a short form of Panavia-Link and that there exists a
specifiacation from Panavia... ;-) On the other hand might
the devices connected to DPL01 - DPL04 have been "silly output
devices" since the box can only listen to one of them - I did not
recognice an interrupt logic on these...
Thanks,
Erik.
Erik Baigar
> SHL, SHR (shift accumulator left or right one
> or more bits. This command includes some
> strange arithmetics which I have not jet
> fully understood)
allows to shift by up to 31bits where the accumulator is
only 12 bits wide. I do not know what happens to the bits
beeing shifted out of the accumulator and I have no idea
where the bits coming in originate from. It is (up to now)
not predictable for me wether a 0 or 1 is shifted in. Maybe
there are more "hidden bits" with some logic generating the
bits shifted in. For example like a hardware CRC or shift
register based random generator...
> index register with the desired offset. Accesses to the upper
> half of the memory cause the box to freeze -> I still do not
> know where the problem is...
My feeling increases that there is some defect part
somewhere within the function decode chain. Memory
works pretty well (I get an error rate of <0.02%) but
freezing of the box is sometimes erratic and 100% for
accesses to the upper half of the memory...
Nice weekend,
Erik.
Ian
> Ian wrote:
> > Can't remember exactly what box you thought it was, but I'd be willing
to
> > bet its a Panlink - Tornado is full of them prior to the MLU programme.
>
> Summary of what i know about the box: It's name is "Programmer
> Electronic Control" and it was manufactured by Marconi Avionics.
> An early maintenance sticker reads "Marconi, Airborne Display Division".
> I got hints that it's purpose might have been the control of the
> displays in the rear cockpit of an early panavia tornado GR1 - but
> I do not know for sure. My investigation further shows that it
> is a general purpose computer with 12bit word width, 1.2us cycle
> time and an accumulator dominated architecture. Memory is 8k words
> of core memory. Something seems to be wrong with the box - it freezes
> rather often - but it does not matter...
>
> Thanks for your hint - MLU means Mid-Life-Update, right? The type
> of electronics contained within the box is obsolete for >15 years
> but, it is a nice puzzle for bad weather days.
Yep
>
> Google is not really helpful regarding panlink - except that
> it is a short form of Panavia-Link and that there exists a
> specifiacation from Panavia... ;-) On the other hand might
You know as much as I do about Panlinks then - I don't deal with them too
much (unless really in trouble!)
Erik Baigar
>
> "Erik Baigar" <er...@baigar.de> wrote in message
> news:4409C373...@baigar.de...
> > Ian wrote:
> > > Can't remember exactly what box you thought it was, but I'd be willing
> to
> > > bet its a Panlink - Tornado is full of them prior to the MLU programme.
> >
> > Summary of what i know about the box: It's name is "Programmer
> > Electronic Control" and it was manufactured by Marconi Avionics.
> > An early maintenance sticker reads "Marconi, Airborne Display Division".
> > I got hints that it's purpose might have been the control of the
> > displays in the rear cockpit of an early panavia tornado GR1 - but
> > I do not know for sure. My investigation further shows that it
> > is a general purpose computer with 12bit word width, 1.2us cycle
> > time and an accumulator dominated architecture. Memory is 8k words
> > of core memory. Something seems to be wrong with the box - it freezes
> > rather often - but it does not matter...
> Any other part no or serial no stickers on it?
I updated the my project's picture page at
http://www.baigar.de/TornadoComputerUnit/
and added pictures of the type plate (TypePlate.jpg) and the stickers
(Sticker1.jpg and Sticker2.jpg) showing that the box was in maintenance
at least twice. At least TrapuInterface.jpg shows the transputer
interface I set up to connect it the the unit at my "console"
(CoreConnectConsole.jpg) where switches decide wether the unit
is in external-memory-access or running-mode...
> > Google is not really helpful regarding panlink - except that
> > it is a short form of Panavia-Link and that there exists a
> > specifiacation from Panavia... ;-) On the other hand might
> You know as much as I do about Panlinks then - I don't deal with them too
> much (unless really in trouble!)
From the waveforms they are silly SPI-like links with defined
bits for some kind of identifier and some seperator-bits. Nothing
interesting or special...
Regards,
Erik.
Erik Baigar
> Erik Baigar wrote:
> > SHL, SHR (shift accumulator left or right one
> > or more bits. This command includes some
> > strange arithmetics which I have not jet
> > fully understood)
> Especially interesting to these is that the micro code
> allows to shift by up to 31bits where the accumulator is
> only 12 bits wide. I do not know what happens to the bits
> beeing shifted out of the accumulator and I have no idea
> where the bits coming in originate from. It is (up to now)
> not predictable for me wether a 0 or 1 is shifted in. Maybe
> there are more "hidden bits" with some logic generating the
> bits shifted in. For example like a hardware CRC or shift
> register based random generator...
(yes 11, not 12) on the right side of the accumulator. I.e.
upon shifting right the accumulator bits become hidden
and reappear on shifting left again. There exists a command
I will call STS which allows to store the hidden 11bits to
core memory with bit11=0.
Thus shifting is clear now since there is always inserted
a 0 on the right side of the hidden register during left
shifting and the bit11 of accumulator is replicated during
right shifting.
Thats all regarding the shifting mystery
in Programmer Electronic Conrtol.
Erik Baigar
> Reverse-engineered more commands and updated my
> assembler. Now the following commands work:
>
> SUB, ADD (subtracts or adds a memory location to
> accumulator register)
> CLRA (clear accumulator)
> STA (stora accumulator to memory location)
> SHL, SHR (shift accumulator left or right one
> or more bits. This command includes some
> strange arithmetics which I have not jet
> fully understood)
> INC (increment memory location by one)
> RJMP, RJAN(relative jump and relative jump if
> accumulator is not negative, i.e. bit11=0)
> OUT (transmit data via MIL-STD bus, i.e. plugs
> DPL01-DPL04)
> LDI (load index register, the next instruction is
> done relative to this register - thereafter
> the register is set to zero again).
>
MSRTA Moves the hidden bits of the extended shift register
(see posting regarding SHR and SHL from yesterday) to
the accumulator (Move Shift Register To Accu).
LDA Loades accumulator with direct value out of core
memory. This is a two-word-instruction!!
Now there are only few bit-combiations left which have
to be investigated regarding CPU-commands (IO-commands
are identified but lots not analyzed now). The unit is
still missing instructions for logic operations like
AND, OR and XOR. This is somewhat strange, isn't it?
Still no spare boards around? The freezing-problem
persists... :-(
Erik Baigar
>
> Erik Baigar wrote:
> > Reverse-engineered more commands and updated my
> > assembler. Now the following commands work:
> >
> > SUB, ADD (subtracts or adds a memory location to
> > accumulator register)
> > CLRA (clear accumulator)
> > STA (stora accumulator to memory location)
> > SHL, SHR (shift accumulator left or right one
> > or more bits. This command includes some
> > strange arithmetics which I have not jet
> > fully understood)
> > INC (increment memory location by one)
> > RJMP, RJAN(relative jump and relative jump if
> > accumulator is not negative, i.e. bit11=0)
> > OUT (transmit data via MIL-STD bus, i.e. plugs
> > DPL01-DPL04)
> > LDI (load index register, the next instruction is
> > done relative to this register - thereafter
> > the register is set to zero again).
> >
> Following additional commands discovered:
>
> MSRTA Moves the hidden bits of the extended shift register
> (see posting regarding SHR and SHL from yesterday) to
> the accumulator (Move Shift Register To Accu).
>
MATSR which moves the accumulator to the hidden shift
register. There exist 16 bit-patterns which do
the same action on electrical signal level...
> LDA Loades accumulator with direct value out of core
> memory. This is a two-word-instruction!!
> Now there are only few bit-combiations left which have
> to be investigated regarding CPU-commands (IO-commands
> are identified but lots not analyzed now). The unit is
> still missing instructions for logic operations like
> AND, OR and XOR. This is somewhat strange, isn't it?
Scanned the remaining area of bit patterns which are
not known commands now and they do not change accumulator,
hidden shift register or any memory location. There are
no IO commands here, too. So indeed there are no AND,
OR and XOR instructions on this box. A call instruction
is missing as well (even PDP8 had something like a CALL).
Somewhat strange instruction set...
Richard Lamb
It sounds like they intended to access In/Out ports via
some selected memory addresses?
Memory reads from I/O space address return a switch setting (or 8?)
Memory writes to the same address could turn on lights, or some such.
For what it's worth...
Erik Baigar
>
>> >>MSRTA Moves the hidden bits of the extended shift register
> >> (see posting regarding SHR and SHL from yesterday) to
> >> the accumulator (Move Shift Register To Accu).
> >>
> >
> > Discovered a last instruction in the non-IO-area:
> > MATSR which moves the accumulator to the hidden shift
> > register. There exist 16 bit-patterns which do
> > the same action on electrical signal level...
> >
> >
> >>LDA Loades accumulator with direct value out of core
> >> memory. This is a two-word-instruction!!
> >
> >
> >>Now there are only few bit-combiations left which have
> >>to be investigated regarding CPU-commands (IO-commands
> >>are identified but lots not analyzed now). The unit is
> >>still missing instructions for logic operations like
> >>AND, OR and XOR. This is somewhat strange, isn't it?
> >
> > Scanned the remaining area of bit patterns which are
> > not known commands now and they do not change accumulator,
> > hidden shift register or any memory location. There are
> > no IO commands here, too. So indeed there are no AND,
> > OR and XOR instructions on this box. A call instruction
> > is missing as well (even PDP8 had something like a CALL).
> > Somewhat strange instruction set...
>
> It sounds like they intended to access In/Out ports via
> some selected memory addresses?
(i.e. values range is from 0 to 4095) and has 8191 words of
memory. The differentiation which bank (<4096 or =>4096) to access
is done by a bit in the machine instruction. But currently
the machine freezes it it tries to acces the upper half of
the memory. So all memory addresses are occupied by memory
and I can write to every memory cell via my external hardware
performing individual read or write cycles on the bus in a
DMA mode (CPU disabled).
Apart from the CPU, accumulator and arithmetic
commands there exist special IO instructions. They where
easy to identify since they cause action in the bus drivers
connecting the CPU bus with the IO boards.
These commands write to the serial transmit registers,
they read from them or the set or query a 12 bit counter
which I suppose is some kind of timer within the machine.
But details have to be discovered...
> Memory writes to the same address could turn on lights, or some such.
> For what it's worth...
As far as I know now the box controlled with high
probability displays in a very early (maybe prototype)
GR1 tornado. Therefor it has 4 serial IO/links and a
5th more sophisticated serial link. This is the main
reason why I posted in this group in the hope for
feedback what the box might have done really etc...
Sure is...
...no lights
...no switches
Erik.
Erik Baigar
> As far as I know now the box controlled with high
> probability displays in a very early (maybe prototype)
> GR1 tornado. Therefor it has 4 serial IO/links and a
> 5th more sophisticated serial link. This is the main
> reason why I posted in this group in the hope for
> feedback what the box might have done really etc...
The list was missing some logic commands - I now
discovered that there are still bitpatterns which
I have not checked for their function. In these I
discovered the following commands up to now:
LDA - load accumulator from memory
AND - and accumulator with memory word
RJAZ - jump if accumulator is zero
MTA - load accumulator with immediate word:
This is the first and only two-word-
instruction. At least up to now.
Erik Baigar
There is another highly advanced jump command
which may be used as CALL. This is in contrast
to all other commands a 4-memory-access command:
First the current program counter is saved
to the memory adress given with the command
(requires two words MSW (1 bit), LSW (12 bits))
and than the new program counter is loaded from
the address where the index register points to
(again two memory words). I will call it IDXCALL.
Greetings,
Erik.
Erik Baigar
>
> Ian wrote:
> > Can't remember exactly what box you thought it was, but I'd be willing to
> > bet its a Panlink - Tornado is full of them prior to the MLU programme.
>
> Summary of what i know about the box: It's name is "Programmer
> Electronic Control" and it was manufactured by Marconi Avionics.
> An early maintenance sticker reads "Marconi, Airborne Display Division".
> I got hints that it's purpose might have been the control of the
> displays in the rear cockpit of an early panavia tornado GR1 - but
> I do not know for sure.
I got the hint, that there are databases online which identify old and
obsolete military components from the manufacturer code or the NSN.
Trying
e.g. http://www.navalsupport.com/index.html, the manufacturer code
K0656 leads correctly to the todays Marconi Avionics successor BAE in
Rochester, England. But none of the NSNs of the box or its parts
lead to a result. On eBay there are often photos of military trash
with readable NSNs and these are recognized quite often. So I
think the "Programmer Electronic Control" with NSN 1680-99-652-3410
is really someting strange...
Regards,
Erik.
Erik Baigar
>
> Erik Baigar wrote:
>
> > OUT (transmit data via MIL-STD bus, i.e. plugs
> > DPL01-DPL04)
>
> The bus on this plugs is not really MIL-STD-1533. It is some
> kind of SPI-communication with seperate clock and data lines.
> End of message is signaled by dropping one clock cycle where
> clock runs continuously on 2MHz otherwise.
>
> Messages seem to something like a composite from data and
> command: Each message consists of 12 data bits (originating
> from accumulator in the OUT command) and a 4 bit command
> passed to OUT in its lowest 4 bits. Last but not least
> there are 2 additional bits which can well be influenced
> but only "11" can be sent to DPL01 and DPL04 whereas
> "00", "01", "10" can be sent to DPL02 and DPL03. Thus
> the unit is not fully symmetric in plugs DPL01-DPL04.
> What might have been connected there?
(1) Three start-Bits (low)
(2) The 12 bits of the accumulator (LSB first)
(3) The 4 bits given in the vommands (LSB first)
Comment (2) and (3) together make a 16bit word or can be
interpreted as Data (12 bits) and command (4 bits)????
(4) Two bits specified in the command, too (I will call them
identifier).
(5) One Bit "1" as indicator that this is a write transmission.
> Now need to figure out how to read... DPL05 has it's own
> receiver/transmitter circuitry which is much more complex...
Reading seems to be a master/slave process: The box transmits only
(3) and (4) identical to the write process. But the trnasmission is
terminated by a "0"-Bit. Presumable the connected client recognizes
the last bit received ("0") as send-command and decides what to send
by looking at the remaining bits.
By connecting transmission and reception lines (4 lines since
transmission
is 100Ohm differential: 2 lines CLK ,2 lines DATA) I was able to
issue a write command and in doing a read afterwards I got back the
last 12bits the write command sent out... Maybe I can build some
kind of cool console now to connect to one of these links...
Maybe this is the Panavia-Link-Format? It is definitively not
1553 since I found a short tutorial on the net explaining this
transmission format...
Another interesting topic is, the following: Only one port can be
read or written to at a time (multiplexed in/outputs). But each
port has got one individual input and output lines. Somehow I
think that these lines can interrupt the box and that the box
can send the connected devices an "attention" signal. But interrupt
circuitry is absolutely uncovered land at the moment ;-)
Best regards,
Erik.
Erik Baigar
> > index register with the desired offset. Accesses to the upper
> > half of the memory cause the box to freeze -> I still do not
> > know where the problem is...
> My feeling increases that there is some defect part
> somewhere within the function decode chain. Memory
> works pretty well (I get an error rate of <0.02%) but
> freezing of the box is sometimes erratic and 100% for
> accesses to the upper half of the memory...
Further investigation upon the "freeze-in-access-to-upper
memory-half" problem shows, that the timing for core
memory is generated in a quite "tricky" way: There are
several channels of RC-paths: After a trigger (e.g. for
Read-Memory), a capacitor is charged and the rising
volatge is monitored by comparators to generate the
X-, Y-, and latch-pulses. The different thresholds
of the comparators yields the timing required. Thresholds
can be varied by potentiometers to optimize the timing.
For writing there exists another RC-chain. What is
remarkable is, that differential line receivers are
used as comparators.
The interesting feature of the "freeze-problem" is,
that even a reset does not resolve the problem - only
a power off/on-cycle does. Technically the function
decode unit asserts the proper address to the bus (with
A12=1) and initiates a memory-read-cycle. But than
the control board does not start an read-cycle (the
first thing which is done normally is, that the
address is transferred the the X- and Y- boards
via a Adress-Latch-Pulse. Even this pulse is not
generated. Since the complete unit is not driven
by a clock oscillator but is mostly asynchronous,
the memory control board does not say "read complete"
and thus the unit stops to operate. I still do not
know why the memory control board does not initiate
the read cycle...
At the moment I am investigating the circuit
and trying to draw a crude schematic of the
memory control logic (arggh - lots of gates
in a at leas 8-layer board). The plan is to
understand how the first action (Adress-Latch-
Pulse) is generated, attach additional probes
to the memory control board and observe the
signals.
Another thing to do is related to the fact that
the unit can be brought back to live not only
by a complete power cycle. It is enough to reduce
the voltage used to generate the drive current
for X- and Y- lines below the 5V supply. The unit
operates quite normal afterwards. The memory
control board does not "see" this voltage, so
the problem might well be unrelated to the
memory control board?!?! The thing I am planning
here is to set up some intelligent trigger to
watch accurately what happens if the unit comes
back to live...
Best reagrds,
Erik.
Erik Baigar
> the memory control board does not say "read complete"
> and thus the unit stops to operate. I still do not
> know why the memory control board does not initiate
> the read cycle...
OK, in the meantime I connected my HP54542a to the
capacitors (C1, C2, C3 and C4) generating the
timing for the core memory and documented their
time constants and voltages etc. under normal
operating conditions. C1 is used the generate
timing for transferring the address which has
to be accessed, from the address/data bus
to the core memories address latch. C2 and C4
are used for generation of read-currents,
whereas C3 generates the write-timing. Thus in
a write-only-cycle the C4-based sequence is
missing. This works well in the lower
memory bank (A12=low) for all types of instruc-
tions.
BTW: I had to use field effect probes to monitor
the timing genration on the fly. Standard
oscilloscope probes (even of the 10:1 type)
altered the timing too much, preventing the
core memory from working as desired. But in
using FET probes the unit operated quite well
even while monitoring the signals I did not
get an unintended crash of the CPU.
> At the moment I am investigating the circuit
> and trying to draw a crude schematic of the
> memory control logic (arggh - lots of gates
> in a at leas 8-layer board). The plan is to
> understand how the first action (Adress-Latch-
> Pulse) is generated, attach additional probes
> to the memory control board and observe the
> signals.
Even circuitry of this part is rather complex.
I got a rough overview of the address latch
generation and the involvement of C1 herein.
Address latch is triggered by a rising edge of a
64ns pulse:
ALS ---------___-------------
^ address transferred
This is generated by tying ALS low
upon start of the read cycle from the
function decode board which pulls MEMRD low:
MEMRD --------__________----------
During ALS=0 C1 is beeing charged and if it
reaches the voltage for a following gate
to detect a High, ALS is set high again.
This rising edge latches the valid address into the
latches and starts the following processes. The
most important is asserting what I called MEMCLK.
This signal tells the main logic board (function
decode), that the address is latched and the read
cycle is running. Normally the main logic removes
the addresses from the data bus hereafter.
In the case that an instruction wants to access
the upper bank (A12=1) what fails is that even
the address is not latched, i.e. MEMRD goes low,
ALS goes low, too and C1 is charged forever.
The reason for this is, that the whole process is
inhibited by the A12 itself!!?!??
Big question, but the logic is made
like this and all chips here are OK: A12=1 prevents
the box from latching this address into the core
memories address latches...
The only way it works is that the logic board removes
A12 before the other address lines are released and
in this instant the read cycle starts with the
right address in the address latch. Two conclusions
remain:
(1) This is a defect in the function decode board.
In this case I can not use the upper memory.. :-(
(2) This is some kind of protection for the upper
memory bank! A rough investigation (only a
short examination last night) shows that the
box is able to EXECUTE code in the upper memory
half. Maybe this is implemented to protect
the code in the upper half from accesses by
data manipulating instructions. But than I
do not understand why these instructions exist
at all...??????
I will check (2) next to see, how timing in reading
instructions from the upper memory half is and compare
what are the differences to loading accumulator from
the upper memory...
Best regards,
Erik.