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

Cartridge stores return value in R0, which is used for message acknowledgement #23

Closed
ghost opened this issue Nov 28, 2020 · 3 comments
Closed

Comments

@ghost
Copy link

ghost commented Nov 28, 2020

According to cartridge.txt, the cartridge puts the return value for messages in R0 register, but from the YCPU spec, R0 is reserved for message acknowledgement (MSG_ACK, MSG_WAIT, MSG_ERROR).

Should the return value be stored in R1 or R2 instead? (In the meantime I'll use R1 in my implementation.)

@ghost
Copy link
Author

ghost commented Nov 29, 2020

I've just realized that keyboard also sends return value as response in some handler. It's at least consistent on MSG_ERROR. Perhaps I could do the same with cartridge, but it feels weird returning 1 on error, which is MSG_ACK and kind of indicate success.

@ghost ghost closed this as completed Nov 29, 2020
@ZaneDubya
Copy link
Owner

@Naryosha Would you like to propose a change to the hardware spec, or are you comfortable leaving as is?

@ghost
Copy link
Author

ghost commented Nov 30, 2020

Since mentioning that R0 could be something else rather than MSG_* would simply fix the issue, for now I'm comfortable as it is. I'll mention it in my own docs though because it's still an unofficial decision.

I see there are two ways to properly resolve this:

  1. change YCPU specs (mainly section about HWQ $02) to match hardware specs: as written above. Hardware may write to R0, R1, and R2 with anything as defined in their specs.
  2. change hardware specs to match YCPU specs: Hardware may only return MSG_* in R0. It also may not modify R1 and R2 if MSG_ERROR is sent via R0.

If I were to resolve it, it'd take some time. 😅

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant