Hi, d030 register is a bad idea if you ever want to put this in c128 :) https://docs.beamracer.net/doku.php?id=registers Regards, Zoran On 5/28/20 10:15 PM, silverdr_at_wfmh.org.pl wrote: > >> On 2020-05-28, at 16:56, Rainer Buchty <rainer_at_buchty.net> wrote: >> >>>> How is the bus then shared between CPU and VASYL in case of competing CPU accesses, e.g. when VASYL cares about rasterline splitting and the CPU moves around sprites? >>> When CPU wants to access the VIC, while VASYL is in charge, request from the CPU is buffered and replayed once VASYL is done. CPU needs to wait until that's finished. >> So VASYL has precedence over the CPU? > Yes. Of course you can turn the display list processing off any time you need. > >> Hypothetical example: VASYL does some funky rastersplitting while the CPU does sprite multiplexing. How would that affect the latter? > First of all in most cases using CPU to do sprite multiplexing would be a waste because most of the display related stuff can be offloaded to VASYL. You may want CPU to modify some display list params on the fly but you shouldn't need to do the plexing itself. Still let's assume that you want anyway. Since you program both the CPU and VASYL you know when (within the raster frame) VASYL is going to do what. You need to time your CPU accesses into those cycles, which are not occupied. If it still happens that you hit an already occupied cycle, your CPU access will have to wait until VASYL is done. > >> Or is there generally enough time, particularly with the CPU taking at least 4 cycles for an STx, so that this is a rather academic example -- and with e.g. "split the line every 8 pixels" the bus is just maxed out similar to conventional exhaustion of rastertime? > I am not sure I understand correctly but generally VIC reacts to the bus changes only once per PHI0 cycle. If you use all those cycles then there is no time for anything else anyway. >Received on 2020-06-02 05:00:03
Archive generated by hypermail 2.3.0.