Jump to content
IGNORED

Gauntlet by Donald R. Lebeau 1984


highendsystems

Recommended Posts

I'm pretty sure if you aren't using BASIC, anything over $82 is fair game, which is about 126 bytes of free zero page space. Don, are you turning off the OS in your Gauntlet game (this would cause it to not run on an 400/800 machine) and then running your own interrupt routines (VBLANK, etc..) ??? A lot of demos and new games does this trick, but that means it only runs on an XL/XE series machine.

Link to comment
Share on other sites

I'm pretty sure if you aren't using BASIC, anything over $82 is fair game, which is about 126 bytes of free zero page space. Don, are you turning off the OS in your Gauntlet game (this would cause it to not run on an 400/800 machine) and then running your own interrupt routines (VBLANK, etc..) ??? A lot of demos and new games does this trick, but that means it only runs on an XL/XE series machine.

The OS doesn't need to be turned off (although that does give you some more RAM in the XL/XE computers. Just need to update a few vectors jumped to be NMI and IRQ to point to your own handlers. You can then use almost all of the RAM however you want (except for the few vectors that are called from the ROM IRQ and NMI handlers.

 

--Ken

Link to comment
Share on other sites

Wow.. Did any of this code interfere with later Atari machines (the XL/XE series) or did they not use any "new" page 0 locations?

 

I think Gauntlet runs on the later machines, but I'm not sure. Never heard that it didn't. By the time those machines came out I had already moved on to other things.

 

Don, are you turning off the OS in your Gauntlet game (this would cause it to not run on an 400/800 machine) and then running your own interrupt routines (VBLANK, etc..) ???

 

I'm not actually "turning off" the OS. I just stopped using the parts of it that I didn't need. Like for the video, I used Atari's video interrupt code to drive the video controller and daisy-chained it with my own routine to handle the Gauntlet stuff, so I didn't touch the page zero locations that Atari's video interrupt code needed. But I didn't use any of Atari's draw or graphics routines, so I could use all those page zero locations. Some pieces of the OS I never used, like the disk utilities, so I could freely use all the page zero locations associated with them.

 

At first I was pretty timid about using any of the "reserved" Atari locations. It just took me a while to realise that I could use most of them as long as I didn't need the functions I broke. The only stuff I left alone were the locations needed by the video interrupt and the keyboard. I drove the sound chip and read the joystick ports directly. Gauntlet doesn't use anything else - it takes the joystick and keyboard as input and uses the video and sound as output, so everything else was up for grabs.

 

I wrote the Game on an 800 and tested it on both the 400 and 800. When the 1200 came out, a friend tested it on that. I don't know what other machines it runs on. As long as Atari didn't move around the data in the Reserved area, it should be ok.

Link to comment
Share on other sites

Dear Mr. Lebeau,

 

I'm glad to see you were notified of this string via kid --

 

"Hey Daddy, I did what you said about the family tree and

people say you made a cool game....!, that's what Google

says Daddy...."

---------------------------------------------------------------------

 

All this talk about core code is very interesting, .... but I feel

we are drifting from the cause -- FUN!

 

I used to cut my way through mountains to get an advantage.

I used to un-leash a barrage of missiles just to sheild me.

I used to use continued bolt fire to keep that 'ball blast sheild'

I used to be killed by own 'ball blast sheild' (rarely)

U can ground enemy flying craft, 'piss 'em off and dig-in' hehe

 

I loved the saucer movement. I could actually evade almost

everything fired @ me. No kidding! I actually loved the heated

moments when I was running loops around them darned

'dirks, darrrkt, deeert, thingy seekers while fighting several

flight craft firing powerful bolts back at me. And still love

those lovely sphres that sprew-out that

'pep pep pepepepepepep" , the 'ditty-dots do hurt!

 

I beat the demo upon a time without firing a single missile/flare or Tridex

 

Once, I saved 99 Tridex for the last 9 levels, (yes, I replayed this

more than a couple times....) The Tridex flash show was as Glorious

as any Klingon exchange of fire ever seen, yet alas!, an enemy slipped

