You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the professional use-case, it's important to control all channels at the same time as possible. But I2C isn't enough fast even for pretending it.
Probably, one possible and reasonable solution for this is to allow bulk a kind of transfer. Now PSG and SCC ends accept 2Bytes write only, first byte is register and the second byte is data. But probably, it should allow 2n Bytes write, 2Nth byte is N+1th register and 2N+1 byte is N+1th data, and reflects all N write operations at once.
It may be hard in terms of CPU performance restriction, but worth considering.
The text was updated successfully, but these errors were encountered:
write 1 to 0xfe, a special register "shadow registers control". this operation copies all register values to shadow registers
while the register is set to 1, all register writes for other normal are stored into shadow registers
write 0 to 0xfe, reflect all values wrote to shadow registers
Application will set 1 to 0xfe on starting vsync period, and do register write operations as usual, then set 0 to 0xfe on ending vsync period.
It's hard to say which is better in terms of minimizing i2c bus traffic. The first one will minimize the total message size, but transaction happens at once. The second one still update registers on the go, but it effectively utilize the bus throughput.
originally proposed by @opmregisters.
In the professional use-case, it's important to control all channels at the same time as possible. But I2C isn't enough fast even for pretending it.
Probably, one possible and reasonable solution for this is to allow bulk a kind of transfer. Now PSG and SCC ends accept 2Bytes write only, first byte is register and the second byte is data. But probably, it should allow 2n Bytes write, 2Nth byte is N+1th register and 2N+1 byte is N+1th data, and reflects all N write operations at once.
It may be hard in terms of CPU performance restriction, but worth considering.
The text was updated successfully, but these errors were encountered: