The Development System

In the beginning rush to start on the Vectrex, there were different development systems ‑ some more reliable than others. During the transition from Western Technologies to GCE, we had time to let things settle down and prepare for the work to come.

The system we chose was built by Ithaca Intersystems. I'm sure that it had a Z-80 processor with 64 kb of memory and two 8-inch floppies. There was no such thing as a small system hard drive at that time.

The first operating system we used was Digital Research CP/M (DRI-CP/M). Toward the end, I think we switched to Digital Research DOS (DR-DOS).

There was a degree of compatibility when running executables from either DR-DOS, MS-DOS and CP/M. Not all programs would run, but most would. It wasn't a big deal to switch between operating systems ‑ for example, you could take-out the CP/M disk, put in the DR-DOS disk and boot the system.

The file system for the three operating systems seemed to be identical. A file written on CP/M could be read/modified by a program on either DR-DOS or MS-DOS and vice-versus.

We used a cross-assembler called ACT09. We would write 6809 assembler code using a text editor, ACT09 would read the source file and it would generate a HEX file. The HEX file could be loaded to a ROM Emulator (or ROM-ulator ‑ I think that's what we called it) or the HEX file could be downloaded to an EPROM programmer.

My text editor of choice at that time was WordStar. The same binary ran on all three operating systems without any trouble at all. There wasn't anything like a mouse when it came to editing. Positioning would be up, up, right, right, make your change and then down, right, right ‑ all day long.

The source code would look like:

         -
         -
TSTBOX   LDA     OPEN             ;  OPEN / CLOSE BOX ?
         BEQ     SCNRY3           ;  .    HAS OPEN BUTTON BEEN PUSHED ?
         LDA     [CBXOBJ]         ;  .    IS IN-FRONT OBJECT A BOX ?
         ANDA    #$E0             ;  .    .
         CMPA    #$80             ;  .    .
         BNE     SCNRY3           ;  .    .
         LDA     WARFLG           ;  .    IS A WARRIOR REQUEST PENDING ?
         BEQ     SCNRY3           ;  .    .
         LDA     FOGFLG           ;  .    IS FOG OR PLAGUE PENDING ?
         ORA     PLGFLG           ;  .    .
         ORA     TSTAT            ;  .    IS A TUNE PENDING ?
         BNE     SCNRY3           ;  .    .
         -
         -

The resulting HEX file would look something like:

:100000006720474345203139383280FEF8F85030B8
:10001000E8574F524B494E478000BDF18B7CC824B6
:100020008EC8836F808CCBE926F97FC8268680B77F
:10003000C900CC9000FDC901BDF192CC80C0FDC8C3
:1000400090BDF354B6C8902605BDF2A9200C840FCC
:100050002605BDF2A52003BDF2A1FCC890BDF2FCAF
:1000600086889704CC007FBDF3DFFCC8908B08FD29
:10007000C89081682FCBCC68C0FDC890BDF354B642
:10008000C8912605BDF2A9200C840F2605BDF2A556
:100090002003BDF2A1FCC890BDF2FC86FF9704CC02
:1000A0008000BDF3DFFCC890CB08FDC890C14F2F86

The first three characters (':10') was some kind of control field. Though I'm not certain, I think that the '10' was actually a hexadecimal count (10 hex = 16 decimal) of the binary bytes that followed.

The next four characters ('0000', '0010') after the control field was the address at which to start loading.

The characters after the address ('00', '06', '72', '04', '74' ...) are the hexadecimal values to be loaded. '00' would be written into address#&160;'0000'. '06' would be written into address#&160;'0001'. '72' would be written into address#&160;'0002' and so on.

The ROM-ulator was a tool that took the place of the EPROM. It contained RAM and code be loaded from the development system. This made it easy for us to write code, assemble it and then download it to the ROM-ulator. Once in the ROM-ulator, we would reset our Vectrex and it acted like a regular game.

To pass around playable examples of the game, we would download our code to an EPROM programmer (which we shared). The programmed EPROM would then be inserted into a cartridge which had a socket for it. When (and if) we got the EPROM back, we would use an ultraviolet (UV) light to erase it and then it would be ready to be re-programmed.

The floppies were a real limit to how fast things could be done ‑ things like assemblies and backups would take progressively longer as the game grew.

At one point, I had two systems. I would work on some parts of the game on one system and other parts on the other. I would get to the point where I wanted to see my code execute, so I would assemble what I had on the current system. While waiting for that to finish, I would move to the other system for a while.

It sounds better than how it actually worked.

One problem was that I would get caught-up on what was in front of me and start to forget what I had been doing on the other system. Another issue was that as the game got closer to completion, you had to deal with the whole game and not just a couple of fragments. It quickly got to the point where I did all my work on one system and kept the other system as a backup.

What Was It Like?

Mark Indictor and I both lived in the San Bernardino mountains ‑ about 2 hours east of Los Angeles. We both worked from home. If the weather was good, we lived about 20-minutes apart ‑ Mark lived up-mountain from me. I should say that I was always (and still am) a bit of a recluse ‑ so working from home was ideal.

My usual day would go something like this: I usually get-up pretty early (around 04:00) and I would go out for breakfast. When I got home, I would make a pot of coffee and start work.

While working, I pretty much ignored all interruptions and focused on the game. Around lunch time and while I was waiting for the assembler to finish a run, I would fix a sandwich (I ate a lot of peanut butter and rarely any since). Dinner was something similar. I called them one hand meals ‑ something to eat in one hand and the other on the keyboard.

I would continue to work until about 21:00. My typical work day was around 14 hours ‑ 7 days a week for a very solid 3 or 4 months. I had a few breaks like shopping, but there really wasn't any escape from the game ‑ it's always in your head.

I don't remember if it was stated in our contract, but I think that we were expected to write 2 or 3 games a year. Since there were various bonuses, it was more than worth our while to get as much done as we could.

For me, it took a couple of weeks at the beginning of a game to really get focused and develop a clear idea of what I wanted to do. During this time, I would be drawing objects, playing with animation and game logic ‑ the majority of which would be discarded as not quite right.

As I went along, I would work longer and longer hours until the game was done. The game would consume all and it was fortunate that I was single and didn't mind the long hours.

After the game was done, I always felt a real emotional letdown ‑ call it a depression if you like. During development, the game was everything. As you approached the end, more and more attention (and pressure) would be put on you and the game.

Once you gave them the game, there were accolades for a job well done and then suddenly the attention would shift elsewhere and it was almost like you didn't exist any longer. At least for me, it would be a pretty hard letdown.

A dark funk would stay with me for a while. For the first couple of weeks, I would sit in front of the TV and watch pure junk ‑ there was no energy or interest in anything else. I don't think I can honestly express how deep the letdown could be.

As I started to feel better, I would take a few weeks and make some trips into the eastern Sierra Nevada mountains (which I dearly love). Gradually I would start to think about what I had done and what I would like to do for the next game. I still didn't have a game, but I would start thinking about it.

Just a comment about TV: At that time there wasn't anything like cable or satellite TV. Being in the mountains limited what could be received and at times, I could only get one or two channels ‑ and even then, it would be poor reception. In truth, it kept TV from being a distraction.

There were always 'ghosts' associated with a finished game. Until I really got involved in the next game, I would think of little changes that should have been made to the last game, something that would make it play better or maybe fix a bug that was just recognized.

These thoughts always came when doing something else. I would stop and then make some notes. I would call people and the response was always the same ‑ you finished that game, it's done and it's time to move on.

That was the case with the bug in 'Mine Storm'. I had tested it as much as I could. It had gone through game testing without any problems and then it went to manufacturing.

Shortly after sales began, the bug was discovered. The moment it was described to me, I knew what the problem was. I talked to a bunch of people trying to get it changed ‑ I even went home (a two hour drive each way), made a corrected version and drove back to GCE. Nope, 'Mine Storm' was done and how are you doing on 'Fortress of Narzod'?

Having to live with your bugs is really hard on the ego.

Even still and for a long time after, I would think of this or that. I would have that moment of panic and then need to remind myself that it was done. Like I said, ghosts.