Mord

Same here. I always fantasized wether a 2600-on-a-chip could just double the TIA circuits; Copy&Paste, there you are. Heh, even 4 audio channels then! No clue what efforts where required to *mix* the visuals though and obviously the (hardware) collission detection wouldn't work anymore... I'm sure clever use of sprites would probably allow sufficient hardware collision detection. For instance, just make sure P0 on both TIA's were drawing the player (or both Missile0's etc) then both TIA's would have the same thing to look for. Of course this means you'd have twice the registers to update and we're all aware of how much time we have to update all the registers we currently have on time. Myself I'd have added a register to HMOVE the playfield registers.

I copied over the code I've been working on to fit as much of the setup code into as few lines as possible for the vblanking. Here's what it looks like in stella. Looks the same in z26. Sprites are fine. unlinked and all that as they should be. Haven't tested for their correct scanline yet but it should be. I still have to add code to set up the sprite's reflection (if needed) and size. (which would also adjust the sprite's coordinate for drawing with the position-a-sprite routine) But what's bugging me is the playfield. For the record, the routine kernel is suppose to be using the Standard Adventure-type Castle Room data. The data hasn't changed but for some reason things are messed up. Too tired to locate the glitch now however, I'll find it in the morning. *edits* But because I had to confirm something for myself, I changed the test room to the No Playfield version. (Mostly used for testing screen boundaries and checking sprites out) ... So yeah. It's pulling data in from somewhere it shouldn't be, or the wrong data is being pulled in the ram locations as it's loaded... If page boundaries can cause problems like that, then maybe that's the cause. I'll explore it more thoroughly in the morning. This time for real.

Seems every time I finish a tiny milestone, as each version tends to be, I get a kind of rush. Of course this means much procrastination for a job well done. At least I spend that time -thinking- about the upcoming goals for the next version. So while it's already been a week I'm getting back to the editor. Work is a little heavier right now up until christmas but I'm sure I'll get a few things done before Christmas Eve. Goals for Version 0.011: 1. Patch in Eric's faster double-move routines for the horizontal tests. (Done!) I've tested the double-subtract in the different situations it's likely to be encountered. (normal collision testing + hitting left-edge of the screen during collision) and both seem to be handled properly. I was worried about the carry assumption not holding, but where I handle that situation with the screen clipping no problems surface. 2. Make Sprites repositional for the Gamefield rather than using left over settings from StatusBar. (In Progress) The code is written, and takes up 4-5 lines. I haven't patched it into the main source yet however as I'm still looking for potential bugs. I'm always overly cautious like this. What I have written -should- work however and it uses up just about every free cycle that would otherwise be wasted in the calls to the PositionASprite routine. That is, the routine is called near the end of a scanline to minimize unnecessary deadtime. This code positions P0 and P1 regardless of if they're used. If a sprite isn't to be displayed on a frame then it'll draw a null object. Same effect as if there's nothing there. It also sets up the VDEL for the sprites, handles the changing of the colors, using default colors for the player if a sprite isn't to be used for P0 or P1, updates the CTRLPF register with our Shadow copy since settings between Playfield and Statusbar aren't always going to be the same, positions the ball and enables it if necessary, calculates sprite height (would be necessary if flickering different sprites with the same hardware sprites) for skipdraw, sets linecounters I currently use, and clears collision latches just before the gamefield begins to avoid corrupted collisions caused by the status bar. There's likely some extra things to add in there if I can squeeze it in. Such as setting sprite attributes. (flipped, copies/size) but I'll look at that more over the weekend. 3. Ensure the proper positioning of P0 and P1 so it's appearing on exactly what line it should - no one off errors. (To Do) Right now it's -working- but as I've said before I'm fairly certain I'm not positioning them properly on the scanlines. It's just going to be a matter of looking at what's in place and then testing new Y positions for the sprites, then making alterations until they're perfectly positionable. 4. ORG the Display code and move the Status Bar code above the logic code. To at least minimize instances where the code messes up due to page boundary issues. I'll handle this last after all the modifications are done to the display for this version. Would hate to do the ORGing then find a few modifications threw things out of sync again. Those I think are the main goals I have set for this version. If I don't get distracted, and if I don't run up against any major setbacks, I'm hoping to have it finished by monday.

Almost worked although had to change the sbc's to adc's it seems. This left me with: (After my extensive comments being added to help my primitive thought processes ) lda SpeedXf; load SpeedX fractional. asl ; double it. (So we now have double the fractional portion in A. bcc NoOverflow; Was there overflow? (didn't need to pre-set/clear carry.) clc ; clear our carry for addition. adc PlayerXf ; <-- add playerX fractional to the fractional speed.. sta PlayerXf ; <-- store the new playerX fractional. lda SpeedX ; <-- load SpeedX (Never more than 4-8) rol ; <-- rol for double instead of asl works in this case beca.... ZOMG!!!! ; THE CARRY GOT SET PROPERLY!!!!!! (only good because we know SpeedX < 8) sec ; set the carry. (as we know it won't be.) bcs Finishing ; <-- skip NoOverFlow section. NoOverflow: ; <-- asuming no overflow occurred. adc PlayerXf ; add sta PlayerXf ; lda SpeedX ; rol ; Finishing: adc PlayerX sta PlayerX When the sbcs were in there for the branches, we ended up with the walls being sticky when trying to push against them. You can tell from the comments added what tricks I didn't realize could work. ... Looking over the code again, we can probably save some more by removing the sec... (And in fact the sec probably throws off the addition when I changed the sbc's to adc's.) Since we know the carry will always be cleared due to the low value of SpeedX... The subtraction variation for moving in the other direction doesn't work unfortunately. With addition we can add the two numbers in any order, but the order does matter for subtraction (7 - 3) != (3 - 7)! So we can't have SpeedX(f) in the A register, we need PlayerX(f) in there. Hm. can't post attachments in replies so can't show what happens. Essentially with the subtraction method given, when you try pushing against horizontal wall (like the bottom of the screen) instead of sliding against it as you move left, you end up moving right. (moonwalking? ) Interestingly tho, if you try to move sideways, the ball ends up acting like a solid wall and pushes you - but stops pushing you and passes over if you stop moving. Thanks for the help! I've modified my move-right routine for it. Every byte I save now could mean a feature saved later. *grin*

Hm I never even considered using Vblank during the screen itself. Colors have to be altered for the menu anyway so I can probably do a fade to vblank type of effect in the lines just before it.

Ok optimization done for now. I think I could probably save a few more bytes in there yet but it's ok for now. Plenty of CPU cycles saved overall. One additional concern to look out for reared its ugly head with this version. The Status Bar routine is extremely tight for timing. To the point where if it's positioned so that one of it's branch operations crosses a page boundary.... To fix that, I've got it ORGed. I'll have to remember to ORG the display code as well so those things don't crop up unexpectedly later on with the more complicated kernel. So now that this is out of the way again, I'm going to return to the display code yet again. At least this time I don't have to reconstruct the entire thing from the ground up to add additional functionality. In version 0.011 I plan to make the sprites truely positionable rather than have them use the left over settings of the Status Bar. There will be Ugly Black Bars introduced but there's nothing I can do about that until I learn how to write an efficient (and reliable!) Cycle 73/74 HMOVE routine. It's on the To Do list... just... conveniently pushed further ahead. I'm also going to look through the code and make sure that the sprites are vertically positioned properly (something I'm sure is not being done just now) and that I know exactly how many scanlines are being generated for the playfield. It should be 172ish. I hate 1-off errors. I'm also going to start looking into the sound registers at some point between version 0.13 and 0.20. *nod self* For that I'm going to examine Paul Slocum's music kit 2 which I downloaded ages ago. As to if I actually use that kit or use it as reference to writing something else is anyone's guess... but it's probably safe to assume I'll use it as-is.

Of course, this means saving compared to how I use to do it. To maintain player movement while they're trying to push along a wall as they move in the collision tests I have to take into account wasted frames and on successive direction tests jump further to make up for lost time. Since horizontal tests are done first, to test movement in the horizontal direction I double the speed prior to moving. Originally I just went through the full 16-bit addition sequence twice. On average that would take up about 80 odd cycles due to the generalized functions I used in it. Those functions are still in the rom but I'm not using them for player movement/collision anymore. I can use those for moving less frequent movement. (monsters/items notably. For the rare couple of items that the player will actually be able to move around with I'll have the item refresh it's X/Y with an offset from the player's X/Y instead of calculating it's movement separately. That should be faster...) Anyway this is what I did for the Move-Right test. I tested it in the rom and it seems to work reliably. IE: Far more efficient than what I was doing. The subtraction routine (moving left) however is still a bit icky. Right now I just skipped out with putting the subtraction in a tiny 2-pass loop. Still more efficient than before but I'm hoping to think up something similar like the below. ; Horizontal Move Test ( Moving Right ) ; This forces a double-step in the right direction. clc ; 1, 2 ; This part handles double-addition of whole part. lda SpeedX ; 2, 3 ; Realistically "SpeedX" will never be very high, normally 0-4 at most.) asl ; 1, 2 ; so there's not going to be any carry flag to worry about. adc PlayerX ; 2, 3 ; sta PlayerX ; 2, 3 ; ; we can assume the carry is still cleared. lda SpeedXf ; 2, 3 ; asl ; 1, 2 ; bcc .MovePlayerHorizontal_Skip1; 2, 2/3; inc PlayerX ; 2, 5 ; clc ; 1, 2 ; .MovePlayerHorizontal_Skip1 adc PlayerXf ; 2, 3 ; sta PlayerXf ; 2, 3 ; lda #0 ; 2, 2 ; adc PlayerX ; 2, 3 ; adds any carry left over to PlayerX. sta PlayerX ; 2, 3 ; ; 35-41 cycles.

God of War is fun. I don't own it but played it several times. It's on the To Get list at some point but not until I have a bit more cash to spend on games. The only reason I don't really like the Greatest Hits packaging personally is that the red spine clashes with the majority of my games. In the end if I have to buy Greatest Hits packaging of a game I want to play or do without, I'll get the game.

A possibility. I'm not entirely sure why what I did to the rom seemed to fix it in the end. But when I get back to the display in the next version to verify everything works the way it should I'll definitely keep that in mind.

The screen no longer rolls on hardware when using my Gemini. If anyone runs it on other 2600/7800 models and finds it still rolls the screen, leave a note? (If for no other reason than I know I'll have to come back to it.) Attached is a rom. While the code has been optimized somewhat it is functionally identical to the version 0.009 release except it works on hardware. The problem looks to have come from how I terminated the visible portion of the screen right before entering Overscan. I moved the code to activate VBLANKing from the Overscan to right before it since I needed an extra WSYNC in there. I may alter that setup again later when I go back to the display to make sure everything is displaying on all the right lines and exactly the right number of lines are being generated. For now however, it works. So the rest of version 0.10 will be continuing the optimization. I've found plenty of things already to cut down on time and rom. That being said there are still some big time wasters that can be redone better. Those are next on the hitlist. Some extra effects have shown up in the new code as well. Not only does it take less time, and seem to be more reliable, but depending on how I apply that code I can alter the effects of player/playfield collisions.

So there's nothing wrong with the actual code as far as I can tell. The problem of it dropping a scanline seems to be based on how it exits the timer-based overscan section. Enabling or disabling the various demo subroutines alter how the extra line is dropped obviously, but so does adding nop's and/or WSYNC's right before it enters the: ; ------------- Enter Overscan Logic Above ------------------- DisplayOverScanLoop lda INTIM ; 2, 3 ; bne DisplayOverScanLoop ; 2, 2/3; wait for Overscan timer sta WSYNC ; 2, 3 ; finish waiting for the current line jmp StartOfFrame ; 3, 3 ; at the end of it. For instance, adding a sta WSYNC + nop right before entering that gives a fairly stable-looking scanline count in z26 - except when I push against a vertical wall (as I try to go left or right) at which point it alternates between 261/262. Alternately, if I just remove that nop and hit a WSYNC prior to entering the code above, the screen appears to ALWAYS give out a 261 count - but turns full-circle and gives a constant 262 so long as I'm moving in ANY direction on the controller. (regardless of if it hits a wall or not) This is with the demo programs off of course. ... *turns them on and checks hardware* Ok... so z26 tries to tell me it's giving a solid 262 (I don't see a blinking 1 in there) but at the same time it's still rolling on hardware. Is there something special about timer-based overscan/vblank's that I'm not aware of?

I'm convinced that the cause of the hardware-rolling is not in the logical section. I swapped out one of the big time-wasting functions in there with something that did the same task in a third of a scanline. I see no change. More importantly however is that according to stella's scanline count/frame, we have it outputting exactly 262 scanlines MOST of the time. Under various conditions which I'm still trying to track down, the scanline count drops, rather than increases, to 261. So.. commented out the 3 demo functions. They alter the player speed, alter the player HP, and move the ball. The screen remains stable while I move around with 2 recreatable exceptions. 1. If I try to touch the very bottom of the screen. (I'm guessing I'm generating 1 line too little in that case as it shortcircuits and avoids the AfterPlayer zone. That should be easy to fix.) 2. If I try to crash against a wall horizontally, the screen will start rolling so long as I keep trying. Interesting enough it won't start rolling if I try to hit it vertically. Naturally, if I try to hit diagonally it'll roll since it'll see the horizontal collision. But why one line LESS in any of those cases? Bottom of the screen I can understand. For the horizontal test though? Perhaps version 0.010 will just be finding the cause of the rolling.

Final "release" of version 0.009. It does everything I set out to do for this version. *> Displays 2 sprites on the screen. *> Playfield is striped instead of solid. *> Ball functions as an extension of the playfield in the form of a positional vertical bar. *> Player is a little more "refined" - more out of timing necessity than on purpose, but still. With respect to the display routine, there's a few things I still need to examine to make sure they're working properly. Mainly to make sure that given the valid range of Y coordinates that it positions the sprite on the proper line. I'm quite sure that's not working properly right now, but where I'm positioning them in the middle of the screen for now, that's not important. I'll save that for version 0.011. Additionally, I don't actually have the sprites positioning themselves horizontally. That'll be added for version 0.011 as well. Just have to make better use of the lines between the Status Bar and playfield so that I can add the routines in. This will generate Ugly Black Bars, but no helping that for now. For now the sprites use the left-over horizontal position of P0 and P1 from the Status bar. This is why one is a double/quad sized sprite while the other is normal and why one is moving. It doesn't show in the screenshot, but the Ball is blinking while it moves from left to right. This is because I decided to use bit 0 of the Ball_X variable to indicate if the ball is to be shown or hidden. The demo function is just incrementing that value, resetting it to 0 if it hits 150. Fun thing is, due to the way I'm currently doing collision detection, the ball won't hinder X movement while it's blinking like that. It does hinder Y movement. I'm changing how I do collision detection with version 0.010 so I don't know if this kind of behavior is of any use to me. Finally, for Sprite display, I had 3 choices to choose from as far as I could think of. 1. lsr the offset generated in Skipdraw prior to moving it Y to be used. 2. Count Scanline Pairs instead of Scanlines. 3. Interleave the sprites. I went with option #3. There isn't enough time to squeeze a lsr in the busiest lines of the kernel. And counting scanline pairs needed additional calculation to determine what scanline it should be on for the scanline pair. (The lsr seemed cheap by comparison.) Interleaving the sprites required no special code or additional cpu cycles during the kernel. The trade off is that it's going to be a nightmare keeping track of the sprites manually once there's a lot of sprites. If I get that far and find it impossible to keep track of them by hand even with the comments and labels I can probably resort to writing some small program to import/export sprites. Importing would generate the .byte data tables, premixed with the necessary labels and comments. Exporting would take a sample of interleaved .byte data and convert them to an easy to read txt file for editting. I'm rusty at C/C++ but with a bit of help from friends who code in C far more often than myself I'm sure I could do that. So. Version 0.009 finally done. After several betas and some wtf's and one refresh of the source code. Before I go ballistic on the display code, I'm switching back to looking at the display code. Partly to see if it's actually causing the screen to roll on real hardware or not and definitely to redo the collision detection. I'd have to redo it eventually anyway because it's not 100% foolproof. Randomly I'd find it'd still let walls grab players and hold on to them until you shut off the rom. In the real game that wouldn't be much fun. "Yay, beat the boss final-DAMMIT!!!" The way I'm thinking of right now feels like it would be far more efficient in time and rom-space. I suspect most of those glitches are caused by the AlterPlayerSpeed demo which wouldn't exist in the main game anyway but since changing speed is something that can happen in the real game it could still happen in the game itself.

Well gee. I wonder why the heck my test item here would never show. Item_Heart .byte %00000000; ........ .byte %00000000; .xx..xx. .byte %00000000; xxxxxxxx .byte %00000000; .xxxxxx. .byte %00000000; ..xxxx.. .byte %00000000; ...xx... .byte %00000000; ........ Excuse me while I put my head in the oven. So anyway. Once I actually filled in those magic zeros. ... Something started to display, but not the entire item. At first it looked like it might be upside down, but closer examination looks like lost lines. *tests* Ok, maybe it's both. AH! The scanline counter! Skipdraw is dependant on the number of lines remaining, and I've been decrementing the lines EVERY scanline. For some reason I thought I was being smart. Obviously this is going to omit every second line of the sprite, since they're updated every second line. Additionally, the lines that are skipped will alternate depending on what line (Even/odd) the sprite starts on. So I should be decrementing the scanline count after every scanline-pair (So after hitting up skipdraw on Line2, before starting line 1 of the next pair.) I should be able to fix this now. Version 0.009 incoming. *edit* Incoming probably tomorrow. Counting scanline-pairs doesn't seem right either.

Hm. Do I still have that emulator handy. I can easily get it if not. I'll see about giving it a shot after I fix up the sprites. The next version update after I finish 0.009 will be pure optimization anyway. I can think of better ways to handle the the collision detection already for instance.

I cracked out the Krocodile cart and made a multicart of various games, including what I've done so far for Action RPG. I don't know what's up with it but for some reason the "Adventure" types that I had on the cart (Action RPG included) all rolled. The TV is fairly new, which could potentially be the cause. I was using a Coleco Gemini (Since it's the only atari 2600 type that I have that actually works well. ) and the three games that showed rolling were Advent, Avalon, and my own. Avalon didn't roll quite as bad. After starting the game it'd only roll every every second or two. The other homebrews seemed to work fine. hm. Perhaps I should look into the cause of this now - although if anyone else with a CC2 or Krocodile cart wants to try it on hardware and let me know how it goes... *edit* Specifically, with Advent it doesn't play at all. While for Avalon it rolls but except for certain conditions. For instance if a dragon bites, then the screen stops rolling until it starts chasing you again - and there's at least one room where it doesn't roll at all. *edit again* The emulator is too forgiving. Now to see why it's outputting a full 10 scanlines more than it should. (For Action RPG) I'm sure I did something stupid somewhere.

