adamantyr

For my own part, I stick with data words over bytes for variables unless I really REALLY need to save space. Trust me, it's easier. If you have a more-or-less static workspace, you can access either byte by using static addressing, use a shift to move it into position, or a swap. (The first is probably best in most situations.) Yes, VERY good articles. A great starting point is his "This is a Football" article, which is where he steps back and tries to explain assembly to the average lay-man. Adamantyr

For border checking, a 2-coordinate system is best. I've tried out the idea of a single index value tracking on a 2-axis data set... it's possible to do, but not really worth the effort because of the math involved. Adamantyr

Good initiative. How do one measure that a game is <= 14K ? If you get "MEMORY FULL" you've gone too far. An old cheat method to determine available space in BASIC is to insert this at the start of the program: 1 A=A+8 2 GOSUB 1 When the program crashes with "MEMORY FULL", print the A value. That's your available memory. Adamantyr

I see a few things... your delay was in the wrong place, it should be AFTER you have written the character, not before. I also made some changes to how the joystick is scanned. Since the X and Y values are in a single word, you can easily check for no activity and just loop back. Code below Adamantyr

Looking good, Owen! Just set yourself small goals and achieve them one by one. Doing borders and being able to detect and pick up objects on the screen is a good set of goals. I agree with Vorticon about the VDP utilities... I've butted heads with Matthew on this subject before. I'd call writing your own VDP utilities and VDP read/write techniques an optimization step, and probably best for the intermediate programmer who has mastered the basics (replicated everything he could do in BASIC and Extended BASIC) and is ready to move on into what assembly can do for you that can't be done elsewhere. One area that is a must for assembly programming is understanding boolean logic. (AND, OR, NOT, bit masks, etc.) TI BASIC and Extended BASIC use these, but you can use IF/THEN without ever really understanding what's going on under the hood. I had a college course on the subject in my CS path, can anyone recommend a decent book that's good for a beginner here? Adamantyr

0 = 1st byte . . . 8 = 9th byte Like I said, 0 as a legit value, kinda hard to wrap your head around. As for the color being off, the colors are off by 1 compared to BASIC. As follows: >0 - Transparent >1 - Black >2 - Medium Green >3 - Light Green >4 - Dark Blue >5 - Light Blue >6 - Dark Red >7 - Cyan >8 - Medium Red >9 - Light Red >A - Light Yellow >B - Dark Yellow >C - Dark Green >D - Magenta >E - Gray >F - White Adamantyr

Yeah, BASIC doesn't have the entire set available, so they offset the values to make it clean. Just like how the colors are all incremented by 1 so there is no "0" value. Fortunately the ASCII values are still intact. So if you need to know the byte to use, just divide the ASCII value by 8, drop the remainder, and that's your byte to change. An '@' is ASCII 64, so the color byte to adjust is the 8th. In assembly, you run into base 0 computations everywhere. That means that a value of 0 is "the first position". The best way to wrap your head around this it to think about it as an offset from a base address. Non-programmers probably have trouble from the get-go with the idea of 0 not meaning "nothing" but is treated as a legitimate value. Adamantyr

Excellent points, Matthew! I also started programming when I was around 10 years old. And frankly, I had NO clue what I was doing. I read the BASIC learning book, and studied programs, but so much of it was weird and incomprehensible for years. There was an actual solid computer class at my junior high school that may have helped, but the teacher retired the year before I could go to it and the new teacher eliminated all the programming classes from the curriculum. So I was stuck reading my books and trying to figure it out. Lottrup's book just made things worse, because frankly, the Mini-Memory assembler is a TERRIBLE platform to develop on... it works, but that's about the most you can say about it. I remember the first time I realized I could use strings to store numeric data. What I actually did was store letters, like A, B, ect, and use those as codes for items and mapping. And boy was I ever excited about it! I wrote some Zelda-esque game with it, which sadly I can't seem to find now... I tried writing a LOS algorithm by hand, but in Extended BASIC it was way too slow... my theory was I could use the SIN and COS functions to plot out from the center of the display to the edge, and just do a 360 degree sweep around to determine tile blockage. I think I got bored watching it after about 10 minutes and realized it wasn't a tenable way to do it. I had similar assembly disasters to Matt's, misinterpreting what commands did, confusing them with BASIC-like commands. I laugh at it now, because I hadn't realized that the source code for a complete game (Tombstone City) was on the second E/A disk. It probably wouldn't have helped a lot to study it, but who knows... Even after I picked back up TI programming after my return to college 8 years ago, I still had to do some studying with an older eye to figure out how the OS was structured. I actually had set out to write Ultima II on the TI, I had planned to store and dynamically load the tile graphics using a complicated queue system into a full-bitmap mode design. Not really a great way to use memory or cycles... better to write programs that take advantage of the native design, not try and force another on it. I know how you feel with the frustration. I've felt that so many times... heck, I'm feeling that now. I'm at a pretty heavy "lots of work, not a lot of return" stage with my CRPG engine, and I'm finding Minecraft, Avernum 3, and other games an easy distraction. We do hobby programming for fun, after all... when it's not fun, it's easy to fall off the track. But don't give up on your games! Think about the 10-line contest. You had no problem finishing things there, right? The trick is scale. You need to build some smaller programs to test out what you want to do with the big projects. Spend a little time just experimenting. Share your code efforts here on the forums, we'll be happy to offer advice and praise when you need it. Adamantyr

