+- Beam Racer Forum (https://forum.beamracer.net)
+-- Forum: BeamRacer (https://forum.beamracer.net/forum-1.html)
+--- Forum: Programming (https://forum.beamracer.net/forum-3.html)
+--- Thread: PBS S_UPDATE register (/thread-67.html)
PBS S_UPDATE register - abbruzze - 2020-09-28
Hi all,
I'm refining the Kernal64's emulation of BeamRacer and I would like to have more details about the S_UPDATE register of PBS.
I read the Programmable Bitmap Sequencer manual but I didn't see any reference to this register.
Soon I will publish some snapshots taken from the emulator (already shared with silverdr that I want to thank for his precious support).
Thanks.
RE: PBS S_UPDATE register - laubzega - 2020-09-29
Hello and welcome to the forum!
This is how it works: first, register S_BASE has an internal copy that is extensively used during all PBS operations. Let's call this copy bitmap_pointer, so we do not confuse the two. S_BASE is copied to bitmap_pointer whenever a value is written to S_BASE_H. So:
MOV VREG_PBS_BASEL, $30 ; bitmap_pointer is unchanged
MOV VREG_PBS_BASEH, $78 ; bitmap_pointer is $7830
MOV VREG_PBS_BASEL, $53 ; bitmap_pointer is $7830
MOV VREG_PBS_BASEH, $12 ; bitmap_pointer is $1253
MOV VREG_PBS_BASEH, $4a ; bitmap_pointer is $4a53
The reason for this behavior is that otherwise it would be impossible to avoid glitches during the cycle when one part of the address has been changed, while the other did not. This mechanism allows the 16-bit address to be switched instantly.
As a side note: alternative solution would be to use a strobing register (like with VREG_DLIST[LH]), but that would require 3 cycles for an address update. Considering that it may have to be performed frequently, it would be one too many.
bitmap_pointer is automatically updated by PBS whenever a cycle step occurs or an end-of-line padding needs to be added. Given how busy PBS can become, soon bitmap_pointer gets very different from what was written to S_BASE. Yet, in some situations it is beneficial to transfer the current value of bitmap_pointer's lower byte to S_BASE_L, so that during the next manual update of S_BASE_H it can be preserved. With PBS_CONTROL_UPDATE_NONE, we get this:
MOV VREG_PBS_BASEL, $00 ; bitmap_pointer is unchanged
MOV VREG_PBS_BASEH, $78 ; bitmap_pointer is $7800
DELAYH 3 ; assume PBS is active and S_STEP is equal to 1:
; when DELAYH finishes, bitmap_pointer is
; equal to $7803.
MOV VREG_PBS_BASEH, $54 ; bitmap_pointer is $5400
If this code was executed with PBS_CONTROL_UPDATE_ALWAYS selected, the final value of bitmap_pointer would be $5403, because the PBS was updating S_BASE_L with the value of lower 8 bits of bitmap_pointer every cycle.
Now it is easy to guess what PBS_CONTROL_UPDATE_EOL does - it updates S_BASE_L with the value of lower 8 bits of bitmap_pointer when PBS finishes fetching a line - that is, when current cycle is S_CYC_STOP.
What is the use of these controls? Briefly, they are handy when building synthetic modes that augment PBS with heavy dose of display list programming. They will be described in the next chapter on PBS, tentatively scheduled for release this upcoming weekend.