I've added a new Avatar to the family...

Hello All,

Well the reason I haven't had a chance to update the blog for some time is because I recently added a new member to the family.

A new baby boy Kyle!

Although I have a new focus it doesn't mean I will be dropping or ignoring this blog.  Please be patient and I will post the tutorial of the Assembly code soon.  This tutorial will be in multiple parts covering each of the different subroutines within the program.

This is a pretty involved tutorial and I want it to be very clear and understandable so it is taking a little time to get it together.

It is coming soon...

Joe

SCREENSHOT OF MY LATEST PROGRESS FOR ULTIMA 1 REVISITED!

Hello all,

Thanks to some interesting and informative comments and nice endorsement of my blog site from Aiera of www.ultimaaiera.com I have regained my true focus of my Ultima Revisited game project and have gone back to my roots.

Check out Aiera’s website if you want to find out about all things Ultima, it is a very cool site!!

Also, he has graciously given me a new project spot on his website to update anyone on my Ultima Revisited game progress. “Thank you Aiera”

http://www.ultimaaiera.com/ultima1/ultima-1-revisited/#comments

Yes, I have seen the error of my ways and put myself back on track with the original goal. I will be posting a video soon of my new progress which covers the intro, character generation, world map movement with the stats present on the bottom of the screen and castle/town movement!!! I will also be posting a pretty detailed tutorial of the Assembly code broken down to each subroutine as I have written it. This tutorial will cover the world map tile generator and movement routines! This to me was the most intense learning process and also the most fulfilling to complete. With the code I have written so far, you could if you wanted to, create your own tile shapes and build a world map and move around in it that would measure 170+ X 80+ tiles. As I have always said from the beginning, this will all be open source and downloadable to the public. Everything I create in Assembly or Basic will be posted, explained “with tutorial is possible”, and downloadable! I hope everyone will stay tuned for my progress and in the end I hope to have a working program that plays exactly like the original look and feel of the game!

I have posted a screen shot of my latest progress and just so no one would think I was posting a shot of the original game, I changed my character to be a TROLL! heehee

Happy trails!

Joe “kingspud”

ultima_revisited@yahoo.com

So that is what Ultima 1 looks like…

Hello all,

Well, call me stupid, but I didn't realize that I was following the wrong version of Ultima 1! I recently received an email from Bob R. who gave me some enlightening information regarding the original Ultima. "Thanks Bob!" Ultima was not called Ultima 1 at the time because Richard didn't know there was going to be a version II or III, etc...

So Bob gave me some great documents covering the game and how to see the files on the original disk images. One really cool doc was from a magazine called CORE, which showed how to create printed maps of each of the [4] Ultima world maps.  WOW! This was truly an eye opener! I didn't realize I was biasing my version on the updated Ultima version created later.  The original version was completely coded in Applesoft BASIC and had a number of issues related to game play, which Bob pointed out, such as:

·  If you died, you were often resurrected in the middle of the ocean. You couldn't move, and you'd have to starve to death or be killed by a serpent and hope to be resurrected in better circumstances.

