Tumulus (2600)

[yllawwally]

Problem.binI tested out several of the revisions on a harmony cart. I can't replicate the problems. I had used an eprom when I saw the problem. Other than the Harmony using a little more power. I don't believe it could cause a problem. I will change the background colors to make it easier to see on the TV. And probably need to replace the RF cable. But those changes wouldn't help the weird issues I was seeing. Perhaps some kind of 7800 compatibility issue with my game. Although that wouldn't explain, why it worked on the Harmony. I'm going to burn a slightly older revision on an eprom, to see if for some reason on eprom it doesn't work, while it works as a Harmony bin.

[yllawwally]

I pulled the bin from the EPROM and compared it. It is identical. Maybe the voltage is low, and the 2600 can't read the EPROM properly. I don't know. I burned a new EPROM, with the identical version, and will see tonight if main player is messed up during game play.

[yllawwally]

I tried the new eprom, with the same problem. The graphics are messed up. The game play is still good. I tried on both a 7800, and a jr. The same rom on a harmony cart works fine on both machines. Are there problems that could be masked by using a harmony cart? I can't think of anything the harmony does that should make a difference. I played a few rounds of ghost manor. There were no problems with that game. The only thing in common is the PCB. I got the PCB from here a few years ago, and mounted a socket on it. I've used it before for older versions of the game. Would somebody mind burning the ROM on an eprom, and testing it. I'm not really sure what to check for at this point.

The ROM on the 7800

 

The Rom on the JR

 

Harmony on the 7800

Edited July 10, 2013 by yllawwally

[yllawwally]

I finally figured it out. I did something incredibly stupid. What put me on the path, was that I thought I burned the wrong ROM, when I went to verify the ROM was burned properly. Every time I started the game, the corruption was slightly different. I was trying to determine what the emulator and harmony had in common. Then I noticed one of the times I started the game, the red eyes appeared immediately. Those are on a timer. The only way they could appear immediately is if the timer was set over 240. So I looked back at my code. What I had done was accidentally remove LDA #0, from the clearmem procedure. So I was initializing all the memory to some random number that happened to be in the accumulator. Stella probably sets it to 0, and the harmony might do something similar. So I added the LDA back in, and burned the ROM again. Presto weird ROM issue fixed.

[yllawwally]

Adjusting collisions. The game will have 2 different pits. One that's large, that can't be jumped. And a smaller one that you are immune to, while on the horse. Horse provides 2 benefits, immune to small pits, and you can hold knife always out. The screen moves faster, when on the horse. When the red eyes are above there is a random chance of the horse running off. The larger pit will knock you off the horse. However this introduced a bug, that whenever you start the game you lose one point of health. So you start with 7 instead of 8. It seems that a hit is always detected. There is still graphical corruption on far left and right sides of the screen. OK, not really that far. Magic still not implemented. No work has been done on end level baddies. Unfortunately there will be very little difference between levels, other than land color change.

[+stephena]

I finally figured it out. I did something incredibly stupid. What put me on the path, was that I thought I burned the wrong ROM, when I went to verify the ROM was burned properly. Every time I started the game, the corruption was slightly different. I was trying to determine what the emulator and harmony had in common. Then I noticed one of the times I started the game, the red eyes appeared immediately. Those are on a timer. The only way they could appear immediately is if the timer was set over 240. So I looked back at my code. What I had done was accidentally remove LDA #0, from the clearmem procedure. So I was initializing all the memory to some random number that happened to be in the accumulator. Stella probably sets it to 0, and the harmony might do something similar. So I added the LDA back in, and burned the ROM again. Presto weird ROM issue fixed.

 

Stella has a 'ramrandom' commandline argument to specify how to initialize RAM that might have helped here. Currently, the option is only available from the commandline (or by editing the config file), but the next release has it accessible in the debugger.

[yllawwally]

