[Home Run / Baseball Atari VCS]

I would enjoy seeing these games with your programmer's eyes. I don't have the knowledge to look at something and say "heeey! look they're using a <insert algorthymic term here> there! Wow!", but I'm glad you point it out as it allows for more appreciation of the cart in the hardware/software context of the time. So, thanks.

 

It's only recently that I've come to learn what the 'first batch' of Atari games was. And it's interesting to note that most of the techniques used to make 'good' games were actually discovered quite early on.

 

Many modern techniques require more ROM space than programmers could afford back in those days (2K is pretty tight). Of the general techniques that may be put to practical use in a 2K cart without using undefined opcodes (in 1977, using such opcodes would have been a bad idea even if they were understood) the only two I can think of that didn't appear in some form in 1977 were (1) using color striping to decorate players, and (2) using VDEL to get six different sprite shapes in 'close' configuration.

 

Something like Blackjack may not look like much by modern standards, but it does show six different sprite shapes per line in 'wide' configuration, and also manages to do three independently-colored and -shaped sprites per line (also 'wide').

 

BTW, I wonder what the first game was to show six independently-shaped sprites in close configuration using the VDEL trick. It's possible to get six almost-independently-shaped sprites without using VDEL (two columns of pixels have to match, and there's some freedom as to which two) so it would be possible to do a six-digit score routine without it. Anyone analyze the early Activision games to see what they were up to?

[Home Run / Baseball Atari VCS]

Assuming your chronology is accurate, I believe that would make Baseball the first 2600 game to perform sprite multiplexing via flicker. It's not quite the first game to use flicker, but I believe Indy 500 and Street Racer only used flicker to 'highlight' something (the 'tag' block in the former and the tip of the Number Cruncher cars in the latter).

 

Interesting that vertical multiplexing was used before flicker (in both Street Racer and Air/Sea Battle, though in both of those games the multiplexed objects were at fixed heights on the screen).

[Minigame Mania]

This years 1K entries aren't much different, but IMO there's again two really outstanding titles in the pack!

 

I've just played through all the Commodore entries (1K and 4K). None of the 4K entries impressed me much, but two of the 1K entries did--one with challenge and simplicity, and the other with the 'wow--that's 1k!?' factor. I must admit I have no idea how the latter title does it.

[Minigame Mania]

I have winVICE 1.16.  And when I try to autorun Jewels it gives me a syntax error

 

Now that's very weird...

 

The VIC-20 changes its memory map substantially when 8K or more of RAM expansion is plugged in. The VIC-LC game requires the 8K expansion be present; the Jewels game requires it to be absent. Use "Settings/Vic Settings..." to change memory expansion settings (I find it curious that the memory expansion is enabled by default, given that back-in-the-day almost no games would work with the 8K expander plugged in).

[Slot Racers, Atari VCS 1978]

Just remind your inner self that Slot Racers was written by THE GREAT ONE. Actually, though it's not too impressive by modern standards, it is well in keeping with the other Atari 2600 titles of its era.

[Ball Horizontal Counter]

So the ball moves horizontally; does it do anything else (any more updates please?)

[Space War, Atari VCS 1978]

I admit it's been ages since I've played Spacewar against another person, but the thrustthrustthrust approach isn't from what I can tell a great strategy since the the player doing that can easily by a shot that's fired at a comparable angle. Perhaps the FB2 version of Spacewar is different from the one released in 1978 (there are multiple revs of some cartridges, and Spacewar might be one such). Any way you could check that out?

 

Also, the docking ones are a nice challenge. I would think that using the difficulty switches you should be able to have fun playing with your son (make it so he just has to hit the thing while you have to dock).

[Limits of Scale]

Thanks - these look like some really useful macros!  I do use ALIGNs a lot, but they get in the way when you want to shift things around.  The macro approach should make code reorganization much less tedious.

 

Another thing I sometimes do with macros: include all the .DB statements within macros (rather than having them operate directly), so that then I can rearrange the order in which items appear in the code without having to rearrange the .DBs themselves. This is especially handy if, as in many of my projects, some of the DBs are in separate .include files. I can .include all of the DB-containing macros at the start of my source file, and then arrange the actual data as I see fit.

 

Another way I use this technique is to produce an "initialized data" segment. After the minigame contest, I'll post my code to SDI to show how that works. It's very easy in many 2600 projects to waste a lot of code with "lda #this/sta here/lda #that/sta there" etc. Four bytes for each location that needs to be initialized. Using an "initialized data" segment reduces this to one byte per byte plus a small "loader":

 ldx #IDATA_END-IDATA_START-1
lp:
 lda IDATA_ROM,x
 sta IDATA_START,x
 dex
 bpl lp

Nine bytes. So if there are four or more bytes that need initialization to different values, it's a win (13 bytes vs. 16). Even if two of the bytes need the same value, it's still a win. And of course, if more data need to be initialized, it's an even bigger win.

 

Indeed, if ZP RAM is abundant, it can make sense to put small tables of constants into ZP RAM since doing so will save a byte of code space for every access to one of them. And if an address is used three or more times with abs,y addressing mode, it can be changed to (zp),y saving a byte per instance at a total cost of two bytes.

 

Of course, in most cases ZP RAM won't be more plentiful than code space. But knowing how to take advantage of initiailized data is still very useful.

[Highs & Lows]

Draw the falling tile using the 8-pixel ball sprite, but flicker the left/right sides on alternate frames, or draw the tile in two halves like this: ----___

 

Hey, the fact that the tiles are crooked when they fall is a "feature". In reality, do you think the tiles would always fall perfectly straight?

 

IMHO, having the tiles skewed like that is definitely the way to go. It should look reasonable, and would fit perfectly with what your kernel is already doing for the sword. I don't know if you're still using the trick I mentioned earlier of just loading HMBL once at the start of screen, hitting HMOVE every two lines, and setting the starting position of the sword to compensate, but if you are all you'd have to do would be to change the initial-position logic and store a $80 in HMBL and you'll be all set.

[Limits of Scale]

I'll assume you already know about the "align" assembler command.

 

Instead of using 'align', I like to use a macro. The macro can take an argument for how much space is needed (so it doesn't advance a page if it doesn't have to), and can output to the screen/list file how much space it's skipping.

[Limits of Scale]

Sounds like an interesting idea - you don't happen to already have these macros defined as I find the DASM macro language rather cumbersome to use.

 

It's pretty straightforward.

               mac     sbpl
               bpl     {1}
               if (* ^ {1}) & $FF00
               echo "PAGE CROSSING","WARNING ",{1}," at ",*
               endif
               endm

For checking data, use

               mac     pcheck
               if (* ^ {1}) & $FF00
               echo "PAGE CROSSING","WARNING ",{1}," at ",*
               endif
               endm

and, after each data item, do a pcheck with a label to the start. The warnings are a little less than helpful as simply output, but you can search for them easily in the .lst file.

[Limits of Scale]

One thing that might help is to create macros for "sbeq", "sbne", "sbcs", "sbcc", etc. which generate the indicated branch but provide a warning if the instruction following the branch is not in the same page as the target. In many spots in your code, this won't matter (so just use ordinary branches) but where it does matter, you can use the macros and be warned if things shift in a bad way.

[Making Labels - Part 1]