through and shared a mistaken proximity detonation of a Tridex.

Ouch! A bit brused, I hit the deck (ground) and while cutting with the

Bolt gun I tunneled some earth, just above my position the enemy tried

eagerly to get me, yet to his own demise -- as the bot could not plow

such an extented path through the terrian.... Journal -- Avid Fan!

 

 

Donald, I appreciate your presence in this forum, and for coming

forward to accept due credit for an innovative gaming concept.

 

And to all others that preserved this treasure.

 

I haven't played the full version yet, yet so glad it isn't lost!

 

This may sound like a far shot, but I would still pay $35 for the

registered version and the chance to win $1000....ehh.umm?

 

BTW, I dislike the flat UFO's that fire bolts the most....hehe

 

 

Chris

Edited by highendsystems
Link to comment
Share on other sites

as ABBUC member I just got today the new issue #92 and the 2nd 5,25 disc was Gauntletak! Cool... :)

 

Don. I am complete rewriting the engines I have developed for Beyond Evil with your thoughts in mind (scheduling, queing etc...).

 

Cool interview and pic btw in the magazine! we should submit the stuff to Retro Gamer mag, too... :)

Link to comment
Share on other sites

as ABBUC member I just got today the new issue #92 and the 2nd 5,25 disc was Gauntletak! Cool... :)

 

Yes, the new ABBUC Mag is out. Don gave us his kindly permission to rerelease his game.

 

Don, thanks again. The Mag is on the way to you... But you have to wait a little bit for the translation, my three month old son eats all my time :)

Link to comment
Share on other sites

as ABBUC member I just got today the new issue #92 and the 2nd 5,25 disc was Gauntletak! Cool... :)

 

Cool interview and pic btw in the magazine! we should submit the stuff to Retro Gamer mag, too... :)

 

as ABBUC member I just got today the new issue #92 and the 2nd 5,25 disc was Gauntletak! Cool... :)

 

Yes, the new ABBUC Mag is out. Don gave us his kindly permission to rerelease his game.

 

Don, thanks again. The Mag is on the way to you... But you have to wait a little bit for the translation, my three month old son eats all my time :)

 

____________________________________

Hi Guys!

 

Per my orignial request (posting) i.e 'This String', I would very much like a 5.25" floppy for

 

my actual Atari-8Ware.

 

 

ABBUC? Where is my Mag?

 

 

Don....This still stands -->

 

" This may sound like a far shot, but I would still pay $35 for the

registered version and the chance to win $1000....ehh.umm? "

 

 

ThanX!

Glad 2B AtariAger37 today! :)

Link to comment
Share on other sites

  • 1 month later...

Hi everybody! Sorry it's been so long. Real Life has been crazy and I haven't had time to post. I'm stuck on an airplane right now so I have some time. :)

 

Ring Buffers in Gauntlet:

 

Now that we've covered ring buffers in general, let's look and how I used them to keep everything schedule in Gauntlet. The timing of everything in the game is driven off of the video refresh interrupt which occurs sixty times a second. During each interrupt, I decide if there's any "work" to do and request that work to be done later on by stuffing a request in a ring buffer. There is one ring buffer for each type of "work" that the game can do - drawing on the screen, making a sound, rotating a font, running a think module, or creating a new object. That makes five ring buffers (It's been a while, but I'm pretty sure there's five. Age.)

 

Each of these queues holds 256 bytes and the Put and Get indexes are located in Page Zero. The data stored in each queue is always an object (ship) index, and by putting that object index into a queue, I'm requesting to do that queue's function on that object. For example, if I want to draw ship number 7 on the screen I stuff a 7 into the Draw queue. Some time later on, the background routine will check the Draw queue, see the request, and draw the ship on the screen.

 

For sake of discussion, let's refer to each object as a "ship" and it's index number as it's "ID".

 

The player ship is ID 0 and is usually handled seperately than using the queues. In many cases, there are seperate routines to handle the player ship's functions and the other ship's functions.

 

Each ship has a countdown counter in it for each of the queues. During the video interrupt, that counter is decremented and if it reaches zero, that ship's ID is stuffed into the appropiate queue. After the queue processes the request, it puts a count into the ship's countdown timer so that it will be schedules for processing again later on.

 

