82 Assmebly

Ash<->OShell-82 Development Kit
By: Thomas J. Hruska

Contents

[Introduction]
[Progress Report]
[Visit The Official Web Page]
v1.0 [Download The Latest Version] v1.0

Introduction: I wanted to learn Z80 assembler. What I decided to do as my first project would be to translate almost anything for ASH into OShell-82. What I needed first was a developing environment to compile for both shells, edit my code, print it off, etc. So, I created COMPILE. It brings both shells together almost seamlessly. Not to mention, its an excellent developing environment. I've tested the software under DOS, Windows 3.1, and Win95.

[Back To The Top] ATTENTION: The final daily update on the ASH <-> OShell-82 Development Kit: UPDATE Aug 1, 1997: Its been a looong 2 1/2 months of development. I have no idea why I blew my summer vacation just to write something that would enable people to translate from one shell to the other. However, it turned out to be MUCH, MUCH MORE than that. I souped up the kit so much since v0.5b1 that you could spend your entire life looking through it and never be able to know what all there is. V1.0 of the development kit contains the following features:

COMPILE (the main developing environment)
Tons of sample source code (all ready to compile for either shell)
SpriteDraw (the only routine that I know of that does clipping)
Graph Buffer routines
FAST FIND_PIXEL-like routines
Single pixel routines
Back-up files for both shells (easier than having to switch directories)
Everything you need to compile for both shells
LOTS of USEFUL documentation
Scrolling functions
Dines Justesen's GreyScale library (and translated test program)

SURPRISE ADDITION TO THE LIBRARY!!!!!!!!!!!! Secondary Buffer and multiple layer routines (Here comes Duke Nukem II!!!)

AND MUCH, MUCH MORE!!!

EVERY TI-82 Assembler programmer needs this development kit in their arsenal of tools. You can always download the latest version from http://shinelight.home.ml.org/.

Since this program is FREEWARE, I would like to receive at least an e-mail telling me what you thought about it.

[Back To The Top] Jul 31, 1997: Well, I can't fix the stupid "ghost" bug with my program :(. It seems to be connected circuitry causing the problem. This bug also appears on the TI-85 (if you hold down 3 keys in a right triangle). However, TI was smarter to spread the keys out farther on the 82.
I'm almost done negotiating with Dines Justesen on the source code. It seems that I may be able to use all but two or three pieces of source in the next version of the kit. I think one more day of "peace talks" and we should be done.
I vistited both shell's web sites today, ASH's hasn't changed, but OShell-82's has. I didn't really like Jason Todd cutting down the Development Kit...but I enjoyed hitting his link to the "truth document" which doesn't work :) That guy should be happy that I'm increasing his shell's power in the 82 world (but he isn't).
I added a surprise to the graphics routines today. It only took two hours to write, but it should prove VERY useful with programming 2-D games. I won't tell what it is...or it wouldn't be much of a surprise, would it? I wouldn't be surprised if games like Duke Nukem II showed up soon after I release the kit (I'm really beginning to enjoy programming these routines :)

