Saturday, February 10, 2018

Pranks and Viruses

Over the years, at many places that I worked, the programmers I worked with were a fun bunch of people.  We'd have really intense discussions about technology and about how best to solve different problems, but ultimately, while we worked hard, we played hard, too.  Even the first viruses were more in the order of a prank compared with the ones we have today.

Changing User Prompt

One of the first pranks I encountered started out unintentionally when we were reverse engineering the Reality operating system.  We discovered a lot of interesting things, including that the very first byte (byte 0) of every frame (512 byte block of memory - that's how Reality organized memory) was not check-summed to ensure no corruption, but for one frame, it was actually used.  Both data and program space was organized by these 512 byte Frames. The first 12 bytes were used for linking and state information.  The rest was for data or machine code, for programs.

On PICK systems, the command line or shell mode was called Terminal Control Language (TCL).  The TCL prompt on Reality was a colon ":". For other PICK systems, they went with the greater than sign ">".

These first PICK systems, were what we called "Native" systems, where they provided the full operating system. Later versions ran as a shell on top of Windows, Unix, Linux and other platforms.  Prime Information was the first one to run as a shell, on PrimeOS, but it was the rare one. On these native versions, the first, lowest numbered frames were where the "operating system" and user assembly programs were typically loaded.  For most of them, frame 6 was the one that handled user terminal I/O.

On most PICK systems, byte 0 of frame 6 held the TCL prompt character.  If you had access to the system debugger, you could change that byte to any character that you wanted.

Be aware that while the TCL prompt character was ":", the BASIC debugger prompt was "$", and the system debugger prompt was "!".  These prompt characters would tell you that you were in different states.

When we discovered this, we changed it to another character to see what would happen. This was on a multi-user system, and we had other programmers doing work. As we changed it, we could hear swearing from the next room. We hadn't intended this as a prank, but it was too good to pass up! For fun, we changed it to the BASIC debugger prompt.  More swearing.  How about the system debugger prompt (this was getting too much fun!)  The swearing was sounding worried.  Then we changed it to the character that cleared the terminal screen.  This was too much!  The programmer in the next room came running over to say that the computer was having serious problems, only to find us laughing uncontrollably!  He realized he'd been had!


On all PICK systems, there was a file that controlled the error messages.  While you could mess with any of them, by convention this was frowned on, with the exception of ERRMSG 3.  This ERRMSG simply printed the words "VERB?" and returned to the TCL prompt.  It was the error message you got if you mistyped a TCL command or intentionally typed random garbage at TCL and pressed return.

001 E VERB?
EOI 001

[3] VERB?

It was generally considered OK to make changes to this ERRMSG.  For most customers, this would be a simple change to something like "WHAT???" or "SAY AGAIN?", but for a couple of our customers, they were always on the lookout for something really elaborate or different to put in it. I saw some that were like 12 lines of text, suggesting you present yourself for a Bozo award.  Finally, one customer changed it to "BUTTERFINGERS!". Unfortunately, there was a worker in a warehouse of theirs who had really big fingers, and was convinced that it was personal. That was the end of them changing that error message!

Water Detected in Drive A

In the early days of DOS, I remember finding this program called "Drain". It was actually an executable called "".  You'd run it, and it would create what looked like a DOS prompt "A:\>".  The moment you typed anything, it would send a beep to the system speaker, and display an error message:

"Water detected in drive A"

The cursor would flash for about 3 seconds, then it would display another message:

"Starting rinse cycle"

Now spinning a 5 1/4 inch floppy drive made a sound a bit like a washing machine on rinse or spin cycle. Enough that you got the idea. It ran the rinse cycle for about 5 seconds, then printed out:

"Starting spin cycle"

This ran for another 5 seconds.

It would end with a message saying something to the effect of "Drive A is now dry - you may resume work." and it would drop to the DOS prompt.

My wife was volunteering as secretary at our church and she ran it, then called the pastor over, telling him something was wrong with the computer.  Great fun!

Airplane Pilot Attempts to Outrun Electrons

One story a colleague of mine tells is of a software package that they had developed for airplane maintenance. The computer also had a word processor called JET and pilots would often use this to write letters.  They were at the Boundary Bay airport and a pilot was using the system as a word processor to write up a letter.  In typical style, still emulated by software programs today, if you typed the keystrokes that would delete your document, the program would ask if you really wanted to delete the document and you could type "Y"es or "N"o, followed by Return.  If you typed "Y" followed by Return, the program would tell you that document "xxxxx" has been deleted.

The pilot did the wrong keystrokes, and had typed "Y" + Return, and got the message saying his document was deleted, before he realized what it had asked him.  The quick-thinking pilot reached over his terminal (they were quite big affairs - see below) and yanked the serial cable out, then ran like mad to the computer room where he pulled the serial cables out of the back of the computer. Then he walked over to my colleague, Jan, who was watching all this in disbelief from another room, and asked her if she thought he was fast enough to stop his document from deleting!

The pilot reached over this and pulled out the serial cable on the back

Coffee Machine is Access Protected

One of the error messages that the computer would occasionally display was one that indicated that an operating system function had tried to access memory that they were not permitted to access or that was not properly initialized.  The message was to the effect that something "... IS ACCESS PROTECTED". It would then display the message "Abort @n.m". "n" was a frame number and the "m" part was the offset within that frame. This was the address of the program instruction that encountered the error.  It would then drop you into the system debugger, with the exclamation prompt "!".

Encouraged by the antics of other programmers that I knew, when working at First City Trust, I decided to create my own program for locking out my terminal while I went for coffee or lunch. I created a program that displayed what looked like a blank screen with a TCL prompt ":".  The first two times you typed anything into it, it would print the "VERB?" output, giving people the idea that they either mis-typed, or something else was going on.  On the third attempt, it would print the message:

ABORT @12:00 noon

The exclamation mark "!" made it look like the system debugger.  At any of these prompts you could type a special password and you'd drop out to real TCL.  If you typed anything else into that last "!", it would display messages to this effect:


Regardless what you typed, it then displayed


(SYSPROG was like the root account for these PICK systems.)

Finally the dots would stop displaying and it would log you off.

Note: No real SYSPROG accounts were ever hurt in the running of this program...

April Fools Day Endless Reboot

When I worked at Synex Systems, one April 1st, one of the programmers pulled a prank on all the other programmers.  The night before, he stayed late and changed every programmer's computer's autoexec.bat file to run a program that forced a coldboot just before finishing.

The effect of this was an endless reboot.  The first people arrived, started their computers and walked away. They'd come back with a coffee and the computer was still booting. OK, computers were slow at booting up (and many times still are), so they'd read a magazine for a few minutes. Finally, the realization dawned that this was taking too long, and that BIOS message they were looking at had already displayed twice...

You had to reboot off a floppy and edit that autoexec.bat file to fix it. That was a good April fools prank!

Stoned Virus

And then there was the stoned virus. It was one of the first real viruses, and very prevalent for a number of years.

When a computer boots up today, it looks for an operating system boot-loader in the "boot sector" of your hard drive. On the original IBM PCs and clones, the BIOS would start by checking drive A, then the fixed disk.  It was not uncommon for someone to load a program or data disk into drive A, forget it was there, and shut their machine down.  When they booted up the next time, they'd get an error message that the disk in drive A did not have an operating system on it.  You would remove the diskette and type Ctrl-Alt-Del to reboot.

The stoned virus was called a "boot sector virus". When you left an infected diskette in drive A, it would actually run a program that scanned your computer for diskettes and hard drives, and would add itself into the boot sector. Then it would display a message on your screen saying "This computer is now stoned." and it would print the standard error message saying that the diskette in drive A did not have an operating system.  You'd take the diskette out and reboot and all would look good. If you worked at Synex, you'd be convinced that one of those darned programmers put that "stoned" message on your computer as a prank.

Thereafter, every time you booted your computer, it would run this stub before running the operating system. Any diskettes you left in, it would attempt to write to the boot sector and infect it during boot-up. After boot-up, any diskette you put in, the now-infected operating system would attempt to infect with this virus.  Although I heard rumours that this virus would occasionally randomly delete files, to my knowledge, other than replicating itself, the only other thing I ever saw it do was occasionally it would display "This computer is stoned" message randomly during operating system boot-up.  These were the days of relatively benign viruses.

I knew of a company that published 6,000 diskettes to go out along with copies of Aldus Pagemaker, only to be told by Aldus that all of these diskettes were infected with the stoned virus!

We got in the habit of write-protecting all our floppy diskettes that we sent out to prevent our media from being infected.

This practice came in handy on multiple occasions. One such occasion was when I was at a large New York law firm, and someone came to me to say that there was something wrong with my diskette. I looked and he had an error message about not being able to write to the diskette. I pointed out that he should never write to our diskette, then got him the program that checked for the stoned virus.  He ran it and it turned out that every computer in the IT group had this virus!

Virtual Hand-Brake

And finally, in the same vein as the aforementioned airplane pilot, I leave you with an innovation that a number of us came up with, but no one ever figured out how to implement: The virtual hand-brake!

Have you ever had one of those times when you realized that the computer was causing havoc faster than you could undo it?  You need a virtual hand-brake!

I could probably go on for hours, but it's been long enough for today!  I hope you enjoyed this little trip down memory lane!

Saturday, February 3, 2018

My First Computer!

The company made an offer to some of their employees, including me. There were a number of opportunities available, and if you agreed, on your own time, to create one of the suggested products, the company would buy an IBM PC XT, and you would over time become the owner.  I'll talk about the project I was offered in another post.

So, I got my first computer. It was the IBM PC XT. It had dual floppy drives and a 10 MB Shugart hard drive.  Terry Winter had a 10 MB hard drive that was larger than most modern desktop systems, so I was impressed with how small it was, and convinced I wouldn't run out of space for a long time.  Was I ever wrong!

Partitioned half the hard drive and would boot into R83 from Pick Systems.  At that point, half my drive was unavailable for DOS stuff.

Then, I got hold of something called Revelation version G.2, and shortly thereafter, a bug-fix of G.2b.

This took up some of my space and I started creating applications with it. I had two applications that my church used for tracking finances and Sunday School attendance.

The Rev G.2b application I wrote for my church - still runs under DOSBOX!

The final blow was when I got a Mark Williams C compiler.  Suddenly, I had to manage my space, and back things onto floppy (never just one, it was always a series of floppys.)

The problem with backups on floppy was that the likelihood that one diskette having an error was fairly low, but when you multiplied that by 4 or 5 floppies, the likelihood went up. If you took one backup, you'd have a bad floppy. If you took two, you'd have a bad floppy in each. If you took three, all three would be fine!  Did I mention that floppies were slow? They were just slow enough to drive you crazy, and just fast enough that you couldn't really do anything else. And this was DOS. If you were copying to a floppy, you were not doing anything else!

Still, it was exciting times, and I loved the amazing new technology!

We changed the company name.  It was Toga Computer Services ("To"ny and "Ga"ry were the founders - hence "Toga".)  Occasionally we'd get calls from people who thought we were a laundromat.  The new name was Datasense.

Sunday, January 28, 2018

Personal Computer Invasion!

I had the great pleasure of being a part of the personal computer invasion.  When I started in software, options for businesses were mainframes and mini-computers.  But there were people with a vision of computing for the masses, and they were prepared to make their vision a reality.

When I was still a teenager, my older brother saved up his money from his job and bought a Tandy Radio Shack TRS-80 computer. Below is a short clip of someone using one.

My brother's computer had not hard or floppy drives. You had to use a cassette tape drive to save programs, and to load programs you wanted to run.  I can't recall if his had a built-in screen, but I do recall that he connected it to the TV.  There was a game where you had to shoot alien ships and recharge at your space station.  The one time I played it I destroyed all but one alien ship, found my station, recharged, then destroyed my space station. It gave me a message about probably getting court martialed. Then I destroyed the last alien ship.  I was the only ship left in the universe!

One of the first to really make waves was Apple.  My wife was working for Canarim Investments, in downtown Vancouver, and the bottom of her building had a store where Apple Computers was showcasing their personal computer.  It was exciting times, although the productivity gains simply weren't there in the first versions.

Here's a funny clip of some digital natives trying to figure out an old Apple computer.  It held the promise of good things, but fell a bit short on delivery:

Shortly after this, IBM came out with their IBM PC. There were several versions before the XT came out. Here's another video with someone looking at an old XT - it's a pretty long one, and the hard drive doesn't work in the end (not uncommon - the drives were always the first thing to go):

My first PC was an IBM PC XT - I'll talk about that in another post.

Soon there were lots of options! Most, like the TRS-80 were focused on games and consumers, and they were very expensive!

I remember going to computer shows, and at one of them, I ran into the Timex User Group of Vancouver (TUG).  This was the same company that made watches, but they'd delved into computers. This was the heath-kit of computers.  You got to assemble it yourself and program it.  The TUG folks struck me as being like a bunch of former WW-I biplane pilots playing with their toys. They had voice synthesis and other cool things that they did, none of which were commercial grade.  But then, these were called "personal" computers.

It was exciting to be involved in the early days of a new technology that held so much promise, and I got to watch it go from promise to reality!

Saturday, January 20, 2018

The Spin-off: PC Harmony

In my previous 3 blog posts I talked about a data migration that I participated in. I'm going to segue into what happened with the IBM PC software that they used for the data migration after the project was finished.

First, I'll take a minute to talk about computer terminals and personal computers.

Mini-Computers vs. Micro-Computers

Back in the day, business computers were either mainframe computers or a new class called mini-computers.  Really large companies could afford a mainframe, but smaller and mid-sized companies generally were using mini-computers. These computers had floppy, tape, or possibly one hard drive.  Occasionally, you'd have an array of hard drives, like what PBD had (another previous blog post.)

Business computers generally involved getting someone to write you a program, or buying a ready-made program from someone and customizing it to your business needs.  But a new thing, called a micro-computer, otherwise known as a personal computer had come on the scene. One of the most powerful tools that business users were seeing on these things was something called a spreadsheet program.  Business users had always had spreadsheets, but these were on paper. This new innovation was electronic.  It was tremendously popular!  One of the best known ones, which was available on the IBM PC, was called Lotus 1-2-3. It came on a 720 KB 5 1/4 inch floppy disk.  Many PCs came with dual floppy drives, so you'd put your program disk in drive A and run the program, and you'd use drive B for your data disk.

Serial Terminals

Now, most business computers used serial terminals with keyboards and monochrome green monitors for data access.  (No, they did NOT have a mouse on PCs yet. Joysticks, yes; mouse no!)  These printers had the ability to go into what was called Slave Print mode. The computer would send a special escape sequence (a string of characters starting with an ASCII 27, otherwise known as ESC) which would tell the terminal to send output to it's secondary serial port, which was usually an attached printer (referred to as a slave printer.)

A Product is Born!

The only problem was that these business computers had all the data, but the PC had the wonderful spreadsheet tool. How can you bring these two things together?

Now put that together with software that captured printer output in the previous blog posts, and an idea was born!  Synex Systems decided to come up with a software package that imitated one of several popular serial computer terminals like the ADDS Regent 40 terminal, but they added a new escape sequence, one that none of the real terminals used for anything. That code did the equivalent of a slave print, but it would capture the output to an ASCII file on the computer.

Then, they had another tool that you could use to set a ruler on the output file, assuming that it was typical columnar report data, and it would import the data into a word processor mail-merge, or a spreadsheet, or a desktop publishing program like Framework, or a PC-based database like dBase.

They developed a version for MAI Basic Four first, as they had worked with one at Terry Winter. Then they went on to do versions for almost all the Business BASIC systems and for a Wang BASIC system.  This product family was called PC Harmony.  MAI licensed an OEM version called MAI PC-Link. Thoroughbred Business BASIC licensed an OEM version called Thoroughbred-Link.  Other Business BASIC vendors just pointed their customers at Synex.

The PC Harmony product included components that ran on the PC, and Business BASIC libraries that were made available on the mini-computer.

I wasn't involved in the development of PC Harmony, but was aware of it happening as I continued to work for Toga Computer Services.

Sunday, January 14, 2018

My First Data Migration - Terry Winter - Part 3

Part 1 is here

In the previous parts of this story, I talked about the problem to be solved, and how we did the migration of the raw data to the staging file. Now we'll talk about what needed to be done with that data.

The data we had was all in a single staging file.  We needed to extract fields and records and write them to the appropriate PICK files (think "tables" if you're from the relational world).  I had to write a program that would take each block of text, and the control codes that said when to change print direction or issue a linefeed, and keep track of the relative offset. For backwards printed text, I had to reverse the order of the letters, all while tracking relative position. I also setup a control file where we defined a "ruler" for the fixed length fields in the print report from the BASIC Four machine.  I then extracted out the data, and for each field, wrote it to the appropriate PICK files.

Data Cleansing

Along the way, we ran into some data cleansing issues.

The first one was that spaces needed to be trimmed out, especially leading and trailing spaces.  But then things got very interesting.  

The system was used to track donations, but it didn't do arithmetic on them. As a result, there was no harm in using upper case "O" instead of a zero, or lower case "L" instead of a 1 (1, l - see they look very much the same!)  This meant that wherever there was a field that should have been numeric, you had to do some careful checking. We discovered that we could automatically replace a couple of these characters and recheck that it was numeric and that would get most of the cases.

The other thing that had happened was that people would use the arrow keys.  Let's say you were spelling the word "Hello" but you hit the letter "p" (right beside "o") instead.  What you really should do is use the backspace key to erase the p, then type the o.  Instead, these staff would press the back-arrow key and type "o". This moved the cursor over the p and displayed the o in its place, so it looked right but in the data, you had these characters:  "Hellp.o" where the '.' was actually a low ASCII control character. With text this was not so bad, but when you did it with numbers, it created an interesting problem!

We also had to deal with dates.  The Microdata couldn't handle lower case dates. "14 Feb 2018" would confuse it, but "14 FEB 2018" was just fine.  The BASIC Four was taking dates as text, so it didn't care. It didn't have to do math, it just had to print it. So we had a cleanup around dates, including the back-arrow problem noted above.  If you spelled a date "14 FEV 20018" the BASIC Four didn't care. It would simply print it.  The Microdata was unable to convert it and gave you an empty string.

Also, from time to time, we had a corrupted record from the transfer into the Microdata. Despite all the delays we put in, sometimes the Microdata would lose a character or two. I would have to go in manually, figure out what the correct positioning was, put some placeholder data in, record the donor information, and we'd have to go back to the BASIC Four to make sure we updated the correct data manually.

Application Development

Finally, we had transferred all the data and were ready to develop the application in Data BASIC.  The first order of the day was two simple programs.  One to capture information for a new donation, and one to print out a receipt that could be mailed to them.  We actually setup a test account that had a copy of the transferred data and started working in there.

Down the hall from their office, Terry Winter had fairly narrow book room. They would send out books as an offer with donations of a certain amount or more.  The room had a shelf for boxes of books, and enough room for a table and a chair. That was where I worked. It also had a door to another small room that had the Microdata and the Printronix chain printer as well as the air conditioning and power supply.  The cold air would seep through door from the computer room to the book room and I'd sometimes work with my jacket or a sweater on. From time to time, there would be a knock at the door and I'd help a shipper to load a couple of boxes of books on the shelves.  Still, it was a good paying job in a recession and I loved the opportunity to create a brand new application for a customer!

Agile Before Agile

This was long before Agile was a thing, but I would make it a point of choosing a key set of features in consultation withe the customer, developing code to the point where the user could see a prototype, then showing it to them and getting their feedback before proceeding.  The feature set to develop was always negotiated with the customer.  They were holding on to donation data, so as soon as the data entry program had all the essentials in it, they took it and started entering the data. The first version, having been rushed out the door, had some annoyances for the users that impeded productivity, so we focused on those for the next version.  The receipt printing program followed immediately on the heels of the first donation entry program version, as they needed to print and ship receipts, then we did the changes to deal with the annoyances. After that, we started building out new features and functionality.

When Agile methodology first came out, we had a bit of trouble understanding what the hype was.  We weren't full-on Agile by today's standards, but the concepts were baked into our DNA! I've had to deal with waterfall mode (it still has its place), and I can tell you which approach suits me better!

So that was my first data migration, and my first full application written from scratch!

A couple years later, I was still occasionally doing support for them.  Joan Winter called me up and told me about a bug they had encountered.  I told her what program to go to, roughly what line number, asked her to read me the code, told her what to change and got her to compile and catalog the program.  I fixed the bug over the phone from memory!  For me, software is like an old friend. I know it intimately, and can quickly pull it back up from memory.  OK, I am weird... I'll admit it!
While the news occasionally caught some big televangelists doing inappropriate things, Terry was the real deal.  He didn't drive a Rolls Royce, he drove a station wagon. For quite a while it had plastic in a window because a thief had broken into it.  He wasn't about ego.  He insisted on the local churches funding his crusades and would only have 1 offering taken, on the last day of his crusades.  He was serious about reaching out to Canadians with the gospel. He was not as big as Billy Graham, but he had the same integrity.  In December, 1998 Terry Winter passed away suddenly from an aneurysm.  I consider myself fortunate to have known him and his family!

Saturday, January 13, 2018

My First Data Migration - Terry Winter - Part 2

Click here to read part 1 of this blog.

The first day on the job, I was standing by the book room, which was just outside of the computer room. As noted in the previous post, the computer they were going to migrate to had 48 KB of RAM and a 10 MB hard drive, all fit into a chassis the size of a large fridge.

I watched my brother and his friend John carry the IBM PC in.  John had the PC, with the hard drive balanced on top, and my brother was carrying the monochrome monitor, keyboard and a power bar (no mouse, this was DOS, not Windows.)  This computer had more than 12 times the RAM and the same size hard drive, and they were carrying it in their arms!

To give you an idea what it would have looked like, here's a picture of my IBM PC XT. This one had the hard drive built in. In their case it was about half the size of the system unit, balanced on top.

They plugged it all in.  It needed one plug for the system unit, one for the hard drive (because it was external) and one for the monitor. When they turned it on, the hard drive sounded like an airplane motor starting.

The plan was to print a massive report of all the data to the Diablo, but instead of the Diablo, they would hook this into the IBM PC's serial I/O port.   This brought us to the first challenge:

The Diablo wanted the data to come to it at about 9600 baud (just under 1000 bytes per second).  The IBM PC's interrupt handler code for the serial port could barely handle 1200 baud on a good day. So they had to write an assembler routine to handle the serial I/O interrupts and replace the existing handler with this. This core routine was a critical piece of software for anyone wanting to do terminal emulation in future years on the IBM PC architecture, including all the clones that came out.

So they took the printer cable for the Diablo and had to rewire it a bit to connect to the IBM PC. It seems that pins 1 and 2 were used for send and receive, but you had to switch them at one of the ends, or you'd have the equivalent of someone holding an old phone receiver upside down, listening at the microphone and talking to the earphone.

They wrote a program on the PC to capture the data and write it to the hard drive.  I believe it was in assembler, but could have been in C.  Then they started with the surnames starting with the letter "A" and printed the report off of that 7 1/2 inch floppy.  They repeated this until they got to the letter "Z".

Then they ran through the data and organized it. They found all the places where escape codes were used to change direction and processed them specially.  Finally, they were ready for the "forward" part of the "store and forward" operation.

This was even trickier.  The Microdata's serial I/O handler was not interrupt driven the same way as the IBM PC.  The program had to be at a BASIC INPUT statement before you could send it data. Otherwise it would just echo a BEL character (your terminal would beep!)  What's more, even in input mode, if you sent two characters too quickly, you would lose the second one.  A human could type too fast for it, let alone another computer. In later years they implemented a type-ahead buffer, but at the time we were doing this conversion it wasn't an option.  The IBM PC could out-type any human, so the output program had to have some special logic.

We would send a character, then wait for the other end to echo what we sent.  As soon as we saw the echo, we'd start a delay of n milliseconds. I believe they parameterized that delay so they wouldn't have to change the assembler program each time.  When they sent a carriage return, you waited for the carriage return and linefeed to echo, then you put in a really long delay (almost a whole second as I recall it.)  Then you could get on with the next character.  This part took several days to complete and had to be restarted from time to time, when characters would fail to echo and the PC would stall, or other problems were encountered.

Finally, the data was all captured into a staging file on the Microdata.

Next post I'll talk about how we got that data into the target files and the data cleansing we had to do.

Thursday, January 11, 2018

My First Data Migration - Terry Winter - Part 1

One of my early customers was a company called Terry Winter Christian Communication.  Terry Winter was a televangelist, similar to Billy Graham, who had a TV show in Canada and did crusades, focused on smaller Canadian cities.  When I first got to know him, his company, and his family, they were looking to replace the system they used for tracking donations and providing tax receipts and reports to what was then called Revenue Canada with something a bit newer and capable of better functionality.

Their system at the time was an MAI Basic Four system that did not have a hard drive, but used a bank of 4 7 1/2 inch floppy drives for data. They organized each letter of the alphabet on its own drive. They had recently run out of room on their "F" drive, in part due to the large number of Mennonite donors across Canada, and the fact that the surname "Friesen" was very prevalent in that community, so they were now having to work through 2 floppies for the letter "F".

To print off receipts and reports, they used a serial printer called a Diablo. They referred to the MAI system as a Sol (can't find any references to it on the Internet) and this was a bit of a joke, as a Christian organization's computer Sol (soul) was connected to Diablo (Spanish for "devil").

Printing from the Basic Four to the Diablo was really interesting in that it would print a line of text, then send a line feed, then if the next line was longer you'd space out to where the last of the text would have been. Then you sent a code to tell the printer to print backwards and you'd send the next line of text in reverse. The printer would print it backwards to the start of the line! You'd send another line feed and a code to put the next line back into forward printing mode. This is important in the data migration stage.

The system they were going to go to was a Microdata Reality system with 48 K of RAM, 4 terminals, and a 10 MB hard disk. It used 9-track tape for backup and was the size of a refrigerator, but unlike the PBD system, the hard drive was inside the system unit. That 10 MB hard drive was as large as a big desktop computer is today.

We had 2 simple tasks:

1. Transfer the data to the new computer.
2. Design as system that let them take donations, and print receipts and Revenue Canada's annual reports.

After that we'd add additional functionality.

In order to do the transfer, they brought in the first ever IBM PC bought in the Vancouver area.  It was bought by Chris Graham of Synex Systems as an IBM PC 5150 with 256 KB of memory, the maximum it could hold at that time. It had 5 1/4 inch floppy drives and no hard disk.  As soon as the PC XT chip came out, he upgraded it added a 10 MB external hard drive.  Some time later he upgraded it to bump the memory to 640 KB.  This was the configuration that they used to do the data transfer with.

The recession was in full swing by this time, so Toga came up with a deal where Terry Winter got me full time for just a bit more than what I cost, so I'd be paid and Toga would not be out of pocket for my salary.

Next post we'll talk about the data migration itself.