I update every object 30 times a second, so I alternate processing even and odd ship ID's every interrupt. This allows each ship to stay on the screen for at least one full video interrupt before it is redrawn. Otherwise, the ships tend to flash because they're being drawn while the screen is updating.

 

One of the advantages of ring buffers is that they can accept data from multiple sources and that data can be removed by multiple routines. This feature is used in Gauntlet to keep everything syncronized. For example, let's look at the Draw queue.

 

First let's talk a little bit about the drawing routine. The draw operation always consists of two parts. First the ship is erased from it's old position on the screen, then it is drawn in it's new position. While the ship is being erased, the pizels are being compared to the last font that was drawn at that position. If any pizels are missing or a different color, it means that something overwrote that pixel and a collision has been detected. Likewise, when the ship is drawn at the new position, each pixel is checked before drawing on it to ensure that it is black, otherwise a collision is detected. So one of the main functions of the draw routine is to detect collisions.

 

When a ship moves, it is erased from one position and drawn in a different one. Many times we want to check for a collision even when a ship is not supposed to move. In that case, the ship is erased and redrawn in the same location and the results of the collision are checked. So even a ship that never moves, like a turret, is constantly being redrawn in order to check for collisions. In short, the only difference between a moving ship and a stationary one are the coordinated of the old and new locations given to the draw routine.

 

The Draw queue takes data from three sources and is processed by one Draw routine. The three sources are:

 

1. The video interrupt.

2. The Font Handler routine.

3. The Think Modules.

 

During the video interrupt, the Movement Ring Counters (rememember them?) are updated and if one of them rools over, the ship moves. The coordinates of the new location as saved in the ship's data and it's index is put into the Draw queue. When the Draw routine is executed, the ship will move because it's new and old coordinates are different. This draw request comes from interrupt space.

 

Also during the video interrupt, the Font Rotation counter is decremented. If it reaches zero, a request will be put into the Font Handler's queue so the the fonts can be updated. When the Font Handler processes the request, it may determine that it's time to either refresh the font (to check for collisions) or to display a new font (for animation). Either case will cause it to put a request into the Draw queue. This draw request comes from background space.

 

The last place that requests could come from is the Think Modules. Just like the Font Handled, there is a Think counter that is decremented during the video interrupt. If it hits zero, a request is put into the Think queue for later processing. When the Think Module runs, there's a number of situations that can cause the ship to be redrawn. For instance, if it "explodes", a font list for an explosion is loaded into the ship's data and a Draw request is made. This draw request is also comes from background space.

 

As you can see, the Draw ring buffer allows me to take asyncronous requests from both the foreground and background and handle them sequentially.

 

Basically, the Gauntlet program consists of two parts: The video interrupt sets the timing for everything and puts requests into the queues. The background routine sits in a loop monitoring the queues and calling the handlers whenever there's any work to do. The background task also checks the workload across the queues and does some load leveling, but outside of that it's pretty dumb. All the real work is done by the five queue handlers.

  • Like 1
Link to comment
Share on other sites

Well, I tried to set things up so that they were self-throttling. I did that a few different ways.

 

The first way was how I handled the countdown counters. They were decremented during the video interrupt and if they reached zero a request would be put into a queue. Later on in the background the request would be pulled out of the queue and processed. Only after that would the countdown counter be set so that the video interrupt could start counting it down for the next time. A few interrupts could go by while the request was being processed and no harm would be done.

 

The second way was how I managed the queues themselves. In the game updating the video graphics was always the top priority because if that slows down the player notices it immediately. So I always processed the draw and front rotation stuff more often than anything else. A simplified version of my background loop went something like this:

 

- Process all the Draw requests

- Process some Think requests

- Process all the Font Rotation requests

- Process all the Draw requests

- Process half of the Create Object requests

- Process up to three Sound requests

- Process all the Font Rotation requests

- Process all the Draw requests

- Process up to three Sound requests

- Process all the Font Rotation requests

- Process all the Draw requests

