Reply by Steve at fivetrees December 24, 20062006-12-24
"Pete Fenelon" <pete@fenelon.com> wrote in message 
news:gomg54-bi21.ln1@stratos.fenelon.com...
> larwe <zwsdotcom@gmail.com> wrote: >>> Crikey, is that book still going? It was the freshman digital >>> electronics text I used over 20 years ago ;P >> >> Yes! Amazing, eh? [pulls copy off shelf...] I think it is still only in >> its 3rd edition, revised in 1993; first publication in 1976. Mind you, >> I'm a bit curious what exactly they revised in 1993, since it still >> reads like a book from the mid-1980s AT BEST. > > When did the 1st ed of Horowitz and Hill come out? Must've been around > then.... An infinitely better book than Mano, or the dreadful > Senturia and Wedlock which totally soured me on analogue electronics for > life!
H&H was first published in 1980 (and reprinted in 1981, thrice, it sez 'ere). Bought mine in 1981. It's looking a little dog-eared now, but it's still my bible. Steve http://www.fivetrees.com
Reply by CBFalconer December 24, 20062006-12-24
jmfbahciv@aol.com wrote:
> sidd@situ.com () wrote: >> <jmfbahciv@aol.com> wrote: >> >> snip re dangerous things-- >> >>> Right. But you won't mind if you locked into a room without >>> access while you are doing your dangerous things :-). >> >> indeed, i would prefer it that way. when i am doing possibly >> foolish and dangerous things, i hate to be interrupted >> >> i recall a setup for an experiment where some of the last things >> done before beginning a (perhaps multiweek) run were >> >> a)check shielded room integrity (20'x20'x10' Faraday cage with all >> modern conveniences, hot and cold running helium, nitrogen, water, >> air and vacuum, filtered power, isolated grounding complete with >> prominent signage assuring the fire marshal that yes, this is >> approved and correct and signed off on, so please dont fuck with it) > > My brother makes boxes that provide some of that functionality. > I don't think he's made a Faraday cage. >> >> b)physically disconnect all computers in that lab from networks. > > You must have been allergic to sparks. What did you use for > spark-prevention? > >> there were no computers or digital electronics allowed inside >> the shielded room. but there were (carefully isolated) computers >> outside it that took data, and controlled many things. One >> supervised the current supply for a 8 Tesla magnet that sat in >> liquid helium. the magnet absolutely Did Not Like Jiggles in the >> current supply. in the event of Jigglage, the magnet could and >> would express severe dipleasure through a flamboyant display >> called a 'quench'. > > I've heard that term but I can't remember where...probably s.p. > >> the superconducting coils of the magnet would go normal, and heat >> up and boil tens of liters of liquid helium. the resulting vapor >> would vent in huge white roaring plumes out of the top of cryostat >> accompanied by squeaky cries of dismay from the attendants. > > Squeaky because of the air they breathed or because they had to > scramble? >> >> did i mention that this particular controller used MMIO (which is >> what probably brought this to memory) but worked and worked well >> for a decade or more. >> >> there were several other computers associated with that experiment >> that could cause disasters, some annoying, some life threatening. >> >> this is more common in research labs, but of course ought not to be >> tolerated outside one. > > Seeing labs is so educational. Watching people work them even more so. > Research labs were always the first to try innovative setups. This > is because those dudes tended to work in extreme conditions. > > What works in the extreme can, usually, be generalized to function > for "mundane" everyday stuff. > > What a kewl lab setup.
This has gone thoroughly off topic, and is no longer suitable for c.a.e. Follow-ups set. I have snipped nothing to facilitate those who wish to continue this in a.f.c alone. If people wish to change the subject, fine, but please alter the subject line and set the follow-ups appropriately. Especially in anything that is cross-posted. Other newsgroups are not as sloppy as a.f.c. -- Merry Christmas, Happy Hanukah, Happy New Year Joyeux Noel, Bonne Annee. Chuck F (cbfalconer at maineline dot net) <http://cbfalconer.home.att.net>
Reply by December 24, 20062006-12-24
In article <458d5457$0$16680$4c368faf@roadrunner.com>, sidd@situ.com () wrote:
>In article <emjbt5$8qk_006@s952.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv@aol.com> wrote: > >snip re dangerous things-- > >>Right. But you won't mind if you locked into a room without >>access while you are doing your dangerous things :-). > >indeed, i would prefer it that way. >when i am doing possibly foolish and dangerous things, i hate to >be interrupted > >i recall a setup for an experiment where some of the last things done >before beginning a (perhaps multiweek) run were > >a)check shielded room integrity (20'x20'x10' Faraday cage with all >modern conveniences, hot and cold running helium, nitrogen, water, >air and vacuum, filtered power, isolated grounding complete with >prominent signage assuring the fire marshal that yes, this is >approved and correct and signed off on, so please dont fuck with it)
My brother makes boxes that provide some of that functionality. I don't think he's made a Faraday cage.
> >b)physically disconnect all computers in that lab from networks.
You must have been allergic to sparks. What did you use for spark-prevention?
>there were no computers or digital electronics allowed inside >the shielded room. but there were (carefully isolated) computers >outside it that took data, and controlled many things. One supervised >the current supply for a 8 Tesla magnet that sat in liquid helium. the >magnet absolutely Did Not Like Jiggles in the current supply. in the >event of Jigglage, the magnet could and would express severe dipleasure >through a flamboyant display called a 'quench'.
I've heard that term but I can't remember where...probably s.p.
> the superconducting coils >of the magnet would go normal, and heat up and boil tens of liters of >liquid helium. the resulting vapor would vent in huge white roaring plumes >out of the top of cryostat accompanied by squeaky cries of dismay from the >attendants.
Squeaky because of the air they breathed or because they had to scramble?
> >did i mention that this particular controller used MMIO (which is what >probably brought this to memory) but worked and worked well for a >decade or more. > >there were several other computers associated with that experiment >that could cause disasters, some annoying, some life threatening. > >this is more common in research labs, but of course ought not to be >tolerated outside one.
Seeing labs is so educational. Watching people work them even more so. Research labs were always the first to try innovative setups. This is because those dudes tended to work in extreme conditions. What works in the extreme can, usually, be generalized to function for "mundane" everyday stuff. What a kewl lab setup. /BAH
Reply by December 23, 20062006-12-23
In article <emjbt5$8qk_006@s952.apx1.sbo.ma.dialup.rcn.com>,
 <jmfbahciv@aol.com> wrote:

