[1977 Retroview]

Y'know, you're probably right. It was a way of sneaking the VCS into the home as an educational tool. I wonder if there was ever a conversation with the programmers where they offered resistence and were told, "look, the launch line-up has to have something we can describe as 'the first of many educational titles'. Don't make it fun, just make it."

 

It's probably worth noting that there were some popular toys around that time which provided similar drills to Basic Math (Texas Instruments "Little Professor", some space-robot thing, Digitor, etc.) though I don't know whether they came before or after the 2600. What's disappointing with the 2600 is that it's Basic Math cartridge fell short of what many of those toys could do. Some of them had cool numbers games, and I see no reason the 2600 couldn't have done likewise. I also know of no reason the 2600 had to have such blocky graphics for Basic Math; that game uses zero sprites.

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

Not a great game, but still pretty impressive technically for 2K. Even today, writing a kernel for that game would pose some interesting challenges (enemy cars etc. are drawn using an assymmetric playfield, two sprites get repositioned mid-screen, playfield data probably has to get shifted on the fly, etc.) No problem in 4K, but getting the whole game into 2K would probably be tough.

 

BTW, I wonder how the game would look if the two players and two missiles were swapped and the playfield left in "SCORE" mode? Would probably have to swap color registers at the top of the screen, but could be interesting having the left and right halves of the screen colored differently.

[1977 Retroview]

Atari did pretty well, didn't they--especially considering that the early cartridges were all 2K (most carts on the Atari are 4K, and some much bigger than that). It's interesting how much stuff was packed into something like Combat or Street Racer. Even for today's programs, writing those games in 2K might be hard. Something like "Basic Math" is pretty trivial, though perhaps its real raison d'etre is to let kids pursuade their parents the 2600 is "educational".

[Sliding Doors]

You will note my use of a to show that I wasn't being entirely serious!  I just mean that Thrus+ is more of an achievement (IMO) because it sticks to a tighter set of constraints.  I guess I will also be happier once there is a way to release RAM-expanded games on a real cart, but (as I'm sure you already know) this looks like it is going to happen very soon now.

 

I'm currently working on rev 2 of the board. Will add two software-controlled blinkenlights if I figure out where best to put them. Don't know if they'll be installed in all the boards or if I'll leave the space open to allow customization of color (as well as cost-saving for any boards that are going in opaque housings).

[Basic Math and Blackjack]

Okay, don't talk to me about basic math, see? It ain't a game, see? It ain't fun, see?

 

It's not fun? I thought when Sears released the cart they called it "Fun with numbers" [gee, where have I heard that name before?]

[Air-Sea Battle + Little Girl]

It's been ages since I've played this cart, but I think I have a copy somewhere. Some of the old Atari games really hold up, don't they?

[So, you think you have a good idea?]

Is this true?  When bit 1 of CTRLPF is set, bit 2 has no effect?  Is this documented anywhere, or did you discover this through trial and error?

 

I discovered it while trying to code a kernel for doing a 16-pixel-wide seven-color screen kernel (usable for puzzle games and such). The game puts player 1, 4x scale, on the left half of the playfield and player 0, 4x scale, on the right half. Using score mode, I can thus independently make each playfield pixel one of three colors. The Ball uses the playfield color register which is unused for anything else, so it gets to be its own color (makes a very nice cursor).

 

One fun little wrinkle is that because the player sprites are in front of the Ball, I have to turn off the pixel where the cursor is sitting or else it will cover up the cursor.

[Leprechaun movement musings, part 2]

If all of the following actions for a monster take the same amount of time...

• Travelling one square horizontally
  
• Travelling one square vertically on a ladder
  
• Falling one square
  

Then it might make sense to arrange the play mechanic so that internally the monsters moved on four-pixel increments horizontally and one-row (however many pixels) vertically. Then arrange things so all the monsters are "out of phase" with each other.

 

If you do this, you can have monsters move visually on every display frame but only have to worry about collisions detection for at most one monster on any frame. One fractional motion counter could take care of all the monsters.

[So, you think you have a good idea?]

Pretty good, generally. A few things I'd mention:

 

-1- The playfield hardware holds half the screen. If the right half matches the left half (regular or inverted) it can be repeated for several scan lines without needing any more CPU time; if the right half doesn't match, it must be redrawn every line even if the data seems to repeat.

 

-2- CPU time requirements for the playfield can be eased considerably by striping it, or by only using the central 32 columns.

 

