You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 :)
Activity
dstelzer commentedon Oct 17, 2026
Tagging @sehugg as the expert on the Apple II version.
sehugg commentedon Oct 17, 2026
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_startblock and see what it gives you. Then you might have to increase the.assert SAVEADDRlimit.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 :)