Oi, you can go up to 14k on a cassette! Adamantyr

I agree with the masses... an awards system can easily become a game of favorites and cliche's. We've got a great friendly atmosphere here with the contests system, let's keep going with that. (Although I must admit I'm not really fond of the "crap game" contest myself... I'd rather do something like "only in BASIC") Adamantyr

Yeah, I got two copies of Timelost, both for the TI. I never knew they published it for other computers, I've only ever seen the TI ones in used bookstores. Weird! Adamantyr

You can use memory addresses for the divisor, like follows: W2 DATA 2 . . . LI R0,10 MPY @W2,R0 . * R0 is now 0, R1 is 20 . DIV @W2,R0 . * R0 is now 10, R1 is 0 . Adamantyr

One other point, DIV and MPY are both unsigned operations. Signed operations require a bit of extra work; you'll have to store the sign bits for divisor and dividend and restore the true value after completing operations. Curiously, the only two new opcodes added in the TMS9995 processor were signed multiply and divide operators. Adamantyr

I think I see part of your problem here... The EQU label is not saying "Put the character pattern table here" or "the character pattern table is here". It is literally just saying "this label points to this address". It is used by the compiler and the programmer to replace something that would ordinarily be a number with a label so that, if you decide you want to move it to another location later, you can just change a single label and have it change everywhere. So what does determine the character pattern table location? The settings in the VDP registers. And they have default settings coming from the E/A cartridge as follows: R1=E0 Standard mode R2=00 Screen image at >0000 R3=0E Color table at >0380 R4=01 Char pattern table at >0800 R5=06 Sprite attribute table at >0300 R6=00 Sprite pattern table at >0000 (not the same as char pats!) R7=F5 White on blue Does that help you grok this a bit better? Adamantyr

It isn't an easy transition from an imperative language like BASIC, I'll agree. I didn't quite grasp it myself as a teen either. I kept thinking "What's the command to do this?" It wasn't until I was back in college years later that I had my "Eureka!" moment. Maybe the best way to try and approach it is to think of the command in BASIC/extended BASIC you want to use, and then ask yourself "Now how would that command actually work? What would it actually do in assembly?" Start with something simple, CALL COLOR. Adamantyr

Numeric variables are just as slow, most of the time, since everything is pushed through the ROM and GROM floating-point routines. Adamantyr

Think of it like this... the VDP is just data storage. There's nothing there BUT data. All you need to know is where to find it, and what order it's in. Also, doing BASIC/Assembly cross-over work is seriously brain-hemorrhaging hard stuff. I tried to do it myself back in my teens, and couldn't grok it at all. I wondered how on earth anyone learned assembly programming that way. Adamantyr

Yes, that is correct. A better way to think of it is like this: Address of character = Starting address + ( character value * 8 ) In assembly, you can do this by having an equated label to the address. A code snippet is below: CHRPAT EQU >0800 . . . * Read a character pattern into BUFFER, @CHAR contains character to read LI R0,CHRPAT MOV @CHAR,R1 SLA R1,3 A R1,R0 LI R1,BUFFER LI R2,8 BLWP @VMBR Does that clear it up? Adamantyr

Numeric variable = 8 bytes String variable = 1 byte per character Strings are much better. It does add an additional operation to convert a string back into a numeric value, but the trade-off is worth it. Plus, you have 11k of stack that you can't use for program space. One question I had was, how are you maintaining different maps for each player? Adamantyr

I think it was in the Beryl thread that I laid it out... I'll do it again here: * Start with a blank map of nothing but walls * Plot random chambers on the map o You can either make them fixed sizes or slightly random in height/width o Overlapping is okay if you don't mind that, but it can make oddball shaped chambers * From each chamber, plot a corridor from the center o Plot anywhere from 1-4 cardinal directions from the center o Don't start plotting until you hit the edge o If a border is reached, change direction o You'll need some logic for direction random changes, otherwise you may just backtrack on your path and end early o If another empty chamber or corridor is struck, end the plotting for that direction * Populate items, monsters, etc. in the maze, either totally random or use the center coordinates of chambers as guides For a space station, you may want a more rigid system that makes logical sense. A space station would likely have single narrow corridors connecting larger rooms, and not a lot of overlap. Or, you may also want the rooms to have a more logical order. A main "central" room that is connected to all other rooms. The secondary rooms aren't necessarily connected to one another. Also, why not have pressure locks on each room exit that have to be hacked open? If you have a "room" generation system, you can do some interesting things as well. You have "rad levels" per room so some rooms have high radioactivity. Adamantyr

