THE CORE MEMORY FORUM
December 02, 2016, 10:00:12 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1] 2 3 ... 10
 1 
 on: November 26, 2016, 04:26:36 pm 
Started by wally - Last post by wally
My brain is almost 10 years older and there are a few gaps too.
Once in a while I'm in contact with Paul by e-mail.
Season's greetings and best wishes for the New Year for you too! Smiley Smiley
Cheers, Wally.

 2 
 on: November 26, 2016, 02:55:54 am 
Started by wally - Last post by Fast Eddy2
Thanx for the links.  Other than Paul Wood, I don't recall any of the others in the links.

Having tuned 63 this year, my memories are fading fast as it has been 30+ years.

I truly enjoyed my time in BDA and have no regrets.

All the best for the coming Christmas season!

Cheers,
Ed

 3 
 on: November 23, 2016, 11:45:04 am 
Started by wally - Last post by wally
Hi "Big" Ed,
I know the group "I worked in Bermuda". But I have stopped my activities in Facebook about 2 years ago.
BTW there is another group in Facebook, it's called "BBM - NCR Bermuda" and was started by Jim Ferguson. It is a closed group.
https://www.facebook.com/groups/122732011269639/

A further group is "Bermuda Friends from the 70's", which is a public group.
https://www.facebook.com/groups/59822659496/

And the group "Old Bermuda: Our Island, Our History", a closed group, might be of interest too.
https://www.facebook.com/groups/OldBermuda/

After working for BBM I was in charge for EDP at "The MarketPlace" in Bermuda.
At the time you worked for BBM, I was part-owner of "Advanced Software", in those days located in the Armoury Building on Reid Street.

Some of the people, I knew at BBM and in Bermuda in general, have passed away (RIP).

Regards Wally.

 4 
 on: November 23, 2016, 12:12:00 am 
Started by wally - Last post by Fast Eddy2
Hello Wally (I hope you are still active on these forums),

I worked at BBM from 1984 to the end of 1986, primarily on the Criterion Mainframes.  There is a group on Facebook called "I used to work in Bermuda" and you can catch up with a couple of ex-BBMers there as well.

Regards,
"Big" Ed.

 5 
 on: November 04, 2016, 06:21:36 pm 
Started by JJW - Last post by JJW
Celerity Computing was not NCR but since it was formed by NCR employees (from Rancho Bernardo and Scripps Ranch in San Diego) and used an NCR processor chip, I thought a brief description is appropriate for this forum.

Celerity was formed in 1983 By Steve Vallender (President), Nick Aneshansley (V P of hardware development) and Drew McCrocklin (VP of software development) all from NCR. The idea behind the new company was that the high speed microprocessor that was used to execute Criterion firmware could be turned into a high speed, direct execution computer for graphic processing which would operate in an office environment and compete with other newly formed companies in an emerging marketplace (like Apollo and Sun Microsystems).

Other NCR employees were quickly brought on board: #4 was Karl Lehman (who would do device drivers) and #5 was me (J. J. Whelan, to work on the port of the Unix Operating System). Others on the software side were: Jeff Anderson (who was familiar with Unix and would also work on the port), Sandra Lee (to do utilities and who was just a general keep everyone's head focused sort of individual), Patricia Shanahan (who would port the Unix compilers), Clark Masters (to take care of operations, software tools and configuration management) and Stephanie McCartney (to do product builds and integration as well as general support). Hardware Engineers from NCR included Jim Kocol, Jim Gilbert and Gary Gilbert. On the software side we were joined by an excellent group of developers from the Burroughs office in Rancho Bernardo. The offices and final hardware assembly were located in a building in Scripps Ranch across the freeway from the NCR facility.

The main challenges were two fold: To turn the 16 bit architecture of the execution side of the chip into a full fledged 32 bit architecture and to provide virtual storage capability on a chip that didn't possess the fault mechanisms to properly suspend operations when a memory location was not available. Implementation was aided by the fact that the chip provided for a large number of external registers (intended for I/O) that could be used to implement the interface with the new hardware and (most importantly) that the chip had a full 32  bit access to external data memory. The founders had already come up with the basics for solving these difficulties and it fell to the rest of us to fill in the details.

This was an excellent team with both managers and others who had experience in designing, creating and delivering products to schedule. The initial development was done on a DEC VAX system and BSD Unix was the Unix base. The operating system goal was to exactly match the behavior of the VAX system.

The resulting system turned out to be more of a competitor with the DEC VAX products than with the originally intended graphics office systems.

The second system produced was a dual processing system and Jeff Anderson and I created what I believe was the first commercially available multi-processor Unix kernel.

The fact that the system was being used mostly in scientific processing environments led to the decision that we should focus on the low end of the supercomputer market. The next product was an up to eight processor high performance system based on a high speed clone of the NCR chip build out of generally available integrated circuits. However, sales of systems didn't make up for the cost of development and the company was merged with FPS Systems in Beaverton Oregon.

