Saturday, December 3, 2016

Origins of Nox Archaist




kickstarter.noxarchasit.com

By: Mark Lemmert

This is a follow-up post to Why an Apple II Game?

---------

Return to Nox Archaist Kickstarter Page

My parents bought an Apple II+ computer in the early 1980s when I was 5 years old. I grew up watching my older brothers dabbling in computer programming on that machine and playing cool games like Ultima, Wizardry and Bards Tale.

At that age those games were so captivating and also such a mystery to me. The first RPG I recall experiencing was Ultima III when I was around 8 years old. Sometimes when my brothers were finished playing they would take out the disk and let me play the game without risk of accidental saves to disk screwing up their characters.  I had no idea what I was doing beyond using the arrow keys to move around, but it sure was fun! In the last year some of our younger relatives have playtested pre-alpha versions of Nox Archaist and it was very reminiscent of this experience.  

I began to explore Applesoft basic around the same time and the desire to created my own tile RPG grew quickly. Of course, I had no clue where to start. Over the years that followed I spent untold hours learning programming, playing games and studying them. I also spent a lot of time reading fantasy books like Dragonlance, watching nonsensical movies like Monty Python’s Holy Grail, and imagining some day being able to channel the fantasy creativity they sparked into something of my own creation.

As a teenager in the early 1990s I had a light bulb moment. I figured out a possible method to create a tile-based map on the Apple hi-res screen. In theory it would allow the player to move across the screen when the arrow keys are pressed. I remember exactly where I was when the light bulb moment occurred; in a car on the way home from visiting my oldest brother in Oklahoma a few years after he joined the air force. Needless to say, I was very anxious to get home to Wisconsin and write some code to test out my idea. 

Once back at a computer, I spent many hours programming a proof of concept in Applesoft. I remember the moment when I typed in “RUN GAME”.

The disk drive whirred.
It whirred some more.
It whirred for longer than any other program I had every written. 
I began to wonder if I had broken the disk drive.         
The screen went black.
The Applesoft prompt disappeared.

I thought any moment now it might start working, but instead the Apple offered up a familiar “Beep!”. The net result of those many hours of work was an error message displayed on the video monitor. I do not recall the exact error, but I knew it meant my program had exceeded the amount of memory reserved for Applesoft programs.

At this point I was stuck because I could not find a way to allocate the additional memory required to my Applesoft program. As a result, for several years I didn’t know if my tile-based graphics engine design actually worked.

Around 1992 my parents bought an IBM compatible 386 computer. One of the first things I did on that computer was learn Microsoft Quickbasic 4.5 and tried again to program my tile-based graphic engine design. Much to my delight it worked! Much to my disappointment, it was horribly slow! The tile map graphics appeared on the screen and the map moved in response to the arrow keys. However, it was painful to watch the incredibly slow screen draws after each player move.

I didn’t know how to resolve this problem and shelved the project. This was the last attempt I would make for decades.

 
Battling 6502 Assembly Language: Round 1

For any programmers reading this, the story so far probably begs the question the following question: why didn’t I try using assembly language?

My dad is an incredibly smart guy and knew that most commercial Apple II games were written in assembly language. In the 1980s he was a high school chemistry teacher (now retired) and was constantly reading. He would read magazines like Nibble on a regular basis and talk to other people who were experiencing the early personal computer revolution. Unfortunately, like me, he did not know how to write assembly language programs.  

But, he tried to help. He found the one and only assembly language book at the library at the high school where he taught. I tried very hard to understand the book, but was not successful. At that point my experience with programming was limited to typing in Applesoft basic programs by turning the computer on and tying in the program code at the first prompt that appeared. There was no compiler involved, and in fact I had no idea compiler programs were used for some languages. Of course, assembler software like Lisa, or Merlin existed at the time, which could be used to write assembly language programs on the Apple II, but I did not know that back then.

As a result, I was very puzzled when typing assembly commands like “LDA $9000” at the Applesoft prompt did nothing other than produce a beep and a syntax error message. There were a couple adults I came into contact with who had programming experience on main frames. When I asked them about assembly language my vague recollection was that their responses collectively were something along the lines of “I’m not sure how it works on the Apple”.

In hindsight I realize that I was asking the wrong questions. And I had the wrong book.
The book I was reading was not a book for a beginner, and assumed the reader already had an assembler program and knew the fundamentals of the language. At that time books on programming, especially assembly language, were hard to come by and this was the only one available to me. I was stuck.



Time Warp

I’m going to cover about two decades in two paragraphs. The RPG project was stuck on the back burner as I became interested in modems and computer bulletin board systems. I launched a BBS out of my parents house in 1994 and turned it into an Internet Service Provider in 1996, just as the general public started to become aware of the Internet. This ISP was one of only a few local options to explore this new fangled Internet and the business quickly took off. Not long after the company was launched I abandoned my computer programming studies at a local college to focus on the business full-time with my brother and future Nox Archaist project co-founder Mike Reimer. After several mergers and acquisitions, it became the largest independent ISP in Wisconsin in the early 2000s.

