supercat

I put my sprite data at $F000, padded out to a multiple of 256 bytes, but arranging for the kernel to be page-aligned is definitely a good idea. I personally prefer to JSR the kernel, though, at least for the programs I've written where one sometimes has to do calculations that don't really fit between display and VSync. I'm currently reworking one of my programs to try to increase the time available for calculation; I haven't figured out how best to handle the frame counting, but the basic concept is: Kernel: bit INTIM bpl Kernel1 Kernel1: stx xsave inc fct lda fct kwt2: bit INTIM bmi kwt2 sta WSYNC lsr bcs mainframe lda #$42 sta VSYNC sta WSYNC sta WSYNC lda #[whatever] sta INTIM64 [forget the name] lda fct clc adc #1 and #$7F sta fct sta WSYNC lda #$00 sta VSYNC ldx xsave rts mainframe: ; Main display kernel goes here (nine cycles after the last WSYNC) ... lda #[whatever] sta INTIM64 ldx xsave rts maincode: ; Periodically, in a time-consuming loop: bit INTIM bpl $+5 jsr Kernel1 ; A and Y trashed; X preserved ; BPL target is here This would allow user code to execute during both vertical blanking intervals. The values loaded into INTIM64 would have to be chosen so that the timer would expire about 150-200 cycles BEFORE the target horizontal blank. The user code would then have to ensure that it checked INTIM every 100 cycles or so [with a 3, 4, 5, or 6 cycle penalty each time it did so depending upon method]. It would be possible to save code space at the expense of time by making the kernel return if INTIM was not yet negative and calling it unconditionally. The extra 12 cycles overhead would seem unduly severe, however.

Different vintages of Commodore 64/128 had different numbers of characters per scan line. My first machine had 262 scan lines of 64 cycles each. The replacement VIC-II chip had 262 scan lines of 65 cycles each. My Commodore 128 had 263 scan lines of 65 cycles each. The processor clock was synchronized with the character clock at precisely 3.579545/3.5 MHz. This is, interestingly, 16% slower than the Atari 2600's 3.579545/3 MHz. I don't know what the derivation of the VIC-20's clock was, though character clocks might have been 3.579545/7 and thus processor clocks 3.579545/3.5. Anyone know?

You're smoking wacky weed if you think the 2600 can do that. Generally, every scan line must be made up of the following items: - The playfield (background), which is 40 quad-width pixels wide, consisting of two colors (background and foreground). Use of more than two colors is possible, but will generally limit what else can be done. - Two player sprites, which are eight pixels wide and one color each. These may be shown at single, double, or quad width; if single-width, up to three copies may be placed at intervals of precisely 16 or 32 pixels [two copies may be placed 64 pixels apart by using wide spacing with the middle one missing]. The three copies may be different shapes OR different colors, but must generally share one or other attribute. - Two missle sprites, which are 1, 2, 4, or 8 pixel wide [selectable] solid strips. Multiple copies will be drawn if and only if the corresponding sprites are also shown multiply. The missles must be the same colors as their corresponding player sprites. - The ball, which is a 1, 2, 4, or 8 pixel wide strip the same color as the playfield foreground. Those are all the things you get. In a few cases, it may be possible to go beyond these restrictions slightly with very tricky coding techniques (e.g. Galaxian shows 7 copies per scan line of one of the player sprites) but they'd be a good starting point for any display-design mockup. Moving a sprite by more than 7 pixels between scan lines generally requires that there be a scan line on which the sprite does not appear. Further, it is generally not possible to move two or more sprites independently on the same scan line (if two sprites are moved in fixed relationship with each other, that can often be done on one line).

Bingo. If the balloon itself hits the wall, showing balloon-only for a frame won't cause any visual disruption, since the balloon-pop animation has no string anyway. And if the string hits the wall, showing balloon-only for a frame is a the right thing to do. So either way, show balloon only. Indeed, as I indicated, if you simply make it so that a collision causes you to switch to balloon only and start animating upward (but with the first frame drawn precisely where the previous frame had been) you shouldn't really have to worry about whether the balloon or string had the first collision since in either case the sequence: -1- Switch to balloon only -2- When balloon collides with anything, pop it -3- Disable user control and make ballon move upward each frame. should work fine. Note with #3 that if the balloon is being blown sideways, that may as well continue (with the balloon blowing diagonally). If the balloon drifts to the exit, I'd suggest having it drive sideways until it hits something.

Although the 7800 supports modes with 1 or 2 bits per small pixel, or 2 or 4 bits per large pixel, the ordering of the bits is different in the different modes. Consequently, the only way to show big sprites is to have data which is sized appropriately. If you're doing a Pac-man intermission, though, this is not a bad thing--a larger "smooth" sprite would be nicer than a blocky magnified one anyway.

I once borrowed the cartridge with no instructions (before the days of the net). I thought the graphics were neat, but couldn't really figure out what the "game" was supposed to be. So far as I could tell, one person selected someplace to hide and the other player had to search arbitrarily until he tried the place the first person chose, with no particular clues to go by. Was I missing anything?

