KhanTyranitar wrote:
When the CPU attempts to read those registers it simply fetches them from this buffer.
This will not work e.g. if someone uses SID's internal fibonacchi generator for pseudo random numbers, or accessing VIC's vertical line register to wait for a specific line.
The register itself will change constantly, content of buffer not.
KhanTyranitar wrote:
Then when it writes to those registers the buffer is updated and it pushes the changes to the 1 MHz bus on a FIFO basis. This way the CPU never needs to slow down for anything.
Video effects require cycle accurate changing of registers. Your solution might generate extra headache to accomplish that. (But one might consider that as extra challenge...)
KhanTyranitar wrote:
And if an interrupt is generated by a device on the 1MHz bus then the registers corresponding to that device get force updated. That way registers such as sprite collision and raster interrupts will work.
Besides there can be lots of reads independed from IRQ, there is not sufficient time for that:
Even if force update is limited to registers that can change, and even only refresh buffer of the chip that requested IRQ, you will have to read five registers. That is 5*20 cycles for your '816 - which might happily be done with ISR in that time frame.
What you might do instead: constantly refresh your buffer. So every ten VIC/SID cycles buffer is up-to-date. You even could refresh horizontal line register every other cycle, that should be accurate enough. If you detect horizonzal sync and trigger refresh it could be possible to keep buffer fully up-todate. But CPU writes might disturb this process.
Speaking of horizontal sync - an alternative would be to build an external raster counter, no need to read VIC's internal register. Shouldn't be to complicated to keep external and internal counter content in sync. By that far less buffer refresh would be necessary.