hth313 / Calypsi-tool-chains

Overview of the Calypsi tool chain and open source support packages
16 stars 0 forks source link

Adding an intrinsic function for the 65816's COP instruction #31

Closed ProxyPlayerHD closed 7 months ago

ProxyPlayerHD commented 11 months ago

title says it, looking into intrinsic65816.h there are functions for directly placing special instructions like SEI, CLI, WAI, STP, and BRK. but COP seems to be missing for some reason.

it would be nice if it were added, on that same note it'd also be useful if both the COP and BRK functions were to take a single char argument since both instructions are technically 2 bytes large and some programs (like my SBC's ROM) use the second byte as a signature/parameter for system calls and similar.

so as example the header could have these:

__attribute__((intrinsic)) void __break_instruction(unsigned char signature);
__attribute__((intrinsic)) void __cop_instruction(unsigned char signature);
hth313 commented 11 months ago

There is no compelling reason to why it is missing, I suppose I was not sure how people actually use this instruction. I can add such intrinsic and I probably need to make use of a different name for __break_instruction() to make it take an argument for backwards compatibility reasons.

ProxyPlayerHD commented 11 months ago

well COP is functionally identical to BRK, it also has it's own vector. both are useful for system calls, similar to jump tables in older computers like the C64. but unlike jump tables you don't have to worry about their placement in RAM/ROM as vectors are always in the same location.

hth313 commented 11 months ago

I have not looked into it in depth, but my assumption is that cop was meant for allowing external hardware to add specific behavior so it may have some difference at the hardware level. If such hardware is not in place (and I suspect it was never really used for such) then it acts like brk using a different vector.

ProxyPlayerHD commented 11 months ago

yep. the intension was to have external hardware sit between the CPU and memory and pass everything through. once the hardware detects COP is being fetched it would feed the CPU NOPs or other instructions to basically use the CPU as a glorified counter to read operand bytes after COP. once done it would stop feeding the CPU NOPs and execution continues like normal. with no hardware in place it would simply read the COP opcode and jump to the vector, doing some software equivalent of the hardware operation, or reporting an error.

either case AFAIK it was never used as the amount of external hardware/logic required to make it work is pretty high. especially for back in the day.

hth313 commented 7 months ago

This has been implemented in version 5.1 which is available. I will close this.