🚀 go-pugleaf

History repeats itself.

Many of you have been extolling the virtues of core memory never
forgetting its data.  Well, I recently saw an article about a new
laptop computer from Psion pls of London.  It uses Intel's Flash
memory for main memory and to replace the mechanical hard disk for
file storage.  ROM Mess-DOS is used for the OS, and Microsoft wrote
the filesystem code for the Flash memory.  Turn it on, and there
you are.  Almost zero startup time, and everything is as you left
it.  Since there is no mechanical harddrive, the batteries last
up to 75 hours.  Also, its 4 pounds, and about the size of a
standard notebook.  Take that, you luggables!

For those of you who don't know, flash memory is basically EPROM
that can be reprogrammed in place.  You don't need to take the
device out of the machine to reprogram it.  

The dynabook is almost here... (yeah, I've heard of the Dynabook(tm))



-- 
Shannon Nelson                    "Live, from Intel Scientific Computers..."
sha...@isc.intel.com          ...!tektronix!{ogccse,nosun}!intelisc!shannon
(503) 629-7607                Intel disclaims all knowledge of my existence.

In article <514@intelisc.nosun.UUCP> sha...@isc.intel.com (Shannon Nelson) writes:
o 
o forgetting its data.  Well, I recently saw an article about a new
o laptop computer from Psion pls of London.  It uses Intel's Flash
o memory for main memory and to replace the mechanical hard disk for
o file storage.  ROM Mess-DOS is used for the OS, and Microsoft wrote
o ... 

Hmmm... Let me put my foot in my mouth for a moment:  From what I
understand, flash memories still have some of the same problems
EPROM's and EEPROM's have:  They are still only good for between
10^5 to 10^6 write/erase cycles due to electron tunneling problems. 
That seems to make them almost usable for disk, but certainly not
usable for main memory.

-charles
-- 
Charles Daffinger  >Take me to the river, Drop me in the water<  (812) 339-7354
cd...@iuvax.cs.indiana.edu             			 
Home of the Whitewater mailing list:    whitewate...@iuvax.cs.indiana.edu

In article <10257@microsoft.UUCP> markro@microsoft.UUCP (Mark ROBERTS) writes:
>compiling and linking on the current system; loading the result into core;
>pulling out the memory board; walking accross the lab and inserting the
>board into the new machine; using the debugger jump to know address.
>
>Needless to say, got more testing done after they brought O/S up on new
>system.

Different scale, of course. HP calculators are all CMOS devices these
days, eh? The HP-41 was cute, 'cause you could take their little memory
modules out, swap them with someone else's calculator, and presto, instant
file/data transfers. Of course, with the original 41Cs, that was only
64 registers == 448 bytes per module, and when I started messing with 'em,
folks were using CVs, with the equivalent of all 4 modules already installed.
(*Only* 4 ports in back. I wish some well-known computer companies would
offer as much!!) But hey, then HP came out with Extended memory modules
for the 41, and the trick returned. Dunno why they called it X-memory,
it mapped in at the other end of the address space but you could still
use it directly. Execute code out of it, etc. (Using synthetics tricks,
that is. You had to alter the memory map, effectively turning the address
space upside down. If you weren't careful about it, the PACK routine that
packs unused memory would start at the top of RAM, wrap around thru zero,
and wham - all gone. The dreaded MEMORY LOST...)

But anyway, these modules were a lot more fun, holding, what, 2K each?
Cool stuff.

Wonder what kind of chips they used, always tossing in memory in
multiples of 448 bytes. This carried on thru the HP-10 series as
well (10, 11, 12, 15, 16, etc.)
--
 -=- PrayerMail: Send 100Mbits to holyghost@father.son[127.0.0.1]
 and You Too can have a Personal Electronic Relationship with God!

My first job was at Cambridge Language Research Unit, which was perenially
strapped for cash. Given the shortage of money, it was odd that they bought
a CTL Modular One computer - they were rather expensive. But they did, and
to save money on the configuration, they didn't order a `boot card' to go
with the paper tape reader. CTL accepted this order, and when the engineer
installed the kit, he got it through acceptance tests, loaded what they were
pleased to call an operating system, powered the machine down and removed
the boot loader card.

In principle this would have been fine, if CLRU hadn't had the thing installed
in a garage with no heating or anything. The installation happened (I think)
in January, and night temperaures plummeted. After lots of visits from
service engineers, culminating with one from Iann Barron (of Inmos fame,
nowadays), they decided to give us a boot card on loan, on the grounds  that
it was cheaper to splash out a bit of their capital than to be for ever
sending service engineers to reload the system. I don't recall them ever
working out *why* the normally reliable core kept coming up scrambled the
morning after cold nights. They suggested that we heat the room, which we did
(convector heaters), but it kept on failing.

Robin Fairbairns, Laser-Scan Cambridge
A grateful guest of the University Computer Lab

Speaking of non-volatile core memories, the first machine I ever
programmed was an IBM 1620 (remember the "CADET"?).  This guy had the
astounding quantity of 20,000 characters of core storage, and (I was
told) it was shipped from the factory with the diagnostics already
loaded into memory, ready to run.  Power it up, say "go," and the
diagnostics took right off.  Good idea, too, since the only other I/O
it had was a card reader/punch and its console TTY.

Another fun thing about this guy was that IPLs from the card reader
were done with a single-card "self loader" at the front of the deck;
push "load," the first card is read into memory and branched to, and
it loads the rest.  But the card reader also had a single card's worth
of storage itself, and (I forget the details, but) you could leave it
"booby trapped" by reading your own "single card loader" into the
reader's "on-board RAM" and then powering the whole thing down.  The
next unsuspecting user would show up (yes, it was a single-user
machine that you signed up for in blocks of a half hour or so), power
the machine up, and fill the reader's input hopper with a huge card
deck containing (e.g.) the FORTRAN compiler.  The unsuspecting user
would then press "load," but instead of reading the compiler's load
card, it would read the booby trap one left in the reader's buffer.
And what would that card do?  Well, such "hilarious" things as pass
the entire compiler through the reader (which was NOT fast!) just like
a normal load, and then do something like print "Burp" on the console.
Or maybe do something cute with the lights.  Or start duplicating the
compiler on the punch.  [Obviously my definition of "hilarious" was a
bit different back then!]

wayne

  Wayne Hathaway            
  Ultra Network Technologies     domain: wa...@Ultra.COM
  101 Daggett Drive            Internet: ultra!wa...@Ames.ARC.NASA.GOV
  San Jose, CA 95134               uucp: ...!ames!ultra!wayne
  408-922-0100

In article <1990Jan30....@ultra.com> wa...@ultra.com (Wayne Hathaway) writes:
>Speaking of non-volatile core memories, the first machine I ever
>programmed was an IBM 1620 (remember the "CADET"?).  This guy had the

I recall hearing (from an HP SE) that the CADET had a faulty arithmetic
unit.  He claimed that CADET stood for "Can't Add - Doesn't Even Try".

- Scott

In article <20...@watdragon.waterloo.edu> sbn...@rose.waterloo.edu (Scott Nicol) writes:
>I recall hearing (from an HP SE) that the CADET had a faulty arithmetic
>unit.  He claimed that CADET stood for "Can't Add - Doesn't Even Try".

The IBM 1620 (a.k.a. CADET) did *not* have a faulty arithmetic unit.

It didn't have an arithmetic unit.

You see, part of what you loaded into memory with your program were
the addition and multiplication tables...

 _____     ____ ---+---   /-\   Mark Crispin           Atheist & Proud
 _|_|_  _|_ ||  ___|__   /  /   6158 Lariat Loop NE    R90/6 pilot
|_|_|_| /|\-++- |=====| /  /    Bainbridge Island, WA  "Gaijin! Gaijin!"
 --|--   | |||| |_____|   / \   USA  98110-2098        "Gaijin ha doko ka?"
  /|\    | |/\| _______  /   \  +1 (206) 842-2385      "Niichan ha gaijin."
 / | \   | |__| /     \ /     \ m...@CAC.Washington.EDU "Chigau. Gaijin ja nai.
kisha no kisha ga kisha de kisha-shita                  Omae ha gaijin darou."
sumomo mo momo, momo mo momo, momo ni mo iroiro aru    "Iie, boku ha nihonjin."
uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru    "Souka. Yappari gaijin!"

In article <17...@gannet.cl.cam.ac.uk>, r...@cl.cam.ac.uk (Robin
Fairbairns) writes:
> My first job was at Cambridge Language Research Unit, which was perenially
> strapped for cash. Given the shortage of money, it was odd that they bought
> a CTL Modular One computer - they were rather expensive. But they did, and

The reason they bought one (The Oxford Undergraduate Computing teaching centre
had one too) was that it was made in the UK and there was a government
directive
on at the time to only buy British.

The Mod 1 was a horrible machine and the operating system was worse.
Ours used to
crash a dozen or more times a day. It got so that anyone could reboot
the machine,
if the operator was out of the room anyone who was in the terminal room
next door
would pop in, run the loader tape through the reader (it was kept ready
mounted)
and respool the tape using a hand spooler.

Nigel Titley

Email: NTi...@axion.bt.co.uk
Snail: British Telecom Research labs, Martlesham Heath, Ipswich, Suffolk, UK
"Well, I'm disenchanted too. We're all disenchanted." (James Thurber)

In article <1990Jan30....@ultra.com> wa...@ultra.com (Wayne Hathaway) writes:
>Speaking of non-volatile core memories, the first machine I ever
>programmed was an IBM 1620 (remember the "CADET"?).  ...

Sure.  Can't Add, Doesn't Even Try :-)

