|
|
|
The HAPCC general meeting is on 4th Sunday of each month. The
next general meeting will be Sept 27th. Meeting time 7:00 - 9:00
pm. The HAPCC has a meeting place at: Maritime Museum of the
Atlantic 1675 Lower Water Street , Halifax, NS.
Parking available in the nearby Government parking lot or in
the Museum parking lot. Access to the building is via the Night
Entrance Doors, located just to the right of the regular front
doors. If door is locked, use the bell on upper left side of the
Night Entrance Doors.
The meeting room is on the second floor and has a theatre
type of layout. Washrooms are located close by. Elevator service
is available. Coffee served.
Feature Presentation:
Finding the Problem - Is it the CPU, a bad memory chip, or some other problem? Club member Rob
MacCara will bring his test gear and show us the in's and out's of locating hardware problems.
"...ah here it is, the
problem is likely this screwdriver sticking out of the
motherboard!"
We'll also have a Question and Answer period and a look at Windows by Bill Marchant.
Bill Marchant - Operational Trainer
Robert MacCara - Super Socket 7 mother boards
General Information
A word of thanks to guest speakers and the their web suites
Newsletter Information
Meeting Schedule for the year
A Computer Story from the Past by Bill Marchant
Foreword:
For anyone who may believe they have read
this account before, I should explain that it appeared in the
Halifax Area Personal Computer Club Newsletter as a four part
article a number of years ago. It is reproduced here in full
(with a few minor corrections and changes) by popular demand of
some of my friends.
From November 1962 to March 1965, I was the
Officer in Charge of the Operations Trainer in the Operations
Division of the Fleet School in Halifax.
I became associated with the trainer in the
fall of 1962 when a briefing team was added to the staff to set
up, run and evaluate the exercises. My assistant was Chief Petty
Officer Kurts. Looking back now, I am not sure who was really
assisting whom but we did work well together. This piece of
history is from my recollections of that time. It is from this
time that my interest in digital computers began. The following
is what I remember about the Operations Trainer and its people.
Since memory is faulty; (mine anyway), there will be some errors.
These will be errors of degree rather than of fact and I hope to
be forgiven for them by anyone who knows better.
Introduction:
In the decade of the 1950s the Royal
Canadian Navy was blessed with the talent of a few people who
believed in the future of digital electronics.
Several achievements resulted from the work
of these people. One was the development of a Ship's Action
Information System called DATAR (Digital Automatic Tracking and
Remoting) which was demonstrated in Toronto in the early 1960s
between a ship and a shore station. In the Canadian Navy, battle
control in a ship was exercised through the Action Information
Organization (AIO). The U.S. Navy calls it the Combat Information
Center (CIC). Datar was the forerunner of the computer assisted
Combat Control Systems used in all modern warships, and deserves
a complete series of articles by itself, which I am not competent
to write. The other achievement was the Operations Trainer.
The Operations Trainer was designed to
provide skills training for AIO personnel at two levels. One was
the need for realistic radar simulation so that Radar Plotters
(RPs - the people who operated the ships radars) could be taught
the personal skills required by their trade in a proper training
environment. The other was the need for a facility where the AIO
personnel from a ship could be trained as a team.
A primary design requirement was to use the
same radar displays as were being used in the ships, so that
operators would not have to learn how to use the trainer, and
then be confronted with different equipment at sea. The design
goals were modest, and tended to fit the definition of what was
reasonable and affordable given the state-of-the-art in digital
equipment as it was in the late 1950s and early 1960s.
Four rooms were fitted out with radar
displays (SPA 4s and SPA 8s), plotting tables (NC2s) and
communications (loud speaker systems with headsets and
microphones) to represent the operations rooms of four ships.
Each of these "ships" was an independent element in the
trainer, and was capable of being seen on radar by the other
three. Each was under the control of its own Captain through a
helmsman provided by the trainer staff.
There were twenty four other targets in the
system. These unmanned targets represented ten surface ships
(which could be made invisible to radar and act as submarines)
and fourteen aircraft. The unmanned targets, as well as all of
the other functions external to the four ship's operations rooms
were controlled or simulated in the trainer's Control Room.
The trainer staff consisted of an OIC, three
other officers, several Chief and Petty Officers and about twenty
five WRENS. Most staff members were capable of filling almost any
job in the Control Room. The Control Room was normally run by an
officer and about ten WRENS. This number would vary depending on
the nature of the exercise.
The Trainer became operational in 1961 under
its first OIC who was also the Project Officer during its
construction, Lieutenant Commander George Carroll. George was one
of the first people to be trained in the use of radar in ships,
and is remembered in the Operations Division of the Fleet School
as the RCN's first RP. George was responsible for many of the
unique ideas that made the trainer the success that it came to be.
The "playing surface" on which the
ships and aircraft could operate, was said to be a 500 by 500
nautical mile square. Those familiar with bits and bytes will
know that the area was really 512 by 512. The next size larger
would have been 1024 by 1024, which was larger than needed for a
normal four hour exercise, and the next size smaller would have
been 256 by 256 which would have been too small.
The exercises were devised by the briefing
staff with starting points for all the required targets and a
starting time. Many of the exercises were very similar, and we
were able to keep a book of exercises which could be referred to
by number. In order to analyse the exercise results, it was
necessary for time to be continuous. But breaks in the training
were required for things like stand easy (coffee breaks), lunch
and breaks necessary to provide instruction. The computer program
and all the clocks were started and stopped by a master switch
which meant that when the exercise was replayed for debriefing,
all the breaks were omitted, but the exercise time was continuous.
Although originally designed for fairly
simple exercises, with only a few ships and aircraft, the trainer
was soon adapted to do many types of exercise not originally
foreseen. Blind pilotage (piloting a ship by radar in reduced
visibility), control of helicopters, air defence, radar jamming,
and radio communications jamming were all done from time to time
with a considerable degree of success. Full scale exercises with
complete Action Information Teams including the ships Captains
and the Squadron Commander were also successfully done.
The Operations Trainer was said to have cost
about a million dollars. In 1960 that was quite a pile of money,
but set against the cost of operating four ships, ten submarines
and fourteen aircraft, even for a short exercise it was probably
one of the Navy's real bargains.
Equipment:
The computer used to control the Trainer was
a Packard Bell 250. Today, we tend to think of all computers
designed in the 1950s as huge electricity-consuming, heat
producing, air conditioning-demanding monsters; which also needed
an army of people to feed them the caddies full of tubes that they required.
The PB 250 was none of these. It was one of
the first computers to use transistors instead of tubes. You
could look inside and count them if you wanted to. There must
have been hundreds, possibly thousands of discrete transistors.
Each one sat on a board beside its neighbours, and was capable of
being replaced individually when necessary.
The box that contained the computer stood
about seven feet high, and was smaller in width and depth than
many house refrigerators. It was located in the control room
along with a number of cabinets of peripheral equipment and the
trainers control consoles. The whole Operations Trainer space was
air conditioned, so the computer took advantage of that. The real
heat generators were the navy radar displays which were full of
tubes. Whether the PB 250 really needed the air conditioning or not I do not know.
The computer memory was unique; at least I
have never heard of another one like it. It consisted of a series
of magneto-striction delay lines (that phrase can be found in the
Encyclopedia Britannica.) It probably needs some explaining
here. Conventional computers of the 1950s used magnetic drums for
their main memory. They were much like the disk storage of today,
except that the physical size was much larger, and the storage
capacity much smaller. Also, the drum was in continuous use by
the computer as an active memory. It was not just for loading and
storing programs or data. The operating program and data were
kept on the drum, having been loaded from paper tape, or possible
some other equally slow medium. The average memory access time
was half of the time it took for the drum to make one revolution.
Access times therefore were slow; being measured in milliseconds.
Today's computers have memory access times measured in
nano-seconds. That is they are a million times faster now.
The delay lines of the PB 250 can be thought
of as a drum, but instead of the hardware physically rotating,
the data circulated as acoustic pulses through a number of
stainless steel wires. Where a physical drum had tracks, the
magneto-striction memory had wires. Each wire was mounted on its
own card. The cards were approximately ten inches square, and the
elements were a flat coil of wire with a transducer at each end
of the wire.
Data in the system was truly dynamic. It
entered the memory when a series of electric pulses (bits)
entered the transducer at the input end of the wire. The
transducer converted the bits to sonic pulses that entered the
end of the wire as supersonic sound (sound that cannot be heard
because of it's high frequency). The sound pulses travelled the
length of the wire and struck the transducer at the other end,
where they were converted back into electric pulses again.
This pair of transducers could be thought of
as the read/write heads of a magnetic memory or a disk drive. If
data was needed, it was amplified and sent to the CPU. It was
also fed back into the other transducer so that the rotation
could continue. When data from the program needed to be stored,
it was put into memory through the transducers.
The time it took for the pulses to travel
the length of the wire coil represented the "rotation
time" of the memory. The amount of data which could be
stored depended on the length of the wire. In the PB 250 the
normal memory held 256 words. The word length was 21 bits (rather
non standard in terms of today's computers), so slightly over
5000 bits of data would be circulating through each wire when the
computer was operating. Because the access time for normal memory
was relatively long, there were a number of fast memory modules
that held 16 words. These were used by the programmer for memory
elements which required more frequent access, or for data that
was constantly being accessed. A program written to exploit this
fast access memory could thus be more efficient than a program
without it.
The total memory for the our PB 250 was
approximately 8000 words so that somewhat more than 32 memory
delay lines were used. The computer was actually capable of using
more memory, which could be put in additional cabinets, but our
system did not have any. Indeed it could not have used more
memory as will be seen shortly.
The only task of the operational program was
to store the current position of each of the 28 targets in the
system, move the target in accordance with the direction and
speed set on the controls, determine its radar visibility from
the four manned ships operations rooms and output the positions
to peripheral equipment so that it would be correctly displayed
on the radar displays in the ship's operation rooms.
The actual ships' radars of the day had
antenna rotation speeds of up to 15 RPM, which meant that four
seconds would elapse between the time a target was
"seen" by the radar, and when it would be
"seen" again on the next antenna revolution. In order
to provide a realistic display it was essential that the elapsed
time for all the calculations required in the computer program
should not exceed 4 seconds. This limit proved to be a barrier
when additional functions became desirable due to the need to
accommodate new equipment capabilities and tactics. Since
additional programming in additional memory would add to the
computation time, and the program calculation time could not be
expanded beyond 4 seconds, we had to use what was there. Random
echo scintillation, was one casualty of this limitation. We
wanted to simulate the fading in and out of a radar target when
it was at the extreme range of a radar. Because of the time
consuming calculations that this would require, the idea had to be abandoned.
One drawback of this interesting computer
was that for whatever reason, it was sensitive to radio and radar
interference. Early in the installation of the trainer it was
discovered that ships' radars in the harbour would cause the
computer to crash. Airborne radar carried by the Navy's Trackers
aircraft had the same effect. The result was that the entire
operations trainer space had to be isolated behind a radar proof
shield. The walls were lined with heavy metal foil, and the
curtains at the window were foil backed, and had to be kept closed.
Computer I/O:
No discussion of any computer would be
complete without mentioning the Input/ Output. The Operations
Trainer computer was unique, because although it was a general
purpose digital computer, its use demanded very special
Input/Output equipment. In spite of the extra I/O, it was still a
general purpose computer. I still have a paper tape containing
the program I wrote to calculate my mortgage. In fact, one of our
officers actually used the machine in off hours to do
calculations in connection with a post graduate degree he was
working on at Dalhousie University.
The keyboard and printer was provided by a
mechanical typewriter called a Flexowriter. It weighed about 40
pounds, and sounded like a badly tuned car engine when it was
idling, and more like a machine gun when it was printing. It used
continuous form feed paper for printed output, and for recording
keyboard input. There was no such thing as a video display.
Attached to the side of the Flexowriter was a paper tape reader and punch.
To get the computer started, it was switched
on, and after going through a few self tests, it paused and
waited for instructions. The equivalent of what we now call the
BIOS was 6 words of wired memory, so we didn't have long to wait.
If a program was to be loaded, the paper tape was mounted in the
reader, and a few key strokes would start the reader. The initial
program (the operating system), was on a loop of paper about the
size of a hoola hoop. This loop was called the
"bootstrap". I suspect the current term
"booting" originated from this source.
The operational program for the trainer was
a roll of tape about 6 inches in diameter, and took 45 minutes to
load. Later, we obtained an optical reader which reduced the load
time to a couple of minutes.
New programs were originally entered through
the keyboard, and then punched back out on paper tape. If the
program needed debugging, a new tape would have to be generated
with the corrections included. We used a lot of paper tape. The
front of the computer contained a bank of lights which flashed a
continuous readout of the current program address. When the
computer stopped, whether accidentally or on purpose, it was
possible to read the binary digits, and calculate the address.
The programmer always knew where in his program the problem had
occurred; or at least where in the computer the problem manifested itself.
There were four output cabinets on one side
of the computer, and three input cabinets on the other. The
output cabinets contained the hardware which took the calculated
position of each of the simulated targets, and put it on a device
which the radar displays could use as though they were connected
to a real radar. Each ship's operations room had one cabinet.
Inside, was a rotating disk about 12 inches in diameter
representing the radar antenna. The surface of the disk contained
a series of coded tracks and touching each track was a wire
brush, the output of all the brushes taken together was the
directional code for the antenna. The distance of each target
from the ship was sent to the radar displays as the antenna
rotated through the correct bearing.
The wire brushes were the weak point of the
system, and we found that we had to have a double set of disks
and brushes so that we could use one set while the other was in
repair. To add to our difficulty, the brushes could not be
serviced locally, and were shipped to Toronto or Montreal (I am
not sure which) for repair.
The three input cabinets contained the
analogue-to-digital converters used to convert the control
signals governing the targets into signals used by the computer.
Target courses and speeds were set by knobs on the control
cabinets. The accuracy of the control knobs was always suspect,
since the speeds and directions were etched on the metal bezels
around the knobs. This lent an air of realism to the exercises,
since as in real life, the courses and speeds ordered were not
always what was received. Each of the four operations rooms had
its own helmsman's console. The remainder of the targets were
controlled form the Control Room consoles. Other features fed to
the computer through the input cabinets, were turning a target on
or off (surfacing or submerging a submarine, or sinking a ship),
and stopping an aircraft (simulating a helicopter in the hover).
We also added a few new features which I will describe shortly.
When a submarine was deemed to be detected
by a ship's sonar, its position, course and speed would be
reported to the ship by one of the WREN operators, who would
simulate the sonar functions. This information was always
available for any target, whether surfaced, submerged, stopped or
out of radar range, by reading it from a set of Nixie lights.
We implemented many changes to the system
during my time there. When the contracted program was delivered,
it was found to have some bugs. People today would not be
surprised at that, but in the early 60s, computers were thought
to be infallible. Anyway, an enthusiastic Instructor Officer
(School Master Branch) was assigned to the trainer as Technical
Officer to clear up the bugs. Lieutenant Commander Ken Vavaseur
who was also an Electrical Engineer and a mathematics expert,
soon became my co-conspirator by carrying out the modifications
needed to keep the trainer current. Needless to say, we didn't
bother to ask for permission to make changes, since we very soon
discovered that no-one else in the fleet school was as well
qualified as we were to judge the possibilities of success. I
judged the needs, and Ken judged the possibilities, and made the program changes.
I carried on a correspondence in longhand
with the trainer technical officer in Naval Headquarters in
Ottawa, and described our activities. He never disputed a single
change. When I left, we counted about thirty changes that we had
made to software and hardware.
One change was to permit the aircraft to
carry and release guided missiles. Remember that during the
trainer's design phase in the mid 50s, aircraft did not carry
this type of weapon, but by the time the trainer was finished,
they did. We devised a method of freezing two aircraft targets
together, so that they showed as a single target. With the flip
of a switch, the slaved aircraft would fly off on its own course
and speed, simulating the release of a missile by the aircraft.
Unfortunately, the top speed of an aircraft target was 350 knots.
This was impossible to change because of the way in which speeds
were encoded within the 21 bit word length. We had slow missiles,
which were better than none, and in manual AIO days, even 350
knots was a test for the RPs.
The Computer Program
The computer program was written in machine
code. I don't mean assembler code, I mean "bits". The
paper tape reader and punch had the ability to change octal code
to binary and vice-versa. The coding sheets we used for
programming used octal numbers.
There were 64 machine instructions called
op-codes, corresponding to the octal numbers from 00 to 77. There
were three data registers in the machine CPU called A, B and C.
Data could be loaded from memory (remember the stainless steel
wires?) Into any register, operated on, and saved back to memory.
The programmer had to remember the octal numbers for the various
operations or else continually look them up. There were codes for
adding A to B, and Subtracting B from A, for rotating the content
of A, B and C, multiplying, dividing, comparing etc. The
programmer was also responsible for keeping track of the absolute
address of every piece of data used. All variables and constants
had octal number addresses for names.
The data word was 20 bits plus a sign bit,
and the command word was 21 bits. The first 6 bits (two octal
digits) of the command word were for the op-code. The next six
bits were the address of the particular memory delay line being
used, and the next 8 bits was the address of the data word on
that particular delay line. The final bit was used to tell the
op-code that one of its operands for the instruction was in the
next address. This optimization bit enabled the programmer to
write faster code than would otherwise be possible because it
eliminated the wait incurred by the fact that the data was
effectively rotating around in the memory.
The operating system was very simple and
very short, consisting of the code on the bootstrap tape already
described. Input was octal numbers, punched into paper tape,
three bits per character. Output on the Flexowriter was also
octal. If you wanted to input decimal numbers at the keyboard,
you wrote your own routine to achieve it. Likewise, to print
decimal numbers on the Flexowriter, a conversion routine was needed.
Maintenance:
I have already mentioned the 45 minutes
required to load the operational program. One day at stand easy
(coffee break) I jumped down from the control platform and landed
rather hard on both feet near the computer. The computer game had
already been stopped by the clock switch, but of course the
computer was still idling. When I landed, the computer stopped.
We called it going to parity, because the lights in the panel
stopped flashing and stopped at the offending address. Forty five
minutes later, we had the program reloaded, and were ready to
restart the exercise. The repair technician asked me what had
happened, so I jumped off the platform again. Guess what
happened! After the technicians had repaired a loose connection
and yet another 45 minute loading period, we were able to resume operation.
Then as now, electronics hardware was going
through some rapid changes so we frequently had trouble getting
the parts we needed. Some parts were rather rare so when we
needed one, we frequently ordered several. One day the Stores
Chief brought a three foot high crate weighing about 150 pounds,
into my office. With a sly grin he explained that this was one of
the three micro-diodes that we had ordered. The other two were to
be sent when they were available. This turned out to be a
confusion of stock numbers. Needless to say we returned the item
with a "No thanks" on the other two.
On another occasion we needed a special
screw. One of the screws used in the radar azimuth coding disks
had been lost. Because of the special nature of these units no
other screw of any other type of material would do the job. After
a number of fruitless tries through the supply system I wrote a
letter directly to the maker of the equipment. About two weeks
later, a small envelope containing a handful of the required
screws appeared on my desk. There was no letter, no invoice, and
no explanation of any kind; just the screws. The manufacturer was
obviously not willing to acknowledge his own generosity, (or
perhaps his own culpability in requiring such an obscure item in
his equipment), but he obviously wanted us to be happy.
Conclusion:
If a yarn such as this can have a conclusion
it must be that a lot of pioneering work has been done with
computers in Canada. The Operations Trainer, which was designed
and built in Canada, was one of the very first digital training
systems built anywhere in the world. It is true that many of its
component parts were built elsewhere, but the conception and
execution was ours. I cannot say it was the first such trainer,
because I don't know for sure, but I was privileged to be an
observer of some of that pioneering effort and even more
privileged to be able to benefit from it. We often take the
achievements of others for granted particularly those of our US
friends. Sometimes a closer look at what is going on at home will
prove to be very beneficial to our own egos.
In this issue
Baby-AT board, VIA Apollo MVP3 chipset, 1 MB L2 cache, 3x ISA, 3x PCI, AGP slot, 2x DIMM, 4x SIMM.
Voltages: 3.2V to 2.0V
This motherboard has 2 SIMM banks
consequently it has only 3 instead of the normal 4 PCI slots, but
the advantage that you may use 2 or 4 SIMM modules. Memory is a
strength of this board: The cacheable area of 256 MB and 1 MB L2
cache make it possible to use almost all applications you may want.
There are both AT and ATX power
connector. The VA-503+ also offers 112 and 124 MHz external clock
speeds. At least the board is equipped with 5 ns cache chips,
which makes it possible to over-clock. This board has support
right up to installing the as yet unreleased AMD K6-2 400MHz CPU.
I'm sure we'll see it quickly over clocked to 448, 496, or even
558MHz. The K6-2 300 can now easily be run at 336MHz with no ill
effects. I have yet to try one at 372MHz, but maybe one day...
One potential problem with this board
is for it to correctly supply the K6-2's required voltage of 2.2v
- the actual speed has yet to be seen at less than 2.5v - which
effectively works out to an increase in heat of about 30! An
extra large cooling fan is required, as well as secondary cooling
within the case. Running without proper cooling can cause extreme
data loss, erratic behaviour, and annoying shut-downs. The heat
problem is not specific to this particular motherboard, but
rather to high-speed chips in general.
ATX motherboard, VIA Apollo MVP3 chipset, 512 or 1024KB L2 cache, 2x ISA, 4x PCI, AGP slot, 2x
SIMM, 3x DIMM. Voltages: 3.52 to 1.0V.
The settings for voltages on this board
are very close to the specified - generally to within 0.1 volt.
In case you are wondering, my tool bag contains a gizmo that
inserts in the ZIF socket to read both the i/o and core voltages
of the CPU. This can help protect from incorrectly setting a
motherboard jumper and toasting a new CPU!
Strangely, AcerOpen puts the FDD
connector behind the memory slots at the other side of the board.
This makes it difficult to reach. Standard PC100 memory runs fine
at 100 MHz and right up to a 350MHz K6-2 CPU is supported. Note
that the 333MHz K6-2 CPU run with only a 66MHz FSB.
Interesting for all up-graders may be
the two SIMM sockets. This way you can still use your good old
EDO memory. The cacheable area of 128 MB ensures the fitness for
most applications as well. In case you should consider larger
amounts of RAM think about the 1 MB cache version of the AX59Pro,
it doubles the cacheable area to 256 MB.
The AX59Pro comes with either a 512k or
1024k L2 cache, but the cost difference is less than $5 - so go
for the larger cache. The board is equipped to run at 112MHz,
although it will frequently lock up at that speed. By the way,
there is a warning about over-clocking in the very thorough manual.
Perhaps another meeting could be
devoted to the different types of computer cases that are
available, listing the advantages and disadvantages of them. As
you can well imagine, some are better designed than others, with
handy features such as side removing covers, dual power supplies,
mounting brackets for multiple fans, and sliding motherboard
trays. The other idea I have for a future meeting is trouble
shooting tools that I use for testing motherboards, conflicts of
interrupts and DMA's etc. Also, operating system independent
system and burn-in checkers, not to mention data recovery software.
In this issue
Chairperson David Potter
Vice-Chair Bill Marchant
Treasurer Rob MacCara
Web Librarian Thayne MacLean
Newsletter Editor Diane Smith
Membership Promotion Pat Conen
and the following members who assist in planning our monthly
meetings: Norman DeForest, Henry Hill, Ken Gilmour,and Colin Stuart.
The HAPCC has two kinds of meetings. Firstly the regular
Sunday night meeting which most members attend regularly,
secondly the monthly (approximately) planning meeting which
organises the business of the Club, including what happens on the
Sundays. The planning meeting is held on Monday, a week after the
regular meeting in which all members of the Club are urged to
attend. At the planning meeting, we discuss feature speakers for
regular meetings, finances, membership, training, and other
computer related subjects.
....Bill Marchant
In this issue
Our guest speaker at the March meeting was Mr.
David Baxter, Product Specialist at MT&T for the MpoweredPc
service. His multi-media presentation showed us how far the
service has come, and in which direction it is heading.
MpoweredPc was being officially launched on April 7, 1998 and it
promises to be a serious contender in the high-speed
internet/software on demand arena. More info can be found here:
Mpowered. Once again, Thank you to MT&T and David Baxter.
Our guest speaker in February was Sgt. Bill
Cowper, Internet Communications Officer of the Halifax Regional
Municipality Police Department. He gave a history of how and when
the police department started using the Internet. They were the
first police department in Canada to be on the Internet. Sgt.
Cowper is continually receiving calls from all over the world
looking for assistance. The presentation showed how well the
department and the officers in the patrol cars are versed on
getting the criminals off the streets. If you would like to
check-out their web site the address is
Halifax
Regional Police Service gives an idea
of what an "Internet Cybercop" is all about.
In this issue
Newsletter Articles.... We are almost always in need of good
articles. If anyone has something that they feel would make a
good article, an interesting story to tell, or even a good
meeting topic, please don't hesitate to pass it on. Articles can
be submitted in almost any format, ASCII text, AMI Pro, MS Word,
Windows Write, WordStar and of course WordPerfect.
The newsletter is mailed to all paid up members and to
anyone who has attended a meeting within the past three months.
Yearly membership dues are $15.00.
Club Mailing Address -
P.O. Box 29008, Halifax N.S., B3L 4T8.
In this issue
We decide the meeting dates for the upcoming year at the last
planning meeting of the season. The dates for these are listed
below. As in previous years, the December meeting is moved to the
early part of January due to Christmas Eve being near the fourth Sunday of the month.
The planning meetings are normally held on the
second Monday (8 days) after the general meeting. They are
currently held at a members home and the address is announced at
the meeting prior to the planning meeting. Anyone is welcome to
assist in the planning of future meetings or events. Meeting
dates for the 1998/99 season:
Oct-25 Nov-22 Jan-3 Jan-31 Feb-28 Mar-28 Apr-25 May-24 June-27
Any changes to the scheduled dates will be announced where possible at the regular monthly meetings and/or in this newsletter.
