Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[REQUEST] 65816 16-bit processor support for DASM #106

Open
TheRealHamtaro126 opened this issue Nov 6, 2020 · 1 comment
Open

[REQUEST] 65816 16-bit processor support for DASM #106

TheRealHamtaro126 opened this issue Nov 6, 2020 · 1 comment
Labels
enhancement New feature or request

Comments

@TheRealHamtaro126
Copy link

Hey there, I tried this assembler before, and it has improved from the days of old where it had no INCBIN, now it has INCBIN... So proud, But that is not why I am here...

Ever since new processor options came built-in to this assembler, hoping for someone to add 65(c)816 support to the latest version. with complete opcode support. used in the SNES, Apple ][GS, and the Commodore 64, as well as some homebrew experiments.

Can it really be supported?

@thrust26 thrust26 added the enhancement New feature or request label Apr 13, 2021
@thomas374b
Copy link
Contributor

thomas374b commented Apr 13, 2021

This task could be in the range from "easy" to "complex".

  1. find out which processor-definition in dasm is the closest match
  2. find out which opcodes/mnemonics have been added with this CPU-variant
  3. find out which addressing modes have been added with CPU-variant

If there are no new addressing modes (compares to what is already implemented) the task is (easy) only to define a new processor, copy paste one of the mneXXXX.c files and edit and finally test it.

If new addressing modes or some fancy bit-branching comes with the new processor, the task would be rather "complex".
Dasm has already support for "some fancy bit-branching" for some processors. Good if the new processor could be somehow "fitted" in the existing implementation. More complex if it can't.

Alternatively one can start with a subset that includes all already implemented addressing modes and add the more complex mnemonics later. If some of the not-yet-implemented mnemonics are needed, they could be replaced by macro definitions from the user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants