Page 2 of 2

Re: VERA DMA

Posted: Mon Jan 06, 2025 2:20 am
by cosmicr
Slight change of subject but does the emulator "emulate" vsync? Because I've not used the proper hardware and have never had any issues with vblank timing like screen tearing etc.

Re: VERA DMA

Posted: Mon Jan 06, 2025 4:20 pm
by doslogo
cosmicr wrote: Mon Jan 06, 2025 2:20 am Slight change of subject but does the emulator "emulate" vsync? Because I've not used the proper hardware and have never had any issues with vblank timing like screen tearing etc.
Yes, it is emulated.

Even if you haven't had any issues, it is recommended to always be prepared for screen tearing. That means, set your IRQ vectors, and have a proper wait for vsync loop (with a WAI if you don't plan to use IRQ_LINE), and do all the updates to palette, tilemaps, sprites and art in your vblank, and hope you have time before the active display starts again. If you don't have time, like me, use extended borders, and make sure the palette is updated first in vblank since that gets reflected in the border color.

If DMA gets implemented (seems like a 0% chance right now), it would speed up everything without affecting programs and games that wouldn't use it, and everyone would benefit from it! To me, that would be worth the extra cost.

Re: VERA DMA

Posted: Wed Jan 29, 2025 5:13 am
by DragWx
DragWx wrote: Tue Dec 24, 2024 5:22 am Check my work, but this should transfer a full 1024-byte sprite table to the VERA in 8807 CPU cycles.
Nobody spotted my mistake. ;)

One LDA/STA pair is 6 bytes. Repeated 32 times, that's 192 bytes, so that branch is out of range. It's simple to fix though, change DEX BPL next to:

Code: Select all

 DEX
 BMI :+
 JMP next
:
; =7 Cycles, -2 on final loop
So, the total cycle time is now 8870, which will still do the trick, and frees you up from needing to prevent a branch from crossing a page (well, it's still a +1 cycle penalty, but that's better than +32).