EricBall

Very good. I don't think I ever managed to get past the second level on the original Skeleton. Note: The difficulty switches are multi purpose. When the game starts the left switch controls the number of Skeletons per level but during the game it turns on & off the radar. The right switch at the controls whether you start with 49 or 99 life, but during the game it controls whether the Skeleton movement speed gets reset when each Skeleton gets killed or only at the start of each level. I haven't played Skeleton+ in a while. My son (3) would turn off the game on me. But I think I've killed off over 20. The basic strategy with Skeleton+ is to avoid getting hit. There's nothing worse than limping around with < 10 life left knowing the next wrong move will end the game. Use the radar to keep the Skeleton in front of you (unless you are running away, waiting for your gun to recharge). You can move as fast as you tap the joystick, so running away is always a good idea. The Skeleton tracking logic will not always follow you around corners so use that to your advantage. You can run through the Skeleton, though you will take damage. If you ever get hit, run! Never assume that shooting a Skeleton will kill it. Trying to go toe-to-toe with the Skeleton is a losing strategy. Although it only requires a second to reload, that is more than enough for the Skeleton to catch up to you. You also can't simply hold down the fire button. You have to press fire after the one second reload time. I gave some other hints back when I first released Skeleton. Those are still applicable, but with the original you had to try to avoid situations where the Skeleton could get the drop on you (like intersections). That is somewhat less important, but avoiding getting hit is still paramount.

As per Manuel, you could connect something to the joystick ports. The program would need to test & reset the collision registers and set the RIOT registers appropriately.

Which platform?

I agree that on 650x (or any other 8 bit CPU) words are 16 bits. But, the same cannot be said if you are talking about the x86, or 68xxx, or some obscure processor like the PDP-1 or the GI CP1600 used in the Intellivision. Anyway. For the purposes of this tutorial, word = 16 bits and 16 bits = word.

One word of caution: although 16 bits is often called a word; a word is not always 16 bits. One of the ways each generation of computers gets more powerful is to process more bits at once. So the 6502 is an 8 bit processor because it works with 8 bits of data at once. The Pentium is a 32 bit processor, and 64 bit (and higher) processors exist. The number of bits in a word is often related to the processor. Byte and nybble (or nibble) can sometimes be different than 8 and 4 bits, but only on processors with oddball (10 or 18) word sizes which are very uncommon these days.

Artists and anyone else interested in the 7800 (even lurkers) is welcome. Skeleton+ is one of the homebrews included in the Activision Anthology for the GBA and can be pre-ordered from Aspyr. According to the website, it is currently being duplicated and should be released in December.

Just to elaborate on the reasons why more bits than necessary may be used: [*]If the two values are independent (e.g. X & Y positions), so they are typically updated or used/tested separately [*]Standard word lengths are easier to manipulate (e.g. 1 byte = 8 bits) [*]Combining/extracting multiple variables requires multiplication/division, which is typically not efficient (e.g. position = Y * 160 + X, or X = position MOD 160) [*]Room for expansion/enhancement

Note: 3 & 4 have two answers depending on whether you are describing width & height independently or not. Bonus marks if you give both answers.

Yeah, Nate fixed some typos in the stuff I added into the previous version and backed out a change I had made to the display list parser (null & extended header detection)

sgn(x) = -1 x < 0 sgn(x) = 0 x == 0 sgn(x) = 1 x > 0

This is a routine which should be fairly easy to translate to 6502 ASM. drawline( x0, y0, x1, y1 ) ax = abs(x1 - x0) ay = abs(y1 - y0) sx = sgn(x1 - x0) sy = sgn(y1 - y0) cx = x0 cy = y0 vx = ay / 2 vy = ax / 2 if ax < ay then if ax == 0 then vz = ay else vz = ax endif else if ay == 0 then vz = ax else vz = ay endif endif while cx != x1 or cy != y1 plot(cx,cy) vx -= vz if vx < 0 then vx += ay cx += sx end if vy -= vz if vy < 0 then vy += ax cy += sy end if wend plot(cx,cy)

