Skip to content

Very little space to spare on 6502 #124

Open

Description

@dstelzer

The 6502 engine needs to fit within $f800 bytes on Apple II, because it goes in the language card area.

Unfortunately, we're very close to that limit. I added a new opcode in #123, which cost about a hundred bytes, and that was too much.

I'd thought removing the CSS parsing would buy us plenty of space, but since that was part of the loader rather than the engine, it doesn't seem to have done so.

Is there anything we can sacrifice for more breathing room? I'm sure the new opcode I'm experimenting with could be made smaller, but I doubt this will be the last opcode we ever add.

Activity

  1. dstelzer commented on Oct 17, 2026

    @dstelzer
    ContributorAuthor

    Tagging @sehugg as the expert on the Apple II version.

  2. sehugg commented on Oct 17, 2026

    @sehugg
    Contributor

    The engine is tricky because it's partially in the language card area. You could move some engine code out of the engine_reloc/himem_start block and see what it gives you. Then you might have to increase the .assert SAVEADDR limit.

    Another thing about the engine -- the opcode list is page-aligned, so you risk wasting 1-255 bytes every time you change it, and you might have to move things around again. It would be nice if a smarter assembler could solve the Sudoku puzzle for you.

    I think there are plenty of optimizations still to be made, but to find 100 bytes might take 100 optimizations :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions