VASYL & access to system bus

[abbruzze]

I would like to understand how VAYSL behaves when accessing the system bus (for example when it executes a MOV towards a VIC register) and how it can "halt" the CPU as mentioned in the FAQ.

Another point: according to the Instruction's doc., MOV will be delayed in case VIC is fetching data (e.g. badline or sprite). Is it the same for XFER (in the documentation is not mentioned)?

Any write to VIC-II register will be postponed until the access is physically possible, i.e. until VIC-II is willing to listen to us. This means that XFER, MOV and BADLINE can stall while they are waiting for AEC line to go up.

Once VIC-II is available, BeamRacer will first separate system and local buses (address and data, see https://docs.beamracer.net/lib/exe/detai...iagram.png). On the local side, the write proceeds as usual - first with a write to the address bus and VIC-II CS and RW lines getting asserted, followed by a write to the data bus.

6510 continues unimpeded on the system bus side, and if it does not want anything from VIC/VASYL IO address space, it will not lose any cycles. However, if it accesses $d000-$d3ff, it will be halted until VASYL is done writing to VIC-II, which may be arbitrarily long (e.g. if the display list makes a sequence of VIC-II writes in successive cycles). BTW, technically the 6510's RDY line is going HIGH at the beginning of every stopped cycle and stays there until VASYL completes its instruction fetch and determines what it will be doing later in the cycle, at which point RDY may go LOW again. But I believe this is irrelevant from the viewpoint of an emulator (correct me if I am wrong).

Now, if the 6510 was trying to make a write access, it naturally won't stop immediately, but merrily push forward. BeamRacer cannot use VIC-II's approach of asserting RDY ahead of time, because display lists are dynamic and VASYL only finds out what needs to happen once it fetches and decodes its current instruction. It cannot let the CPU make the access either, because that would mean postponing display list's write access and likely result in a visual glitch.

So what happens is that 6510 is allowed to continue, and the writes by the CPU and by VASYL happen concurrently. The system and local buses are isolated, so VASYL write gets to VIC-II, while CPU write gets recorded by BeamRacer and preserved for future use. When the time comes for the CPU to run again, it will need to wait one more cycle, during which the previously recorded write access is replayed to VIC/VASYL.

In other words, VASYL writes always have priority over CPU writes.

Thanks for your clarifications: I already figured out the problem with CPU writes. I will (if possible) try to resolve this scenario after all others will be ok.
Anyway, now I have I doubt about BADLINE. 
Below what I understood so far (wihout AEC handling):

1. it doesn't wait for condition, after the beam check the VASYL will execute the next instruction
   
   
2. if the target raster is reached that raster line becomes a badline
   
   
3. Otherwise, all the other rasters between become non-badline. So, for example: VIC is on raster 100, VASYL executes BADLINE 2 => raster 100 and 101 become non-badline while raster 102 becomes a badline.
   

Now, if the execution continues with the next instruction, does it mean that VASYL remembers that it has to force a badline or a non-badline according to raster line target (as I do in the emulator) ?
Where, in this process, AEC signal is checked ?

Thanks in advance.