snip re dangerous things--

>Right. But you won't mind if you locked into a room without >access while you are doing your dangerous things :-).
indeed, i would prefer it that way. when i am doing possibly foolish and dangerous things, i hate to be interrupted i recall a setup for an experiment where some of the last things done before beginning a (perhaps multiweek) run were a)check shielded room integrity (20'x20'x10' Faraday cage with all modern conveniences, hot and cold running helium, nitrogen, water, air and vacuum, filtered power, isolated grounding complete with prominent signage assuring the fire marshal that yes, this is approved and correct and signed off on, so please dont fuck with it) b)physically disconnect all computers in that lab from networks. there were no computers or digital electronics allowed inside the shielded room. but there were (carefully isolated) computers outside it that took data, and controlled many things. One supervised the current supply for a 8 Tesla magnet that sat in liquid helium. the magnet absolutely Did Not Like Jiggles in the current supply. in the event of Jigglage, the magnet could and would express severe dipleasure through a flamboyant display called a 'quench'. the superconducting coils of the magnet would go normal, and heat up and boil tens of liters of liquid helium. the resulting vapor would vent in huge white roaring plumes out of the top of cryostat accompanied by squeaky cries of dismay from the attendants. did i mention that this particular controller used MMIO (which is what probably brought this to memory) but worked and worked well for a decade or more. there were several other computers associated with that experiment that could cause disasters, some annoying, some life threatening. this is more common in research labs, but of course ought not to be tolerated outside one. sidd
Reply by December 23, 20062006-12-23
In article <458c7455$0$17158$4c368faf@roadrunner.com>, sidd@situ.com () wrote:
>In article <458B2EC8.CF4E9E3D@yahoo.com>, >CBFalconer <cbfalconer@maineline.net> wrote: > >snip-- > >>I consider <snip> dangerous. > >if you prevent me doing stupid things, then you also prevent me >doing clever things > >let a hundred flowers bloom...
Right. But you won't mind if you locked into a room without access while you are doing your dangerous things :-). /BAH
Reply by December 22, 20062006-12-22
In article <458B2EC8.CF4E9E3D@yahoo.com>,
CBFalconer  <cbfalconer@maineline.net> wrote:

snip--

>I consider <snip> dangerous.
if you prevent me doing stupid things, then you also prevent me doing clever things let a hundred flowers bloom... sidd
Reply by December 22, 20062006-12-22
karthikbg wrote:
> Generally, Processor families have two distinct address spaces > through which they can communicate with these memories and peripherals. > The first address space is called the memory space and is intended > mainly for memory devices; the second is reserved exclusively for > peripherals and is called the I/O space. However, peripherals can also > be located within the memory space, at the discretion of the hardware > designer. When that happens, we say that those peripherals are > memory-mapped.
Well, those are definitely two ways of doing I/O, but they are far from the only ways. Many old architectures (60's and earlier) have dedicated instructions for doing I/O to each individual peripheral. So one instruction for the paper tape punch, one for the reader, one for the console, one for the printer, etc. There are remnants of this approach in some modern microcontrollers where there's a couple special instructions that access a very few on-chip peripherals directly without having to specify an address. This is seen in 8085's, low-end PIC's, and undoubtedly the bazillions of embedded CPU's pouring out of the far east for the past couple of decades. Many mainframes make the more complex peripherals (generally but not always the ones that do large block transfers) go through "channel processors". Roughly this is equivalent to a DMA controller in modern micros, but there is an important difference: channel processors interlock tightly with the I/O subsystem on the mainframe, and are usually accessed via instructions that talk to channel processors only. This is brushing up against the "I/O coprocessor" as implemented in micros, and conceptually not different than say an IDE hard drive with DMA, EXCEPT that IDE hard drives are not accessed on x86 via channel-specific instructions. Channel processors had to deal with multiple different busses: one ran from the channel processor to the device controller/formatter, and the other ran to the mainframe for channel instructions, and usually there were more to the different mainframe memory banks for DMA. The bus from the channel processor to the device controller/formatter used its own addressing scheme, specifying often a formatter # and unit #. The mainframe had to be cognizant of the formatter numbers and unit numbers to issue instructions to the channel processor, but it did not have direct access to the bus that understood those numbers, so there's yet ANOTHER example of a new addressing scheme. Tim.
Reply by CBFalconer December 22, 20062006-12-22
karthikbg wrote:
> CBFalconer wrote: >
... snip ...
>> >> Cross-posted to alt.folklore.computers, where the other old fogies >> tend to hang out. They will probably correct me and expand on my >> blathering. > > Actually, Cross-posted from : > http://groups.google.co.in/group/comp.arch.embedded/browse_frm/thread/8999bc6e4e509ec7?hl=en
No, my original is correct. Google is just a poor interface to the actual Usenet system. -- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net>
Reply by karthikbg December 22, 20062006-12-22
CBFalconer wrote:
> "Everett M. Greene" wrote: > > "karthikbg" <karthik.balaguru@lntinfotech.com> writes: > > > >> Thx for all of your replies that gave me clarifications. > >> > >> Got some good info from the net regarding this - i have placed > >> it below .... > >> > >> Generally, Processor families have two distinct address spaces > >> through which they can communicate with these memories and > >> peripherals. > > > > I would take exception with the use of "generally". I/O-mapping > > seems to have been initiated by Intel way back when and only the > > look-alikes (Zilog, et al) ever followed that lead. > > In 1969 or earlier the Microdata machine used separate i/o space, > among small machines. Big iron, such as the IBM 360, actually used > a separate i/o processor and separate space, known as i/o > channels. I'm sure there are many more early examples. IIRC the > SDS machines of 1963 or so are included (which later became Xerox > machines). > > I never used it, but my bus system and cpu cards for the 8080 > (1973/4) had provision for remapping a block of memory space into > i/o space. This was meant to "simplify?" code, without altering > the peripheral hardware. IIRC it was enabled by a dipswitch jumper > on the CPU card. > > I consider memory mapping peripherals dangerous. It effectively > prevents scanning memory for actually installed memory, because > arbitrary writes (or even reads) to/from i/o devices can do evil > things. It also makes it possible for wild pointers to destroy the > external storage, or worse. > > Cross-posted to alt.folklore.computers, where the other old fogies > tend to hang out. They will probably correct me and expand on my > blathering. > > -- > Chuck F (cbfalconer at maineline dot net) > Available for consulting/temporary embedded and systems. > <http://cbfalconer.home.att.net>
Actually, Cross-posted from : http://groups.google.co.in/group/comp.arch.embedded/browse_frm/thread/8999bc6e4e509ec7?hl=en Regards, Karthik Balaguru
Reply by CBFalconer December 21, 20062006-12-21
"Everett M. Greene" wrote:
> "karthikbg" <karthik.balaguru@lntinfotech.com> writes: > >> Thx for all of your replies that gave me clarifications. >> >> Got some good info from the net regarding this - i have placed >> it below .... >> >> Generally, Processor families have two distinct address spaces >> through which they can communicate with these memories and >> peripherals. > > I would take exception with the use of "generally". I/O-mapping > seems to have been initiated by Intel way back when and only the > look-alikes (Zilog, et al) ever followed that lead.
In 1969 or earlier the Microdata machine used separate i/o space, among small machines. Big iron, such as the IBM 360, actually used a separate i/o processor and separate space, known as i/o channels. I'm sure there are many more early examples. IIRC the SDS machines of 1963 or so are included (which later became Xerox machines). I never used it, but my bus system and cpu cards for the 8080 (1973/4) had provision for remapping a block of memory space into i/o space. This was meant to "simplify?" code, without altering the peripheral hardware. IIRC it was enabled by a dipswitch jumper on the CPU card. I consider memory mapping peripherals dangerous. It effectively prevents scanning memory for actually installed memory, because arbitrary writes (or even reads) to/from i/o devices can do evil things. It also makes it possible for wild pointers to destroy the external storage, or worse. Cross-posted to alt.folklore.computers, where the other old fogies tend to hang out. They will probably correct me and expand on my blathering. -- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net>