[Back To The Top] Jul 30, 1997: I am nearly done with the kit, just a few final touches and the "go ahead" from Dines Justesen. Speaking of Dines Justesen, he appears to be stalling for some reason or other on the source code problem. I really hate to upload the kit without his permission on the source (so I'll probably delete it).
I just discovered (accidentally) one minor bug in the Multi_Key routine that has to do with the keypad port (and not my routine). No matter what I do, I can't seem to fix it. It appears to be a misc. hardware bug that TI never paid attention to (as usual :). Try the program out that I uploaded yesterday. While pressing the LEFT ARROW key, hold down LN and STO>. The key will "lock" up. If you look real hard at "A Programmer's Guide to TI-82 Ports", STO> and LN are on the same line (so are LEFT and RIGHT). In the second table, STO> and LEFT (LN and RIGHT) are on the same line. I have no clue why the port doesn't mask out these keys like the routine tells it to. REAL WEIRD! I will attempt some other ideas I have to see if I can mask the correct keys out (probably won't work though). If I recall, I had a similar problem before when I didn't reset the port (it exited the program with the wrong key). Well, its worth a shot.

[Back To The Top] Jul 29, 1997: I completed the Multi_Key routine today and it now covers EVERY key (including the [ON] key) on the keypad. I even got my scrolling sprite demo completed (which I have attached to this document). It is faster than I had been thinking it would be. This program even uses Multi_Key to show off the possible 8-way directional scrolling. It probably will slow down a little when people actually do something useful with the routine (besides scroll a plane of sprites around). Transfer it to your calculator to see some possibilities in the near future. NOTE: I'm only uploading this to show that I actually have completed the routines that I say I have. Click Here To Download (Note: This is an OShell-82 program)
Dines Justesen is still giving me problems about some source code. I'm getting closer though to a solution. I really want to leave the translated source in the next version.

Well, that brings you all up to date. I still am hoping to release v1.0 of the ASH <-> OShell-82 Development Kit this week (even with the setback of Dines Justesen).

[Back To The Top] Jul 28, 1997: I am currently communicating with Dines Justesen to work out a deal on a source code conflict that we are having. Now onto some more important things at hand. I am declaring the SpriteDraw routine completed! I still have to get the rest of the stats on it, but that should only take an hour or so to do. I spent most of my day working on scrolling routines. I finished them and now I can scroll in any of four directions, combine these routines with Multi_Key, and you can create some pretty awesome games. I'm currently working on a scrolling sprite demo which will demonstrate every major aspect of my routines. I updated Multi_Key today so that it now will support KEY_21. I have even found a way to detect KEY_101 (the [ON] key). It should be pretty simple to add this key to the Multi_Key routine. I expect to release v1.0 sometime this week. Remember, every aspect of the kit has to be tested for bugs before I can put out the first official release. So, I can't make any promises except that it will come out REAL soon.

That brings you up to date. If you want to do something productive, tell Dines Justesen (c958362@student.dtu.dk) that you really would like his translated source code for OShell-82. He translated the original 85 code (and "copyrighted" it), then I translated his translation, and he got ticked when he saw Dump82, HexView2, KeyTest, and a whole slew of others for OShell-82.

[Back To The Top] Jul 27, 1997: I have received several complaints from the two mailing lists I duplicate these reports to. As a result, they will only appear on the asm82 home page at . Now to the more important stuff at hand. I realized today that my previous way of testing my sprite routine's speed was incorrect. This means that I have already broken the 800 sprites/sec barrier on a non-clipped 8x8 image!!! Here is the updated table for NO CLIPPING:

NO CLIPPING:	Sprites/sec.	Frames/sec.
Using Sprite1 (8x8 with transparency filled):	827.02	7.07
Using Sprite1 (8x8 w/o transparency filled):	827.02	7.07
Using Sprite2 (8x8 with transparency empty):	773.3	6.61
Using Sprite2 (8x8 w/o transparency empty):	624.02	5.33

This is the fastest the routine can get. I also have good news on all the FIND_PIXEL, ADJUST_A_HL, and other graphics routines. Thanks to the amazing 85 programmer, James Yopp, I cut about 100 clock cycles out of each routine!!! I just wish TI had left the screen size at 128x64...I could've made the routines even faster. You will be able to get these updated routines as soon as I release v1.0 of the kit (hopefully soon). I still have to get the rest of the stats (and add some more features to the sprite routine) before I can make a release of the kit.

[Back To The Top] Jul 26, 1997: Okay, I've had a really hard day and I said yesterday that I would have some stats on the sprite routine. I kept running across bugs in my source that would have crashed my calculator. I corrected every bug that I found and added the nice feature of detecting if a clip is equal to or greater than the size of the image. If it is, there is no image to be displayed, so you get returned to the caller. However, this has one little drawback...it slows down the routine about 10 sprites/sec. This "feature" was added because I want my routine to be virtually fool-proof. I re-gained those 25+ lines of code that I deleted yesterday...so I'm back where I started (almost). Now to what you all are waiting for: Those AWESOME stats!

NOTE:: Frames/sec. is calculated for a 13x9 screen of 8x8 sprites. Also, when clipping, the range is from 1 to 7 (0 would be equivalent to no clipping and 8 would break the syntax rule).

NO CLIPPING:	Sprites/sec.	Frames/sec.
Using Sprite1 (8x8 with transparency filled):	770	6.60
Using Sprite1 (8x8 w/o transparency filled):	770	6.60
Using Sprite2 (8x8 with transparency empty):	695	5.91
Using Sprite2 (8x8 w/o transparency empty):	580	4.94
UPPER CLIPPING:	Sprites/sec.	Frames/sec.
Using Sprite1 (8x8 with transparency filled):	805-1570	6.87-13.42
Using Sprite1 (8x8 w/o transparency filled):	805-1570	6.87-13.42

You can tell I'm not quite done :). As you will also notice, when you clip a lot off of an image, the speed nears 1600 sprites/sec (13.7 frames/sec)!!! Not bad for a routine with over 1000 clock cycles (still). Actually, 800+ clock cycles are used to clip the image down to size. The rest do the actual drawing of the image.

[Back To The Top] Jul 25, 1997: Okay, I'm back from vacation. I really didn't get much of a chance to work on the kit though (bummer). However, I removed around 25 lines of code from the sprite routine that weren't really needed. This was mainly made of loops that I replaced with simple ADD statements. I also caught a bug that would have crashed my calculator when using left clipping. I still have quite a few optimizations to go before I'm finished with a decent routine. The current speed is good (for a first routine), but it could be better. By tomorrow, I should have some updates on the speed comparison list. Remember, I'm aiming for 800 sprites/sec. on a filled 8x8 non-clipped image and 100 lines of source code.

[Back To The Top] Jul 20, 1997: I found two bugs in the ADJUST_HL and ADJUST_A_HL routines in the graph.inc include file. The updated routines will be released with v1.0 of the kit. I also tested my SpriteDraw routine and here are some amazing results. Here are the stats for an 8x8 filled (all 1's) transparent image without clipping for three different sprite routines:

NASRWARP.....375 sprites/sec.
PutSprite....674 sprites/sec.
SpriteDraw...767 sprites/sec.

Not bad for 1000+ clock cycles (I couldn't believe it when I first tested it, so I tested it again). Both of the other routines have around 150-400 clock cycles. I have a hunch why my routine is so much faster, it probably has something to do with pre-calculating several values. The routine still needs to be optimized! I think that I can squeeze about 850 sprites/sec. out of an 8x8 non-clipped image after I optimize it. I also got a possibly faster routine for all of my graphics routines. If it is faster, that will mean that the SpriteDraw routine will become even more optimized!

Well, that report should blow your mind to nothing (especially if you are an ASM programmer). I can't make any guarantees, but I should have another report the day I get back.

[Back To The Top] Jul 19, 1997: I spent most of my day going pouring over the source code for my sprite routine after I crashed my calculator five times in a row. At 8:30pm (after staring at the source for three hours), I came across a line of code that was in the wrong spot. It was supposed to change the zero flag but was later cancelled out by an ADD instruction along with a pop af...therefore putting it in an infinite loop. Oops :) 160 lines of code (for a single routine) is no walk in the park when it comes to bugs. I have yet to test the updated program. I now have a zillion sprite routines on my hard drive, and I thank everyone who sent me one.

[Back To The Top] Jul 18, 1997: I have good news and bad news. First the good news. I have completed the first SpriteDraw routine. I still have to test it, but it is done. The bad news is that I am going to be out of town from Monday Jul 25 to Friday Jul 25. I should be back by Friday evening though. However, I will work on the sprite routine while I'm away. The routine currently uses 160 lines of code. My estimate of 150 lines came pretty close. I still have several optimizations to make before I'm done. I really need as much ASM code as I can get my hands onto so as to optimize the routine to get the maximum possible speed out of it.

[Back To The Top] Jul 17, 1997: The sprite routine is just about done. I estimate that it will be about 150 lines of code when I complete the first working version. I hope to optimize the code enough to cut the size down by 1/3 (making it only about 100 lines). Not bad for all the additional capabilities that PutSprite (55 lines of code) for the 85 has. I am hoping to make this somewhat faster than NASR WARP but unfortunately it will be slower than PutSprite. Oh, by the way, I've decided against making the kit shareware, although I would like people to tell me periodically (like once every couple of months) what they think of the product. However, I am always open to suggestions on making this kit better.

[Back To The Top] Here are updates for the past two days on the ASH <-> OShell-82 Development Kit:

UPDATE Jul 15, 1997: The third beta of the kit is out!!! This has come a LOOONG way from where it had started out. The final release of v1.0 will decide what it is: Shareware, Freeware, or public domain. Only your support can keep it from becoming shareware. Tell me what you think of this beta and I will be encouraged to make it freeware. I have only received THREE e-mails from people about how well they like it. I need about three dozen more before I will change my mind on making it shareware.

Jul 16, 1997: I am starting on one of the final routines to include with v1.0...SpriteDraw (or DrawSprite...can't quite make up my mind). This routine will draw ANY size sprite. It will also have CLIPPING capabilities (I can see a zillion SQRXZ games now... :). I have even planned 2 different types of sprites: Transparent and non-transparent. So far, I just have the basic skeleton of the routine down. The coding of it shouldn't be too hard now.

That quickly brings you up to date. JUST REMEMBER TO RESPOND TO THIS E-MAIL! IT IS VITAL TO RESPOND IF YOU DO NOT WANT THIS TO BECOME SHAREWARE!

[Back To The Top]

Jul 14, 1997: I just finished translating all the games with source to the other shell. Its pretty awesome to see Columns v3.0 running under OShell-82 and Tunnel v1.0 under ASH! Every program works like a dream with only a few modifications for each one. I think I might be able to design Multi_Key before the release date.

Jul 15, 1997: Just ran into a problem with Multi_Key. One of my POPs isn't even being recognized. Maybe, I'm over the limit on something. I've got to go back to the ol' documentation on TASM to find out :( I really want to get this out before the deadline so that decent games can be made.

THIS MIGHT BECOME SHAREWARE IF I DON'T GET ENOUGH RESPONSE TO THE SOFTWARE. I HAVE NO WAY OF TELLING HOW MANY PEOPLE HAVE DOWNLOADED IT. E-MAIL IS THE ONLY WAY TO TELL ME WHAT **YOU** THINK OF IT.

Jul 13, 1997: I have a few optimizations to make yet in the single pixel graphics library before I can call it done. I just discovered today that my FIND_PIXEL routine doesn't change HL like the one on ROM page 4 does. So, I solved this problem by creating two more routines. In doing so, I realized TI made a mistake with FIND_PIXEL. Nobody will use both the memory locations of ($800F) and ($8011) in the same routine as hl (at least I can't think of any). HL, in TI's version of FIND_PIXEL, is normally used for the location of a byte in a graph buffer. ($800F) and ($8011) are normally used for moving to the specified pixel location at (b,c). My optimizations in this matter, should increase the speed a little bit. I still have to decide whether or not what type of software this should be. I am going to need a LOT of response from people if they don't want this to end up as shareware!

UPDATE Jul 13, 1997: I think I have figured out how Multi_Key will work. Remember, Multi_Key is going to be a routine which will allow for multiple keypresses to be detected at one time. If you programmed for TI-Basic and used the GetKey statement, it will work in the same way. An example: Multi_Key(Key_25) will see if the up arrow is pressed. This routine will use the zero flag as the indicator if the key was pressed or not. An advantage of this will be that no registers will be destroyed!

[Back To The Top] Jul 12, 1997: I've got the single pixel routines completed, I just need to finish getting the _GRBUFCPY_V support added. I think I've found a way to optimize that routine to get maximum speed from it. I plan for the third release of the kit to come out sometime next week. Oh, look for something very exciting in the upcoming graphics library. Hint: Upper-left corner = (0,0).

LOOK FOR THE FOLLOWING THINGS TO BE IN LATER RELEASES:

Multi_Key routines (will be able to detect multiple keypresses)
Sprite routines (2D object routines)
More ASM source code
Descriptive help on any Z80 command at the touch of a button

Jul 11, 1997: I had to release an updated version of the kit today because there were bugs in it. They have all been removed as far as I can tell. The two most important programs that were translated are Dump82 and HexView2. I have completed the graphics routines that I was working on. It seems that they are slightly faster than FIND_PIXEL. In the next version of the kit (v0.9b3), there will also be support for the only routine that splits ASH and OShell-82 apart: ROM_CALL(_GRBUFCPY_V).

Jul 9, 1997: I just finished translating all the ASH source code to OShell-82. It only took a couple of hours to do. However, I am sad to say that all the OShell-82 source seems to contain the two lines of code that can't be translated: _getkey and _grbufcpy. However, I can use GET_KEY instead (and there also seems to be a little bit of code to translate _grbufcpy). It will probably take a little longer to translate the OShell source to ASH. At the rate I am going, I will have the kit done by tomorrow (providing there are no more complications)!

UPDATE Jul 8, 1997: About 4:30, I got real ticked off. OShell was updated to v2.5. This meant that I would have to download the new version and change the Development Kit. However, only a few additions were made, so I quickly got back on track (I still need the ROM_CALL routine I designed). I should be able to meet my deadline now that I have the ROM_CALL routine done. The ASH <-> OShell-82 Development Kit should be done by the end of this week (as scheduled), permitting that there are no more delays.

Jul 8, 1997: About 1 o' clock today I got an extremely brilliant idea for my ROM_CALL routine. It now fits in one #DEFINE and only destroys the flags. All I need now are some people to give me the "go ahead" to port their ASM code to the other shell (I can't translate code that uses ROM_CALL(_getkey) or ROM_CALL(_grbufcpy) though).

Here is what is in this release:

COMPILE (the main developing environment)
Multi_Key (detects multiple keypresses)
Single Pixel Graphics Routines (Point_on, Point_off, etc.)
_GRBUFCPY_V support for ASH!
TONS of translated source (will compile for both shells)
AND MUCH, MUCH MORE!!!

ALL TI-82 ASM developers need this software in their arsenal of programming utilities!

Tested under DOS, Windows 3.1, and Win95!

Download the Development Kit v1.0

[Back To The Top]

Official Web Site

Shining Light Productions -- "Meeting the needs of fellow programmers"
http://www.geocities.com/SiliconValley/Heights/8504
http://shinelight.home.ml.org

[Back To The Top]