Suggestion: add an `opcode` function that returns the value of the given opcode about rasm HOT 5 CLOSED

I love the idea because it allows somehow more "readable"/"maintainable" code in theory.
In practice because opcode can be more than one byte, I understand that it causes complexity and promise of maintainability of the assembler program itself weighs against. ¯\_(ツ)_/¯

What I would do as a user is have an independently generated, ready-to-use table of name-for-Z80-opcodes-that-fit-on-one-byte and use those names.

from rasm.

thanks for the opcode file, i puted it in a "resources" folder

from rasm.

i think it's too messy in order to be friendly and convenient to use, mostly because opcode may have "any" size

from rasm.

anyone can propose some kind of "best includes for you" like "amstrad_firmware_calls.inc" or "opcodes_bytes.inc"

from rasm.

anyone can propose some kind of "best includes for you" like "amstrad_firmware_calls.inc" or "opcodes_bytes.inc"

Well, "anyone" can be me.

@rgiot, you will find on https://github.com/cpcitor/cpc-dev-tool-chain/blob/master/cpclib/cdtc/asminclude/cdtc/z80_syms_for_opcodes_first_byte.s a generated table.

It uses the sdasz80 syntax (because it is part of cpc-dev-tool-chain which existed before rasm), but it is very easy to change all .equ to EQU or whatever you want.

As you will see, it somehow does more than you expected, as it additionally provides names that ensure opcode meaning and visible hex value are always in sync.

"amstrad_firmware_calls.inc"

I might make something similar one day.

As a side effect of making a C-level wrapper to the firmware routines, some are in https://github.com/cpcitor/cpc-dev-tool-chain/blob/master/cpclib/cfwi/src/fw_nowrapperneeded.s

from rasm.