supercat

Each byte of data represents one column of seven dots; seven bits the dots, and one bit to mark whether a column is the last one. Characters are one to five columns wide, and the shapes are thus represented by 1-5 bytes. Each byte in the "string" shows where that character's data starts in the shape table. What more help do you need?

I wonder what the best way to handle "copy-protection" issues would be? It may be possible to make money on a popular game for a popular computer even if 90% of the copies out there are pirates, but on a comparatively obscure console that's not going to work. I have some ideas for how things could be implemented, but I'm not sure what would be best.

In many cases, I think one should evaluate what a sound chip can do if there will be periods of 1,000 cycles or more during which one is not allowed to write to it. Many sound chips can do marvelous things if one is willing to babysit them constantly; even the Atari 2600 can do nice four-voice music with a five-octave range (15.75KHz sample rate), if one doesn't mind spending 60.5% of the CPU cycles on EVERY scan line processing the audio, but for the most part such techniques of sound production aren't practical within a game. Both the SID and POKEY have unique abilities; the SID's filters are unlike anything on any other machine, and the POKEY's four-voices cannot be matched by the SID's three.

If each pixel is subdivided into 15 sub-pixels, then for hue values other than $00, about half of those will be lighter than the other half. For one hue value, the light ones would be first; for the next hue value there would be one dark, then half light, then the rest dark. There is thus some control over where to place the brightest part of the pixel. If it were possible to set the hue for a single 320-mode pixel, such ability could be used to achieve high resolution when viewing stuff on a monochrome screen (on a color screen, chroma artifacts would make it impossible to see fractional pixels). Unfortunately, the hue is set for a pair of 320-mode pixels; consequently, while one could make the left half of a pixel lighter and the right half darker, or vice versa, or the center two quarters lighter and the left and right quarters lighter, or vice versa, there is no way to make the left quarter lighter without also making the right quarter lighter. I thus don't see any strong prospects of showing a usable 640x200 screen.

I don't see much point in trying to build a crazy complicated piece of electronics for that purpose. If you're seeking to use the 2600 as a performance musical instrument it would be better to figure out what exactly you want to do and have someone write some suitable software, probably in bBasic. The keypads are not designed for rapid operation, and trying to pulse them quickly would probably not yield the results you're after.

Probably not for drawing a full asymmetric playfield, but if one is using the 'copy' mode rather than 'mirror' mode, one could use VBLANK to hide places where the playfield really shouldn't be duplicated but is anyway. My Ruby Runner demo did that (it shows the middle 80 pixels of the screen).

I hadn't looked at this game before. It seems quite nice. One caveat, though: it looks as though the screen is bouncing up and down a bit, probably related to sprite positioning. Have you looked into that, or would you like any help?

It's possible to create interesting "Z-ordering" by selectively blanking parts of a sprite. Toyshop Trouble blanks the portions of sprites that go "behind" the edges of the conveyor, for example. You'll need enough RAM to hold the sprite that will be partially blanked, and some creativity will be needed to make things work. I'm not sure such an effect would be practical in bB, though if there's room for the sprite it might be workable. Here's a more extreme demo of the approach. Move the man with the left controller and observe that he goes in front of some objects, but behind others. pop2.bin

Not quite. The Atari 2600's horizontal motion circuitry is rather complex, and I doubt that more than a handful of people back in the day ever understood it (and I suspect none understood all its wrinkles). The horizontal motion circuitry is designed to hit each sprite with 0 to 15 extra motion pulses during horizontal blanking interval. That would have the effect of moving the sprite 0 to 15 pixels left. To allow sprites to move rightward, the TIA designers engineered the TIA so that an HMOVE would blank the first 8 pixels of the following line and disable the motion pulses that would normally occur there. Eliminating the first eight motion pulses effectively moved all the sprites eight pixels rightward. If the horizontal motion registers were set to output 8 pulses, the 8 pulses they output would offset the eight pulses that were blanked, leaving the sprite's position unaffected. If it output fewer than eight pulses, the sprite would move right. If more than eight pulses, it would move left. There are two ways to reposition objects without blanking the left 8 pixels of the following scan line: -1- Set the sprite's position to a multiple of three pixels using RESxx and don't fine-position it with HMxx/HMOVE. For shapes that are at most six pixels wide, one may achieve pixel-level control by selecting one of three different versions of the sprite shape. Both approaches were used back in the day, but I don't know if they were ever combined (the only use I'm aware of for the latter is in Galaxian). -2- Hit the HMOVE register just before the start of horizontal blanking. This will trigger the pulser circuitry for the usual 0-15 pulses, but it will not trigger the blanking circuit for the next line. The net effect is that sprites will move 0-15 pixels left (instead of -8 to +7) but the HMOVE "bar" will be eliminated. I am unaware of any game using this technique in the twentieth century.