By 2004, my career had shifted from IT to finance and business. I returned to college part time and eventually completed a bachelor's degree in finance, an MBA, and earned a CPA license. While I occasionally thought about it, the prospects of ever picking up the project of developing an RPG seemed further away than ever.


Nox Archaist Project: Modern Era

In 2014 I bought an Apple IIe on ebay because I thought it would be fun to play games like Castle Wolfenstein and Ultima again. Mike liked the idea as well and over the course of about a year we replayed many of the Apple games we had enjoyed as kids. 

After playing though a few games, Mike commented that it would be fun to develop an RPG as a mobile app. We kicked the idea around for a while but it never got off the ground, partly because I still wanted to finish the Apple II RPG I started as a kid.

Explaining the reason is difficult. I’m not sure I fully understand it myself. To some extent it is probably a sense of unfinished business and wanting to summit the mountain I tried to climb years ago, so to speak. And, also, I think it’s a good measure of whatever it is about Apple II computers that still keeps tens of thousands of people captivated with them to this day.

Coincidentally, the tipping point that led to decide to renew my pursuit of developing an Apple II RPG involved Ultima III, the first RPG I played many years ago. In the fall of 2015 I purchased a 5.25” copy on ebay because I wanted to make a disk image so I could play Ultima III in emulators in addition to my Apple IIe.

I quickly learned that the copy protection built into commercial software by developers in the 1980s prevented disk images from being made. I also learned that the solution to this problem required stripping the copying protection off the 5.25” disk, not just working around the copy protection with a program like Copy ][ Plus or Locksmith like I might have done back in the day.

For some reason, I wouldn’t let the matter drop. Copying software for the purposes of making a backup or using the software in a different medium (i.e. an emulator) is legal and I wanted the software in a digital medium that would theoretically last forever. I started looking at solutions published in 1980s magazines for removing copy protection from various games.

The solutions I found involved typing in some assembly language commands and running a special copy program written in Applesoft. I couldn’t get the solutions to work. As I did research to try to figure out the problem, I found myself learning more and more about assembly language.


Battling 6502 Assembly Language: Round 2

Eventually, I resumed my search for an assembly language book written for beginners. This time, I knew what kind of book I needed and found it: "Using 6502 Assembly Language" by Randy Hyde. It is written specifically for use with the Liza Assembler, one of several popular assemblers used in the 1980s. I read the book cover to cover, and typed in most examples.

The college classes I had in the 1990s on computer architecture really helped in understanding the material in the book. By the time I finished the book I realized that I had learned enough assembly language to make a serious attempt at once again trying to develop an Apple II tile-based RPG. My motivation to crack the copy protection on Ultima III soon faded, replaced by the long dormant desire to create a game. 

Ok, this probably bears some explaining. How in the world does a finance/business guy who had a few computer science classes in the 1990s pickup one book on assembly language and suddenly know how to develop and Apple II RPG?

While the computer science classes were helpful, the many years of trial and error I spent as kid trying to put together a working tile-based graphics engine were the most significant factor. What I found during the process of creating Nox Archaist was that the skills needed to write the other components of an RPG are very similar to those needed for the graphic engine. While there is much more to writing an RPG than the graphics engine, it is arguably one of the hardest parts.

To build the knowledge base needed to start programming the game I essentially had to figure out the assembly language required to produce results similar to my old Applesoft and QuickBasic code. This was much easier that it would have been starting from square one with no conceptual understanding of how the engine mechanics worked. 

My computer science classes from the 1990s helped in figuring out a plan of attack and providing context to what I was reading. For example, I knew that programming languages at their core are very similar, each containing a mechanism for performing flow control, arithmetic, and I/O. I had a basic understanding of the role of computer hardware, the operating system, application software and how they interacted with each other. This made it possible to understand the structure of assembly language and picture how I could use it to do what was necessary to replicate the tile-based graphics engine I had written years ago.

While “Using 6502 Assembly Language" by Randy Hyde is an excellent book, it certainly did not contain all the information that I needed.

Some major holes that remained were disk I/O, random numbers, hi-res graphics, printing text to the hi-res graphics screen, and a mysterious thing I didn't know I needed called a boot loader.  Filling in the holes took months of tracking down old technical manuals and spelunking in old Apple II newsgroups. Eventually I found the comp.sys.apple2.programmer forum which is haunted by some of the few remaining true masters of 6502 assembly language.   

After launching the Nox Archaist project I also met Beth Daggert, a former 1980s game developer, and Peter Ferrie (aka qkumba), an assembly language master, who have been kind enough to brainstorm with me on a variety of technical challenges. The comp.sys.apple2.programmer newsgroup community has also been very helpful in answering questions. 


Conclusion

By late 2015 I was writing code for Nox Archaist, though the game had not yet been named. One evening I met up with Mike Reimer for dinner and let him know what I had been up to and asked if he was interested in collaborating on an Apple II RPG instead of an RPG for mobile devices.

Soon after it was official. We formed 6502 Workshop and began work on a new Apple II RPG called Nox Archaist. On March 26th of 2016 we launched the Nox Archaist website and publicly announced the project. In September 2016 we welcomed our first team member, Bill Giggie, a professional graphics animator in the movie industry. Bill has been instrumental in providing new and innovative tile artwork for the game.

In addition to creating awesome games, a goal of 6502 Workshop is to be a modern resource for information on how to develop RPGs on the vintage Apple II platform. This is motivated in part by the fact that I’ve yet to find a book on the subject. Our intention is to provide information on our website describing this journey and providing insight into the development techniques we used to bring Nox Archaist to life. Hopefully this will help out people with similar crazy aspirations. We welcome any questions you may have!

Also, if you've enjoyed this post and/or are interested in Nox Archaist please post a comment and let us know. We really enjoy hearing from everyone!



kickstarter.noxarchasit.com

4 comments:

  1. What was the general idea you struck upon for your tile engine? What do you think made the QuickBasic version too slow?

    ReplyDelete
    Replies
    1. Great questions. Up to the point of the light bulb moment, I was picturing the graphics architecture of tile games as being analogous, to an extent, with the way animated cartoons were developed in the 1980s (i.e. each frame of the cartoon being drawn by hand and then the frames flipped fast enough to simulate movement). I envisioned that each “screen” that the player saw in a tile game was a hand plotted hi-res screen and that when the player pressed an arrow key to move, and other hand plotted hi-res screen was summoned from memory and displayed.

      By hand plotted I mean fixed coordinates were used for each line/pixel (in Applesoft, something like HPLOT 10,10 to 20,20 instead of HPLOT x1,y1, to x2,y2). At that time I had the skill to drawn a complex hi-res screen on graph paper and plot it with fixed coordinates, but I couldn’t comprehend how the computer could have enough memory and disk space to account for the hundreds if not thousands of unique screens that exist in even a 64 tile X 64 tile map.

      I spent years wrangling with this problem. The tipping point was when I wondered whether it was possible to dynamically address array elements in Applesoft. For example, A(x) = 50 instead of A(1) = 50. I tried it out on my brothers Apple IIc when I was visiting him in Oklahoma City and it worked. On the drive back to Wisconsin I started to imagine what I could do with this new tool in my toolbox.

      Essentially at that moment, the lightbulb turned for me that most things in programming could be done with dynamic or relative addressing. On the long drive back to Wisconsin I started to picture the following tile-engine design:

      *setup subroutines which draw each tile shape using relative addressing (i.e. HPLOT X+10,Y+20)

      *Use a loop (screen draw) that change the value of X and Y to place each shape at the hi-res coordinates for each tile on the screen.

      *In the loop, determine which shape to draw based on map data (tile IDs) stored in an array.

      *A formula would determine which array elements were associated the tiles on the current graphics screen.

      *When the player pressed the arrow keys to move, the formula would be adjusted, and the draw loop would be run again.

      In assembly language the implementation details are a lot different but the fundamental concept remains the same and is used in the Nox Archaist engine.

      The other question: Why was the quick basic version too slow. The short answer is that quick basic 4.5 itself was too slow on a 386 PC to run the draw loops fast enough. More specifically, as a 3rd generation language, quick basic could not access video memory directly which precludes an important tile engine design technique known as screen scrolling which was very important on early personal computing platforms.

      The Nox Archaist engine only does the initial screen draw (at boot up or after a map change) using a loop to draw each tile on the screen (as described above). When the player moves the engine only draws the tiles that were not on the screen before; usually 6-15% of the total tiles. The tiles that were on the screen before the player move, and after the player move, are relocated on the screen using the screen scrolling technique.

      Screen scrolling is performed by copying the graphics data in video memory to different memory addresses. The copy is an ultra low level operation that is much faster than a shape drawing subroutine.

      Delete
    2. My vague memories of QBasic was that you could write to screen RAM with DEF SEG tricks. This page seems to confirm it, although I don't think I have a copy of QBasic to hand to try it.

      http://www.petesqbsite.com/sections/tutorials/zines/qbtm/8-memory.html

      Delete
    3. Very interesting, thanks. I never encountered that information years ago, but then again, I wasn't familiar with graphics scrolling back that so maybe I looked right past it.

      There would be a lot overhead in a 3GL memory access command but certainly it should be faster method of moving graphics than redrawing them, so maybe it would have worked. Unfortunately I don't have the source code anymore for my quick basic tile engine or someday I would try it just out of curiosity.

      Delete