There were some very good games for the VIC-20 (e.g. Rally X [mangled into Radar Rat Race], Omega Race, and Jelly Monsters [mangled into Cosmic Cruncher?]), but it really wasn't all that great as a gaming platform. The video controller had no sprite capability whatsoever, and the screen thus consisted of a (typically) 22x23 grid of character boxes. Each box would contain either an 8x8 matrix of pixels that were either a foreground color (one of eight, chosen per-character) or a background color (one of sixteen chosen for the whole screen), or else a 4x8 matrix of double-wide pixels chosen from foreground color (1 of 8, per-character), border color (1 of 8, screen-wide), background color (1 of 16, screen-wide), and "auxilliary color" (1 of 16, screen-wide). Most games performed all action in per-character increments. In Snakman, for example, the pac-creature and ghosts both moved in 8-pixel increments. Although some games worked fine with such constraints (e.g. Rally X) it generally made Vic-20 games "clunky". A few VIC-20 games used tricks to allow smooth motion, but the color restrictions often resulted in color bleeding which was impossible to eliminate [e.g. in Jelly Monsters, dots near the pac-man or ghosts would turn the color of the pac-man or ghosts in question]. The VIC-20 could certainly do many things the Atari 2600 could not; many things that were trivial on the VIC would be impossible on the 2600 (unless one was willing to accept an insane amount of flicker). On the other hand, the Atari could also do many things the VIC could not. Pitfall is not a terribly tricky cartridge from a graphics perspective, but it would be beyond the abilities of the VIC-20 to do a really good port. A few cartridges manage to use interesting tricks to work around the VIC's limitations (e.g. Demon Attack) but the approaches used there are pretty limitted.

The READY line on the 6507 freezes the processor in the middle of read cycles (only). For purposes of doing a STA WSYNC, this doesn't really matter since the next bus operation following the write to WSYNC is almost always going to be an instruction fetch (i.e. read). If one were to do something goofy like point the stack pointer at WSYNC and do a BRK, the three write cycles would happen immediately, regardless of the state of the horizontal sync, but unless one is trying to seriously torture-test an emulator I'd not consider that an issue. For the MARIA chip, however, it's necessary to stop the processor BETWEEN bus cycles, and to delay both read and write cycles. Thus, it's necessary to have a HALT wire on the processor which behaves differently from the READY line.

What's the best resource for finding a list of such opcodes, DASM's preferred mnemonics for them, and any side-effects or weirdnesses?