Setting playfield priority causes anything that would be shown using COLUPF to take precedence over anything that would be shown using COLUP0 or COLUP1. Electrically, score mode causes the playfield to be drawn using COLUP0 and COLUP1 in addition to COLUPF. If COLUP0/COLUP1 have priority, that will effectively cover up the COLUPF-colored playfield. But if PFP is set, the COLUPF-colored playfield takes precedence.

Impressive indeed, especially given that it's only 7.5K+128B.

Custom kernel. I think it's possible to use custom kernels within VB, but I don't know how it's done. The rain is implemented using the Ball. The kernel uses four shape pointers and four color bytes: even frame even line, even frame odd line, odd frame even line, and odd frame odd line. Presently, there are two shapes defined in the code. Pushing the joystick up or down forces the kernel to display only even frames or only odd frames. One of the difficulty switches controls whether the even scan lines show the same frame as the odd scan lines, or whether they show the other frame. Note that if you were to use different shape data for the even and odd lines, you could improve your vertical resolution if you use flicker, and may be able to improve apparent resolution for areas of the 'bright' color. though testing would be necessary to determine what actually looks good.

Do you have any thoughts about a practical way to use an Atarivox plus a second joystick?

Two wave tables for each pitch from middle C to the B above (one for loud, one for soft). There are also twelve modulus tables (one for each pitch). Each channel mixes two waveforms selected from those, independently selectable for 1/4x, 1/2x, 1x, 2x, or 4x speed; the C may also be played at 8x. The Stay Frosty tune uses the full 5-octave range. Getting a 4-channel wave-table synthesizer to run in 46 cycles/sample was no easy task (note that 6 cycles were spent on STA AUDVx, leaving 40 to do the computations). The code is unrolled in an interleaved 4-line pattern, so generating four samples requires, for each voice, four LDY zp, five LDA (zp),y or ADC (zp),y, and one STA zp (40 cycles in all).

