How to choose a firmware partner

"Alan Balmer" <albalmer@att.net> wrote

> Anthony gave a good description. Keep in mind that many of us old
> farts have a tendency to call even semiconductor memory "core." In
> fact, crash dumps are still called core dumps even by people who never
> saw any core <g>.

You should see the looks I get when talking about "control cards" when
referring to JCL.  Every new programmer should have to punch up a deck
and learn why sequence numbers are worth the effort.  ;-)))

Jeff Fox <fox@ultratechnology.com> says...
>
>Guy Macon <http://www.guymacon.com> wrote in message news:<76mdnf1RjM7kMSjdRVn-uA@speakeasy.net>...
>> 1n 1965 The Sperry Rand UNIVAC 1108 II (aka 1108A) had two 
>> memory cabinets with 262,000 64 bit words each, which adds 
>> up to nearly 2MB.
>
>64-bits is 8 bytes.  262,000 * 8 = 2,096,000 bytes per bank.
>2 banks would be 4,192,000 bytes.  Did I miss something?

My error.  I forgot to multiply by two cabinets  D'oh!

-- 
Guy Macon, Electronics Engineer & Project Manager for hire. 
Remember Doc Brown from the _Back to the Future_ movies? Do you 
have an "impossible" engineering project that only someone like 
Doc Brown can solve?  My resume is at http://www.guymacon.com/ 

> So this may seem (a troll), to some people, but won't anyone even
> consider this for a moment:
> 
> 1) A one byte loop is lockup-proof.

Unless, of course, theres a glitch on the power rails or something that 
sends the PC off to neverland.

> 
> 2) So for a standalone, MCU, lockup proof code is only a matter of
> scale.

Assuming your hardware is perfect, which it's not.

> 
> 3) Evidently the MCU hardware itself cannot become inherently "stuck"
> because that would make the clearWDT instructions inaccessible and a
> mockery of the whole watchdog scheme.

Of course it can becom stuck. If the "clearWDT instruction becomes 
inaccessible" then something is very wrong. The watchdoing will timeout 
and reset the CPU. Thats the whole point!

> 
> I am guessing that the above posters are talking of complicated,
> multiproccessor, asynchronous systems; which is a little narrow
> minded.
> 
> A better response could be: "The OP probably means 1/2k of code
> running in a 12C505, heh heh, he'll grow up eventually!"

If your 12c508 code is expected to be very reliable, then I'd include a 
watchdog.

Al

> 
> Cheers
> Robin

Eric Smith wrote:
> Phil wrote:
> 
>> I would be interested (and surprised) to know which
>> computer had a megabyte of core in the 60's.
> 
> On April 7, 1964, the IBM System/360 announcement included systems
> with up to 512 Kbytes of main memory and optionally from 1 to 8
> Mbytes of slower (8 us) "bulk core storage".  First customer
> shipment was in 1965.
> 
> But several years earlier, IBM shipped their first computer that
> could directly address more than a megabyte.
> 
> The IBM 7030 Data Processing System (AKA "Stretch") had a typical
> configuration of six IBM 7302 core storage units, each of which
> was organized as 16384 words of 72 bits.  It was the first
> computer to use ECC memory, so 64 of those bits were data.  Each
> 7302 stored 128 Kbytes. The typical six-unit configuration stored
> 768 Kbytes, though the system could be expanded to 16 units for a
> total of 2 Mbytes.
> 
> First customer delivery of a 7030 was to Los Alamos Scientific
> Laboratories in April 1961, with customer acceptance in May 1961.
> 
> Note that the 7302 core storage unit was more commonly used in an
> organization of 32768 words of 36 bits, as used on the 7090, 7094,
> and perhaps other machines.
> 
> Early 7302 core storage units were oil-filled, but later ones
> (7302A?) were air-cooled.

You guys are in the wrong place for this stuff.  Try
alt.folklore.computers.  Crossposted and followups set.  It is OT
for comp.arch.embedded.

-- 
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem.  Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison

