[Heuristics take time.]

Or just write a mini-kernel that has maybe 10 lines that say "Thinking" and have a progress bar beside it made out of playfield pixels.  Wouldn't be quite as fast, but you could blank the screen right after 10 scanlines and resume calculations.  Should still give a good increase in speed, at least 4-5x.

 

Depending upon the nature of your 'thinking' loops, the mini-kernel idea may be a good one. Within your loop, just have:

 bit INTIM
 bmi .1
 sta somewhere; If needed
 jsr KERNEL_V
 lda somewhere; if sta'ed
.1

My kernels usually preserve X and Y but not the accumulator or status register. They wait for INTIM to reach some value (typically around 124) and then do the necessary kernel stuff. The smaller you make the target value, the more time you can have between kernel checks, but the more time will be wasted in the kernel itself.

[Strat-O-Gems 2600 looks decent]

In Z26, pushing the up button will change the color combination so that is a great way to compensate for the inability to rotate the pieces like in Tetris and other puzzle games.

 

Pressing player 1 up will switch the "current" and next gem colors. Pressing the player 1 firebutton will cycle the colors of the current 3 gems (I may make the left difficulty switch select between cycling upward and cycling downward). The current posted game supports the following cheats:

 

-1- Game starts "primed" for an eleven-deep cascade. Just drop the first set of gems down the left.

 

-2- Left difficulty switch, if set, skips gems #2-#60 on each level (makes it much quicker to see higher levels).

 

-3- Right difficulty switch, if set (and if Atarivox or EEPROM is plugged in) will cause an automatic replay any time gems are cleared.

 

-4- Pressing up on player 2 joystick will randomly reselect gems.

 

-5- Pressing down on player 2 joystick will cause a wild gem to appear, and will also skip ahead to almost the end of the level.

 

These cheats will not be available in the release game.

[A better chessboard]

I would update the PF data just before each row. I'd need 30 bytes to do it (5 columns*6 doubled scanlines). The quickest way I can think of to assemble the playfield data is to save the board with one byte holding the shapes for two pieces. If each byte corresponds to a PF column, then there would be 40 bytes (5 columns*8 rows). Each number could serve as an index to quickly retrieve playfield data from a table. If I used another 8 bytes to store the colors, I can hold the entire board position in 48 bytes.

 

I guess there are somewhere around 80 cases you'd have to worry about in a chess game since the piece shape is independent of color (49 cases, times two for reflection, but some of those will be duplicates). But if you're not going to be using full vertical resolution, what's wrong with venetian blinds?

[Strat-O-Gems 2600 looks decent]

Honestly, I don't fully understand what it is.

 

The Atarivox is a device which connects to the player 2 joystick input on a 2600/7800. It provides two features:

 

-1- 32Kbytes of EEPROM memory

 

-2- A Speakjet chip.

 