I will have to edit the config file, so I can have that going all the time. Thanks for the info. Is there a way to get the scanline count on the game screen. I thought I had done it once, and can't figure out how to do it now.

Stella has a 'ramrandom' commandline argument to specify how to initialize RAM that might have helped here. Currently, the option is only available from the commandline (or by editing the config file), but the next release has it accessible in the debugger.

[yllawwally]

Is the accumulator set to a random number, when ramrandom is enabled?

[+stephena]

Is there a way to get the scanline count on the game screen. I thought I had done it once, and can't figure out how to do it now.

 

Press Alt-L while the emulation is running.

 

Is the accumulator set to a random number, when ramrandom is enabled?

 

No, ramrandom sets RAM only (both zero-page, and any other RAM the cart may contain). I suppose I could add a similar option to set the CPU registers (perhaps cpurandom??).

[yllawwally]

Thanks Alt-L is exactly what I was looking for. Looking at my config, I had the ramrandom there. The clearmem routine copied the Acc to every location, upon closer inspection. I don't think the 6507 has a guaranteed state on power up. Other than the state of the Program Counter.

Edited July 16, 2013 by yllawwally

[yllawwally]

Changed some of the logic. I was using a rolling counter to determine when to move. I'm still using the counter. However it now runs a different routine on each run through. Basically slices of code. On Slice 0, the mountains are moved. Slice 1 enemies move, etc. There are 8 slices. This helped with the screen jitters a little. It also introduced a problem of trees appearing in all 8 lanes. However this was probably always a bug, just being masked. This was probably what was causing the player to have 7 life a start. He would hit a tree which would disappear by the time, the screen was drawn. Another bug I just noticed is attacking and moving at the same time add an extra line. Which would make a real TV jump. It's easily seen if you're on the horse, and have the fps displayed.

Tumulus_12.bin

[yllawwally]

The player is no longer hurt at the start. I simply moved him to the right, so he wouldn't hit the tree. I may leave the trees intact. The screen should no longer bounce. Fixed a bug where the player wasn't knocked off the horse.

Tumulus_13.bin

[yllawwally]

Monster graphics corruption is now fixed. This was a headache because of my stupidity. I use vdel so that I can work on the monster graphics anytime in the loop. However I had put together the color and graphics in my mind as inseparable. Of course they aren't, so I thought I had graphics corruption. But the real problem was color corruption. I had this idiotic thought that the color was delayed as well. Just today I had the epiphany that color has nothing to do with the sprite, duh. Then I was able to move the color to a different part of the kernel, which fixed that issue. I improved a little bit on the player graphics problems. Although he still gets issues on the right hand side. They are less pronounced. You can see the issues most easily when on the horse. Also, the screen goes to 263 lines, when the player overlaps the monster. This is an issue, with the logic. I'm just taking a little too long. I need to rewrite some more of the collision stuff. I'm a little stumped on how to fix the player issues. It takes alot of time to do both the player and monsters in color.

 

Tumulus_14.bin

[+stephena]

Is the accumulator set to a random number, when ramrandom is enabled?

 

The next version of Stella will have a 'cpurandom' option that randomized the A/X/Y/PS CPU registers.

[yllawwally]

Thanks Stephena, that will help. It's nice to have identical behavior in all circumstances.

[yllawwally]

I made a few more graphic tweaks. The player graphic is almost fixed. There is an issue on the far right where on some lines his color is changed, on one line. His sword is missing on a couple lines on the far right, and doubled up on a couple other lines. To see this, you need to use the horse, and move as far right as possible. Overlapping monster and player no longer causes an extra line. Began adding potion effects. To see it you would need to manually alter a memory location. However it causes all the monsters to change to a fire palette. Change memory location FD to something over 4, to see the effect.

 

Tumulus_15.bin

Edited July 25, 2013 by yllawwally

[yllawwally]

Now you can use the potions. Pushing the player 2 fire button, will use a potion. Although if you hold it down in less than a second all 3 potions will be used up. I'm not sure I like that. I may need to put a delay in so that a second potion won't be used when the first is done. If you had 3 potions the effect of the first will last for 4 screens, which is only 1/15th of a second. Or maybe just slow down the potion so it takes 1/2 or a full second to use a level 3 potion.

 

 

Tumulus_16.bin

[yllawwally]

Fixed a bug in the potion routine, which caused the number of potions to go crazy. Extended the time the potion is in effect, and the amount of damage dealt. Now using a level 3 potion causes 7 points of damage. A level 2 cause 5 points of damage, and a level one causes 2 points of damage. So if you're at level 3, and use all three potions, you could cause 14 points of damage to each creature on the board. Changed the level loading a little, again. Uses more ROM, but will help with adding level bosses later. Allows creature to start at the exact x, on different lanes. Before I couldn't choose the exact timing of when they entered the screen.

 

Tumulus_17.bin

[yllawwally]

I've been a little busy, and haven't got as much done the past couple days. I'm trying to add the first boss. A will'o wisp. This creature will jump to a new lane when slain. And has to be defeated several times. However his graphics are giving me problems. For some reason I haven't figured out yet, he only looks proper on lane 8. On all the other lanes we looks like a deformed fighter. Once I get him added, I'm going to add the ability of monsters to grapple the player. So that when they are grabbed, they are damaged until the player can wriggle out, while the player can't damage them, until freed. Potions won't work during grappling, you need you hands free to fight or use magic.

 

Tumulus_18.bin

[Gateway]

Please keep working on this! It sounds like a fun adventure game. The 2600 needs more of this type of game.

[yllawwally]

Please keep working on this! It sounds like a fun adventure game. The 2600 needs more of this type of game.

Thanks for the encouragement Gateway. I've been busy at work the last couple weeks. So progress has been slow. However I'm getting back to my regular routine, and will be working on it again.

[yllawwally]

I haven't worked on this for almost 3 weeks. But finally I've had a little time to get back to work. The will o wisp, bug was a simple one. I had the graphic crossing a page boundary. I think the sword bug is fixed now. Although I had to introduce a different bug to fix it. Now the color is off by one line, when on the right side of the screen. This is a good trade off for now. Always having the weapon work seems a little more important than keeping the color of his arm correct.

 

Tumulus_19.bin

[TrekMD]

Just downloaded it to give it a spin. Thanks!

[yllawwally]

Just removed one of the lanes for the monsters. So now a max of 7 monsters on the screen at once, and 7 pits. However this frees up 5 bytes of RAM. But more importantly well let me shift the monsters on the field. I had originally thought, that having them in lanes would be best. But this style of game, really needs the monsters to be able to chase the player up and down, as well as left and right. Now I can shift the whole playfield. The only difference a player should see at this point, is that there is a safe area at the bottom of the screen, where no monsters will ever go. In future versions, this won't be a safe area. The monster will sometimes move down so that there is no safe area, no matter how many monsters are on the screen. No bug fixes in this version. There are still several outstanding bugs. Player color gets messed up. The will o wisp break into 2 monsters, not sure what causes that? No form of mandrake should ever hurt the player. Also the horse shouldn't damage the player.

 

Tumulus_20.bin

[yllawwally]

Added some more bug fixes. Added a few more bugs. There are actually 7 monster lanes now, last time there was only 6 visible, but monster could exist invisibly. Which caused you to be stuck. The only way to kill invisible monster is with potions. Not much was done in the past week. I know how to fix the snake and tree issue, it will take nearly an hour of work to fix however.

 

;FUTURE FEATURES

;make giant ogre as level 2 boss

;Need to add grappling

;need to differentiate levels, probably different colors

;maybe monsters shouldn't attack when on fire

;BUGS

;Moving and attacking causes an addition line to be added

;1 line of player is discolored

;will o wisp becomes 2 creatures

;snakes don't damage player

;tree doesn't damage player

Tumulus_21.bin