Re: [stella] Euchre: a tight fit

Subject: Re: [stella] Euchre: a tight fit
From: "TwoHeaded Software" <adavie@xxxxxxxxxxxxx>
Date: Tue, 4 Sep 2001 10:12:44 +1000
You can save a fair bit by junking the LetterImageTable and calculating the
address instead of looking it up.  This requires the letters to be defined
in a set order, but that's not a big limitation.  Replace...

    lda LetterImageTable,x
    sta $00,y
    lda LetterImageTable+1,x
    sta $01,y


    adc #<LetterImageSpace
    sta 0,y
    lda #>LetterImageSpace
    adc #0                                            ; can be omitted if
LetterImage stuff doesn't cross a page
    sta 1,y

This loses 1 byte in the routine, but junks the LetterImageTable, saving a
total of 65 bytes or so.
The same thing can be done with the other tables indexing data of known

eg: ScoreImageTable indexes 5-byte entries, so

    stx temp
    adc temp
    adc #<ScoreImage0
    stat 0,y
    lda #>ScoreImage0
    adc #0                                    ; can be omitted if ScoreImage
stuff doesn't cross a page
    sta $01,y

This should save something like 25 bytes.
Same can be done with RankImageTable.  Another mmh.... 15 bytes or so.

As Thomas said, LOTS of space to be saved.


Andrew Davie, TwoHeaded Software

----- Original Message -----
From: "Erik J. Eid" <eeid@xxxxxxxxx>
To: "Stella Listserv" <stella@xxxxxxxxxxx>
Sent: Tuesday, September 04, 2001 7:01 AM
Subject: [stella] Euchre: a tight fit

> I've been working on incorporating the actual play of a hand of Euchre
> my game.  I nearly finished adding the code that would allow a full hand
> be played, counting up tricks, scoring the hand, and let the human player
> select a card with the paddle.  The computer, for now, would just pick the
> first available card from its hands.
> When I finally compiled the code, I got this message from DASM:
> "segment: code fb00      vs current org: fc14"
> "line 2281 D:\Atari2600\Euchre\Euchre.asm Origin Reverse-indexed"
> I'd gotten this once before after I added a couple of new messages and
> digit images.  It means that my code crossed over an org boundary that I
> set up.  In the case mentioned above, my code has overlapped code that is
> set to start at $fb00 by 276 bytes.  This is without adding in the
> intelligence for the computer to play a hand!
> Needless to say, I'm in a bit of a tight spot.  I still want Euchre to be
> 4k game.  This means something has to give.
> I don't believe that I have room enough at the end of the pages that I
> set aside to cram in some utility code - certainly not 276 bytes'
> worth.  Since I haven't finished adding everything in, my problem will
> even more later, so trying to push chunks of code into little spots isn't
> the whole solution.
> What I need from readers of the list is some advice as to what I can trim
> from my code.  I'm looking for a general strategy, though advice about
> specific segments of code is certainly welcome.
> One prime candidate for trimming is the user interface.  The text messages
> that appear at the bottom of the screen, while they inform the player
> may be too expensive.  The definition of each letter takes eight bytes,
> plus two bytes for inclusion in a table of letters, for a total of ten
> bytes.  With 26 letters plus some other symbols, this can push 300
> bytes.  I could get rid of the message area at the bottom and just have
> symbols or short words appear near the card of a player.  "Pass", for
> instance, can fit into two sprites if each letter is only four bits
> wide.  Of course, having messages potentially appear in more than one
> location could be expensive in terms of code to display them.
> Another candidate for trimming is the computer's intelligence.  I'm
> reluctant to reduce that at all because I'd like to have a game that
> provides a worthy opponent.  Backgammon, Bridge, 3-D Tic-Tac-Toe, and
> Chess all manage on 4k (as far as I know).  Euchre should be no different
> (particularly because Euchre is a much less complex game than Bridge).  I
> should not need much more code than what is already in place.  With only
> five cards to choose from at most and a requirement to follow suit, the
> amount of choices available to a computer player during play are small.
> far as deciding whether to accept or call trump or not, a lot of "thought"
> goes into judging whether or not the team can reasonably take three out of
> five tricks.
> I might be able to save some bytes by reading the joystick, which is only
> one read per frame, versus reading the paddle, which is many reads per
> frame.  However, some overhead would be added because I'd need to always
> track the current selection so that the cursor moves to the right
> one.  With the paddle, the paddle's location always determines the
> There are probably other areas in which I can shave off a few
> bytes.  However, given that I'm now over by a page and essential game play
> elements aren't finished, not to mention fancier features (sound and a
> title screen), I need to cut out and/or optimize a significant amount of
> I've attached the current source, which will not compile successfully.
> advice as to what I can reasonably cut out and how I can make the code
> efficient will be greatly appreciated.
> Thank you all very much!


>     .      .     \_ +\_ + o_-/     .   O
>       .            \-_o -=/-   .          .
> .           .        \=//  .
> ---------\_______     ||O        ___.______
> /* Erik Eid */   \____||L/\_____/
> /* eeid@xxxxxxxxx */_______________________

Archives (includes files) at
Unsub & more at

Current Thread