Nope. This port (that's not even done yet, mind you) had me genuinely in the throes of turmoil with troubleshooting and debugging. Even now I'm still struggling after I overcame a massive flaw.
FIRSTLY, the game logic itself is entirely different than anything related to the normal Bejeweled. Instead of swapping pairs of gems in order to make a match, you (what else?) TWIST the gems clockwise into their matches. THIS itself already posed an extremely difficult challenge for me to pull off since a swap would be infinitely easier - spinning the gems would require setting up logic for rotation, the sprite for the rotator cursor itself, the recognition of matches, et cetera, et cetera.
So how exactly did I do it? Did I curl up and cry in the corner like a wimp?
Well maybe yeah I did. But it was just a LITTLE bit of ugly crying! Don't act like you wouldn't too!
ANYWAYS! Development of the game itself started with having to essentially re-learn 6502 ASM. Given that I already knew it prior to, but just needed a refresher, I got looking through my old documentation from 2019. I was just 11 at the time! (And boy, let me tell you. My handwriting was absolutely AWFUL.) Luckily my knowledge was simply buried underneath the sands of my memories so once I started feeling that flow again, I got to it right from the get go.
--------------------
The first thing I needed to do was set up a list of criteria. Obviously with Bejeweled Twist being released in 2008, it was GUARANTEED that I would not be able to include certain functions of the game, given that:
1. It is complex; it has 4 game modes, that being CLASSIC, ZEN, BLITZ and CHALLENGE. CHALLENGE mode itself would require having hundreds of challenge phases, which just wouldn't be possible with only 64 KB of memory. Maybe in the future if I learn bank-switching routines?
2. The original game has saving and loading which, with my current skill-set, isn't yet possible.
3. It also has a multitude of different gem types, some of which would be difficult at my current skill-set.
So, my initial criteria was simple; mainly to get the premise the whole game is centered around working. This was going to be a great challenge indeed. My first goal was to create a custom character set, as I wanted the high-resolution graphics mode that comes with it. (Also because I could not quite figure out the multi-color graphics mode when I started the project - but I'm too deep into it to undo it!)
Right here was when I initially created my character set with the jewels, and set up the rendering itself. I was quite happy to see that I could still load in my own character data! (Although with C64Studio, this frankly wasn't that hard. I just had to set up a constant at the start telling me which address has my character data, then set up at the very end the !bin path my charset binary was located.)
The next thing to do was get multiple other tiles made and get a grid of 8 gems by 8 gems up on the screen. At this point in time I wasn't concerned about function so much as I was about getting things generally operational. This was easy enough to do, though, and I got this. The tileset looks a bit strange for Bejeweled, but this was because at the moment I hadn't yet made the rest and used placeholder tiles from another game I'm working on. Then, I set up a randomizer for the board itself using the SID Noise initialization I set up in the constants; that being, Bejeweled sets up the board with a random amount of each gem on the board. Again, this was easy enough to do, but lord if I wasn't totally sidewinded once this initially-smooth-sailing period was gone.
At this point I was feeling pretty good about myself. I thought the rest of the game's coding was going to be smooth, clean, relaxing.
Well if that wasn't the most incorrect statement of the century then I haven't any idea what else IS!
---------------------------
It was at this point I wanted to get the actual rotation part of the game operational. I wasn't concerned yet with getting gem-gravity, matching logic or cascades to work (which was a catastrophic mistake as you'll see later,) so I turned my attention to the cursor system, inputs, et cetera. I went ahead and chose to use a sprite for the cursor, as it'd appear over the gems and could move independently.
As you can see, it was very hastily thrown together as my main concern was getting the thing functional at all. It was at this time I also set up a score counter (which didn't work yet because I hadn't yet created matching logic to determine when and where to give points...) and began coding in the actual rotation part of the main code.
This is where sh*t hits the fan.
I assemble the code so far, and immediately I notice something wrong - which I later discovered was a result of accidentally overwriting the character set I had JUST written INTO memory in the initialization routine. I left the character set back to $2000 to give myself some extra room. I'm sure you can see where this goes.
Unknowingly I had created a situation where I was 'limited' by the position and address I had given the character set. My current game code was set to initiate at $0801, which as far as I know is fairly standard, but also forgot to update the VIC register beforehand! And with the advancement of my game code, it was beginning to creep up - going from $1000, to $2000 (uh oh!) and before I knew it, BAM! It crashed right into the character set's data in RAM, started reading it as game code and wouldn't work!
I didn't yet realize, when I initially wrote everything in, that this was a significant mess up. But this wasn't even the biggest one - you'll see that here in a second. It took me a couple hours, maybe a few more than that, to figure out via process of elimination what it was I was doing wrong (because I stupidly had the console debugger closed on C64 Studio...) but eventually through lots of wasted time I ended up correcting it like I should've and set everything in the proper places so nothing got overwritten. It only got worse from here, as the game got better.
I then noticed the twist function stopped working at all - and I wasn't sure why. I now of course know this was because I had written an LDX instead of the LDA I had intended on using- which meant that my input for the FIRE button was being loaded from the register that had nothing meaningful to it inside of it - this kept causing me game crashes. Again, it took lots of time searching to figure that out and change that pesky little instruction to the one I wanted. At the time though it was driving me MAD!
--------------------
At this point, I rewrote the placeholder graphics and made them look like what the game was supposed to be; Bejeweled. I was happy with how they looked for now, and I'm not still concerned with adding any special effects. As you can see right here, it looked decent...
This is where that failure to write in the logic for the cascades in a timely manner REALLY came back to bite me in the ass.
Gravity and cascades were not working, as I never coded them in to begin with. I didn't think this would be that big of a deal, but it turned out to be an issue that STILL plagues me! I had to write in a routine to check for gravity, bring gems down, deposit new ones onto the board - and make no mistake, it was not (and still isn't) pretty to write - and it barely works. But I've made my current code so dependent on this section not changing that it breaks the whole thing to try and rewrite it. Allow me to explain what I think is going on;
When the fire button is pressed on the joystick and the cursor rotates your selection of 4 gems, the game scans the whole board for if any matches of 3, 4 or 5 are made horizontally and vertically. If it detects any, it clears those, produces a little Plink! noise, and if it's a 4 or 5 match, creates special gems to put on the board. 4 gems creates what is called a Flame Gem, and it explodes in a 3x3 Gem area and destroys those gems when matched. What I failed to account for was gravity, and cascading - that being when gems drop automatically into a line of 3, 4, 5 or more. This resulted in cascades being calculated and executed INSTANTLY - which took the 3x3 area it was supposed to destroy...
And takes a big chunk out of either vertical or horizontal bars of where other gems would have landed before the calculation completed.
I still haven't managed to figure out the true cause, not just speculation, of why or how this happens and for the life of me I still haven't been able to fix it, no matter what I do. But, at least it works... For now though, I've been directing my focus on polishing up some features, working on graphics and trying to figure out why my game won't play SID music no matter what kind of input I attempt to get out of it. I suspect I'm just being stupid again but if that changes I'll let you all know. Here's the current version of the game, updated for NTSC. I haven't tested this on an in-person system quite yet but once I get my SD2IEC device, I will do so.
As for the list of bugs I'm still trying to squash at the time of writing:
- Sound Effects seem to un-randomize gemfall - I think this has to do with the SID and it's noise generator?
Lightning Gems and Flame Gems take random chunks out of horizontal and vertical bars
Cannot get SID files to play no matter what kind of thing I do with them or the code itself
Holding down a direction on the joystick causes the game to stop execution - letting go continues it
Board starts out with no gravity - pressing FIRE starts game function properly
Score seems to be broken and tied to LEVEL for some reason I can't figure out
Level Meter does not work
https://drive.google.com/file/d/1_ul-cv ... sp=sharing
https://drive.google.com/file/d/1R9rsKR ... sp=sharing
https://drive.google.com/file/d/1A-7aLj ... sp=sharing
Download my C64 Covers @ 
