I need some help verifying some research.
Attached to this post is a test ROM I put together called Communication Workshop for experimenting with link operations. It exposes the CCR, CCSR and CDTR registers to the user for direct manipulation.
Controls are as follows:
• Left D-pad moves the cursor
• Right D-pad up/down changes the selected value
• A button on “Write” stores CCR or CCSR accordingly
• Select button reloads CCR and CCSR into the display (if this were automatic, the user’s settings wouldn’t stick)
When modifying the value of CDTR, the new value is automatically stored into the register.
If an interrupt is raised, the handler will set C-Int-Inh and CC-Int-Inh to acknowledge it and return. The “IRQ” field will immediately be updated, but the register fields must be refreshed with Select.
__________
Consulting the… shall I say, “primary literature” on the subject (you know the document I mean)… many things fall apart and it does not correctly describe the behaviors I’m observing in my experiments. I’m using a homemade link cable that DogP put together and sent me, and while I’m near certain it’s correct, part of me can’t shake the thought that something might be off.
So I come to you, the handful of you out there capable of helping me with the communication stuff… Is the following correct?
1) When initiating a communication with the internal clock selection, it will immediately process without a peer and load [font=Courier New]0xFF[/font] into CDRR.
2) When initiating a communication with the external clock selection, C-Stat will go high until the connected master unit with the internal clock issues a communication. At this point, both units exchange data.
3) When writing to CCSR, the value of CC-Rd on both units is the bitwise AND of the most recent values written to CC-Wr for both units.
4) After communication data is exchanged via CCR, the value of CC-Smp on both units is the bitwise AND of the most recent values written to CC-Sig on both units, as well as a bitwise AND with CC-Rd.
5) Does the C-Int-Inh or CC-Int-Inh bit corresponding with the source of the interrupt need to be set in order to acknowledge the interrupt? The literature says CC-Int-Inh works for both, but I haven’t tested it.
6) Setting C-Start while C-Stat is already set will have no effect.
7) I haven’t yet tested the behaviors of CC-Rd or CC-Smp with only one unit or without a pending communication on a remote unit. It’s getting late and I’m tired. I’ll do it tomorrow!
8) Will changing C-Clk-Sel while C-Stat is set abort the current communication? I’d hate to think that the link component could soft-lock itself on both units by waiting for an external master unit that will never come…
Did some more experiments today, which came with an update to Communication Workshop, attached to this post. The Sacred Tech Scroll has been updated with my findings.
1) When initiating a communication with the internal clock selection, it will immediately process without a peer and load [font=Courier New]0xFF[/font] into CDRR.
This appears to be true when another system is linked and powered on, but with it powered off or disconnected, CDRR gets garbage bits. This is unfortunate, as it makes it more difficult to automatically negotiate which unit gets to host the clock signal.
5) Does the C-Int-Inh or CC-Int-Inh bit corresponding with the source of the interrupt need to be set in order to acknowledge the interrupt? The literature says CC-Int-Inh works for both, but I haven’t tested it.
There are two distinct sources for communication interrupts: one configured via CCR and the other through CCSR. If either register’s condition triggers an interrupt, that register’s Int-Inh bit must be set to acknowledge it.
This can be tested with the new Communication Workshop. If you store [font=Courier New]0x01[/font] into CDTR, it will unconditionally attempt to acknowledge any interrupt with a write to C-Int-Inh. Similarly, [font=Courier New]0x02[/font] makes it try CC-Int-Inh. If any other value is in CDTR, interrupts will be acknowledged automatically.
The text next to the IRQ field in the output describes what happened. It will say either “CCR” or “CCSR” if a single register was needed, “Both” if both registers qualified, or “Twice” if the first attempt specified by CDTR failed and the interrupt handler was called a second time.
7) I haven’t yet tested the behaviors of CC-Rd or CC-Smp with only one unit or without a pending communication on a remote unit. It’s getting late and I’m tired. I’ll do it tomorrow!
If there is no connected unit or the connected unit is powered off, CCSR automatically behaves as though a phantom second unit has the same configuration in that register.
8) Will changing C-Clk-Sel while C-Stat is set abort the current communication? I’d hate to think that the link component could soft-lock itself on both units by waiting for an external master unit that will never come…
A communication initiated with C-Start cannot be canceled, but changing C-Clk-Sel from External to Internal will cause the normal internal behavior to carry out, even if you don’t write to C-Start.
Attachments:
1) When initiating a communication with the internal clock selection, it will immediately process without a peer and load [font=Courier New]0xFF[/font] into CDRR.
Sorry for the late reply. My observations:
If a communication operation with internal clock is started and the Virtual Boy is not connected to another system, CDRR is set to 0xFF.
Edit: It gets a bit more complicated when connected to another Virtual Boy. Will conduct further investigations tomorrow.
Further to the above:
If a communication operation with internal clock is started while connected to a powered off system, CDRR is set to 0xFF or 0x00 depending on which way round the cable is connected between the two systems. I’m not sure why this is the case.
If a communication operation with internal clock is started while connected to a powered on system, CDRR is set to 0x00.
I haven’t seen any garbage bits in CDRR.