Sorry, double-post... got an error while trying to post.

Sweet! Can't wait to see more. So you're loading static maps from disk? Have you considered doing procedural generation? If you use a random seed value system, you could actually get a static set of maps that way. Adamantyr

Yep, that works fine. The VDP is an 8-bit system, and you're going through an 8-bit memory-mapped port, so there's no even addressing issues. What I did find myself was that sprite attribute changes often involved single words, so I did end up writing a VSWW and VSWR routine, so I wouldn't have to keep loading R2. Adamantyr

We got our TI-99/4a in 1984, for my brother's 12th birthday. My mom and dad had decided a computer would be a good thing to have, and Texas Instruments already had an impressive line with the Speak n' Math and Speak n' Spell units. Plus, the price was right at $249.99 with a $100 instant rebate at Jafco. (Jafco being a Sears-like store that operated in the Pacific Northwest. They later changed their name to "Best", before disappearing entirely. NOT related to Best Buy. My TI box still has Jafco stickers on it.) My parents were unaware that TI had just discontinued the product line, of course... And to be honest, most other computers were way too expensive for your average lower-middle class family in that era. Paying $800-1000 was just unthinkable for what was widely considered a "toy". My brother was told he could pick the game cartridges he wanted from what was available. What caught his eye (being into D&D) was the Tunnels of Doom box, with the blue cover featuring a dragon breathing fire on a figure with sword and shield. It was $59.99, though, compared to the $29.99 price tags on other games, so he had to give up two picks to get it. We also got A-Maze-ing, Munchman, Parsec, and Alpiner on that first trip, I believe. I know we eventually got enough cartridge UPC's to send in for the free speech synthesizer, but we didn't have one initially. All the games were very enjoyable, but Tunnels of Doom was a world apart. We did Pennies & Prizes many times at first, before my dad started "Quest of the King". I remember the first game was very chaotic... Mauve kept dying at fountains and eventually everyone died to a random encounter on the 2nd level. Since there was three of us, we traded off with each character deciding our actions independently. I think that was really a good way to play a party-based CRPG, but it eventually morphed into MMO's. We got a Triton Catalog at some point... I still have every issue except the very first one from late 1983. I'm not sure how we came into it, but it was a definite life-line for the system, because Sears, Payless and other stores soon after stopped carrying software. (It wasn't just TI getting phased out, though, nearly every computer got boned in the post Video Game Crash.) My brother lost interest in the system because a friend of his had a TRS-80 Color Computer and had an impressive set of magazines and games for it. Plus, Radio Shack was still around and easy to get everything you wanted at, so he ended up moving on to the CoCo and left the TI behind for me. (Years later, at the Tacoma TI faire, he bought a whole new TI system (with disk drive, PE box, the works) because he wanted the spreadsheet software. He had been frustrated by the lack of good utility software on the CoCo.) We actually found a computer store (Northwest Computers) in Mount Vernon, WA, that sold TI equipment. The owner was a 99'er, although he sold other vintage computer software and hardware. I bought my PE box through him in 1987, pooling birthday money from several sources to do so. It was great to have an actual disk system at last, I had been getting really tired of cassette tapes at that point. Plus, a good friend of mine also owned a TI and we both traded off games with one another from time to time. He also gave me the TexComp catalog, which offered a whole new set of things to order. (I just ran into this old friend at Microsoft, and in my building no less. Most of his TI stuff was lost, though, when his parents passed away, and the awesome XB game "Food Frenzy" he had been working on has been lost to the ages. Alas.) I visited Bits N' Chips in Lynnwood, WA, once around 1988, and actually got copies of several games on disk, including Legends. (I later realized I was essentially paying a buck a disk to pirate software.) I got a subscription to Micropendium around 1990 as well. I really wanted to program great things in my youth. I worked very hard to learn how to program in BASIC and Extended BASIC. Unfortunately, assembly was nearly incomprehensible to me. I didn't have the necessary background to understand why things worked like they did, and the few clumsy attempts I did to create a simple program failed, and I had no idea why. Truthfully, looking back... I probably wouldn't have gotten far. The speed of compilation is so slow on the TI, and without a debugger, you'd be tearing your hair out trying to find problems. Plus, I'm pretty certain I'd have burned out my disk drives with all the compiling eventually. I do need to dig up some of my old Extended BASIC projects, dust them off, maybe put them up on Walid's site. Adamantyr

First byte (left) is the high byte, second byte (right) is the low byte. Yes, we know, it's NOT how modern PC's are. It's Big-Endian instead of little-Endian. They call it "Motorola" style these days as opposed to "Intel", at least in my hex editor application. If you need to do things on non-even addresses, you must use byte commands like CB, MOVB, etc. The word operations NEVER do anything with odd addresses, if you try and force them they just round down to the even address. This is because the address line is, literally, only 15-bits. Adamantyr