·  There were no Up and Down keys on the ][+. Up was "Return" and Down was "/"

·  Hit ESC after any disk changes (if you select 2 drive mode at the beginning this shouldn't be necessary)

·  Movement was SLOW, especially with the dungeons redrawing themselves line by line after every step. (FYI if you're using AppleWin it has to be set to ][+ emulation mode for the dungeons to work)

I can relate to these issues because now that I have the original disk images I have played through some of the game and seen these bugs first hand.

I also found out some interesting points regarding the world map. The world map was made up of [4] binary data files that were 64x64 tiles. In my version I create [2] binary map files that are approximately 180x82 tiles. The reason my maps are much larger is because I have two map sections plus the ocean tiles that are surrounding them.  I made it so if you move around the world map 1 you had at least 11 ocean tiles surrounding that entire map section. If you moved off the 2nd map you would cause the second world map binary file to load and movement would continue on to the second world map area. I'm not sure if I want to change this to having four separate maps. I guess it all depends on memory size and if the files fit on the disk when complete. I was once told that as long as the game plays and looks like the original than it doesn't really matter how I program the internal parts.  I have to agree on this because since I’m programming the game in assembly it is going to be different from the original from the start! 

I also need to make some major changes to the tile shapes.  The shapes I created are from the updated version and they look totally different than the original shapes.  This isn’t too big of an issue because all I have to do is draw the new ones on graph paper and update the data values.

Also, I will be posting a detailed tutorial of the entire world map movement program written in assembly very soon.  I need to clean up the variables used in the program and put more remarks in the code so it will be easier for reader to comprehend.  I will try to break down each subroutine so as to explain how the program reads the data for the tiles, creates the shapes, created the maps, places the character on the map, and how it allows you to move around the world.  This to me will be very critical for programmers because once you have this code you can literally make your own world map with your own shapes and then move around it.  I plan on making a ZOMBIE game after this one that uses a different world map and city block and towns that a player can enter to find objects and fight zombies.  The game would be similar to Ultima but with a zombie theme.  It is in the works but I need to complete the Ultima game first.
Talk to you soon,

Joe

New look to Ultima 1 Revisited...

Hello all,

Well I've been working on some new improvements to my Ulitma 1 Revisited program and I've added a border to the game screen as you can see here. The problem; and yes it was a big one, was I had to make major changes to the code due to the change in tile layout. Since I was initially using 20tiles x 10 tiles for the gaming screen section of the world map, the new look changed the layout to 19tiles x 9tiles! This caused some shifting of starting values and an extra Binary file for the border. I also need to condense the code for the banner to make it so I can fit it in with the initial program code.



Right now my program is too big to include the banner code. :0(



The other issue that cropped up, which I didn’t think about, was the color change due to the shift in the tile starting locations! Since I had to shift the starting location of the upper left corner by [1] byte to the right and down [1] byte to compensate for the banner, this caused a color shift in certain tiles. This affected the ocean, trees, and plains tiles.  These tiles use a set bit set to high to get the blue color.  When I ran the program for the first time all the ocean tiles came out orange due to the color shift! All the trees and plains came out purple due to their color shift! This was a major pain in the butt!



So I had to go back to these shapes and recalculate the byte setting to compensate for this shift!  This meant I had to redraw each of these shapes and redo the values that make up the byte count.



I also had to change some byte values within the main program that was used to draw the shapes on the screen.  Luckily I have good remarks in my code or it would have been a lot of searching.



I like the new look and if gives if a more game feel.  Let me know what you think!



Enjoy,



Joe

Ultima 1 Edvard Munch style.....

Hello everyone,

I was messing around with some of the images I created from Ultima 1 and produced this interesting take on Ultima 1 art similar to the painting Scream by Edvard Munch!

Edvard Munch eat your heart out.

Let me know what you think!!!

Enjoy,

Joe

Tutorial covering CALL, POKE, and PEEK statements...

Hello all,

Well, yesterday I was doing some testing with CALLs, POKES, and PEEKs and realized I had a less than desired understanding of these concepts and how they are used within assembly and Basic programs.  I know there is a lot of information floating around out there that covers these topics but I haven’t seen anything that gives a direct sample and explanation to how these work in an adventure game.  So I thought I would give some examples of how they work and how they are being used within my Ultima 1 revisited program!

Here we go:

A CALL statement by definition is as follows:  A CALL statement executes a machine language subroutine from a BASIC program.  Control transfers to the subroutine.  When is finishes, execution goes to the statement following the CALL.

Ok, great but what does that mean?!  Here is how I will try to explain what this means and show you how I’m using it in my program.  Within the game I have a subroutine in my assembly program that checks when the player character moves on the map and if there is a collision with different types of map tiles such as mountains, oceans, or normal movement tiles.  In the beginning part of the game I use a BASIC program to check the key strokes while on the world map of the game.  So, while I’m using the  I, J, K, and M key to move around the map, if I hit an “I” to move up I use a CALL statement within an IF-THEN statement to execute the subroutine in the assembly program.   

In essence, it passes control from the BASIC program to the assembly program and then back again.
We all remember that GET A$ in BASIC is used to track when a single keystroke is pressed and that key can be checked within an If – Then statement.

Example:  10 IF A$=”I” THEN CALL 26534

“You have to convert HEX to DECIMAL for the call statement in Basic”

The way the CALL statement works is as follows; everything in assembly is written to a specific memory location. So, I have a subroutine in assembly called MOVEUP and it starts at memory location $67A6. 

“You will discover this memory address after you compile the assembly program and it gives you a listing of all the subroutine headers and there HEX location!” 

Remember that memory locations $6000 to $BFFF are free for program statements.  

Now, the CALL statement is executed when you hit the “I” key and it executes the MOVEUP subroutine at memory location “in decimal” 26534, which equals in HEX $67A6”!  Within the MOVEUP subroutine I do different things like check against tiles I shouldn’t be able to move through and against tiles I can move through.  If the tile is a collision tile such as a mountain I have a statement that writes “YOU CAN’T MOVE THROUGH MOUNTAINS!” and then it returns back to the line immediately after the original CALL statement in the BASIC program. 

If the tile is a plains or tree tile, the character is free to move and the screen must be updated with new tiles.  Since the movement is clear I use a JSR command in assembly, which is a “Jump to a Subroutine” command and update the tile and shape information for the next 200 tiles that will show on the screen.  These new tiles are drawn to the screen and once complete the subroutine returns back to the line immediately after the original CALL statement awaiting the next keystroke press.

This is how the CALL statement works with assembly from BASIC; it goes to the memory location and executes the subroutine then when it completes its task in the subroutine, it returns back to the BASIC program.   This is the link between assembly and BASIC so both programs can communicate with each other. 

The assembly program does not necessarily have to have a name header like I’m using such as the MOVEUP header but without some kind of name reference it is much harder to find the exact location of the memory address where the start of that routine is located.

I hope this tutorial was informative and gave a little better insight into how the CALL statement is used within a BASIC program to communication with your assembly program.

Joe

LAST BUT NOT LEAST.... Ultima 1 revisited program clarifications...

HI Beth,

A few things...

1.  I tested the POKE and it worked like a charm!  My initial program had the row and column values set in the main assembly program, which didn't allow for modification.  So, my test was to set the ROW and COLUMN as set variables which were equal to $1E and $1F.  I then entered in my Basic program two lines that read:

10 POKE 30,10

15 POKE 31,11

I did these lines before the BLOAD of my main assembly program and it worked!

The main character shows up on the map in the location set by the poke statements!   I tested this with different values and the character started in different locations on the map.   I love it when things work like they are suppose to.  So now I think I can use a 2 dimension array in basic with X,Y to track the main characters movement and when the player wants to save the game I can PEEK these values and BSAVE them, right???   Also, I know that the first Page of memory is 256 byte locations, do you think I should use these bytes for all of my variables or is there a better location from memory to use??  So now that I know how to use the POKE statement in my basic program I was thinking that I could use these locations for the variable such as player character map location, hit points, gold, experience, food, monster and transportation locations, etc...  right???  Then I was also thinking I could save all these values with a BSAVE when the player wants to quit and save his place in the game.  Is this the correct way of doing this?

Joe, yes, that’s exactly how you pass information back and forth, as well as loading and saving the data. However, be VERY careful with using the “first page of memory”. That is referred to as “zero-page” memory and it’s a very valuable and constrained resource. Here’s a link to how it’s being used by the system:

http://stason.org/TULARC/pc/apple2/programmer/017-Which-Zero-Page-locations-are-likely-to-be-in-use.html

You don’t want to use any locations that might be in use by something else, as those may change your values or you may corrupt what it is that they do. You should reserve your use of zero-page memory for critical timing routines where you optimize using fast instructions that rely on zero-page indirect addressing, for example. For all of your program variables, find a higher location in memory and use PEEK and POKE on those addresses. (This gets back to figuring out a memory map so you can know exactly where in memory you’ve allocated all your variables, your data, your programs, etc.)

2.  Concerning the towns and castles:  Since there are probably 8 to 10 castles and 30 to 40 towns, which all seem to look slightly different.  I was thinking I SHOULD do them in assembly to save space as you mentioned but I still have the issue of the number of shapes that will be created for all these places and how do I use data compression?  The world map was easier because I only had about 12 or so main tiles on the map, less than 15 total, but the town and castle have way more.  I won’t be able to use the data compression even if I create a separate assembly program for each separate town or castle because some of the towns look like they have more than 20 shapes that make up the tiles for the town!  So that bring me to the main question:  Should I just do them in assembly and use normal data strings which use a byte for each shape #, like I did in the beginning.  This way I could create one assembly program that would generate the images for all of the towns and castles  OR should I do them in BASIC, which would use a single file that had all the shapes necessary for all the castles and town and create a ransom assess files that would have a text file that used three values for each shape, such that it would have the X,Y, and shape # for each shape in each town/castle.    Which do you think would take up more space; the BASIC program of the Assembly program????  I know that space is a critical issue and I would hate to start spending a bunch of time of one path then realize I should have done it the other way just to save a bunch a memory!!!  

Well, I think you’re fine with doing it in Basic, but I don’t see why you need three bytes for each shape. Why not just store the data in data strings like you store uncompressed maps, so each byte is the tile # and the X,Y is implied by the location of the tile # in the array? You just lay out 20 x 10 tiles for 200 bytes, for example. You could still randomly access the file every 200 bytes or so to pick off the specific town/castle you wanted, or you could have a bunch of different little data files. Regardless of whether you use basic or assembly you should keep the X & Y out of the data, imho. Save that space at least! I don’t think you need to bother with compression, since you could load in the town/castle instead of an outside map when you switch between modes, for example.

3.  I think I got where you are coming from concerning monsters and transportation tiles and the memory they use but let me reiterate just to make sure.  Since I plan on using individual memory locations for the locations of transportation tiles and monster tiles, similar to how I did the ROW and COLUMN deal.  Did you mean I should set aside a number of these locations just for a set amount of these items locations on the map?  Meaning, if I use the first page of memory and set aside 10 or 15 for each transportation tiles, which would mean two byes needed for each tile, which is basically for the X and Y location values, correct?  This way I could create arrays for each new monster or transportation tiles and save their location in each byte with their X and Y values.  Then I would able to check these values on each character move and if they fall into the map screen parameters, I could use them to draw their location on the map.   Is this what you meant or am I way off???

Well, again, don’t use the first page of memory. Find another block somewhere for this type of data. I would argue you still need 3 bytes for each, one byte for the type of transportation (e.g. 1 = cart, 2 = horse, 3 = ship, etc.) and an X, Y for that as well. Otherwise yes, what you say sounds correct!

4.  Concerning front and back buffers:  I understand now what you mean about using these two pages of graphics and will start testing them.  I know now that I have to add Page 2 "$4000 and up" graphics memory locations right after my Page 1 graphics locations used for indirect indexing.   After that I will have to create another addition to my program to incorporate these two page swaps.  The question I have is:  You say to draw on screen two that is not seen by the user but how do I draw on the screen when I don't know which direction the player wants to go?  My understanding was I would start with the initial map view on Page 2, while Page 1 is blank!  Then show Page 2 and when the player makes a move I would draw on Page 1 then switch them.  Is this incorrect?  If so, I'm not sure how to implement the page flipping for the game.  I see there being a delay between page flips due to the amount of time it takes to get the new information concerning the direction move.  I also see how the 90% could make a huge difference with speed due to the page flip delay!!!  I need to figure out how to get the 90% shift working because I already notice that the redraw is not fast enough!!!  I will do more testing on the 90% map shift because I have to get this working in the program and then utilize page flipping at its most!

It’s easy for me to say, but don’t overthink this too much. It’s actually pretty simple.

1.       Get user input for direction they want to move

2.       Copy the 90% of the front buffer to the new location in the back buffer – shifted by user input

3.       Draw the remaining 10% of the back buffer required

4.       Flip the pages

5.       Goto 1

Since you aren’t trying for constant animation, you don’t have to keep things running. You can always wait for use input. If you were animating (say you wanted to have the water tiles always moving so it looked like all the waves were in motion) you wouldn’t wait for the user input at step 1, you’d just check to see if there was any.

To break this down further:

Step 2:

You can literally copy screen-memory lines from the front-buffer to the back buffer. You just need to copy them from the current location to the shifted location. So instead of copying from $2000 to $4000 directly, you might copy from $2000 down a full tile to $4080 or whatever it is in the event the user decided to move up.

Step 4:

Flipping the pages is very fast. All that happens here is you switch which hi-res screen the user is seeing. As I recall, this is done like so (where K can be 0 or 1):

POKE49236+K,0                               //set hi-res graphics page (K)

And to keep things consistent, you might want to follow it with this:

POKE230,32+(32*(K=0))                 //set hi-res plotting page (for basic, 32 = page 1, 64 = page 2)

And of course this clears the current plotting screen to black (if you need to do so)

CALL-3086                                       //clear current hi-res screen to black

5.  I had an idea that I wanted to get your opinion on:  I was thinking of using a main location array in the BASIC program that would have the main character map location tracked at all times.  This array would basically have the X,Y coordinates of the characters location on the world map.  My thinking was I could use this array values for a number of issues:

 A.  I could have all the town, castle and signpost X,Y locations on the world map saved in a data file and check after the player hits the ENTER key, which is the key used to enter these locations.  Once the enter key is hit I could check against the players X,Y position and if it matches an X,Y value within the database I would know exactly which town, castle, or signpost for that matter, which the player was trying to enter!!!  Then all I have to do is a simple CALL statement to the portion of the assembly program that draws that town or castle of updates the quest when the signpost is visited.  What do you think?? 

B.  Also this would work out great for when I want to board a transportation tile because when the player hit the "B" key for board I could check this value against the values save for all the purchased transportation tiles on the map!!  What do you think?

C.  Also, also... "hehe"   I what be able to use this X, Y value for the monsters to track too.  I know in the game that if you move on the map while a monster is near it will move after you.  So I thought that I could use this X,Y value to help the monster's track the player’s location and attack this location accordingly.  Again, what do you think?

All of the above sounds good! I worry a bit when you say “data file”. As long as you mean a data block in memory, cool. You don’t want to be loading an actual disk file every time the player hits ENTER, though! I’m assuming you meant in-memory locations.

Also, as a bit of an aside, check out this article:

http://mirrors.apple2.org.za/ftp.apple.asimov.net/documentation/magazines/incider/inCider-July-1983-Fudge-It.pdf

I realize you’re not really concerned with how to do smooth animation on the Apple ][ (at least not yet), but this goes into that, which is a whole topic in and of itself. What I thought you might find immediately interesting was to check out how this program interfaces with its assembly bits. It involves a fairly integrated Basic and Assembly program which both read/write data used by the other, with calls from the Basic program to the Assembly program(s). Sound familiar? Check out how they made it work and maybe it will help further inform your own efforts!

I know these are a lot of questions but what better way then to go to the source!!!

Thanks again,

Joe