I would like to invite everyone interested in programming the Atari 7800 to join the following mailing list: Users can subscribe to your list by sending email to [email protected] with 'subscribe' in the Subject field Although the majority of Stellalist consented to allowing 7800 topics to be included, I am hoping that a dedicated list will spark more interest. So whether you be an absolute beginner with questions or a crusty old hand with knowledge and experience, sign up and contribute.

I would like to invite everyone interested in programming the Atari 7800 to join the following mailing list: Users can subscribe to your list by sending email to [email protected] with 'subscribe' in the Subject field Although the majority of Stellalist consented to allowing 7800 topics to be included, I am hoping that a dedicated list will spark more interest. So whether you be an absolute beginner with questions or a crusty old hand with knowledge and experience, sign up and contribute.

I would like to invite everyone interested in programming the Atari 7800 to join the following mailing list: Users can subscribe to your list by sending email to [email protected] with 'subscribe' in the Subject field Although the majority of Stellalist consented to allowing 7800 topics to be included, I am hoping that a dedicated list will spark more interest. So whether you be an absolute beginner with questions or a crusty old hand with knowledge and experience, sign up and contribute.

evil thought learn the 6502 on the KIM-1, which has a six 7 segment LED display and a hex keypad. Build your own KIM-1, which uses a 6532 RIOT, just like the 2600 VCS. For some bizzare chance of fate, I won a KIM-1 programming book, "The First Book of KIM", at a junior high computer programming competition. I quickly figured out that the book was useless without the computer. Though it was interesting to read about some of the things they made this simple machine do - including a version of "Hunt the Wumpus".

Nope, although there are a lot of similarities, there are some major (and minor) differences - starting with 16 bit X, Y & S registers. Of course, what make a computer/console isn't the CPU but the other chips.

z26.log - yes it's huge but it give lots & lots of info. (A helper application is also being developed to make it easier to work with). I believe that PCAE alos has some tracing capabilities, along with an add-on to Stella in development. The problem, IMHO, with programming other computers & consoles is you spend most of your time figuring out what BIOS calls to make instead of coding actual 6502 routines. That BIOS knowledge can't be re-used on other platforms.

This is probably more to do with your TV. Since the 2600 CPU is trying to execute code which doesn't exist it isn't causing the TIA to generate VSYNC or a valid frame.

The problem is most 6502 based consoles and computers are very different from an I/O perspective. So although you can re-learn 6502 using a C64, 90% of what you will need to learn will be C64 specific. And I have to disagree with Thomas, the 2600 isn't a bad console to use to learn the 6502. Although it can be difficult to program the 2600 to do many things, it is reasonably easy to get it to do something. You don't need to write very much code to persuade the TIA to start kicking out graphics. (Whereas you need a lot of code to set up the DLL used by the 7800 for example.)

I haven't done any Lynx programming, but I've done lots of C and ASM (6502 and others). A big benefit of ASM programming is it gives the programmer almost absolute control. There is no translation layer (compiler) making decisions on your behalf. C is also built around function calls and typically uses stack-based local variables. Both are not that efficient for the 6502 (JSR/RTS=12 cycles). And unless the Lynx C compiler has been optimized for the Lynx/6502 there may be other inefficiencies (starting with the size of int).