- Process all the Create Object requests

- Process all the Font Rotation requests

- Process all the Draw requests

- Process up to three Sound requests

- Process all the Font Rotation requests

- Process all the Draw requests

- Back to top

 

My actual loop was around 100 steps long and I spaced the workload out over time. I had calculated how long each operation would take so I knew how many operations of each type I could do every second. I used that information to average out the workload over time. At the end of each loop, I would evaluate the workload in each queue and might do some special things to catch up. Like if the Sound queue was filling up, I might process four at a time next time through the loop.

 

Some operations like rotating the fonts and making the sounds took almost no time at all, so I could safely do a lot of them at once. Drawing took a lot of time and was the most time critical, so I serviced the Draw queue as often as possible.

 

You'll notice that I don't run the Think modules very often. In the 100 step loop I only serviced them four times. Thinking takes time, but you really don't have to do it very often. A ship can decide it needs to get closer and then just check it position once a second until it gets close enough to decide to do something else. Many of the decisions are trivial and don't take any time to do: "Am I out of ammo? Start dodging.".

 

The Think Modules were divided up into chunks and any time I got a request in the Think queue for a ship I ran one chunk for that ship. Most of these chunks took very little time to run, but a few of them - like the ones that needed to check Line of Sight - took a long time. So I created the concept of Big Thinks and Little Thinks. Big Thinks took a long time and were more strategic. Little Thinks took almost no time and were more tactical or logistical. For example, A Big Think would decide that it can see the player and wants to fire at him. Then a number of Little Thinks would run to make the ship fire until it ran out of ammo or it was time for another Big Think to check the LoS again.

 

Notice that when I processed the Think queue, I processed "some" requests. What I actually did was keep processing the Think requests until either the Think queue was empty or I had processed a Big Think. As soon as I processed a Big Think, I knew I had used up a lot of time so I saved the rest of the work for later. That spaced out the workload in the Think queue nicely and it also had an interesting byproduct: Because I always checked LoS by using a Big Think before a ship started firing, it automatically spaced out the firing times so that I wasn't creating a lot of new objects at the same time.

 

I enhance that effect by only processing half of the Create Object queue right after I run the Think Modules. If a lot of fire requests were made, I would space them out evenly over the next few video interrupts. I used to have problems with the game "pulsing" before I started doing it that way. It had a lot of slow downs when the worjk would pile up.

 

During the video interrupt, I also control the number of requests I put into each queue during a single interrupt. Maybe on a certain interrupt ten ships are scheduled to think. After I decrement the countdown counters and make the requests for the first five, I stop checking the counters and save the rest for later. "Later" will be two interrupts from now because I alternate even and odd ships every interrupt. When I first started doing that, I had problems with some ships always getting delayed and getting behind, so I change the direction that I process the ships in from low to high and then high to low. If I had eight ship slots, here's how they would be processeed:

 

Interrupt 1: 1,3,5,7

Interrupt 2: 2,4,6,8

Interrupt 3: 7,5,3,1

Interrupt 4: 8,6,4,2

 

Since the AI was responsible for firing bullets, when it slowed down because of load, the ships would shoot less often and in a few seconds the number of objects on the screen would drop and everything would speed up again. What was nice about this is that the player never really notices that it's happening because there's so much stuff flying around on the screen. To compliment this, all the ships checked how many objects were on the screen and if it was starting to get full they would manouver instead of firing.

Edited by donlebeau
  • Like 1
Link to comment
Share on other sites

Ehm... I am still impressed how much highlevel thoguhts & work went into the game... ;) That's the difference to me... I am not a software engineer or studied physics... ;)

 

But what I know is that's the the explanation & reason why I loved Gauntlet in the past not knowing why... ;) now I know...because so much work went into the engines under the surface...

 

or to say it more precise "I am not worthy!" :)

Link to comment
Share on other sites

  • 3 months later...

