matthew180 Posted March 9, 2010 Author Share Posted March 9, 2010 Excellent stuff! Oh, and for what it is worth, you might want to take a peek SPECTRA (shameless plug ) as it offers some routines for task scheduling, handling sprites, etc. Anyway, great to see a new assembler game in development! .. and what is even better hope to see this as a full tutorial Spectra is pretty nice, and people should check it out for sure. As for me though, I *want* to write all this myself. For me it's more about the coding and learning the guts of the machine than the end result. I'm trying to put together some sort of tutorial, but more in the form of a book though, since I tend to get verbose. Matthew Quote Link to comment Share on other sites More sharing options...
The Codex Posted March 9, 2010 Share Posted March 9, 2010 By the way, what acronyms are you not sure about? Mostly BLWP and VDP. I think I've somewhat intuited what they apply to, but am unsure exactly what they stand for. When I did a web search for "assembler BLWP", the first result that came back was this thread. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted March 9, 2010 Author Share Posted March 9, 2010 Haha, well this thread is the end-all be-all of information on the Internet. :-) VDP == Video Display Processor. It is really a generic term, but not used much any more. Now days we just say Radeon or gForce. In the TI, the VDP is the TMS9918A which is a single chip that takes care of displaying the video image. The 9918A also has its own RAM, typically called VDP RAM. The CPU can get access to the VDP RAM but it has to do so by going *through* the VDP, which can be a slow process since the VDP is almost always busy drawing the screen. The 9918A supports a few graphic "modes" as well as the 32 sprites. However, there is a limitation on the number of sprites the VDP can display on a single horizontal scan line (due to the amount of time the VDP has to process a horizontal scan), so after 4 sprites are displayed on a given scan line, the VDP stops drawing sprites on that line. This is the "4 sprite" limitation you see us referring to. The VDP does *not* automatically move the sprites, and the auto-sprite movement you might read about on the TI is done by the one and only ISR (interrupt service routine) in the console. The ISR is triggered by the VDP vsync 60 times per second, and it can be disabled (which is usually done for assembly games.) BLWP == Branch and Load Workspace Pointer. It is a machine instruction (assembly language mnemonic) that was primarily designed for doing OS context switching since the TMS9900 was most used in TI's mini computers. It is one of a few ways to do function calling in assembly, and definitely the slowest way to do functions. It has a few advantages though that depending on the circumstances can be worth it. You can read about the gritty details in the EA (Editor Assembler) manual or the TMS9900 Datasheet. I'm pretty sure both are available on the WHTECH FTP site, or I think there is a torrent set up too? Anyone? The EA manual was the "big book" that came with the Editor/Assembler package and is the de-facto reference for the 99/4A (although not complete.) The PDF I have is a scan of every page and weighs (virtually speaking) as much as the real book. The 9900 Data Manual is the datasheet that TI put out for engineers to build computers with the 9900 CPU and has all the low down details about instruction execution, timing, internal operation, interfacing, etc. I use both quite a bit, and the especially the data manual when working on my emulator. Hope this helps some. Matthew Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted March 9, 2010 Share Posted March 9, 2010 Actually the simplest solution is to just use Classic99 since I know you ignore the 4 sprite limit. I don't think that's all true anymore. Tursi ? Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted March 9, 2010 Share Posted March 9, 2010 You can read about the gritty details in the EA (Editor Assembler) manual or the TMS9900 Datasheet. I'm pretty sure both are available on the WHTECH FTP site, or I think there is a torrent set up too? Anyone? The EA manual was the "big book" that came with the Editor/Assembler package and is the de-facto reference for the 99/4A (although not complete.) The PDF I have is a scan of every page and weighs (virtually speaking) as much as the real book. The 9900 Data Manual is the datasheet that TI put out for engineers to build computers with the 9900 CPU and has all the low down details about instruction execution, timing, internal operation, interfacing, etc. I use both quite a bit, and the especially the data manual when working on my emulator. Both the Editor/Assembler manual and 9900 Data Manual PDF's can be referenced from the development resources sticky thread. Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 10, 2010 Share Posted March 10, 2010 Actually the simplest solution is to just use Classic99 since I know you ignore the 4 sprite limit. You underestimate me again, Batman! Classic99 has supported sprite flicker since 22 Jun 2009. The method used to calculate it is hacky, but the results are 100% correct. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted March 16, 2010 Author Share Posted March 16, 2010 Playable WIP (work in progress). Arrows (joystick) to move, fire button to start a new game (controls are like a coin-op). Extra life at 10,000 pts, level stays at 5 once you reach level 5. FlyGuy and the Spiders get faster on each successive level. The timer is added to your score after each level. To run: unzip and using Classic99, select the file as a User Cartridge. Press 2 2. Matthew flyguyC.zip Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 16, 2010 Share Posted March 16, 2010 Thank you for this Matthew. It's a real pleasure seeing your assembly work. Quote Link to comment Share on other sites More sharing options...
The Codex Posted March 16, 2010 Share Posted March 16, 2010 Woot, looking forward to trying this out tonight! Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted March 16, 2010 Share Posted March 16, 2010 Excellent work Matthew! This is fun. Now that assembly language is used it would be cool to move the flyguy pixel by pixel (but still let him snap to the grid) Dunno if someone asked this before, but why not make a homebrew cart out of this ? Either way, looking forward playing the final version Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted March 16, 2010 Share Posted March 16, 2010 22600 Quote Link to comment Share on other sites More sharing options...
matthew180 Posted March 16, 2010 Author Share Posted March 16, 2010 The original was character based, so I wanted to duplicate that first. I started on the sprite-based version but decided to get the character version playable and somewhat complete first. The response over this version will heavily dictate whether I do the modification to sprites or not. Just moving at fixed 8-pixel intervals is no big deal, but my plan was to let FlyGuy and the spiders move freely at a pixel level and simply be confined to the grid (web). This means you could reverse direction at the pixel level, whereas moving at fixed 8-pixel intervals means FlyGuy would have to complete the full 8-pixel move before you could reverse direction or stop. The unconfined movement is what we are used to in the arcades, but it is also a lot harder to implement. I'm still not sure how to take the levels further either. I don't think hand made levels is the answer, especially since they take a lot of data. Finding a way to generated them like the original version would be required, or having fixed levels with more of a design and other challenges. Having the spiders jump or dangle on webs, and FlyGuy "fly" (maybe for a limited time, or a limited number of times) would be other alternatives. I don't really like the FlyGuy "entrance" either, but I needed a way to bring FlyGuy's location to the attention of the player, since his start location is random each time and he was had to location at the start of a level. I just could not come up with anything more interesting right the moment. Matthew Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted March 16, 2010 Share Posted March 16, 2010 I don't really like the FlyGuy "entrance" either, but I needed a way to bring FlyGuy's location to the attention of the player, since his start location is random each time and he was had to location at the start of a level. I just could not come up with anything more interesting right the moment. Matthew Are you kidding? That is one of the coolest thing of the game Quote Link to comment Share on other sites More sharing options...
matthew180 Posted March 16, 2010 Author Share Posted March 16, 2010 Well, it is a total hack. Since I don't have enough RAM (other than copying back and forth to/form VDP RAM... ugh) to store the two paths across the screen, I have to redraw the level, pills, an spiders after the effect and there is a quick flash of the display when that happens. If the effect is that acceptable, maybe I'll redo it the *right* way and see if I can make it non-destructive so it looks nicer. :-) Matthew Quote Link to comment Share on other sites More sharing options...
The Codex Posted March 16, 2010 Share Posted March 16, 2010 Just moving at fixed 8-pixel intervals is no big deal, but my plan was to let FlyGuy and the spiders move freely at a pixel level and simply be confined to the grid (web). This means you could reverse direction at the pixel level, whereas moving at fixed 8-pixel intervals means FlyGuy would have to complete the full 8-pixel move before you could reverse direction or stop. The unconfined movement is what we are used to in the arcades, but it is also a lot harder to implement. I've got a technique for that, came up with it for the Solar Fox remake I never released. Like the arcade original, you move on a grid but can only make left/right turns at grid interesections. I also use a small loop to snap the player back to the closest gridpoint if they stop moving. Let me know if you want to take a look at this, it's in Java but is pretty easy to suss out from the sources. Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted March 16, 2010 Share Posted March 16, 2010 Well, it is a total hack. Since I don't have enough RAM (other than copying back and forth to/form VDP RAM... ugh) to store the two paths across the screen, I have to redraw the level, pills, an spiders after the effect and there is a quick flash of the display when that happens. If the effect is that acceptable, maybe I'll redo it the *right* way and see if I can make it non-destructive so it looks nicer. :-) Matthew Well, I guess you could do the below: 1. Draw the screen 2. Copy the screen 3. Switch VDP name table pointer to copied screen 4. Do your funky animation stuff on copied screen 5. Switch VDP name table pointer to the original screen Quote Link to comment Share on other sites More sharing options...
matthew180 Posted March 16, 2010 Author Share Posted March 16, 2010 I've got a technique for that, came up with it for the Solar Fox remake I never released. Like the arcade original, you move on a grid but can only make left/right turns at grid interesections. I also use a small loop to snap the player back to the closest gridpoint if they stop moving. Let me know if you want to take a look at this, it's in Java but is pretty easy to suss out from the sources. I'd like to avoid the snapping or forcing to a character boundary except during turns where you have to be aligned +/- 4 pixels or so. Getting it working is not really the problem, getting it working in a slick efficient way is the problem. :-) I'm using PacMan as a template, and if anyone has not done so, I highly recommend you read The Pac-Man Dossier on Gamasutra. It is one of the most excellent articles I have ever read about classic coin-op games. Absolutely amazing what is actually going on inside the game and makes my efforts feel less than adequate. Matthew Quote Link to comment Share on other sites More sharing options...
matthew180 Posted March 16, 2010 Author Share Posted March 16, 2010 Well, I guess you could do the below: 1. Draw the screen 2. Copy the screen 3. Switch VDP name table pointer to copied screen 4. Do your funky animation stuff on copied screen 5. Switch VDP name table pointer to the original screen Even doing that does not solve the problem. When the lines of FlyGuys are being erased, the "proper" thing to do would be to restore what was under them to begin with. Having a second screen does not help with that. Since I don't have the RAM in the console to store the 54 characters I need (I can't use the 32K expansion since I'm trying to keep this as a console cartridge that will run on an unexpanded system), I'd have to copy in chunks from the VDP into a small buffer in CPU RAM, then back into VDP RAM. Then when erasing the FlyGuys, I'd have double the VDP accesses to get the original characters from VDP RAM and put them back in their original location in VDP RAM. I know what to do, I just need to do it. But I didn't want to spend that much time on it if the effect was lame or confusing to the player. Matthew Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 16, 2010 Share Posted March 16, 2010 Even doing that does not solve the problem. When the lines of FlyGuys are being erased, the "proper" thing to do would be to restore what was under them to begin with. Having a second screen does not help with that. Since I don't have the RAM in the console to store the 54 characters I need (I can't use the 32K expansion since I'm trying to keep this as a console cartridge that will run on an unexpanded system), I'd have to copy in chunks from the VDP into a small buffer in CPU RAM, then back into VDP RAM. Then when erasing the FlyGuys, I'd have double the VDP accesses to get the original characters from VDP RAM and put them back in their original location in VDP RAM. I know what to do, I just need to do it. But I didn't want to spend that much time on it if the effect was lame or confusing to the player. You say you have it already, but as a suggestion.. when you have tons of ROM and little RAM, use the ROM. It might be helpful to just predefine the screens in the ROM itself, then you can just copy right out of them when you need to erase. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted March 17, 2010 Author Share Posted March 17, 2010 Okay, here is another update with the FlyGuy "entrance" done right. :-) Fixed a bug or two as well. Small note about entering initials, use the fire button (tab key in Classic99) to move to the right (the left and right joystick work too), but you have to hit the fire button in the last character to commit the initials. Matthew flyguyC.zip Quote Link to comment Share on other sites More sharing options...
The Codex Posted March 17, 2010 Share Posted March 17, 2010 Argh, what's the keyboard equivalent for the fire button in Classic99? Never seems to be the same key twice. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted March 17, 2010 Author Share Posted March 17, 2010 The TAB key is joystick "fire" in Classic99. Not sure if that can be remapped or not. I found it by trial and error. :-) Matthew Quote Link to comment Share on other sites More sharing options...
The Codex Posted March 17, 2010 Share Posted March 17, 2010 Gravy, I'll give that a try tonight. Thanks! Quote Link to comment Share on other sites More sharing options...
matthew180 Posted March 17, 2010 Author Share Posted March 17, 2010 Is anyone actually interested in the code for this game? Does anyone read assembly code anymore? Matthew Quote Link to comment Share on other sites More sharing options...
Opry99er Posted March 17, 2010 Share Posted March 17, 2010 (edited) Matthew, I am not yet an assembly programer, but I tried to get my hands on as much "commented" source as I can. I love Filips stuff he put out on Pitfall. It helps me understand how the computer "reads" so to speak. even though the source cannot really run by itself--- it must be assembled into object code. But I would certainly be interested in seeing your source... If you're offering. Edited March 17, 2010 by Opry99er Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.