>Another fun thing about this guy was that IPLs from the card reader
>were done with a single-card "self loader" at the front of the deck;
>push "load," the first card is read into memory and branched to, and
>it loads the rest.  But the card reader also had a single card's worth
>of storage itself, and (I forget the details, but) you could leave it
>"booby trapped" by reading your own "single card loader" into the
>reader's "on-board RAM" and then powering the whole thing down.  ...

Yes, I believe this was correct.  That's why you always hit the RESET button
(or whatever) on the card reader -- to clear the cache memory and remove any
little presents left for you by previous users.

Anybody remember MONITOR-I, the disk operating system for the beast?  I
remember going through the source listings for it one day, trying to track down
some bug or another (yes, back in those days, IBM routinely provided source
listings).  I remember being at a point where I had totally lost track of what
was going on, due to overlays and such (remember overlays?), and was
completely and hopelessly lost.  At this point, I ran across the comment

			WHITHER WANDEREST THOU, WAYFARER?

Broke me up.  

On a similar subject, one version or another of the IBM VM/CMS source listings
has this little helpful comment, which appears just before the control flow
disappears into some similar morass:

			DIVE!  DIVE!

Anyone else seen any of these little documentation gems?

							spl (the p stands for
							punching cards since
							1966...)
-- 
Steve Lamont, sciViGuy	(919) 248-1120		EMail:	s...@ncsc.org
NCSC, Box 12732, Research Triangle Park, NC 27709
"That's People's Commissioner Tirebiter -- and NOBODY'S sweetheart!"
					- F. Scott Firesign