-3- It is possible to show different shapes or colors in the different copies of a sprite (this is now most games' score displays work) but it is very CPU intensive. It is generally only practical to do it for objects at fixed horizontal positions (like the chickens in Freeway).

 

-4- Objects may be inexpensively 'nudged' on a per-line basis. One may either nudge all objects -8 to +7 pixels left, or 0 to 15 pixels left. The former mode of nudging will blank the first eight pixels of the next scan line. Nudging may allow sprites to appear to be higher-resolution than they really are, and may also allow missiles to have 'interesting' shapes.

 

-5- When the playfield has its own color, objects will appear, front to back, in one of the following orders:

 

-a- Player 0 and missile 0 in front, then player 1 and missile 1, then the playfield and the Ball, then the background.

 

-b- The playfield and the Ball, then player 0 and missile 0, then player 1 and missile 1, then the background.

 

-6- When the left/right halves of the playfield share colors with the sprites, the object ordering is fixed:

 

-a- Player 0 and missile 0, then player 1 and missile 1, then the Ball, then the playfield, then the background.

 

-7- It is often possible to make tradeoffs between time, code space, and RAM requirements. It can be tricky to predict whether a given effect will turn out to be practical or not without actually coding it.

[Archon is possible.]

Can you extend your sprites to 8x14? That is the size of the characters in the C64 screenshots. For smaller sprites, I agree that it would take an artist.

 

Sure. I updated the sprites to borrow the original graphics. The original game had light/dark at the left and right sides of the board rather than top and bottom, though, so the sprites should still be redone. But this gives proof-of-concept anyway.

[Archon is possible.]

Yeah, I've been looking at supercat's kernel, and it's very close to the original design. The advantage of higher resolution sprites and recreating the original appearance outweighs the disadvantage of flickering.

 

@supercat, you can get screenshots from the link above, That'll give you the sprite data.

 

I'm not enough of an artist to render all those things in 8x12 and 8x6 resolution (it would probably be best to allow players to select lores or flicker mode).

[Archon is possible.]

I've just formulated an Archon kernel which requires extra RAM (actually quite a bit of it) but accommodates either 8x12 characters (with Venetian-blinds flickering) or 8x6 (blinds only, no flicker). I posted a demo in the Homebrew forum; if anyone wants to give me some sprite shapes in the proper dimensions I could put them in. The board is set up with black on the bottom and white on the top.

[Scanline timing diagram]

What I've done in the past is to put it in a simple spreadsheet which then makes it easier to shift sections of code around.

 

Once upon a time I used a Macintosh paint program to draw up a timing sheet with 76 cycles across, and with the playfield pixels marked. I may somewhere have a paper timing diagram from my first kernel which I did back in 1995 or thereabouts.

[One Step forward - Two steps back]

Hm... dunno if it can be that easy. It sounds like a good idea, but it might be tough to work it in, as it'll require two different vertical resolutions. Also adjusting the pointer inside the kernel might be tricky.

 

I guess I'm a little confused as to why you'd need to adjust the pointer inside the kernel? If your object is supposed to be six scan lines high, then in one shape table you have: (line4 line2 line0 blank) and in the other you have (blank line5 line3 line1 blank). Bear in mind that the zero-byte following one object can be the same as the zero-byte preceding the next.

 

Your object height should be set to four scan-line pairs. If your object is supposed to appear on an even scan line, set the zero-page pointer used for showing even scan lines so that the bottom even-scan-line data will be line4 and one for odd scan lines so that the bottom odd-scan-line pixel will be line5. If your object is supposed to appear at an odd scan line, set the zero-page pointer used for showing even scan lines so that the bottom even-scan-line data will be the blank before line5 and the bottom odd-scan-line data will be the line4.

 

Alternatively, depending upon what you're doing with the other sprite register, you may be able to just use VDELx.

[Family cat is gone....]

Sorry to hear about your cat. Felines are wonderful creatures.

[Little Man Progress]

What I don't like about using the select switch during a game is that I tend to push the reset button by mistake in the heat of the moment.

 

Solution to that is to make the reset switch only operate if held down for some period of time.

[Illogical]

Simplified rules (equivalent to the ones supplied):

Whichever player goes first goes to his type of square (odd or even). The second player always goes to an odd square. After that, players go to whichever type of square they're not on (alternating odd and even).

[One Step forward - Two steps back]

But, it can't happen on a repositioning scanline.

 

I'm afraid I don't see the problem. Keep your object repositioning on even (or, if you prefer, odd) scan lines and pad your sprite shapes with a blank row at top and bottom. Depending upon whether the sprite is supposed to appear on an even or odd scan line, the blank row at the top may or may not be displayed.

 

Is there something I'm missing?

[Ball Horizontal Counter]

Sure suggests where Atari got some of the ideas behind the 2600's sprite controls.

[Kernels]

Check out my demo (homebrew forum, POP thread) of moving an object in front of and behind a striped background. The player moves behind the column (control with joystick), in front of the "POP" logo, and then goes behind the wall but is visible through the window.

 

I don't think I've seen this technique used on the 2600, but it can really add an incredible depth to a game. Note that I used a slightly "cheating" technique at the foot of the left-hand column, to avoid use of a third masking set. Note also that while this demo relies entirely on pregenerated masking tables, it's possible to generate such tables on the fly given adequate RAM (this demo just uses the RAM in a stock 2600).

[Kernels]

I know it is not entirely logical, but for me: spare cycles = more work still to do!  I like to feel that the hardware is being pushed to the limit, even if it is only artificial

 

Yeah, I can sorta go along with that, but if you fill up your cycles too quickly, you may come up with a better use for them later and have none left.

 

BTW, I haven't looked at your code (figured if I did, I'd better be careful or I'd hand you an 'ending' for your game :-)) but I was curious how you're doing the sword. In particular, are you writing HMBL during the frame, or are you just writing it once? It would seem like writing HMBL once would be a nice way to go about things. You'd have to consider that the position to which you set the sword at top-of-frame wouldn't match the position where it would appear (since the sword would snake down diagonally) but that shouldn't be a problem.

 

If I decide to take some time off my RAM+ cart, I may give a go at demonstrating my proposed 'look' for the background. Can then see if it comes out decent-looking.

 

Incidentally, one thing that would be really awesome if you could pull it off would be to display the player character shape from active RAM, and have it masked so that the player could walk behind pillars and things and not "show through" where he shouldn't.

[Kernels]

Why is being totally out of cycles a requirement for a good kernel? Personally, I like having a bit of slack time if I haven't yet thought of anything useful to do with it, so if I do think of something useful it'll be there. Of course, usually as soon as I free up slack time I find something to do with it.

[Shiny Object Syndrome]

Yes, I would like to know this also, and I'm sure it will be something special!

 

My current "shiny object" is a cart which will hopefully tonight properly implement 16K+Superchip, and should also be able to do all sorts of wondrous things with RAM and bank switching, all while being manufacturable at reasonable cost and fitting within a standard cartridge housing.

 

No TV at the lab, unfortunately, so testing's a bit difficult, but last night Save Mary sorta worked. My write pulses were a little too long, though (address changed right at the rising edge of /WE, and was sometimes early) so the game was glitchy. Hopefully tonight it won't be.

[Perfectionism]

Thanks for the clarification - I think I am now sold on the idea of using illegals on the 2600 in my code.  From your description, I guess there is no more danger in using illegal opcodes than there is in relying on precice cycle times for the various instructions!

 

That's a decent way to look at I guess, especially given that programmers on most platforms are generally discouraged from relying upon instruction timings (beyond the fact that code should run 'fast enough'). Writing a 2600 game without relying upon instruction timings would be rather limitting (RESPx could only be used at the start of a scan line, every scan line would need a WSYNC, etc.) It would be possible to code something like Combat, but it would be necessary to use venetian-blinds for the score digits [use SCORE mode, but set one side or the other to match the background]. I think it's pretty clear, however, that being unable to rely on cycle timing would be a severe limitation.

 

I think therefore that anyone coding for the 2600 could assume nobody would ever try to produce a 2600-compatible console that was not cycle-compatible with the NMOS 6507. That would have been just plain dumb. The idea that a future 2600-compatible console might not support the same undocumented instructions, however, would have been a legitimate worry. On the other hand, some people did use such instructions and got away with them; whether such people were being brave or foolish, who knows, but their decision was vindicated by history.

[PoP Development]

I think the basic wall collisions will be simple enough.  However, I anticipate problems with things like clinging onto ledges, and the fight scenes, though I could be worrying about nothing.  In any case, there is still a lot of work to do before the game will be playable.

 

Speaking of fight scenes, will the guards be restricted to platforms that don't have anything else interesting on them? Also, is there any reason the playfield is in front of the player? I know in Hunchy2 you had to do that to 'hide' unused missiles, but is that an issue here?

 

There are currently around 9 free cycles in the main loop which should be enough to read a colour table and write to the PF, though it will require some work as they are currently in the middle of the scanline. Did you have any colour scheme in mind (e.g. blue colour bands)?

 

I don't know what all you're going to want to show in your backgrounds, but if you color the playfield with two different colors on alternate scan lines, you can make things more colorful. For example, if you were to use cyan and orange stripes, then places where the playfield was 'solid' would be whitish while other areas could be blue or orange. If desired, the colors could be made more subtle (e.g. blue and green, which together would yield cyan). Note that Apple II games formed colors this way, except using adjacent horizontal rather than vertical pixels.

 

Note that for this technique to work well, you'd have to double the vertical resolution of your playfield. This may require changing how things are stored. My inclination would be to suggest that you have your playfield stored much like you do in Hunchy, using fairly short tiles (16 scan lines or so) and then have the map be composed of mega-tiles. When you walk into a room, use a set of translation tables to convert the screen full of mega-tiles into the smaller tiles. If you have nine cycles free per scan line, things should work out: you spend four extra to use indirect addressing instead of indexed, and five to do an LDA #color / STA COLUPF. Note that the code can be patched on the fly if different rooms are supposed to be tinted differently.