I'm very glad I found this thread. :cool: I signed up with this site solely for this game...Googling for "Gauntlet" only yielded results for that other Gauntlet, and I never knew about the rename to Gauntletak. I remember it being very fun and difficult and I never finished the game, but my father did. He was treated to a brief little tune and then the game was over. We joked about that for years--"all that for 'doo-doo-doooo. doo-doo-doooo. dodododododo doo-doo-doo'" Great game! :cool:

Link to comment
Share on other sites

  • 9 months later...

Ok, time for my story ... :)

 

The time is 1989-1990 ... and stuck in the basement of my parent's house, in my early 20's, on my Atari 130XE computer and a 300 baud modem, dialing up the local Commodore 64 BBS which is just down the street from me. See, there were no Atari BBSes around, cept for the local Knoxville Atari Users Group ... anyway, a couple of other Atarians happen to log on to the BBS, and end up by uploading a game called Gauntlet to that BBS. It took me ages to get it at 300 baud, but I remember it being a really cool game.

 

For whomever asked earlier: It runs just fine on XL/XE hardware. Just played it onh the emulator just now, it brings back memories ... I remember it being a tough game, and I got my butt kicked by it ALOT! But it brings back memories of the old BBSes, I remember how excited I used to be dialing in at 300 baud just to read the new messages and see what new games there were.

Link to comment
Share on other sites

  • 5 months later...

Well, Phil was nice enough to get in touch with us several days ago. Here are the instructions for the game we received earlier today: http://www.atarimania.com/Gauntletak.pdf

 

Not Found

 

The requested URL /Gauntletak.pdf was not found on this server.

 

:? :? :? :?

 

 

Here is a working link. http://www.digitpress.com/library/manuals/atari8bit/gauntletak.pdf

  • Thanks 1
Link to comment
Share on other sites

  • 1 year later...

I realize that I'm late to the party here it seems. I actually tried to write a letter in June of 2002 to Don, asking if I could buy a registered copy of the game :-D

 

 

Donald Lebeau

P.O. Box XXX

Pepperell, MA 01463

 

Brian Manning

P.O. Box XXX

San Diego, CA 92167-XXXX

 

 

Dear Mr. Lebeau,

 

I am a fan of one of your games that you wrote for the 8-bit Atari back in

the mid-1980's, called Gauntlet. I was wondering if it was still possible to

purchase a registered version of the game, along with the manual, and if it was

possible to obtain the assembly source code to the game.

 

Thanks,

 

Brian

I never got a reply back, but I'm glad that everything has worked out.

 

I downloaded the ATR image last night, and booted it up under Atari800 on my Macbook Pro. I had a Gravis Gamepad USB hooked up, and surprisingly, everything worked. I was pretty stoked.

 

Thanks again Don for all of the instructions and the behind the scenes details as it were.

Edited by spicyjack
Link to comment
Share on other sites

  • 8 years later...
On 3/14/2008 at 9:28 AM, donlebeau said:

 

I think Gauntlet runs on the later machines, but I'm not sure. Never heard that it didn't. By the time those machines came out I had already moved on to other things.

 

 

I'm not actually "turning off" the OS. I just stopped using the parts of it that I didn't need. Like for the video, I used Atari's video interrupt code to drive the video controller and daisy-chained it with my own routine to handle the Gauntlet stuff, so I didn't touch the page zero locations that Atari's video interrupt code needed. But I didn't use any of Atari's draw or graphics routines, so I could use all those page zero locations. Some pieces of the OS I never used, like the disk utilities, so I could freely use all the page zero locations associated with them.

 

At first I was pretty timid about using any of the "reserved" Atari locations. It just took me a while to realise that I could use most of them as long as I didn't need the functions I broke. The only stuff I left alone were the locations needed by the video interrupt and the keyboard. I drove the sound chip and read the joystick ports directly. Gauntlet doesn't use anything else - it takes the joystick and keyboard as input and uses the video and sound as output, so everything else was up for grabs.

 

I wrote the Game on an 800 and tested it on both the 400 and 800. When the 1200 came out, a friend tested it on that. I don't know what other machines it runs on. As long as Atari didn't move around the data in the Reserved area, it should be ok.

It works on all Atari 8-bits faultlessly.  It even works on an 800 with CTIA just peachy.

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...