You've been fed a bunch of misinformation about the IBM 1620.

a) It did not have diagnostics preloaded.  As Mr. Crispin correctly
   noted, it did not even have the math tables preloaded (at least the
   first model; a model II did actually know how to do math without
   having to load result tables into memory).

b) You could IPL from the console (I got pretty good at typing in the
   machine language to bootstrap disk) or from cards.  The reason I'd
   type the digits was to save looking around for the card which would
   boot disk.  This "limited boot ability" isn't terribly unusual; our
   DEC KA10 used to boot disk from paper tape (well, we used mylar so
   the stuff wouldn't wear out so fast).  1620 machine language was a
   snap, since the internals were decimal.  I remember the
   instructions (not the arguments) for the disk boot even after these
   20+ years...

c) The card reader (and punch) was "buffered" in hardware.  When you
   put the thing "on", it would snarf a card immediately.  If you read
   "slowly" enough, you would be able to grab the buffered card
   without the read operation blocking for physical card motion.  On a
   model I, it wasn't hard to have your program be "slow" enough to
   take advantage of this feature.

The hearsay hack of having a card in memory which would screw the next
IPL sounds remotely possible.  If an operator was stupid enough to put
an IPL deck on top of a user job, if the user job did not read its
last card and the operator stupidly pressed IPL, it would yank that
prior deck's last card as the IPL image.  IPL was awesomely stupid; it
would do 1 read (whether card or console) and jump to it.  That single
card (or typed machine language line) had to have enough instructions
on it to read something else and start things rolling.

An operator who stacked an IPL deck on a user job would have to be
pretty stupid.  In this computer, with no operating system, memory
protection, job control, or anything, a runaway job could eat the next
deck in the reader quite easily by simple mistake, let alone
maliciousness...

nti...@axion.bt.co.uk (Nigel Titley) writes:

>The reason they bought one (The Oxford Undergraduate Computing teaching centre
>had one too) was that it was made in the UK and there was a government
>directive
>on at the time to only buy British.

>The Mod 1 was a horrible machine and the operating system was worse.

At Edinburgh they used MOD-1's as batch stations to front-end the
360/50 and 4/75. Presumably as some substitute for some high-priced
IBM gear. I well the remember the funny black and white boxes - can
you even imagine thos as having been "designed" by someone? The card
readers were quite cute though.

Lindsay
--
MAIL : Lindsay....@newcastle.ac.uk (UUCP: s/\(.*\)/...!ukc!\1/)
POST : Computing Laboratory, The University, Newcastle upon Tyne, UK NE1 7RU
VOICE: +44-91-222-8267 		FAX: +44-91-222-8232

[]

	"In this computer [the 1620], with no operating system, memory
	protection, job control, or anything, a runaway job could eat
	the next deck in the reader quite easily by simple mistake, let
	alone maliciousness..."

Literally so.  On our 1620, the card reader and punch were fed from the
*same hopper*.  If the "fake IPL" deck contained a program calling for
an infinite number of "punch card with all holes" commands, it would
turn the following deck into lace.

  -=- Andrew Klossner   (uunet!tektronix!frip.WV.TEK!andrew)    [UUCP]
                        (andrew%frip...@relay.cs.net)   [ARPA]

In article <61...@alvin.mcnc.org> spl@mcnc.org.UUCP (Steve Lamont) writes:
>In article <1990Jan30....@ultra.com> wa...@ultra.com (Wayne Hathaway) writes:
	  [ stuff about cute documentation ]

	  Well in the micro model Bs first version (and still one of the best 
	versions) of Elite (THE Space Simulator game!) it had a small string

	  Does you mother know you do this?

	  Heard this one from someone who was backing up their copy of the game
	.....


--
         )--------------------------------------------------------------------\
*CHOMP!*  } P.R.Banks (aka BANKSie!)  Internet :- ban...@rata.vuw.ac.nz      |
*CRUNCH!* }          "Help! The .sig monster has got me!"                     |
         )--------------------------------------------------------------------/