Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

Community Reputation

822 Excellent

About Airshack

  • Rank
  • Birthday 01/01/1965

Profile Information

  • Gender
  • Location
    Phoenix, AZ
  • Interests
    TI-99/4A, Atari 800XL, Commodore 64, Intellivision, Odyssey2, Colecovision, basically retro computing and gaming is why I'm on AtariAge.
  • Currently Playing
    SCRAA on the TI-99/4A
  • Playing Next
    T.I. Munchkin on the TI-99/4A

Recent Profile Visitors

13,637 profile views
  1. This is interesting. Let’s say I’d like to test what I have so far using FinalGROM. After using AORG >6000, I’ll need to know more about cartridge headers. Any good sources? I have but a vague notion of what a cartridge header involves.
  2. Thanks @PeteE. I’m familiar with the scratchpad and EQUates. I do like the way you’re using offsets vs actual addresses, as I’m using. Your method makes it easy to maintain available scratchpad awareness without doing any Hex math. As for the ISR, I’ve been convinced to avoid that for game programming with LIMI 0 as per previous posts on this same thread. Rolling my own routines to preserve scratchpad predictability and speed.
  3. Actually, No! I’m not using AORG at all. There’s no absolute addressing of my program code. While studying the EA manual I incorrectly assumed that an omission of AORG would simplify matters. What I believe I am realizing now is I’ve simply chosen to defer control over where my code is stored. I was vaguely familiar with the assembler directive AORG from messing around with the mini-memory cartridge. Seems my game project began and has grown wildly without using AORG to manage absolute addressing. This being my first assembly game and all, I was pretty happy to let the assembler do its thing. It appears AORG is going to be necessary if I want this game to ever run from a cartridge. Correct? Also, I’ll need to find another way to place keys upon my game background as ROM map images are obviously impossible to manipulate in the manner I’ve recently implemented. One thought: If I keep track of where my key objects should be located on the scrollable game map, I can simply plot them over grass tiles, after each viewport redraw. I’m imagining this will create a blinking appearance as the map is continually redrawn, and the key is then replotted. Perhaps it will appear as a nice feature highlighting the key’s location?
  4. At this point in my learning cycle I exercise little control over where the assembler is going to locate my code. Big Picture Wise: How may I restrict myself to the unexpanded console RAM?
  5. What a difference some coaching, some sleep, and a cup of coffee make! Of course my problem was undetectable near bedtime. Thanks @sometimes99er & @Asmusr. It’s almost thrilling to simply manipulate expanded RAM without messing around with the VDP portal routines. So this must be what it’s like to develop on a system with no VDP between the CPU and RAM. Of course the other retro systems of the era are hampered by: 8-bit registers, fewer registers, less capable registers, no divide and multiply op codes, etc. I suppose the VDP memory access restrictions aren’t that big of a deal considering the power of the 9900, vs Z80 or 6502. Anyway, it’s working now. I have a bridge key on my game map! MOV @MAPDAT, R6 * pointer to beginning of map LI R7,>D900 * Character D9 = bridge key MOVB R7,*R6 * Place key at map origin as a test My problem last night was I was using the following first line: LI R6, @MAPDAT * then basically corrupting MAPDAT Caused all sorts of havoc onto my game screen.
  6. Odyssey2 has a nice golf title which is quite entertaining despite the simplistic presentation. As with their other sports games — no player vs computer mode. So so difficult to get good at an AI-less sports title unless you have another human player with equal enthusiasm. I believe a computer AI player will significantly enhance the replay value.
  7. So I may then use a simple register-to-memory or memory-to-memory application of MOVB to get the job done? Seems so much easier than working with the VDP RAM via ports. I don’t know why it’s not working out for me. Zero examples in the EA manual of mem-to-mem and reg-to-mem, and probably failing due to fatigue...zzz. Will try in the AM. LI R0, >D900 MOVB RO,@MAPDAT * to replace byte at MAPDAT w >D9 I think I tried this earlier and received a warning. Will the 8bit data path to upper expansion ram result in MOV operating transparently even though it moves 16bits?
  8. I have a game development situation: In order to avoid using more than four sprites in the same horizontal row, I’ve decided to “drop” a key onto my game map using a background tile vs using a fifth sprite. The game is a vertical scroller with the play area roughly the size of four TI screens vertically. At the beginning of my code I load a Magellan assembly data formatted map into memory. The assembler takes care of where... I have a pointer to this map data memory location called MAPDAT. It turns out the assembler mysteriously assigns the map location (top left tile location) to: >C5B0. In Upper Expansion RAM. @MAPDAT = >C5B0 (50,608) >C5B0 holds character >8B I’ve used the debugger in Classic99 to verify my map data is in fact loading properly at this location. My scroller is working... Question: Is it possible to overwrite the data located at >C5B0? I’ve previously only used VDP console RAM read/writes. I guess I need a kickstart on accessing upper expansion RAM. There’s something simple I’m overlooking perhaps? Obviously the data at >C5B0 and beyond is part of my code listing. It’s not logic — just data. Would modifying this data be considered self-modification of code? It’s possible I’m over-complicating something easy here. Just late and my progress has halted. Help!
  9. I love sports related titles on retro gaming consoles and computers. Can’t wait to play this. Looks great so far! One BIG thing I find missing from most retro sports titles is opponents with AI. Any chance this game will include two player mode or single player vs computer?
  10. I can’t wait to check this out. Word on the street is the EA Cart’s example game code —Tombstone City— is full of poor/inefficient programming techniques. Sounds to me like this is going to be a better example to learn from. I skipped using the Tombstone City code as part of my TI-99:4A Assembly learning process. You deserve a big THANK YOU for publishing your source code. Hopefully this will inspire others to publish more source code. Why not guys? Surely not a financial risk. My current/first Assembly game project will include source code upon completion. Perhaps as an example of what not to do? There’s value in that. Seriously though, I’ve been loading up my code with comments intended for beginners — dummies guide style. My game may suck but at least it will provide an opportunity for others to learn. No doubt I’ll be documenting mistakes and lessons learned as well. This assembly coding deal isn’t as difficult as the 1980s documentation makes it seem. Especially with the AtariAgers offering help along the way. Thank you! @retroclouds PS - Enjoy your Pitfall in the Tomy Tutor as well! It’d be interesting to hear you explain how TI-99/4A code is then ported to the Tutor.
  11. The game graphics are beautiful especially considering it was developed in 1983. Cleaning up (removing) the moon/planet graphic and slowing down those damn demon spawn would be an awesome project. Do we have a place where game code listings are available?
  12. Where does one get an 18" extender. Never in my life did I ever expect to need an extender but now I do.
  13. The firehose is not connected in the Feb 20 graphic?
  • Create New...