Jump to content

adamantyr

+AtariAge Subscriber
  • Content Count

    1,852
  • Joined

  • Last visited

Everything posted by adamantyr

  1. So far, not really seeing or hearing a lot of enthusiasm or planned submissions... Where is Owen? He could submit Beryl Reidchart for this one... Adamantyr
  2. Actually, Theirry Nouspikel already has the 9900 opcode speeds worked out, you can find them here: http://nouspikel.group.shef.ac.uk//ti99/tms9900.htm#Speed Multiplication and division are really just add and subtract operations that loop. Multiplication is "Add first value a count of times equal to second value". Division is "subtract first value from second value until remainder is smaller than first value." The problem with division is that it doesn't have a known stopping point, where multiplication does. That means the time to complete is not a stable value, and it also does a comparison check after each subtraction to see if the remainder is still larger than the divisor. Multiplication doesn't need to do this. Matthew's main point about multiplication and division is that they are cycle-expensive. In assembly programming, you are often either optimizing for speed or memory. Usually speed ends up costing more memory space. So you should look at your algorithms and make certain that you're not using MPY and DIV when another set of instructions would suffice. If you're always adding/dividing by a power of 2, using shift operators is far more economic. Interestingly, modern ARM processors also don't have division as an opcode, but they do have multiplication. There's a method, thanks to overflows, that you can use to have multiplication actually do division for you, in fact. That being said, I very much appreciate having MPY and DIV in the TI opcode system. If you're programming for a 6502, you don't have them, and it HURTS to do operations without them. Adamantyr
  3. Awesome! Any more info available yet? What language are you writing in? Adamantyr
  4. Hopefully someone will see fit to post some neat game construction stuff for the contest this weekend... besides me, I mean. I made a start of things for "Stellar Empires" by generating the random galaxy. Instead of using an array, I'm storing the data in long-length strings. It creates a little overhead extracting data. The map size is 20x30, to easily fit the TI screen and give me some display room on the bottom. I'm using the display to act as a tracking system for already occupied coordinates, and generating other details like the system class and name. Class 3 and 4 systems will also have their own native fleets to contend with, but only 1/3 of the systems will be that caliber. Player systems will automatically be class 5 and will overwrite the existing data. I decided to have a little fun with the system names. Instead of having a set of names assigned randomly, why not use suffixes to generate completely random names? So I made a set of 64 suffixes that each name is comprised of 2-4 of them at random. They seem fairly random; the chance of two systems having an identical name is pretty remote... examples generated include "Memfogcha", "Vorxenros", and "Oracammil"... Here's the code so far: Adamantyr
  5. I love how you said putting registers in non-scratchpad will "affect performance drastically"... Most BASIC users wouldn't notice a problem for a LONG time, until they got over-ambitious. Adamantyr
  6. Can we get some context...? The DSK. parameter attempts to find the disk of the given name in all the drives connected to the controller. If you want to explicitly run a file on the first drive, try RUN "DSK1.STORY1" Adamantyr
  7. Let me offer up an idea I may turn into a game, as an "does not qualify for a prize" entry, since I'd be a judge... My brother had a game on his Color Computer called "Stellar Empires". It was a turn based multi-player game in which you took control of star systems, which increased resource output and allowed you to build warships with which to take over systems or defeat other players. The span between systems (on a 2D coordinate map) determined how many turns before ships could arrive, so you had to reinforce border systems periodically in case of attack. Basically a simplified version of Risk, in space. It had an AI player, but I honestly don't think it did much other than issue silly threats in the message system. I've taken a stab at writing this for the TI once or twice in the past... the last time was 6-7 years ago in an early Classic99 build. I've also written a version in Java using object-oriented design as a console application, which was entertaining... nobody had ever really planned Java to be used for DOS-style apps, it lacks fundamental key controls. For the TI version, my target platform would be Extended BASIC, with 32k RAM required. I'd probably offload graphics definitions and other static data to disk in order to free up space for game code. I'd really like to try and make a "smart" AI player like my Java version was, although it may process too slowly to be fun in Extended BASIC. I'd want to add some new features as well, such as different warship types, an alterable tax rate (increase production at the expense of greater risk of rebellions), and ship battles that are more complicated. In the original game, the side with the more ships automatically won and destroyed the other fleet, while taking some losses, a tie meant all ships were destroyed. I'd rather that a defeated fleet suffer greater losses, and retreat to the closest owned system. Obviously, multi-player games where one of the players has to turn away while the other takes their turn are a bit old-school... but I don't think I want to tackle a "modem" version right now... on the TI especially, this is pretty complicated. Which is why I'd want a smart A.I., so a single player can pit himself against a computer opponent. Sound intriguing? Adamantyr
  8. I could see myself playing Dr. Mario for an hour on a rainy day... that would involve a lot of manual dexterity, though, and it's not exactly deep... Adamantyr
  9. Boundary checking in assembly isn't easy or simple. Kudos on creating a working solution! Probably the most important paradigm to embrace here is that the screen is not a data storage area. What you're doing is storing a value in a linear array 768 bytes long. The fact that it's the screen is just how the data is being displayed. You're using a single register to track an index in this array, so this is why it's not easy to suddenly have it behave like it's in a two-coordinate system. So, one solution is to use two data words to store a row and column value, and then calculate the index value on the screen from that. Then you can just check that the row and column are within boundary limits before calculating the index value. Here's a short snippet how it would work: ROW BSS 2 COL BSS 2 . . . CHECK MOV @ROW,R0 CI R0,24 JL CHECK1 * Value is 0 to 23 CLR R0 CHECK1 MOV R0,@ROW MOV @COL,R0 ANDI R0,>001F * AND against 32, will cause column to wrap around if -1 or 32 to 31 and 0 respectively MOV R0,@COL MOV @ROW,R0 SLA R0,5 * Multiply by 32 A @COL,R0 This is a bit crude... I have wrapping working for columns but rows will be strange. Also note that by using the SLA (Shift Left Arithmetic) instruction, I can multiply by any power of 2 value. You can use SRL or SRA to divide in much the same way. Does this help? Adamantyr
  10. That sounds nice! I don't think I got one with my cartridge... I'll put it at 3rd prize, I got one potential 2nd prize of a 96k RAMDisk. Adamantyr
  11. I had to re-read that a few times. I think a better phrase, to avoid confusion, would be "open to all 99/4A languages". To me, "platforms", especially here at A.A., means other computer systems, i.e. Apple, Atari 400/800, C64, etc. Good point! Fixed. Adamantyr
  12. Oh, and since it's open to all TI-99/4a languages... I keep hearing how Forth is the greatest language platform on the TI ever made... well, it's showtime, Forthies! Adamantyr
  13. It's not restricted to turn-based. Just not something you'd only play for a few minutes because there's not a lot to it to experience. Obviously this favors a more cerebral type of game. Just to throw out a game idea: take your favorite board game, and adapt it to the TI! Adamantyr
  14. An F18A board, sounds like an intriguing prize! And I'd be happy to have judging help, any other volunteers? Three would work for settling ties. Adamantyr
  15. Seems like things are too quiet around here... time for another contest! I live in the Pacific Northwest, so I'm used to rain and rainy days. I remember spending many hours of my childhood in front of my TI, playing games while the weather was too nasty to go out in. So, I propose this for a contest: write a game that you'd play on such a day. It should be fun to play as well as hold your interest for at least an hour. A good cerebral game with thinking, strategics, and brain challenges is the ideal. There's nothing wrong with a fun little sprite shooter, but they generally would only occupy you for a few minutes. Then you'd be looking for another game. No game will be "refused" based on these guidelines, but it will be considered in judging if the game involves a lot of manual joystick movement and not a lot of thinking. Also, unlike the other contests, we'll open this up on the technical side while limiting the theme. Write in any language/platform you want! The only rule is, it can't require hardware that isn't common. Pascal is right out. All entries should be posted to the "Official Rainy Day Game Contest" thread which I will start as soon as someone has a game to post. Contest guidelines: Write a game on platform language of choice Must be loadable with BASIC, Extended BASIC or the Editor/Assembler cartridge Can use 32k memory expansion, and a single drive/disk for data storage (Keep it to a classic 90k disk if you can) Can use machine language subroutines All entries due by October 3rd, 2011 You may enter as many games as you wish, but only one will be considered for prizes Game may be either an original idea or a port of another game for another platform At least six contest entries must be presented for prizes to be awarded. The winning entries will receive: 1st Prize - F18A board, serial 2nd Prize - 250k RAMdisk 3rd Prize - Full-color original printed manual for Pitfall! cartridge Games will be judged in three categories, in order of priority: Game Play (Must be fun and involving, have depth) Performance (Should be playable on iron, but CPU overdrive is fine) Graphics (Gotta look good) Incidentally, if I do write an entry for this contest, it's not a contender. Please offer any comments, suggestions, concerns, criticisms, etc. on this thread. Adamantyr
  16. I think what the Yahoo group was lacking was a sense of fun and vitality. It's more a bunch of old guard 99'ers hanging around, reminiscing about the old days. They're not really interested in software projects, they have NO interest in games. I think AtariAge is a great place for 99'ers, and I don't see things going downhill here yet... I certainly would never snub any new visitors! It is true that we need motivators around. I think the contests are good for group morale and to get people thinking about TI-related things. For the next contest, I suggest we open it up a bit. Extended BASIC, 32k RAM, and up to a 90k disk of data, including the program, and maybe have a game theme. (Space, fantasy, contemporary, weird, etc.) Adamantyr
  17. Here's Amazon's used book listing for Lottrup: http://www.amazon.com/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.com%2Fgp%2Foffer-listing%2F0942386744%3Fie%3DUTF8%26ref_%3Ddp_olp_all_mbc%26qid%3D1300483409%26sr%3D8-1%26condition%3Dall&tag=atariage&linkCode=ur2&camp=1789&creative=390957 I remember when they were going for $400+ Mind you, that was just an artifact... frankly, even $43 sounds a bit high for it. Adamantyr
  18. Any version of Windows would have to pre-date Windows XP as well. The problem being that a lot of the low-level routines for floppy drive access are no longer mutable at that stage. Given that floppy technology hadn't changed in a long time, it's not surprising they locked that off. I got a Pentium 200 MMX running DOS 6.11 which seems to work, at least as far as reading the TI disks. I haven't tried writing them, though, I suspect it wouldn't work because of the RPM speed differences. Adamantyr
  19. Very cool! (Was that you singing, by the way?) So when does the March issue of Retro Gaming Monthly come out? Adamantyr
  20. Those old drives probably won't work with modern motherboards, or the Windows OS. You'd need something at least 10-15 years old and running DOS to have a shot at it. Adamantyr
  21. Thanks, but I wrote Aperture in BASIC, and it's been entirely fine-tuned for that platform. Compiling it or re-writing it for assembly would be, in essence, creating a different game. I respectfully request that others on the forum also not provided a compiled or re-written version of Aperture. Thanks, Adamantyr
  22. The first two are Boxer and Break-out, which I saw on cartridge in TM Direct magazine close to the end of its run. I'm not sure about last two. Adamantyr
  23. I got a message that the chatroom was full. Adamantyr
  24. No, those are sectors, with are 256 bytes each. Every file has at least 2 sectors, because 1 is used for tracking. So your load program is around 4k, and the NEWFORO file is just over 16k. Adamantyr
×
×
  • Create New...