Thanks to vdub_bobby I fixed the ball routine so that it no longer pokes over the top - and it doesn't wait until when a sprite is suppose to start drawing before working. To keep timing in the HBLANK however I had to modify the way the player appears. Instead of being a pure strip we now have a dual-colored box! The colors naturally changing based on the colors of the sprites currently on the screen. Doing this caused an unnoticed semantic bug to stare me in the face. Notice the extra thickness of the bottom? That should not be like that and in fact it's only like that half of the time. The stripped color of the playfield made it easy to find the cause. The problem was in the StopPlayer line. All 3 branches of this section are suppose to fall into the appropriate AfterPlayer Zone after completing one line. However the "Line2" variant, which is responsible for testing the LinesRemaining to the zone and branch to either UpdatePlayfield or NoNewPlayfield lines jumped back to the StopPlayer versions. This caused it to do one more line of displaying the player's outer box before jumping properly to AfterPlayer to turn it off. Beta 2 actually has this fixed. The only problem now is with the sprites. I must be using SkipDraw incorrectly which would cause it to either never trigger (always skip and load #0) or it's reading the wrong place in rom that just always happens to have 0's... And I don't know what it could be. If it's loading from somewhere else in ROM it should end up loading $FF's instead of 0's since in my experience so far with DASM that's what it seems to stuff into unused bytes. And I don't have any large segments of 0's placed in the rom. But I know it's at least triggering at the right time - roughly. The delay we saw in the previous version when the ball's VDEL was taking 30% of the screen to turn on? That was the line that one of the items -should- have started displaying. I hardcoded one to start drawing at (40,40) in the gamefield window. (Status Bar lines aren't counted.) The other was due to start at (130,130) but obviously we wouldn't have noticed anything special with that one. Guess tonight I study the math behind Skipdraw. I also have to double check the VDEL settings for P1 and P0 to make sure what I have set is still valid now that I've moved the GRP1 and GRP0's. At worst I'd just have to switch them around. Here's the fixed beta2 for version 0.009. The only thing left to do for this version is fix the sprites so they'll display properly.

A quick look at the code verifies it too. I'm going to need to alter some things in the scanline again it seems although I started to realize the need for that a while ago. Of course with the modifications to the PFColor alteration the registers were no longer fighting so it shouldn't be hard to do. Now if I can only figure out exactly how skipdraw is working. I thought I understood it, but the lack of the test sprite images displaying proves me wrong. *edit* And looking briefly at the code, it appears I am missing writes to GRP0 and GRP1. I had modified them for fitting the writes into HBlank, but then afterwards removed it so it was in the visible screen again. At least it means there will be fewer edits to make when I move the GRPx's back into HBLANK tonight.

Ah bugger. Looks like it's back to the code for me. This shows I'm somehow avoiding to write to GRP1 or GRP0 until so far down in the line when it should be writing to it alternately every scanline regardless - even if it's just a #0. Saw a miss in the initial write to GRP1 that followed the ball setting for instance and sure enough... Where I see it trigger almost 1/3 down the screen, that -should- be where one of the objects begin to show (Neither do at present, going to look into that tonight after I clear up the ball.) Tankye. This gives me something to look into.

Could someone explain to me how the ball Vertical delay works? VDEL for P0 and P1, if I read the mini-dig correctly, works by writes to GRP0-A causing the contents of GRP1-A to be copied automatically into GRP1-B and vice versa. So if VDEL was turned on for P1, you'd get the delay that way... But how does the Ball work? I've done a bit of testing with what I was doing and VDEL is indeed the cause of the ball triggering like 1/3 of the screen lower than it should. (I was hoping for a single scanline later but... )

Still ironing out bugs but it's starting to take shape somewhat. Sorta. This is what happens when you forget to actually copy your new display code into the source. So I copy it over again and fix the remaining label bugs and the like and I get: I didn't alter my Playfield data for the double-scanline kernel. As a result, stretched vertically. When in and changed all "F" sized zones to "8" sized zones. to fix the stretch. Edited colors and made sure the BGCOLOR was being set. (that was omitted in init2.) Items are not showing however! I also had to add proper vertical delay decisions. However, after adding that, there's still no change. Since that's the part that rely on skipdraw I must be using it incorrectly. Time to re-examine exactly what it's doing.. *update* For now, I decided to get the ball working. I knew that wasn't working simply because I had it turned off and it wasn't set to position itself yet. Now the problem with that is that there wasn't really any time to turn the ball on in the kernel itself without hacking something. (A potential option.) So I thought I'd just turn it on in the line above it! 290s_d6a.pdf.zip Bad idea as you can see from the discolored portion of it sticking out over the top. (That portion is actually still in the StatusBar, or more accurately, the buffer between the two.) So why don't I turn on it's VDEL I said! Surely that'll turn it on in the next scanline right?! Apparently not... So... That means I don't really know what triggers the VDEL on the ball. I was -not- expecting it to trigger that late into the screen. Asking in the programming forum for clarification on what triggers it.

My brain is frying but that's ok! The code is starting to take shape. Been spending most of today analysing and editing the PrePlayer branch. The rest of the code is just a copy/paste + minor editing affair I believe so as long as THIS looks like it'll fit in the scanline properly the others should as well. (And I want to make sure PrePlayer is perfect before I copy/paste otherwise it'll mean a lot more editting later!) As a bonus to me I added a check for screen termination that will end up in all the zones and is already figured in to the timing. No more "special cases" like I hacked into the last version. This is good as otherwise the code wouldn't fit in a scanline properly in the later segments. (the extra tests would kill the timing!) So hopefully the next entry I make will actually be Version 0.009. *update* Timing is too tight for this room display kernel so I'm limiting the ball. Ideally I wanted to be able to move the ball around and have it turn on/off in such a way so that it could simulate another player. That may still be possible but I'd have to rearrange a lot of code and it isn't strictly necessary for most of the rooms. So for the Basic Room display the ball is regulated to being a solid bar going the full length of the screen. The room data will be able to position it horizontally at any pixel and set it's thickness. This is good for blocking off the side exits rather than using missiles like other games. The initial code is written and while I think it's possible to pull off I have no idea how how long it's going to take me to fix the bugs I'm sure to encounter. Right now browsing the code repeatedly, fixing things as I see them. Some would get caught by a compiler but others would take a while to find if I jumped to the compiler right now.

I've been trying to build up the scanline pairs for the first stage, the rest of it after that is generally an issue of copy/paste with a few modifications. I was topping out in cycles again so looked for ways to remove things from the kernel without removing anything from the kernel. I think I managed to do that although it cost a couple bytes of ram. By doing this it also freed up a lot of color selection choices for the playfield alterations. As a result, hopefully I'll have version 0.009 written and if nothing else in the debug stage this weekend. *update* Now started on writing the display code proper. Got a long weekend, so in amongst cleaning out the game collection to see what works and what doesn't. (I'm not quite as Pro Quality as my apartment tells me I should be ) I may take the Model II genesis down to the local pawn shop if I can confirm it works and I have enough spare connectors for my Model I genesis and the like. A few other odds and ends that might get traded in as well. I noticed they had a "Heavy Sixer" for sale down there, but after getting a closer look at it, it looked to be a CX2600 instead. Not too surprised I guess. I may just trade those things in for some more 7800 and/or 5200 carts depending on what they have at the time. I'm already up to 8 games for the 7800. I don't see them very often. As for the mentioned saved cycles above, I was altering the playfield color slightly in the hopes that it'd stand out a little more in the room. So we'd have 2 colors altering instead of just one for the entire screen. Is it really necessary? Not really. But darnit I wanna see it. lda PFColor eor #00001100 sta PFColor This is what I was doing every scanline. This format would keep the two altering colors the same hue but just vary their lum values slightly by toggling the same bits back and forth. I had bit 1 kept at 0 to make sure I could set it as a 1 and then use that for enabling missiles and the ball. That restriction saved the need of setting up the register since I always enabled the missiles or ball immediately after setting the playfield color. (Can't vdel the missiles after all.) By adding a second byte of ram, I could define PFColor_Even and PFColor_Odd instead of just PFColor. I could then set those two colors when I load the room and simply do a lda PFColor_Even or lda PFColor_Odd based on which of the two scanlines I'm in for the 2-scanline kernel now being used. from 8 cycles to 3. I know later on I'm going to end up with ram issues. Luckily in this game most items and monsters aren't going to be as ever-present like they are in certain other games.

That's nothing, even after reading it afterwards I'm still reading it as Grand Theft Auto.

Indeed, I've been reworking the display to use a double scanline kernel to make use of vdel. Although typing this reply reminds me it -is- a double scanline kernel now... so some of the things I was worried about probably don't apply to it anymore. This frees up a register if nothing else. This kernel is really a leap forward for me.