Search the Community
Showing results for tags 'code'.
-
I'm looking for the TI Assembler commented source code. Not the E/A cart code. I'm guessing that it was probably sourced from some 990 package originally? Any ideas? Thanks.
-
Hello! After some searching for MADS highlighting for Vim, I haven't found nothing useful, so I decided to write something new… The only solution like this which I found was vim-xasm, the XASM highlighting, but it wouldn't enough good to use with MADS (lack of preprocesor directives and so on) So, here it is! Completely new plugin, suitable for every serious Atari coder with Vim as his main editor. (Note: If Vim isn't your primary editor yet, give it a try! But remember, some of your habits will be quickly broken :>) URL for GitHub Repository (aka "The Giant DOWNLOAD Button"): https://github.com/skrzyp/vim-mads (of course, if you're not familiar with Git, you can still grab this plugin as archive, but you'll lose the ability to update it when something new will be added/corrected) Installation Manually: Put folders syntax and ftdetect in your Vim configs directory: Windows: %USERPROFILE%\vimfiles Rest of world: ~/.vim Recommended: Using Pathogen Clone this repo into your Vim path: git clone https://github.com/skrzyp/vim-mads ~/.vim/bundle/vim-mads Of course, I'm fully open for any suggestions and comments, even if you found any bug or problem, tell me here or make a pull request. I'm also very interested about any feedback from users. Screenshot (sorry, I don't have a code which use a full potential of MADS, but if someone has, send me your pic, please)
-
Early this year, I learned that MAME, which has recently been combined with MESS into one single emulator, also emulates some handhelds now... among those are some I have or had myself, Coleco's Donkey Kong tabletop game, MB's Bigtrak and Nintendo's Mickey & Donald (Game & Watch). I decided to take a deeper look at Mickey & Donald (after nearly competing the Bigtrak code, but that's off topic here) because I was always curious how such games have been programmed... I started on it in February 2016, about 33 years after I got the actual game. Obviously, this is a low-power device powered by two button cells and having an LCD screen. It's using a Sharp SM510 mictrocontroller with a fixed ROM. There is a nice write-up on that CPU here: http://watchdev.blogspot.co.at/2013/06/sharp-sm510-innards.html This chip has got a built-in LCD driver, and the display is memory-mapped, that is, all memory locations from $60 on are visible (at least if they've got segments connected to it). Since the disassembler in MAME didn't work quite correctly (don't know if it has been fixed by now), I wrote my own disassembler for the code in VB.net, which is actually not so hard considering the CPU doesn't have that many commands. There are some quirks like 1-byte subroutine calls which are routed through an address table in the first page, though this still only enables certain jump destinations because those addresses still only have 8 bits, but the address range of the CPU is 12 bits. Well, as I said I was curious how such a game is programmed. Actually it's quite different to what you're used to on video based systems. Normally you would have sprites, which are objects with an X and an Y coordinate, and they move and interact in some fashion. Well, for the most part, it doesn't work this way here. How it actually works is closer to a shift register, actually several of them. As you may know, a shift register is a stack of bits which get shifted left or right in sync to each other. In this game, there are several lines of bits which work like a shift register. But they're not hardwired, all of this is done in software. There is a subroutine for each possible bit which swaps that bit in a memory location with the carry flag. The actual bits in a line often don't have a real logical position in memory, rather they were seemingly positioned so the lines in the LCD screen are best used. For instance, for an object that has 3 possible positions, one position might be displayed when bit 2 of memory location $62 is on, the second one is on bit 1 of memory location $6D and the third one on bit 2 of memory location $6B. The line is now shifted by starting at the first position, fetching its status to the carry flag. Then you set the memory location for the next bit (by one instruction) and call the respective subroutine to swap the bit you want to access. Now you've got that bit in the carry bit and go on to the next location... and so on until the line is through. For instance, Mickey on the left has three possible positions, on bottom, in the middle or on top. If the player presses the "up" button, the Mickey line gets shifted upwards, on pressing "down" it gets shifted downwards, only that the last bit in the line gets re-set if it's found to be on after the shifting. The game code generally doesn't "know" the coordinates of any object visible on screen, it's all done by checking if a certain bit in memory is set. And there are more shift "lines"... two for the hose (one for small and one for big blobs), six for drops and fires and one for Donald on top. The fire shifting routine checks for each position if the corresponding drop bit is set, if so, both are cleared, a point is scored and the routine terminates. The routine shifting down the drops does the same. As for game variables, there are only a few controlling if there's one of the possible leaks, which game or demo mode is on, if the alarm is set, and as far as I can tell two counters for keeping the correct speed. But maybe there are some more which I missed because I didn't examine the complete code. Since the objects don't have coordinates in memory, all checks that depend on a certain location to be set or clear, such as collision detections, check the actual bit in memory... for instance, the routine that creates new drops checks all three possible locations of Donald to find out where he is and place a drop there. That way, they also go around the limitation of the CPU that indexed writes are very hard to do... with this game architecture, none are required, the closest thing to it is actually the routine that converts score digits to the 7 segments that are displayed for each number. This one uses an indirect jump instruction which loads the data byte to the PC. Keep in mind that the PC is not linear, but a pseudo-random shift register, which means that the numbers 0-9 get converted to addresses which are actually all over the place in that page. Oh, the total ROM in that chip is 2772 bytes (44 pages with 63 bytes each). I guess it's similar for other Game & Watch games, though much later models like Pinball and Super Mario Bros. might use a different chip, as may much earlier models like the Silver Series Ball, Vermin, Fire and Judge... there are more advanced models SM-511 and SM-512 supporting independent sound generation, more segments and more ROM up to 4K while the SM-510 has to generate sound writing 0's and 1's for each wave "by hand". On the other hand, there's a simpler chip with only 2016 bytes of ROM that may have been used on the first games. But still I suppose most Game & Watch games will have been programmed in a similar way, because you see some kinds of shifted strings of segments in all of them, with some of them going only one way and others going both ways.
- 3 replies
-
- 1
-
-
- Game & Watch
- Architecture
-
(and 5 more)
Tagged with:
-
i have been having problems with batari basic for a couple years so i've made no games because i cannot compile so i decided to make a very atari like game on a site called scratch https://scratch.mit.edu/projects/236564770/#player i was wondering if anyone wants to code this program for atari and send me the bin file and if possible you could add a score board and a lives.
-
It can be done in any coding language but i think assembly will be fastest. I'm looking for solution that is faster than ATARI basic which is 50-80 muls per sec and it have loss of precision :( How many times per second can 6502c multiply 10-digit number by 10-digit number without a loss of precision?
-
i am in the process of making a game and well i don't know how to make an enemy shoot i only want the enemy to shoot down and up according to player 0's y position can any one help?
-
Ok so I dont know if Im in the minority, but whenever I tried to learn batari basic I find them a tad confusing, like whenever i attempt to make something I just dont understand enough to make anything... But you know what I did understand, Atari Basic A Self Teaching Guide: https://www.atariarchives.org/basic/ One of the things that Random Terrain recommended that I look at before I tried Batari Basic. While I didn't understand BATARI Basic I feel like I under stand ATARI Basic very well. It felt kind a fun with the examples and with the practice in the book it helped really pound in the language and how to actually use it. Am I only one who thinks that Batari Basic could use this self teaching guide treatment as well?
-
I always wanted to know how software sprites worked in this demo. Here it is a dis6502 2.2.2015-04-06 zipped workspace of laser demo. I don't think i will be working on disassembling it anymore. Maybe someone will use it for something else. laserdemo.zip
-
Anyone feel like writing a MegaDemo? Well now you can! Here are two versions of an assembler that was used extensively for demo coding back in the day: http://www.pouet.net/prod.php?which=47999 http://www.pouet.net/prod.php?which=62372 (apparently this one includes a manual) If anyone knows of other assemblers that are good for this sort of thing, feel free to post links in this thread.
-
AtariX Hello everyone, my name is Iuri Nery, and a few days ago I started reading some tutorials at RandomTerrain to learn more about Atari programming, and so far I’m finding everything fascinating. I’m right now at number #16 of Andrew Davie’s tutorial (Atari 2600 Programming for Newbies). I’m learning a lot from it, and to learn faster, I needed to built something to help me testing the sample projects, that’s why I made this IDE. AtariX is a very simple IDE, but has a couple of features that can help novice users to get into Assembly programming: · Save/Load assembly files (.asm/.s); · Build binary files by pressing the “Export” button; · Test your games with 1 click; · Colored syntax for comments, assembly instructions, numbers, binary numbers and also for the labels from “vcs.h” (like COLUPF); Files included: · “vcs.h” and “macro.h” (unmodified); · DASM Assembler; · z26 Emulator; · AtariX executable; How to use: 1. Open the assembly file you want to test; 2. Put all the included files in the “include” folder; 3. Click on the “Play” button (you can also press F5); Credits: ; AtariX ; ------ ; Copyright © 2017 by Iuri Nery ; DASM Assembler ; -------------- ; Copyright © 1988-2002 by Matthew Dillon ; Copyright © 1995 by Olaf "Rhialto" Seibert ; Copyright © 2003-2008 by Andrew Davie ; Copyright © 2008 by Peter H. Froehlich ; z26 Emulator ; ------------ ; Copyright © 1997-2004 by John Saeger . This is not an advanced IDE or anything like that, just wanted to share it with you guys, I hope it can help someone. ps: I’m not an experienced programmer, so any tips are apreciated, also I don’t know if this is the correct session to post this kind of stuff. Thanks! AtariX_v01.zip
- 2 replies
-
- 5
-
-
- 2600
- programming
-
(and 3 more)
Tagged with:
-
People often complain about how the original Pacman had flickering ghosts, Sure, it's certainly a problem but at least I can understand why. It's because they only had two sprite reset registers and so they had one for Pac-Man and one for the ghost and would switch out which ghosts would display so they could give the illusion of multiple ghosts, which gives me another question, how where they able to get rid of this problem in Mrs. Pac-Man?
-
This Topic is intended for those who are willing to learn, assist in learning, develop and publish code using GPL, the Graphic Programming Language proprietary to TI 99/4A also known as the GROM Language. To ensure that one can start from scratch and try to dabble a few lines of code in GPL I will list the most basic things that are needed and then show you a very small GPL language program which fills the screen with the letter A. 1. Install python 2.7.11 (Do not install 3.5 as it will not work with the GPL emulator I will propose) https://www.python.org/downloads/ 2. You need an assembler for windows and good documentation according to the assembler chosen. Assembler: https://endlos99.github.io/xdt99/ Documentation : http://www.unige.ch/medecine/nouspikel/ti99/gpl.htm I will assume you install it in C:\XDT99 3. You need a great emulator to run your well crafted virtual cartridges which we shall be creating. Classic 99 is my favourite : http://www.harmlesslion.com/cgi-bin/showprog.cgi?search=Classic99 I will assume you install it in C:\CLASSIC99 4. You need some kind of Editor I prefer Notepad++ : https://notepad-plus-plus.org/ 5. Setting up your assembler > There are clear notes on how to have XGA99 up and running to compile your .GPL code but I will cover this step by step for those who hate reading a lot of material scattered all over the place. Install XDT99, I selected c:\XDT99 folder. Unzip the attached file (xdt99.zip) into C:\XDT99, you can choose a different folder but there are some batch files you would need to change later. This will add a new folder to the standard XDT99 called "myfiles" and also the python program files are in C:\XDT99 (.py files) Point the PATH windows environment variable to point to C:\XDT99 where the.py reside. Please edit C:\XDT99\MYFILES\G.BAT and MG.BAT to point to myfiles and classic99 according to the paths you chose. Please note that all the files you create should be named <filename>G.gpl Example c:\xdt99\myfiles\testG.gpl To compile just go into DOS c:\xdt99\myfiles cd c:\xdt99\myfiles and type G test Note that I did not type G TESTG.GPL as the G.GPL will be auto appended by the G batch file. if no errors just type mg test. This will move TESTG.BIN to CLASSIC99\MODS 6. The last step is to execute the newly created cartridge. Fire Up classic 99 and select Cartridge->User->Open .... navigate to c:\classic99\mods and select the bin file. The TI Program menu will contain the program called TEST in position 2. Have fun... In this post I will place code snippets and BIN files for all to try and enjoy. xdt99.zip
- 101 replies
-
- 3
-
-
- GPL
- Development
-
(and 3 more)
Tagged with:
-
Hi there! I try to find an overview and comparison of all mnemonics of all CPU TI made. I'm looking for a comparative table with all mnemonics for each processor with its addressing modes an opcodes, perhaps with additional descriptions like affecting status bits etc. Does anybody know of such a list? I'll be thankful for any tips.
-
So I'm tinkering with batari for the first time, and have gotten past the ENORMOUS headache of compiling issues to actually be able to make some neat little things. one of my sprites i.e. the player is even animated and looks awesome. I've got a second sprite however, that is making me go crazy. I am 100% new to coding in general, but this is something that I really want to successfully accomplish. Anyway.. the whole thing I want the main player to be able to do is chase mice and "munch" on them to earn as many points as possible before a timer runs out(I'll figure that out later) So far I've gotten my cat to be able to move everywhere flawlessly. the mouse just shows up right now and is chilling out. my question: How can I make it so that when the cat comes in contact with the mouse the player gets their points/ How can I get the mouse to "run away" from the cat and re-spawn when "eaten"? Forgive me for being a complete noob, but I'm at the point where I'm completely stuck, and google has run out of answers. The attached file is what I've come up with so far. Thanks!!!default.bas
- 7 replies
-
- batari basic
- batari
-
(and 8 more)
Tagged with:
-
Does anyone know how the RNG works on Bomb Squad? It would be interesting to know the RNG iteration algorithm, as well as how it generates 1-digit, 2-digit, and 3-digit codes for the game.
- 3 replies
-
- bomb squad
- random number
-
(and 3 more)
Tagged with:
-
Folks: Hi ho, Apple users. I have a few Apple programming guidebooks which I am putting up on Ebay. Some are already up, some more are going up today/this week. I play around with TI and Commodore, but not Apple, so I don't have a whole lot of use for them, though they are great books. Putting most of them up for around $10. Not really trying to make bank on these, just picking up a little cash for a few toys Santa seemingly forgot to bring. ^_^ I also have a random Tandy 1400HD power supply and a Vtech LCD Talking Baseball game up. Tandy PS is tested and working, but having no Tandy 1400HD, etc etc. Talking Baseball is ubercheese but the voice cracks me up. Auctions: Beginners guide to Apple II assembly language eBay Auction -- Item Number: 201013141026 Nibble Expresses -collected snippets and code for Apple from Nibble Magazine, 150-200 pages each eBay Auction -- Item Number: 201013138578 eBay Auction -- Item Number: 201013136901 eBay Auction -- Item Number: 201013074044 eBay Auction -- Item Number: 201013308513 eBay Auction -- Item Number: 201013307938 More Apple Secrets from nibble eBay Auction -- Item Number: 201013311895 (Edit - More added) Applesoft BASIC Toolbox eBay Auction -- Item Number: 201013314361 Basic Apple BASIC (Integer & Applesoft FP) eBay Auction -- Item Number: 201013312998 I'll be adding a few more books to the above in the near future. Tandy 1400HD power supply eBay Auction -- Item Number: 201006101600 Vtech talking baseball eBay Auction -- Item Number: 201011770776
-
Does anyone have the source code for Ti invaders (cassette version) or any other old classic games for the ti-99/4a?
-
Ok, added a couple monsters that I'll be using to test the various aspects of the Inactive List. I'll likely tweak it but for now it's ok. The Data byte for the slots is patched in and it will save to the Inactive list when that's implemented next version. Color of the object is usually hardwired into the object's data. That will probably work fine for most cases but if the color is read in as 0, it'll load whatever is in the Data byte instead. The application of such is used in the Hearts and the "gear" monster. Each monster has it's own AI. One will never leave the screen it's in. The other will bounce off of dead exits, but otherwise pass through the edge of the screen the same way the player can. It's movement AI is pretty simple but it's just for testing purposes. Also, the Heart Placer picks a random Data value which ends up giving it's hue (since it flashes the lower bits are meaningless!) however it then does a bit of modification on that Data byte and stores the result in it's HP byte - which is what determines how much HP/Power/Magic/Whateverit'scalledeventually you receive for picking it up.
-
- maze realms
- 2600
-
(and 1 more)
Tagged with:
-
I won't be getting the inactive list working with this release. To really be able to test that setup I'm going to need something extra. Monsters! (After all, monsters don't drop to the list!) So in preparation for the inactive list setup, I'm going to do a couple very simple non-animated test monsters. One of them will do nothing but bounce around a room, changing direction whenever it hits the edge of the game field. The other will run in a straight line unless it hits a dead exit. Hitting a dead exit will make it turn around. One monster, when destroyed, will generate a heart. I may alter it so it has a % chance of generating a heart. The other will generate the Black Key, which by that time will be set up a regional object. Some of the ideas I thought up tonight at work may require objects to have one more byte of data for misc info. It's use would be entirely dependent on the mob's AI. It may be necessary to add that variable to the inactive list as well. I believe there's more than enough ram on the cartridge to handle this. My weekend starts early so hopefully I'll have this sorted out and the next official version done before Sunday! (As it's way too cold to step outside for me without a real good reason!)
-
- maze realms
- code
-
(and 1 more)
Tagged with:
-
So after most of a week, I finally managed to replace the old room loader with the less compact but easier to read new room loader. Essentially a change in room format. It doesn't save as much space as the older one but you end up saving space on the code portion to load it. Which is good because the Inactive Object management is going to suck up some rom space when I get to patching it in. (Most of it is written, but not untested.) I also changed the "undefined" object flag for room objects to trigger on the Input byte instead of the Y coordinate. It was fine for versions up to now where either the object existed or it didn't. Things in the upcoming Inactive Object list however will have a Y value saved. They won't have anything in the Input byte however since that's not saved when they're pushed to Inactive. Nothing interesting has changed in the rom with this switch so I'm not going to release yet another binary for today. The only visual difference from a player's point of view is that I also fixed a glitch introduced when I changed the status bar. I made the status bar smaller, thus making the gamefield size larger. However I didn't change the values for the Maximum Y coordinate of the player before switching screens which meant if you got close to the bottom of the screen, it'd change screens before you actually touched the bottom. Nothing special here. Just had to fix the associated value in the constants file. What I WILL show off today, is one of the several freaky "worlds" I created by having bugs in the first few attempts at the new room loader. Basically info is being read wrong for the playfield but it can still be "explored". There are several dead ends etc however so learn where you can and can't go! There was one other "Weird World" that I saw but didn't think to keep a rom of it. It was actually larger than this one too. Ah well.
-
- maze realms
- 2600
-
(and 1 more)
Tagged with:
-
Ok, this should do for another micro-version. In this version I've redone the status bar. In this game the only things it will need is the player's magic/power bar, so I've removed the extra things. The color of the status bar (the blue part) will actually serve a purpose to indicate to the player when they step into a magic field. I'll be changing the default color to probably a gray color to indicate the absence of a magic field. This will be a function of room AI which I will be adding in a bit later. Also, I backported the cycle 73 HMOVE code I wrote for the new Action RPG code base which allows me to pull off the status bar's repositioning without the ugly h-bars. One sprite is repositioned right before the start of the power bar, the second is repositioned immediately following it. I do notice the gate of the castle seems to be moved. I don't recall changing it's coordinates in the init code so I'm guessing there's an issue with using the cycle 73 code. I'll look into that more and hopefully have it figured out and fixed by the next version. The status bar overall is vertically more compact because of these changes. This means the game field can be larger, which is something I've been meaning to do since before v0.018. Otherwise, all the other changes in the code are are speed optimizations. In some cases I only trimmed a few cycles off. In others I found entirely different ways to do things or realized a couple things were entirely pointless! (I use to zero both hardware sprites at the end of each frame up until now. Not necessary since if I just point their ItemSlot to FF, the code assumes they're empty.) I'm not entirely sure what I'm going to do in the next version. It's a toss up between re-adjusting/re-naming the item slots or redoing the room loader. Either of those two options will probably be time consuming.
-
Oh before I forget, here's the source for version 0.019. (20091113) I've already started in on optimizing what's already there. Some things run a lot faster, other things have waste trimmed. After I take another look through the code for "easy" optimizations, I'm probably going to start hacking away at the Status Bar. The only thing that Maze Realms is going to need is the player's power/magic bar so everything else is going to be removed. At the same time, I'll be centering the power bar since there will be no reason to keep it on the side of the screen. Previous source code versions, etc, are also available on my website.
-
Ok here's an updated rom for Maze Realms. (Previously "Action RPG") Mostly this just fixes up a few scanline glitch scenarios and an update to the held-object/drop-object routines for use in the new direction this old code base is taking. (I'll be taking Action RPG in a different direction later. I figure it would be best for me to keep working on this code now that I'm familiar with it again along with getting a bunch of ideas for it!) At any rate, the file names are being changed to reflect release date of the rom in such a way that all the roms will line up in a directory on their own! Year/month/day format. 20071027 was when I first released version 0.018. And then went on code vacation for over a year. Still using the same old Test Realm for now. I have to see about making the code run faster. Code can take too long as it is in some situations. I'm not sure if I'll work on that next or if I'll turn my attention to the display to update the status bar.
-
I fixed the glitch mentioned in the last post soon after the update. Not entirely sure what was going on but the bug was caused by good old copy pasta. It was testing one condition then setting a totally different one based on it and voila. Key-to-Heart glitch. Anyway, I likely won't do the next part today as I'm a bit busy with other chores, but the next task will be expanding the drop-item code so that it can detect when an object is out of bounds when dropped - and if dropped while out of bounds, it will be dropped in the proper room. If the exit is dead or wrap-around to the same room, the drop code will simply drop the object to the other side. (Currently I believe if I dropped an object out of bounds, it would become unavailable in the game!) This will work for the vast majority of rooms but it brings a little snag into play. what if you push the key outside of a castle? Right now for when the player exits, a special routine will run to move them in front of the gate. (Generally the Gate's own AI will do the check by looking for the character's position on the screen.) I think I can take care of this with a similar routine in the room loader. Dropping the object outside of a castle (or dungeon really, etc) will cause it to drop to the side of the screen in a place where the player would normally set off some AI to reposition them. Since it doesn't really matter where the object is in the room until the player enters it, we can do a similar trick in the room bank itself. That'll be the next trick AFTER the initial drop code modification. After that I'll consider "version 0.019" done. However I won't be calling it that. After reading over a thread that touched on WIP filenames, I've decided to change the format to a "title-year-mm-dd.bin" format. That way all the WIP roms will line themselves up. I'll post the old version 0.018 (renamed) and the new version at the same time for people who want to do comparisons without digging through the blog archive for the old one or going to my website to get it. Oh, I also think I have an idea for the life bar which will be redone in the following version. It'll be changed to a power bar instead and might implement a similar "powers" system to that used in E.T. In that your position on the screen will enable you to activate different powers. The powers that will be available, how the power bar is used, and how it will be notified to the player however won't be anything like it. I'm thinking of a bunch of ideas that would go well with this kind of setup and how to implement them in the game, but right now I'm too tired to actually write them down. I'm sure I'll remember them. *update* Finally finished modifying the drop code to handle out-of-bounds objects. Took a lot longer than it should have due to me typing on a branch by leaving out the space between the opcode and the label. This didn't cause an error as far as I could see. I'm guessing it interpretted the entire thing as a label or something... Anyway, been up too long this morning and have to get some sleep before work so I'll clean things up a bit tomorrow and try to post the new version.
-
- maze realms
- code
-
(and 1 more)
Tagged with:
-
It took a few days longer than originally planned, but I finally finished reformatting the old Action RPG code and it's dubbed Maze Realms now. Action RPG has a different code base that I haven't gotten too far with just yet. It's all good tho. So now that the insane levels of potentially inaccurate comments and the like are taken out, I've started the second phase. That being fixing some of the bugs I spotted while I went through the first time as well as reworking some of the existing code. For instance in Maze Realms there's no need to have a delayed-press-and-release to drop a held item so I took it out. I'll be needing that kind of code for Action RPG later but I'll just copy/paste it over from the older backups. There was also a couple of instances where I found buggy non-bugs... or would that be non-buggy bugs? It was a few instances of "lda $FF" being used instead of the intended "lda #$FF". It just happened to be that address location $FF held value #$F1. For the purposes of the code, it just needed to have a value greater than $80 that was not $F0. $F1 fit the bill so the code acted as it was suppose to. Glad I caught that as I was reading through it otherwise it could have really had me stumped farther down the road. The fire button now simply drops held objects. It has the side effect that a holdable object can be passed through without picking it up if you keep the fire button pressed. I wasn't sure if I liked that or not, but I can't really see the harm in leaving it that way. That only works if the object can be held and moved. Maze Realms, like Action RPG, will have instant-use items that activate on touch. Holding the fire button down won't affect them. It could be altered so all objects pass through the player, but we'll see how it goes. It'll just need a quick short-circuit based on the fire button's position in the object's collision code. Otherwise I fixed a graphic glitch in the first castle room where an extra line would be generated if the player tried moving up past the closed gate. The kernel is pretty tight in some instances and in at least one case there's no room for cycle penalties. The glitch occurred because the castle gate's graphic was lying over a page boundary. That made one particular scanline case use too much time, generating an extra line in the process. The next big scanline glitch occurs when you try to push a held object through the left wall. This causes a problem where the object's X position wraps around and the 2600 thinks it's over 200. The sprite positioner ends up waiting a LONG time since 200+ is outside the allowable 0-159 range and an extra scanline is generated. I'll be fixing that as well before I release the next rom. I already know how I'll be doing it. So yeah, the next version is just going to be a less buggy version of what I've already released. >_> After that's done, I'll be fiddling with the display code and changing the Status menu to be something far FAR simpler. Of all the things on it, the only thing I really want to keep will be the status bar. And if that's all I'm keeping, I'll probably consider centering it as well.