Jeff Fox wrote:
> Guy Macon <http://www.guymacon.com> wrote in message news:<76mdnf1RjM7kMSjdRVn-uA@speakeasy.net>...
> 
>>1n 1965 The Sperry Rand UNIVAC 1108 II (aka 1108A) had two 
>>memory cabinets with 262,000 64 bit words each, which adds 
>>up to nearly 2MB.
> 
> 
> 64-bits is 8 bytes.  262,000 * 8 = 2,096,000 bytes per bank.
> 2 banks would be 4,192,000 bytes.  Did I miss something?
> 
> Best Wishes

IIRC, Univac 1108 was 36 bits / word.

Tauno Voipio
tauno voipio @ iki fi

On Thu, 27 May 2004 01:53:31 -0700, Guy Macon
<http://www.guymacon.com> wrote:

>
>1n 1965 The Sperry Rand UNIVAC 1108 II (aka 1108A) had two 
>memory cabinets with 262,000 64 bit words each, which adds 
>up to nearly 2MB.

Are you sure about the 64 bit memory word length, since the 1108 was a
36 bit machine, so a 64 bit memory word width does not make sense even
with parity or ECC bits. IIRC there was also some 1:1 interleave so
that odd memory addresses came from one module and the even addresses
from an other module, thus speeding up sequential access (a core
memory read access required that the controller wrote back the value
read back into the core).

Paul

On Thu, 27 May 2004 13:33:13 GMT, "Anthony Fremont"
<spam@anywhere.com> wrote:

>
>"42Bastian Schick" <bastian42@yahoo.com> wrote in message
>
>> Forgive my ignorance (I was released 1970), what is the difference
>> between core and RAM chips ?
>
>Wow, do I feel old now.  Magnetic core was a bunch of tiny little
>"donuts" that looked something like miniscule ferrite beads.  It was
>literally sewn together by meticulous women (peering thru microscopes)
>into an X, Y type lattice that also had a sense/inhibit wire running
>throughout all the "donuts".  Each little donut could be magnetized into
>one of two polarities to represent a 1 or 0.  When core was read, it
>destroyed the data stored and had to be automatically rewritten by the
>hardware.  Some guy named Wang figured all this out.

Ah, thank you Anthony. In German we call it (translated) Ferrit Core
Memory.


---
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@epost.de instead !

>>Forgive my ignorance (I was released 1970), what is the difference
>>between core and RAM chips ?
>>
>>
>Anthony gave a good description. Keep in mind that many of us old
>farts have a tendency to call even semiconductor memory "core." In
>fact, crash dumps are still called core dumps even by people who never
>saw any core <g>.

Ha, now you got me why I could not come up with the right picture.

I thought core dump == kernel dump. But actually it's memory dump.

I loved this word, now I do like it even more :-)

Thanks.

BTW: I saw one, but only at the German Museum in Munich.


---
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@epost.de instead !

Anthony Fremont wrote:
> "42Bastian Schick" <bastian42@yahoo.com> wrote in message
> 
> 
>>Forgive my ignorance (I was released 1970), what is the difference
>>between core and RAM chips ?
> 
> 
> Wow, do I feel old now.  Magnetic core was a bunch of tiny little
> "donuts" that looked something like miniscule ferrite beads.  It was
> literally sewn together by meticulous women (peering thru microscopes)
> into an X, Y type lattice that also had a sense/inhibit wire running
> throughout all the "donuts".  Each little donut could be magnetized into
> one of two polarities to represent a 1 or 0.  When core was read, it
> destroyed the data stored and had to be automatically rewritten by the
> hardware.  Some guy named Wang figured all this out.

  It's comming around again : Ramtron's FerroElectric FRAMs also have
a destructive read, and Motorola and Cypress are working on
MRAM devices, but it's not clear if they have destructive reads.
  FRAMs do have a finite, but large, cycle count limit.
Anyone know if the old CORE had the same wearout issues, or
did they never cycle it long enough the those lower bus speeds
to find out? :)
-jg


	

"Jim Granville" <no.spam@designtools.co.nz> wrote

>   It's comming around again : Ramtron's FerroElectric FRAMs also have
> a destructive read, and Motorola and Cypress are working on
> MRAM devices, but it's not clear if they have destructive reads.

After a little googling it appears that they do and consequently have an
automatic rewrite cycle generated internally.  This is interesting in
that you have to manage your read cycles as well as write cycle counts.