I'm really not sure what I'll use this blog for so I should probably leave this blank, but that would require backspacing. Much easier to just hit a period and stop typing.
Not that there's much different between this and version 0.005, it's about all I'm going to pretty it up at this point. All I did was remove a few things here and there that weren't needed and were just messing up the code unnecessarily. I figured it was pointless to go through the display code right now as I'm changing/modifying it with the next goal anyway, which I'm hoping to have done by sunday night.
That next goal is going to be the status bar.
This will obviously cause chang
I refreshed the code back to version 0.010 and redid the modifications to the code to make things work. The weird problems didn't restart and I even fixed up the code a little better this time to make sure no jumping of scanlines was occuring when P0 or P1 was touching or crossing over the top of the gamefield. (too much time taken - in each of hte lines where I updated P0 or P1 via a modified Skipdraw.)
Then I tried altering the playfield again and noticed the exact same funkiness return.
*cough*
I'm glad I stumbled upon a thread that pointed to the mini-dig. While I've been there and poked around in the past now and then, I randomly checked Eckhard Stolberg's description of how VDEL works. That's saved me a few rewrite versions. But at the cost of needing to think about how this'll impact my upcoming display kernel. Hm.
Might work out. Might be hell.
In other "news". I think I've mentioned it before but odds are in the process of building up Action RPG's functi
And done. Mostly it seems a couple of the glitches that cropped up were just me confusing the meaning of some variables. And then "fixing" things that weren't broken. In the end I refreshed some of the code I was fixing and found the real culprit. (A comparison on the Heart AI and unnecessary checks on hardware sprites on the key AI)
Flicker works as expected although I can think up a few ways to help reduce flicker. Right now, for instance, even if the key isn't displayed on the scr
So I had all day to procrastinate on the display. I mean to work on the display.
Admittedly, for code I didn't get much done. I ended up reverting the main source code back to beta2 in preparation for the next display kernel attempt. Then I cleaned up the variables some and reorganized them a bit to make them a little easier to find (for me at least.) Then I sat down and thought about all the things I want the display to be able to handle in a single frame.
1. Ball display.
2. Sp
I got the animation mod working (although it wasn't being used - I'd have to modify the AI for that.)
The new code was displaying the objects properly at any rate. But I noticed some Bad Behaviour shortly after as I mucked about. Screen jumping. At predictable points.
In short, it looks like the Vertical Blank is taxed beyond capacity under some conditions (holding an object while pushing against walls was a sure way to do it if there were a few other objects on the screen) etc. I d
I started coding on the 2600 again recently. I have this horrible habit of starting it, dabbling with it, getting carried away with some aspect of it, then losing interest and dropping everything for months and months. Thus when I get back to it again... I end up not knowing what the heck I was doing.
So I start over.
Usually with some totally different idea anyway.
I have like 4-6 different game ideas in my head as a result, some more hammered out than others, for the most part wi
I use the stack pointer as an extra register during the gamefield zone scanlines, namely to keep track of the scanlines to generate - it's faster than updating ram itself. Problem ended up I was setting the stack pointer before the last sprite positioning subroutine call that I added in to the zone between status bar and gamefield. This corrupted the playfield that was intended then returned the stack value to "normal" so the screen would still generate the proper number of scanlines.
Noti
I won't be making version 0.011 before christmas. Had to reload from version 0.010 because at some point really messed up things happened and I didn't have the slightest idea where to start debugging the cause. Basically it went something like this. The collisions only test the outer missile. Something funky was going on that caused hte outer missile to somehow turn off randomly. And at the same time the inner missile was striped (horizontally).
Additionally, the playfield's color se
Ok got the new roomloader working. Here's a little map of the realm. I've moved the sprites to push them off the screen for now. They're not serving a purpose yet anyway.
You start in room 1 when you start up the rom. Room 2 is the only room right now that is using relative-exits. I had problems with it in the code at first so changed all the rooms to explicit then turned 2 back into relative to test. The problem was me, not the code. Basically I was adding the wrong thing to th
Spent about 4 hours today hunting the code for what was causing problems with the glitches. As per the replies I got in the Atari 2600 programming forum, the glitches were being caused by the routine I was using to clear main ram. It simply wasn't doing what I thought it was doing, and since it was copied code I didn't suspect it as a problem. Since I'm positive I copied that code with copy/paste, I guess I copied it from one of the chapters that had an error in it. The proper routine (8 byt
And so I now own Castlevania: Order of Ecclesia, and Yggdra Union. Hopefully I'll be able to contain myself and avoid further purchases until December when Ar Tonelico 2 is suppose to come out.
Working away at version for 0.013 and since I'm running away from the code I'll give a general idea what I'm planning on having this release do when I'm finished.
The display has been lightened up some already, but it's looking like trying to iron out timing issues with branches crossing page boundaries is going to be a nightmare. I did a manual count of the bytes to see how things would fall. As it turns out there was a branch crossing right on the boundary. When I did a little moving of
I decided the final Status Bar scanline size will be 20. The top 16 basically handle the useful info, but I'm keeping a few lines reserved for repositioning the sprites used in the status bar to be used in the gamescreen itself. Obviously that's going to be needed.
As such, the final version 0.008 looks slightly different from beta 2. I'd love to finish the status bar completely but until I master a hmove 73 routine it just isn't going to be. I have a potential alternative to it if it be
As the screenshot shows, I've fixed a couple of things from version 0.013 already.
1. The Object Manager is in place. This is the Real Deal. Although it will need a couple more tweaks and I'll probably try to make the code a bit more compact, this code is probably going to be used from this point on. It cycles through the list of existing objects, and selects up to 2 to display on the screen. If it finds 0 or 1, it'll make 1 full run through the list. If it finds 2, it'll also update it
I've begun moving room data into a real room loading procedure. I had a few issues to work out but after a few hours of wondering WTF was going on with the data that was apparently NOT what I trying to load, and finding a few errors in the code along the way (not that they would do anything to fix the situation apparently) I finally got it working normally again.
All I have to say is this.
BNE != BEQ
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;
... of budget!
Seriously, I have to beat this stupid spending habit I have for junk food and fast food etc.
It's not a good thing when the local Dairy Queen knows what the "Usual" is. Sitting down and just doing a few quick calculations kind of made my heart jump a bit, even as I reached for the diet cola.
And so hopefully I'll be able to sit down and write out a few changes to my spending pattern while allowing for other things to continue. For instance, I really have to
Nearly time to go sign the lease and get the keys for the new apartment (on friday). Haven't heard back from them, so that's a Good Thing. (The appointment to get the keys is already set as a given, so long as there were no problems with the application at which point they'd call me. And as they said before, they aren't expecting problems.) Later today when I wake up I'm going to see about making sure some relatives are willing to help me move my stuff over the last week of the month so to h
Here's the rom of the elusive pseudo-random bug. I tested it on the krok cart and while the data was wrong still, it remained constant all the time. Probably an effect of how the superchip is done on the krok.
To see the bug in action on the emulator (I've just been using Stella) start the emulator, start the rom. Notice the weirdness regarding the player. You should just be seeing a single copy of the missile sprite for the player in a squarish formation. Offhand not sure what the colo
With version 0.011 I've added/fixed a couple things. First of all the sprites are positioned properly. They're hardwired for now, and there's no mechanism to determine what sprites need to be displayed each frame, if any, depending on the room. There are no actual items yet!
There are, however, actual rooms!
The exits are working although it's not prefect yet. I still have to add the room exit info to the collision detection routines. So if you try pressing against a wall while wal
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
It's proceeding although I find the thing I'm having the most trouble with right now is fitting the code that would organize when to start displaying the ball or player and keeping track of how many lines of playfield remaining into the kernel. I'm going to have to step back and try to organize my thoughts on paper and see where I can reclaim some cycles or find a more efficient way to do some things. I'll probably think of something.
For budding 6502 programmers.
ldx #7 ; We load the Collision Pointer.
lda (SpriteP1_SpriteDataPtrLow),x ;
sta Collision_PtrLow ;
ldx #9 ;
lda (SpriteP1_SpriteDataPtrLow),x ;
sta Collision_PtrHigh ;
jmp (Collision_PtrLow)
This code compiles with dasm just fine.
But it is INCORRECT. To get the proper addressing mode, you must use the Y instead of the X. Something I keep forgetting to double check since dasm won't break down on me when it compiles. I just spe