Request for cloning, and a suggestion

[kervinck]

I love this, just under 1K! I didn't go over all the code, but it looks pretty neat.

Would you mind if I clone the puzzle in the Gigatron-rom repo, so I can include it as a preloaded program in its Apple-1 emulator? I will need to make a patch to bypass the SED/CLD sequence. But we've recently done that for another game already: http://forum.6502.org/viewtopic.php?f=2&t=6026 [Another patch will be to compact the instructions. Our screen is much smaller.]

Second, I don't know if you're into code density, but consider this: Each call to GETKEY is followed by a call to ECHO. You can move the ECHO into GETKEY (as a JMP) and save 7 bytes if I'm not mistaken.

I just noted because I wanted to check if your input handling would work ok in our Apple-1 emulation.

[Apologies for submitting this under my work git-account earlier... MvK]

[JeffJetton]

Hi Marcel,

Thanks! By all means clone away. That would be awesome to having it running on Gigatrons!

Yeah, keeping from going over 1K was actually a specific goal of mine. My first foray into 6502 programming was targeting the Atari 2600 (which I'm still trying to wrap my brain around), so yeah, I do appreciate code density. :-)

Love the tip and have already implemented it. Good observation. Took me a minute to figure out what you were getting at with "as a JMP". I rolled the ECHO into GETKEY and was only saving 6 bytes. Then the lightbulb went on that, if a subroutine's last statement is calling another subroutine, you can always replace the JSR with a JMP and get rid of the RTS. Of course! Brilliant!

I'm still pretty inexperienced at assembler, so those sort of tricks are great to learn. Found the same situation in two other subroutines and saved two more bytes. While I was at it, noticed a needless call to the PRNG cycling routine and got rid of that for another three bytes. So now my code is down to 998 bytes, which makes me very happy. (And yet for some reason I still wound up spending a bunch of bytes on randomized winner messages... go figure.)

Oh, as far as the smaller screen goes, there's some logic I recently put in there that redisplays the board after ERR_MAX invalid game inputs. This is to keep the board from scrolling off the screen, never to be seen again, if your cat walks across the keyboard or something. So in addition to the text changes and BCD stuff, you might want to either lower ERR_MAX or just get rid of the counting entirely and redraw after every error (as slooow as that would be).

Thanks again,

• Jeff

On Sat, Mar 7, 2020 at 5:00 PM Marcel van Kervinck notifications@github.com wrote:

I love this, just under 1K! I didn't go over all the code, but it looks pretty neat.

Would you mind if I clone the puzzle in the Gigatron-rom repo, so I can include it as a preloaded program in it's Apple-1 emulator? I will need to make a patch to bypass the SED/CLD sequence. But we've recently done that for another game already: http://forum.6502.org/viewtopic.php?f=2&t=6026 [Another patch will be to compact the instructions. Our screen is much smaller.]

Second, I don't know if you're into code density, but consider this: Each call to GETKEY is followed by a call to ECHO. You can move the ECHO into GETKEY (as a JMP) and save 7 bytes if I'm not mistaken.

I just noted because I wanted to check if your input handling would work ok in our Apple-1 emulation.

[Apologies for submitting this under my work git-account earlier... MvK]

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JeffJetton/apple1-15-puzzle/issues/2?email_source=notifications&email_token=AAXSTVKC4IK36MWF2VVIR4DRGLGXJA5CNFSM4LDTXXB2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ITKUIUA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXSTVPIE4ULO4O2DPX6L7TRGLGXJANCNFSM4LDTXXBQ .

[JeffJetton]

BTW, if it would be helpful for me to pare the program down further just let me know. Happy to spin off a "lite" version if it would fit the ROM better.

[kervinck]

I happen to have a hole in the memory from $400 to $800, so it will fit. I won't make more local changes than needed to get it running within the Gigatron constraints...

Your posting made me happy, because at exactly that time I was trying to trim down WUMPUS to under 2K (to fit in the BASIC area $800 to $1000), but it was going to be tedious. Your game is a much nicer replacement. With that we have with MASTERMIND probably the oldest game, and with the 15 puzzle the newest release on the Apple-1 platform! It's perfect.

[JeffJetton]

For fun, here's my attempt to rewrite INCMOVE to avoid BCD mode, yet still use a two-byte counter (since a player can easily make > 99 moves on a hard puzzle). Based on that wonderful method from your link, but uses an X offset and sets the carry flag:

INCMOVE SUBROUTINE  ; Increments the two-byte BCD move counter
        ldx #MOVELO
        jsr INCBCD
        bcc .done
        ldx #MOVEHI
        jsr INCBCD
.done   rts

INCBCD  SUBROUTINE  ; Increments a single BCD value at zero-page address X, but
                    ; without actually using BCD mode. Affects carry flag and A.
        inc 0,X
        lda 0,X
        and #$0F
        cmp #$0A
        bcs INCBCD
        lda 0,X
        sec
        sbc #$A0
        bcc .done
        sta 0,X
.done   rts

This adds 17 bytes to the BCD-mode version. Perhaps could be improved?

[JeffJetton]

Ah yes, it can. For this game, something like the following is probably much better. It only works up to 999, but if any player winds up with that many moves, they've got bigger problems than an inaccurate move counter. :-)

Only six more bytes than the original, BCD-mode routine:

INCMOVE SUBROUTINE      ; Increments the two-byte BCD move counter,
                        ; without using BCD mode, up to 999
        inc MOVELO
        lda MOVELO
        and #$0F
        cmp #$0A
        bcs INCMOVE
        lda MOVELO
        sec
        sbc #$A0
        bcc .done
        sta MOVELO
        inc MOVEHI
.done   rts

[kervinck]

Just to let you know, I already cloned (grafted) your tree, and started working. There are new issues on the emulation side I'm solving, but maybe also on the puzzle side. Currently I'm tracing a crash in the middle of the instructions string. That should be emulation side, although I'm clueless on what causes it. I already ruled out a stack overrun. I can spend only few hours each week, so bear with me.

[JeffJetton]

Interesting. Well just let me know if it turns out to be my fault. :-)

[kervinck]

For your reference, I've just completed the integration for my TTL emulation. Two changes might be interesting to port back. The space after the move number, and the jump back to the welcome message/instructions after ERR_MAX bad inputs.

Commit is here: https://github.com/kervinck/gigatron-rom/commit/4eec793c1c09744fa38f7640d2048a4d228c4533

    Apple-1: Integration of 15-PUZZLE

    Gigatron-specific changes:
    - Replace INCMOVE with code that doesn't use BCD mode
    - Accomodate for smaller screen
      - Reduce ERR_MAX from 9 to 8
      - Be more economical, but consistent, with newlines
      - Squeeze instructions into 6 lines
      - Shorten INVALID CHOICE message to SORRY
      - Split win-message over 2 lines
    - Start from $400
    - Jump to $C100 on exit, so we go through the emulator menu again

    General changes:
    - Put a space after the move number for readability
    - Go back to welcome and instructions after ERR_MAX wrong entries

    Total size: 984 bytes

Online emulator here: https://marcelk.net/gigatron/apple-1/

Screenshot:

[JeffJetton]

Looks great!