The 7800 has 6 different graphics modes selected by three bits: bits 0 & 1 of the CTRL register (read mode) and bit 7 of the second byte in a five byte graphics header (write mode). WM RM1 RM0 mode details 0 0 0 160A 4 color, 2 bits/pixel 1 0 0 160B 0 1 1 320A 2 color, 1 bit/pixel 1 1 0 320B 4 color, 2 bits/pixel 1 1 1 320C 0 1 0 320D Modes 160A, 320A and 320B are straightforward - the palette is given in the display list and the bits in the graphics data select one of the colors. Modes 160B, 320C and 320D are more difficult to understand (and use) because they mix the graphics and palette bits. See the 7800 Software Guide for a description of these modes. Because the Write Mode bit is contained in a graphics header, it could (theoretically) be changed "on the fly" to allow some graphics (e.g. backgrounds) to be more colorful than the rest. It would be interesting to know whether this was ever done in practice. However, this does mean that you will need to stick a 5 byte header into one of the display lists to set the Write Mode bit. (It doesn't have to be on the visible screen, so it could be part of one of the hardcoded null display lists.) 160A is a standard 7800 graphics mode used by many games. The graphics header selects one of the 8 palettes and each pair of bits (76,54,32,10) selects a color, with 00 being transparent. 320A is also simple to understand - again, the palette is given in the graphics header and each bit determines whether a pixel is on (color #2) or off (background or background). 320B is the same as 160 except it has double the resolution and the bits are in a different order (73,62,51,40). It should be noted that all of the 320 modes have some limitations. First, the 320 modes are more like doubleres 160 modes. Although the color resolution is 320 pixels per line, the sprites are still positioned the same (effectively 160 pixel resolution). The 320 modes are have a quirk when it comes to transparency. Both halves of the singleres pixel have to be 0 for transparency to work. If only one half is 0, then that half will be the background color instead. With a little care, this can almost be used as an additional color. (Setting bit 1 of the CTRL register (kangaroo mode) causes color 0 to be background instead of transparent in all cases.) Finally, the 320 modes can cause color artifacts because the pixel frequency is the same as the color modulation frequency. The 7800 game Tower Toppler uses this intentionally and with great effect. An alternative is to set bit 7 of the CTRL register (colorkill) which suppresses the colorburst causing the graphics to be black & white.

See Session 13: Playfield Basics for my comments about the VBLANK control bits and some other comments about VBLANK usage.

I'd say that homebrews are started from scratch, possibly using routines and ideas from other works. While hacks and hackbrews are modified versions of existing games (to a lesser or greater degree). It's kinda like music: are you sampling a riff, or re-interpretting the whole song. Just to clarify: Skeleton was programmed from scratch. I wasn't even aware of the two or three first person maze games for the 2600 when I started. Any similarities between Skeleton(+) and other 2600 games is co-incidental. There are other games (like Space Instigators, I believe) where the gameplay is similar to another, but where the code is unique. (Question: do Jammed and Crazy Valet share any code?) For me the difference between a hack and a hackbrew would be whether the creator made changes which required disassembly & re-assembly.

See A 7800 hack request over in the Hacks forum for some possible starting tools. For pure graphics hacks, the first challenge is figuring out which mode(s) the game is using. That will give you the bit to pixel/color mapping. Just like a 2600 hack, the color (or palette on the 7800) will require some disassembly to change. (And disassembling is non-trivial.) But I'd really prefer to see other people take up the challenge of programming the 7800 rather than make a "Kill Dr. Phill".

Made a bunch of tweaks and a fix to the thrust & velocity tables. (Thanks to Rob Mitchell for pointing out that shots down didn't go straight down.) Changes (based on your feedback): - decreased gravity - increased thrust - decreased top speed - increased speed of rotation - decreased shot speed and range I've also played a bit with the PDP-1 SpaceWar! under MESS, and I found the thrust very low, even lower than my previous version. I simply found it very difficult to fight gravity. Although my version may be more "arcade like", I think that makes it more fun. Some other notes: - Due to how the 7800 works, I will not be able to duplicate the Expensive Planetarium in the 4K version (not saying there will be a >4K version thuogh). I will however resist temptation to make the background something other than black. - Just like the original, touching the singularity will destroy the ship. (Although my version will have a larger collision area than the absolute center.) - The current version only allows two shots total onscreen at once, with a third shot replacing the first. This is a temporary side effect. I haven't decided how to handle shots yet. (I'm also not inclined to limit shots or fuel, though I have a wicked idea for hyperspace if that gets implemented.) Oh, found a different PDP-1 Spacewar (via Google Groups)- a punchtape image! Uncompress the attached file into the mess/software/pdp1 subdirectory. Select PDP-1 then the spacewar.rim file in the MESSGUI and press Ctrl-Enter to load (this takes a while). pdpspacewar.zip