Cute game. If you have code space, one thing that might be a nice touch would be to have two death scenes: -1- If the balloon touches the wall, use the explosion as-is -2- If the string touches the wall, have the string disappear and force the balloon to rise until it hits something (whereupon the ordinary explosion would occur. Minor improvement, but such things can help lend polish to a game. If detecting the distinction between a string touch and a balloon touch would be hard, you could force the code to always do death-scene #2 starting with the balloon in its present position. If the balloon itself touched a wall, it would still touch after the string vanished and would pop immediately. BTW, if you can spare the cycles, a different-colored string might be nice too.

It is somewhat similar to the ground in Defender II, or the web in Krull, or a few other things, but I've never seen anyone use the triple-sprite feature with precalculated sprite shapes to produce a conformable zig-zag object. BTW, a somewhat similar technique which perhaps someone else can try coding up would be to use a 48-pixel wide sprite shifted one (or two, or 3) pixels per scan line to yield a 48 (or 24 or 16) pixel high full-resolution diagonal 'stripe' that ran the full width of the screen. Perhaps one could even construct a flicker-free 'mini-Zaxxon' game using such an arrangement.

No, actually. The Atari 2600 is basically limitted to displaying a maximum of 48 pixels worth of sprite data per scan line, or if you really want to push things 56 (or maybe 64) and there are pretty severe restrictions on how that data can be placed. The zig-zag shape maximizes the effective usable screen real estate over which these pixels can be spread. At the spot where the upward and downward lines of text join, the maximum width is 16 pixels. If the left and right texts scroll inward at one pixel per scan line, this gives a height of 8 pixels. If you were to try to "flatten" out the shape on the top, this would reduce the allowable text height. Further, even using unrolled loops, the calculations required to shape the text as it went around the curve would be too much for the poor 6507 to handle. Even on the Zig demo where I made things as simple as I could, there are only about 10 cycles left per scan line. BTW, in case anyone is curious, the Zig demo uses two bitmaps for the scrolling text: one for the upward edge and one for the downward edge. Some of the letterforms are quite noticeably different in the two bitmaps. I did this rather than using one bitmap and deforming it on the fly because (1) it's oodles faster [and thus actually doable], and (2) hand-tweaking the bitmaps for some of the letters greatly improves their appearance. A few letters deform strangely right at the "turn", but for the most part they look pretty reasonable.

It's interesting how some games get named as the "worst game ever" and yet have people defending them. Sometimes it's because the supporters have no taste; other times I think people give up on games as 'unplayable' even though they can be mastered with patience. I have yet to hear anyone come to the defense of Froggo's "Karate", though. I wonder why?

Here's a preliminary taste of my "zig scroller" routine. Still needs some improvements, but the display is unlike anything I've seen on the 2600. The top line is controlled by moving the joystick left and right; the next line by moving it up and down. The remaining five bounce at various speeds. Pushing fire will let the joystick move text faster, and reset will restart the top two lines in their default positions. I'll release some source code once I get everything improved to where I like it, but for now I'd be curious how well people can guess (without peeking at the code) how it all works. Anyone want to give it a go? JPZIG1A.ZIP

Here's a preliminary taste of my "zig scroller" routine. Still needs some improvements, but the display is unlike anything I've seen on the 2600. The top line is controlled by moving the joystick left and right; the next line by moving it up and down. The remaining five bounce at various speeds. Pushing fire will let the joystick move text faster, and reset will restart the top two lines in their default positions. I'll release some source code once I get everything improved to where I like it, but for now I'd be curious how well people can guess (without peeking at the code) how it all works. Anyone want to give it a go? jpzig1a.zip

Not so easy in some games where movement is tied to flicker rates. Skipping every sixth frame in such games would look horrible.

On older television sets, there is a fair amount of line-frequency ripple on the high-voltage circuitry, and this ripple couples through into both the electron-beam intensity and the scanning geometry. The picture will thus be a little brighter and a little wider during the active part of the line phase, and a little dimmer and narrower at the null. These differences are pretty slight, and if the line phase is constant, are not really noticeable. If the line frequency doesn't match the scanning frequency, however, the screen will appear to throb and undulate at a frequency twice the difference between the line and scan rates. Thus, if the line frequency is 60.0Hz and the scan rate is 59.9Hz (as it might be from a VCR) the screen will stretch and shrink every five seconds. Newer television sets don't have this problem, so nowadays frame rate doesn't really matter. But in the early days of television, matching frame rate to line frequency was important (a 10Hz difference would have been horrible!)

For NTSC and PAL, the TIA generates a chroma output on one pin and a grayscale code on three others. These four pins are combined with various resistors to yield a color composite signal. The chroma output is totally useless for SECAM (System Essentially Contrary To American Method), however. What the SECAM 2600 units do is take the three grayscale output pins and feed them into a simple color generator. Too bad they didn't mix the chroma output with an amplified version of the crystal input and amplify the result to get a grayscale signal. Colors would have been entirely different from PAL/NTSC games (chroma would set luma and vice versa) but the results should be somewhat workable.

What'd be the fun in that? One of the joys of the 2600 is seeing a new technique and then figuring out for yourself how it's done. Plus, in some ways my code is sorta icky. But I'll probably post it pretty soon anyway.

Thanks for those. They're kinda cute, though my approach shimmers less (for four of the colors, shimmer is pretty minimal) >:*3. I'll leave this thread to Boulderdash, and look forward to seeing it when it's done. Yeah, I sorta discovered my scan line count was way off after I posted it; I hacked down my code to get it under 1K and sorta oopsed.

Hmm... that's not quite what I had in mind. Check out the enclosed demo I just wrote to see what I was thinking of. JPDEM1.ZIP

I'll have to check those things out. I just wrote a cute little demo of a color technique that's a little different from what you're probably using; the color/BW switch toggles between 'stripes' mode and 'flicker' mode. For this engine, I think flicker mode is better, although given the amount of dirt in Boulderdash having non-flickering stationary colors is probably better. JPDEM1.ZIP

I just produced a cute little seven-color paint program for the 2600 using an all-new display kernel. The kernel displays a 16x16 grid of squares that can be black, orange, pink, yellow, or cyan, dark blue, or dark green. It can also display a red or brown cursor. To use the program, load the executable in your favorite cartridge or emulator. On startup, the drawing space will be preloaded with a demo picture and the cursor will blink in the upper-left corner. Moving the joystick will move the cursor (naturally). Pushing and releasing the button will change the color under the cursor. Pushing and holding the button while moving the joystick will draw with the color under the cursor. The color/BW switch selects flicker or stripes mode. The left difficulty switch selects between a brown and red cursor. Pushing reset will reload the default picture. Pushing select will cycle colors in the current picture. Pushing reset and select simultaneously (releasing reset first) will clear the current picture. The expectation is that this kernel should be good for puzzle games. The whole drawing program is just under 1kbyte. Note: First attempt was buggy JPDEM1.ZIP Second attempt--should be fixed

I may have come across as slightly disparaging in earlier posts, but as I view the constraint more as "76 clock cycles" rather than as finite RAM, I see that there's still a lot of challenge left. One thing I was wondering about: do you show the same colors in the same scan lines every frame, or do you change them? One thing that might work well, if it doesn't expand your engine to the point that it goes kaboom, would be to use interlacing so that you could show colors displaced by 1.5 scan lines each frame. This would allow 2:1 flicker instead of 3:1 and might thus allow for improved appearance. I do hope to see Boulderdash when it's finished--that was an awesome game though I still can't imagine how a 2600 could pull it off.

Write a 1k minigame 867963[/snapback] I'm planning on trying that, actually. My gorgeous title screen idea wouldn't fit in a 1K, though. Maybe I'll have to release my game as a 1K and 8K version. >:*3