If you plug an amplified speaker into the Atarivox, it will produce speech and other sound effects for games which support it (Man Goes Down, Stratogems, and I don't know what else). In addition, the EEPROM memory is used by some games for storing things like high scores.

 

An Atarivox costs about $40-$50 but the Atariage store is out of stock. If you just want the EEPROM memory, I think a board with just that is about $10.

[A better chessboard]

Here is a sample scanline for my chess kernel, so you can see how tight space is:

It's true I have 14 cycles of downtime, but I'd need 25 to update the addresses for the playfield data (5 cycles to update 5 addresses for LDY).

 

I think a more fundamental problem is that you don't have nearly enough time to 'assemble' the playfield data during a frame, nor nearly enough space (on an unexpanded 2600) to hold it all even if you could use indexed accesses to fetch it.

[A better chessboard]

There's no denying that Venetian blinds worked brilliantly for your Strat-o-Gems title. I figured you would have some good ideas for my kernel. I'll have to study your code to have an inkling of how it works.

 

The Strat-O-Gems title code is actually very simple. I don't change any color registers mid-line, and I don't even change the sprite 0 shape after the even scan lines (since the even lines end with "S" and the odd lines start with "S"). But I'll certainly grant that it looks cool.

[A better chessboard]

I would guess you're probably using sprites for the board squares and playfield for the pieces. Your color stores must occur 5-6 cycles apart (some five, some six). That leaves a fair amount of room for other stuff, but you need two load/store pairs for the playfield data (which will use up much of that room).

 

I personally happen to rather like the style of venetian flicker that David Crane invented; I would think it preferable to non-venetian playfield graphics for chess pieces. Nonetheless, your approach is interesting.

 

One thing I'd suggest looking into, though: you only need to do the COLUPF store if a piece is a different color from its predecessor. This fact should allow you to greatly reduce the number of different cases you need to handle since a non-store provides time to load registers. The different cases that can be handled by different types of code overlap in tricky ways, so you'd probably need some tables to help select which case applies to any particular color combination.

 

Another notion--not sure it would work well here given the slightly irregular timing requirements--is using the stack as a versatile branching method. I was thinking of doing this awhile ago for an eleven-invaders clone using Venetian blinds. The basic idea would be to have a code segment:

 

xinv5:
 nop 0
 jmp inv5
xinv4:
 nop 0
 jmp inv4
xinv3:
 nop 0
 jmp inv3
xinv2:
 nop 0
 jmp inv2
xinv1:
 nop 0
 jmp inv1
xinv0:
 nop 0
 jmp 
inv6:
 nop 0
 sta RESP1
inv5:
 nop 0
 sta RESP0
inv4:
 nop 0
 sta RESP1
inv3:
 nop 0
 sta RESP0
inv2:
 nop 0
 sta RESP1
inv1:
 nop 0
 sta RESP0
inv0:
 rts

 

The stack would be set up with a list of 'segments' of invaders, followed by a pointer to the code that should execute after showing the last invader. The stack pointer would be set to the byte before start of this list and an RTS executed. In worst case, the stack would need to hold four entries (there would be two stacks, one for the even rows and one for the odd rows).

[Strat-O-Gems 2600 looks decent]

Thanks. Do you have an Atarivox?

[my lack of programming skills finally revealed!]

The Ball's width is controlled by the CTRLPF register (bits 4-5 I think).

[The 19x19 board]

Furthermore, I don't think that 128 bytes is enough to store a 19x19 board with four colors and the dynamic code. However, there is nothing wrong with playing Pente on a 17x17 or 15x15 board.

 

A four-color 19x19 board would require an absolute minimum of 90.25 bytes for the board, and you'd need 33 bytes for the self-modifying code and 2 for stack. That's 126 bytes. I guess it might conceivably be workable if you played the right sorts of games (use the RIOT timer for the row counter instead of using a byte of memory; use five bits from the last byte of row data to keep track of the cursor Y position and use one byte to keep track of both cursor X person and the next person to play; use the last byte for user-interface timing and various other purposes.

 

Theoretically possible, but IMHO not worth the effort.

 

A three-color 19x19 board could be handled not-to-inconveniently in 76 bytes of RAM (store five stones per byte via arithmetic coding; store 5 bytes per line). It could be handled less conveniently using 72.2 bytes (store five stones in each byte). Using 36 bytes for the kernel (16x2 store instructions, 1 rts, and three bytes that the ROM would load into the color registers during HBLANK) and 2 for the stack, that would total 111 bytes. Enough left over to handle a reasonable user interface.

 

The kernel would need five 256-byte tables to convert byte values into stone "instructions"; if such tables were used, each row of stones would require about 200 instructions to set up--entirely reasonable. I don't think game logic could very well use the packed values; it would be necessary to pack the data after each player move was selected (during which time the screen is blanked) and then unpack the data when it's the player's turn again.

[The 19x19 board]

That's right; the 9 pixel figure is just the STA. It could also be STX or STY, so we have three colors to work with, two for the pieces, and one set to the background color.

 

I think you actually get four, one of which is somewhat restricted, since the 6507 also has a "SAX" instruction that stores the quantity (A and X) without affecting either register. It might be possible to also use the PF color (so you'd have four colors of pieces plus blank squares) but I don't think that quite works out; you'd have to place different combinations of playfield and objects to yield different combinations of objects (with proper [even fixed] object placement, you could get individual control over the playfield pixels by having sprites cover up half of them on the left and half on the right, but you couldn't then hide the sprites and not have the hidden playfield pixels show through).

[The Pong Clock!]

(Seems to me this might make for a pretty good 2600 homebrew.)

 

But be sure to remember that an hour is only 215,722 frames (in NTSC). If you don't drop 4.64 frames per minute the timekeeping will be off by almost two minutes a day.

[Trails and trials]

Reading the first few paragraphs, I found myself confused by the shifting tense. You're offering a flashback, but it's not immediately clear. A couple of things that might help would be use of the past perfect tense ("I'd had lunch..." or "I had eaten lunch") and the use of adverbs or prepositional phrases to establish the time before the verbs ("Earlier, while leaving town, I'd had lunch...")

 

I wouldn't want to be so presumptuous as to rewrite things, but unfortunately I find your prose difficult to read without doing a mental rewrite to figure out what you mean. If you're having trouble trying to 'turn a phrase' to make things less awkward, I'd be more than happy to offer my suggestions (some of which are usually good, and some of which are usually terrible).

[Time, it is precious]

Of course, any suggestions on how to reduce the number of cycles required would be appreciated.  The full source is included in the attached ZIP.

 

If less than half of the memory locations that you might want to Blt to have 'stuff' in them, it may be faster to erase things after showing them on screen than to have to erase everything.

 

Alternatively, if you're trying to clear out a bunch of memory much of which is likely to be blank, and the number of bytes is a multiple of four, I'd suggest something like:

lp:
 lda $1000
 lda (ptr),y
 dey
 lda $1000
 lda (ptr),y
 dey
 lda $1000
 lda (ptr),y
 dey
 lda $1000
 lda (ptr),y
 dey
 bpl lp

By my count, that's (4+5+2)*4+3 cycles for four bytes, or 11.75 cycles/byte. I don't see room to get much better than that. Using more than one pointer could save some 'dey' instructions, but would increase the loop setup time.

 

One caveat is that when writing to the SuperCharger, you must ensure that there are no unexpected page-boundary crossings.

[Four-Play with simple AI]

Pretty nice. How are you doing the four-in-a-row checks? And how many cycles per 'loop' does your AI take?

 

Keeping vertical sync while 'thinking' is nice if you can manage it? Z26 shows 265 lines during the thought process. If you're kinda sorta keeping vertical sync (but off by a few lines) it might be nice to also show a 'thinking' message or progress indication. Don't want to do anything that would take too much CPU time of course, but something quick might be nice.

[Memory Matches, Channel F]

I was devastated by the level of functionality available in Basic Programming. I could have gotten three other games for the amount they spent on BP and I don't remember ever seeing another game for those keyboard controllers (at least never something I was interested in getting, which is a shame because I would've liked Brain Games a lot.)

 

I know we're ahead of ourselves, but one thing I was thinking awhile ago is that the Atari 2600 might have made a reasonable scientific calculator. Given that such instruments were very expensive when the 2600 came out, such a cart might have made economic sense.

[Memory Matches, Channel F]

The keypads on the 2600 aren't bad, but it seems many of the good games avoided using them because not everyone had them, and few people bought them because the games that used them were generally feeble.

[printf(" LDA #$2B \n ORA #$D4 \n");]

Gee, who would have thought the answer to Hamlet's quandry was $FF?

[Ball Horizontal Control (Part 1)]

Glad you're back.

[Catacombs of Mu]

Does the player get to do anything in this one, or is it just a kernel demo?

[Hunt & Score aka Memory Match]

I haven't played the Atari version of this game, but I think Concentration can be a worthwhile one-player game; I wouldn't fault the Atari for making one.

 

It's odd, though, that they'd use a number pad on a game that would be good with joysticks and joysticks on a game that would be better with a number pad ("Basic Math").

 

Okay, I just tried the game briefly. What a waste. Atari has already demonstrated with Blackjack that the 2600 can show six sprites on a scan line. Why can't this game show more than four numbers at a time? Or else use joystick? This cartridge is as big a loser as Basic Math, and I like "concentration"-style games.

[Hunt & Score aka Memory Match]

I haven't played the Atari version of this game, but I think Concentration can be a worthwhile one-player game; I wouldn't fault the Atari for making one.

 

It's odd, though, that they'd use a number pad on a game that would be good with joysticks and joysticks on a game that would be better with a number pad ("Basic Math").

[Brain Games]

Maybe they used the low res for the scores because they could copy the code from a previous game? In this case, "time" might have been harder to come by than code space. Interesting though.

 

Using the same code to show the sequence number and the scores would not have been difficult if the two player's scores were shown on different lines. Even with their scores on the same line, it would have been no more difficult than the 2x2 digit lores score routine. In "Combat", using high-resolution score routines would have required tracking objects' horizontal positions, complicating things. But Brain Games relocates the sprites horizontally multiple times per frame anyway, so doing a couple more wouldn't have been any extra work.

[Brain Games]

I hadn't seen this entry before. The keypads weren't terribly popular, and the cartridge is really boring without one, but it's not a bad cart for when it came out. Interesting that the game uses both high-resolution and low-resolution digits. Sorta odd, actually, since using high-resolution digits for everything would have taken less code.

[Outlaw aka Gunslinger]

Next entry: Um, gee, I honestly don't know yet. I guess we'll try Flag Capture next.

 

Do we have to !?