yllawwally

I thought the original programmers were Brice Poehlman and Gary Stark.

Has anyone ever found the original programmers and asked what they had hoped it would look like when finished?

It does exactly the same thing in version 3.9. If I change the C_KERNAL_HEIGHT to 181, memory location B5(181 decimal) will be misnamed instead. I'll PM the zip to you.

There is a bug, in version 3.7.2.0, where one of the memory labels is incorrect. I noticed in Tumulus. I have a constant called C_KERNAL_HEIGHT, it has a value of 182. Memory location B6 is misnamed as C_KERNAL_HEIGHT. It should be named E4_Health. In the symbol file it appears to be correct. I would upload the symbol file, but apparently I'm not permitted to upload this kind of file, file ext doesn't matter.

pimpmaul69 is correct. The reason you can put DC into an AC machine, is because to make the power plug cheaper, they remove some of the components, and place them in the console. Usually this is a capacitor and a bridge rectifier. An Atari always runs on dc, it's just that this model converts the ac to dc internal to the atari, instead of in the wall plug. So if you put dc in instead, you are simply converting dc to 5v dc. Which would use the exact same components, as 10v ac to 5v dc. You don't need the capacitor to convert the dc to dc, but it doesn't hurt. The only potential problem is that they could have used a pair of diodes instead of the bridge rectifier. If they do that then you have to use the correct polarity for the dc. However if you put it in backwards it shouldn't damage the console. If you leave it a long time, perhaps it would damage the power cord.

There are several big reasons they used asm. The basic language would have needed to be coded on a computer, which is a large task. The programmers at the time would have been more familiar with assembly. Assembly allows the programmer to know exactly what each step is doing in his program. With the extremely limited resources of the 2600, it was important to use every byte of RAM efficiently. The timing is also very critical, so that it is easier to get more technically impressive results by asm, instead of through any other language. Even other later machines used assembly as well. The NES was primarily programmed in ASM, as well. Most arcade machines of the 80's would have been in assembly as well.

Any of those 3 should work fine.

Is there schematics around for the Sears Video Arcade II? They are probably using a simple bridge rectifier. You could probably have a lower voltage if using a dc supply. Most likely the machine runs at 5v, with an additional 1.5 volt loss for the conversion. The higher AC voltage is needed because it fluctuates. Over voltage would probably be ok, to about 12-14 v. The old linear power supplies, need to have at least half of the current used, or the voltage would go up. Which is why when you measure the old atari power supplies, they always gave more than 9v, when not connected to the machine.

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

You can Demo Tumulus, if you like. It's currently playable, but not complete. Although I hope to have it complete before October. Unfortunately I can't go to the PRGE, I moved from Corvallis to Vegas. Does anyone know if there is going to be a Vegas show this year? http://atariage.com/forums/topic/213104-tumulus-2600/

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

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

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

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

Doesn't interlacing drop the frame rate to 30Hz, instead of the 60Hz?

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

I always though a chromadepth version of Asteroids would be great. Where you only hit asteroids that are the same color as the player's ship. I even bought a few pairs of the glasses, a couple years ago.

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

I was hoping to save counter top space, and put away the 2600. However it seems I need to keep both out, or buy a second 7800 and mod it.

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

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.

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

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.

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.

I've never opened it up. So I presume the shielding is still intact. I would open and tinker with it. But I would like it to display the way it would have, when released. The jr, I'll probably mod some day. Did technicians modify the 7800 like, they did the 2600?