When I did my wife's grave marker, I wanted to include her signature. The signature I used was about 3" long--even my 600dpi scanner couldn't get suitable resolution for printing at 300dpi (the marker is 24"x14", so the signature was probably about 18" long).

 

The approach I used, for better or for worse, was to scale up the scanned image and then experiment with different combinations of 'blur' and threshhold operations until I got something pretty close to reasonable. With the image rendered into one-bit black-and-white, I then went in and hand-retouched everything.

 

Perhaps not the best approach (especially today, when memory is cheap) but in 1999 working with a large document in greyscale would have been difficult. And the approach of using a combination of blur and constrast-boosting to smooth out edges can be useful. Line edges will still need cleanup, but this approach gives a much better 'starting point' than simply beginning with a black-and-white scan.

 

Note also that a lot will depend upon the quality of software you're using with the image. In my case, I was using self-written software to combine the signature with other graphical elements to produce a 300dpi output. That software only knew how to read a black-and-white .bmp file, so that's what I generated. Some paint programs' "fill" tools can have difficulty filling in outlines that aren't an absolutely solid color; when using those, cleaning up the outlines can be helpful.

 

The biggest thing I'd suggest is that when working with discrete-tone images, higher resolution is necessary than when working with continuous tones. If it's easier to work with a 600dpi discrete-tone image than a 300dpi continuous-tone one, go ahead. But if the latter's easier, do that.

 

FYI, a mockup of the finished result:

 

BTW, though not particularly visible, the cross is another interesting story. I started by scanning a necklace, then inking that, and scanning that. I then did a mixture of cloning and vector objects to clean everything up.

[Colony 7 Sprites]

These sprites look great   However, I agree with Manuel that the Fighter would look better if you could use a similar effect to the Bummer to avoid the holes in the sides.  The Scout looks good to me as it is though.  The playerpal tool is good for producing sprite data in the correct form for the 2600.

 

Making the fighter be a scan line taller might help if you added another line above the windows. At the expense of accuracy of appearance, you might also try filling in the mostly-empty scan lines. I suspect a lot will depend upon the speed at which the animation is run; many things which look bad at slow frame rates look fine at higher speeds.

[Tile Trouble]

Thanks for the suggestion - it might just work   The walls are a different colour from the floor tiles, but it shouldn't be too noticable on a rapidly falling tile.  The pointer shifting trick is already used to open and close the doors.  I know that the Supercharger is all RAM, but it isn't very convenient to use and 6K doesn't seem to go very far for a game like this!

 

Will the falling tiles be at the same horizontal level as the player and other objects? When they aren't, you might be able to use a missile for the falling tile and have its color be "correct". If the code didn't get too outrageous, you could have the game use a missile when a good one was available, and playfield when it wasn't.

[Ooze Lives!]

I'll agree with Eric and say that the kernel is probably the trickiest (and most fun!) part of a 2600 game to write, but it usually isn't the biggest time sink.  The biggest time sink is all the game logic and other parts.

 

Kernels can be hard or easy, quick or slow to write, and rewarding or not, probably in just about any combination. Along with the kernel, some games require a "pre-kernel" which runs each frame and prepares data for the kernel to use. Something like Ms. Pacman, for example, probably uses a pre-kernel to determine which sprites are in which zones and how they should flicker.

 

The real challenge for a 2600 game is often not just designing a kernel that works, but designing a kernel whose data structures can be manipulated with acceptable speed by the game itself. Interestingly, this is where I got tripped up in the first 2600 game I started to write (since abandoned, but I may pick it up sometime). The game was to be an implementation of Columns (similar to Salu's Acid Drop, but better) in which there is a 6x20 grid that fills up with gems. The gems come in six different colors, and getting three or more gems in a row vertically, horizontally, will cause them to disappear; any gems over them will then fall down, possibly triggering further reactions.

 

The kernel itself looks pretty good, especially for a first attempt (the scan line count is way off, because I had no facility for measuring it--this was years before any emulators were on the market). The gems appear with nice color shading and the kernel supports sixteen colors of gems which may be solid or shaded. The plan was to use solid black for non-gems, six colors for gems, and then have "brighter" versions of those colors for exploding gems, and make the remaining three colors show shades of grey, used to further animate the exploding gems. All that's implemented and works great.

 

The problem is that the data is stored sorta goofy. The upper-left gem's color is stored in bits 0, 2, 4, and 6 of address $C0. The gem to its right is stored in bits 1, 3, 5, and 7 of that byte. The next gem is in bits 0, 2, 4, and 6 of address $D4 [i.e. twenty bytes after the first one]. Then bits 1, 3, 5, and 7 of that byte. Then $E8 [bits 0, 2, 4, and 6; then 1, 3, 5, and 7]. The next row starts at $C1, etc.

 

Not the worst way to store things, perhaps, but I was unable to figure any good and fast way to do the checks for adjacent dots being the same color. Perhaps I should revisit that, because I've learned a few tricks since then.

[Little Man Progress]

I am not sure if you are talking about Little Man or Cybergoths Jumpman clone work.

 

Nor am I, half the time, so don't mind me. Someone (maybe Cybergoth) posted that Roy Glover was friendly toward the idea of Jumpman clones, so including Figurit would seem nice.

[Little Man Progress]

I wonder whether it would be practical to use a tile-based approach similar to "Hunchy II" but with a bigger tile set? If one had different tile sets for different levels (easy with banking) it might be possible to render each level as a 4x16 grid of tiles. Doing that would allow a level to be stored in RAM, which would in turn make things like Figurit doable.

[Little Man Progress]

GP-III doesn't change it's structure at all. It just switches to the secret level, when you disarm the right bombs and then let yourself hit by the moving square

 

It's implemented as a large collection of 'draw girder', 'erase girder', etc. operations though for the 2600 you could simply switch to a different level.

 

How would you handle something like Figurit, though [which is actually the level I was really thinking of earlier]?

[Little Man Progress]

Extra RAM would make it too easy! 

 

Well, best of luck to you. What's your target cartridge size and number of levels?

[Little Man Progress]

Looks interesting. Any consideration to using a RAM+ cart and holding the level in RAM? Would probably make it much easier to have levels change in response to touching objects (as in GP-III). Colors look good, though.

[1977 Retroview]

BTW, going through all the 1977 carts, it seems there was exactly one which redefined sprite shapes mid-line: Blackjack.

[Street Racer a.k.a. Speedway II]

I'm glad you brought that up. I am a VCS programming neophyte, but I was thinking it must have been tough to do the whole fourplayer AND enemies. There's not a lot of flicker if I recall correctly, either.

 

There is no flicker in Street Racer. Flicker hadn't been invented yet (seriously--I don't think any 1977 titles used it; I think it first appeared in Home Run).

[Scramble 2600]

It would be nice if there were a way to "fake" smoother scrolling on the 2600. Maybe by edging the playfield graphics with sprites or balls. Although that probably wouldn't leave anything for the rest of the game. (Seems to me this was done on Radar Lock for the horizon line though.)

 

The Radar Lock horizon only has one 'edge' that needs smoothing, so it just uses the Ball. Stargate/Defender II has two edges that need smoothing, so it uses the Ball and one missile (this is why the player's ship and shots are the same color as the ground). Super Cobra's landscape scrolls up and down in somewhat chaotic fashion and would thus require multiple objects to smooth it out. The only way I can see to do this without flickering everything would be to use missiles and the Ball to smooth the landscape, and use Venetian blinds as well to allow the NUSIZx and COLUPx for the missiles to be different from those of the other objects.

[Bush deserves the benefit of the doubt?]

I find the Harriet Miers choice puzzling, but my big question is whether she can actually read the Constitution, a skill which seems to be lacking in too many justices today.