Open Sesame can show a display while outputting its "speech". In that sense it's more sophisticated than Quadrun. Pitfall II, Quadrun, and Open Sesame all work by setting AUDC0 to zero and banging audio out AUDV0. My BTP2 demos, and the Stella's Stocking menu use both AUDV0 and AUDV1. Basic speech output at 7.875KHz would require less than 30 cycles per line pair, so keeping up some sort of display shouldn't be a problem. The BTP2 driver uses 46 cycles per scan line for 15.75kHz output; showing a good-looking display in the remaining 30 is a major challenge, but in Stella's Stocking I was able to manage it (the title screens drawn by Nathan et al. would be considered good by 2600 standards even if they didn't have fancy music playing; a new banking scheme was necessary to free up enough cycles for stuff to work, but the music in Stella's Stocking is all generated by the 6507. With regard to using fractional-frame timing to generate phasing effects, that would be theoretically possible, but difficult. The Atari's sound channels each have a five bit counter which counts twice per scan line and is reset to zero if, at the start of a count cycle, it equals AUDFx. When it resets to zero, it also triggers the AUDCx-based noise shaper circuit. Note that when changing from a lower frequency to a higher one, if the programmed value goes from being higher than the counter to being lower, the result will be a longer-than-normal wave cycle as the counter misses the programmed value and runs until it wraps at 32. If one were trying for subtle phasing effects, the audio disruption from that would almost certainly ruin them. It would probably be possible to generate some very nice phasing effects by changing AUDFx at appropriate points in a frame, but one would have to always be aware of what the frequency counters were doing. Probably more complicated than would be worth bothering with.

How about Combat? With two players of matched skill, it's a lot of fun. But it's often viewed as the generic 'had to put something in the box' game. I'll admit, though, Sears may have had the right idea with Target Fun (Air-Sea Battle), since that does include some one-player options. Not great, but none of the games from the first set were very good as single-player.

I don't understand the rationale of requiring the player to waste a slingshot before being able to turn on a lamp. I would think it would make more sense to design things so that aiming at a lamp point-blank will turn it on without using a pellet. I would think the game should fit pretty easily within the 2600's abilities, especially if there were only one lamp, desk, or other object per line (it would be possible to handle two or three such objects, plus the player, using 30Hz flicker, but I think it would be nicer not to). I'd also be inclined to allow the player to move smoothly if practical; I see no particular reason that shouldn't work.

Cathouse Blues is about the only "adult" games that I've found playable; Gigolo is essentially the same thing. At least in Cathouse Blues, prostitutes walk to their houses (hence the title of the game); the player has to remember which houses have prostitutes, and visit each of those only once. There doesn't seem to be any particular reward for visiting all of them (other than to watch more prostitutes walk to houses) but the overall play mechanic could be the basis of a decent 'decent' game. AVGN missed Burning Desire (similar to Jungle Fever, but with sex roles reversed) and Lady in Wading (Knight on the Town), but also missed one title which is very different from the rest: X-Man.

The 2600 definitely has its challenges. That having been said, there are somewhat different expectations with different platforms. While an NES version of something like Toyshop Trouble would probably be considered a pretty good even if it did very little beyond what the 2600 version does, the expectations for NES games tend to be higher than anything the 2600 can realistically do. Though sometimes (as with e.g. Thrust) the 2600 does things it can't realistically do (but does anyway).

For best results, use a single-line kernel. Here's a demo which shows a few different styles of "rain" and sprite coloring. Use right difficulty and color/bw to select four styles of 'rain'. Use left difficulty to select between two styles of flicker. Use up/down to force the sprite to show frame #1 or frame #2. Note that for this demo I used half resolution (even and odd lines show the same data) but that would not be a requirement. Best results may be to use Venetian blinds without flicker, but you'll have to try for yourself to see what you like best. rain.bin

Wizard of Wor would seem a pretty good fit for the O2, if one can manage to do a 'raster split' just below the bottom of the main map. The CBS version was playable on the 2600 showing two sprites at once; the O2 version could easily push that to four, and if you could manage to do a raster split it could do a nice job with the scanner as well (show two sets of two sprites side by side to show a 16x8 2-colors-plus-black bitmap). It might be possible to do the scanner with a bunch of period characters in close proximity, but I'm not sure the system would render those correctly.

The Apple ][+ had two hardware advantages over the C64 and Atari. (1) Its standard floppy-drive interface that was actually designed to be fast, and (2) it allowed more than one bus-based expansion device to be installed simultaneously. In nearly all other regards, the Atari and C64 hardware were superior. On the other hand, if people are trying to actually get things done and may need to switch between programs fairly quickly, a drive that lets a user switch between programs in under 10 seconds is vastly superior to one that takes minutes to do so. There's also a curious 'image' aspect with displays. A program which designed to run in black and white on the C64 or Atari would look just as good on a monochrome display, if not better, than a similar program running on a monochrome display with a stock Apple ][+. On the other hand, programmers didn't generally code for black and white displays. A program designed for a color display will look more colorful on a color display than one designed for black and white, but won't match the crispness of black and white text on a monochrome display.

The basic approach for acceleration in Toyshop Trouble was something like: (pseudo-code) target_speed = 0 if joystick is left then if firebutton then target_speed = -8 else target_speed = -3 endif if joystick is right then if firebutton then target_speed = 8 else target_speed = 3 endif if current_speed < target_speed then current_speed = current_speed + 2 if current_speed > target_speed then current_speed = target_speed else if current_speed > target_speed then current_speed = current_speed - 2 if current_speed < target_speed then current_speed = target_speed endif A key question in your acceleration logic is going to be whether you can manage enough animation frames to keep the character's feet on the ground. If so, different approaches will be required.

The data stored on an Apple-formatted floppy has to be encoded so as to meet certain requirements. It's not possible to simply store arbitrary data bytes to the disk and read them back. IIRC, the processor has about 30 clock cycles to deal with each raw byte of data coming off the disk; unless one has some massive pre-calculated translation tables, that isn't enough time to do much decoding. Under DOS 3.3, the system would read a sector of raw data, then decode it, then read the next sector, decode that, etc. Reading a track of data would thus require multiple passes. Even under ProDOS, I don't think a whole track could be read in a single pass. If, however, software uses a simpler coding scheme to store information on the disk or else uses some suitable translation tables, then it may be possible to read data off disk in one smooth operation.

The basic concept behind flicker is that the display alternates between states on (typically) alternate frames. Having large areas of the screen flicker can be very annoying. The idea behind flicker blinds is that rather than having solid areas of the screen flicker between two states, alternate lines of the screen will have the opposite state. As a simple example, one could show an object in a mixture of show tan, pink, and magenta by setting the sprite color to tan and displaying the tan and pink parts, and the setting the sprite color to magenta and displaying the pink and magenta parts. The pink parts would flicker between tan and magenta on alternate frames; the other parts would alternate between being displayed and not being displayed. Depending upon the nature and shape of the tan and pink parts, the flicker here may or may not be objectionable. A second approach is to have the sprite color alternate between tan and magenta every scan line, keeping the mapping constant from frame to frame. This approach works, but the color striping may in some cases be objectionable. Further, it effectively negates half of one's vertical resolution. A third approach is to combine the above two approaches: on one frame, make the even scan lines tan and the odd scan lines magenta, and on the next frame make the even scan lines magenta and the odd ones tan. In some cases, having alternate scan lines flicker alternately will make the flicker less noticeable; in other cases, it will make it more noticeable. I'll post a kernel demo later tonight to show the different approaches.