FPS was a very successful manufacturer of scientific array processors which were attached to DEC and IBM equipment. They were encountering decreasing sales because DEC and IBM were providing their own array processors (often integrated with their system). The idea was that the merged company could provide a high performance scientific system with array processing capabilities that would compete with DEC, if not IBM. This hope was buoyed by the fact that FPS had a successful sales team and record in the desired marketplaces. The Mainframe development remained in San Diego under the same management though Clark Masters took over from Steve Vallender..

It was also realized that the Celerity team would not be able to keep up with the rapidly growing high performance micro-chips and it was decided to move away from the NCR based architecture. After looking into the possibilities, the decision was to use the Sun Microsystems SPARC architecture. A high performance SPARC chip was already in development and Sun had no plans to develop a supercomputing system using it and that meant elerity would have Sun's full cooperation. SPARC also already had the, UCB Unix based, Solaris operating system and it was simple matter to move the multi-processing capabilities to that version.

The combined company sold several systems but was unable to maintain itself and was bought by Cray and then sold to Sun where it ended its life as the "Sun Supercomputing" division.

 6 
 on: November 01, 2016, 06:53:35 am 
Started by fred - Last post by JJW
Heiko, It wasn't until VRX (Centurion not Century though they had almost identical instruction sets and API's) that an indexed sequential access method was provided as part of the standard software. That was available on disks, not CRAM which was pretty much discontinued with the Century series.

 7 
 on: November 01, 2016, 06:12:00 am 
Started by kdianis - Last post by JJW
As implementer of the B1 executive/kernel and designer and implementer of the B2 executive/kernel I can definitively state that "B" meant "Basic" meaning fundamental, not related to the programming language of that name. Probably reasonable for B1 but the others became more and more divorced from just providing the fundamentals but the "B" was retained.

 8 
 on: October 31, 2016, 07:24:55 pm 
Started by JJW - Last post by JJW
Shortly after I completed the work on the 315 On-line Banking Executive for teh 321 controller and it became a product, there was an emergency support request from the Philippines. A system had been ordered for the Philippine National Bank and they were planning a big roll-out of their first on-line system within a couple of weeks. We were told that the system wasn't working and that since the then-president Marcos was scheduled to attend the openning it was imperative that the problem be corrected. I spent a day running around L.A. getting a visa and passport and was on a plane to Manila the next day with the 321 hardware engineer.

We arrived to discover that the problem was that much of the equipment had been left out in the tropical rain in a leaky container. New equipment was shipped by air and the system came up and ran perfectly. I spent the week training the support team in the On-line software system.

One think about the visit I won't forget was that the Philippine branch had an apartment for visitors with a maid who prepared breakfast for us every morning. She taught me how to prepare mangoes.

 9 
 on: October 31, 2016, 06:55:35 pm 
Started by JJW - Last post by JJW
I started at the NCR Electronics Division in Hawthorn California writing what would now be called device drivers for the 315 computer. The 315 didn't have anything like a modern operating system. All the device drivers were linked directly with the program that used them and the whole package was loaded into memory for execution.

There was a monitor program that was executed between the applications that controlled the order and specifics of which batch jobs were run. I remember (though it's been some time) that it allowed control of program by date, day, and time so that companies could have certain programs run daily, others monthly, others on weekends, ...

Programs were often linked with "executives" which provided a more general control of peripherals and operations, somewhat more like modern operating system "kernels". I believe "STEP" (Standard Tape Executive Program) provide magnetic tape file and reel management. There was a similar executive for CRAM devices (though I forget the name).

I, personally, worked on the on-line banking executive which provided communication device and CRAM management for banking systems. It was also adapted for Pacific Southwest Airlines ticketing and check-in.

 10 
 on: October 31, 2016, 06:32:05 pm 
Started by n8eyh with OCD-WM42 of Hilse - Last post by JJW
At NCR in Hawthorne CA, I was responsible for providing support for the 321 communications controller in the 315 On-Line Banking Executive. Then later I designed and built the B2 operating system for the NCR Century and was also involved in hardware designs for multi-processor systems. Because of that I had several chances to interact with the NCR Japan team regarding Sumitomo Bank and especially with Akiyama-san. In some ways we were friendly rivals with his focus being on Sumitomo Bank and mine on general purpose operating system capabilities.

There is no doubt that the numerous indexing registers provided a performance challenge for any multi-tasking system. The choices wer basically to 1. save and restore all of them, 2. save and restore only some and limit applications to those. or 3. to share the registers among all tasks and require programmers to use only certain registers in certain tasks. In providing a general purpose system I chose #1 (the least performance effective). Akiyama-san with his focus on Sumitomo Bank and with a known programming staff capable of managing their register use chose #2 (and I believe some use of #3 with the registers which were not saved and restored.

With the introduction of the Centurion computers and virtual memeory this problem could be resolved by the virtual memory system since the indexing "registers" were actually in the first 256  bytes of the program memory. That allowed register switches to be performed simply by changing the first virtual memory page.

Pages: [1] 2 3 ... 10
Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC
Page created in 0.058 seconds with 14 queries.