Question regarding the DMA transfer palette effect

When I commetted out the hblank were there should be water there wasn't so I think hblank does the final transfer already as it is vblank appears to set it up in some way. I do think it would be very cool to have the left half have no water and the right half filled with water.

 

From my observations, it could be partially feasible, but not really usable, and most likely very slow.


Partially feasible because it takes a little less than one full horizontal line drawing to transfer one palette line to the vdp, so you could transfer a few colours before the right side is being drawn, but in this case, the colours transferred would progressively become visible (if, as I think, the palette isn't loaded once per line only, but I may be wrong).


But anyway, if this is really how it works, you have to begin the h-int at the top of the screen and change the palette back and forth on every single line. In other words, after the right side has been drawn, you'd have to load the original palette again before the vdp begins to draw the left side, then load again the palette for the right side.


You'd lock all the resources of the 68k for this during the entire drawing.


As a side note, although it may not be of any use for what you want to do, it is definitely possible to change the palette line of a sprite according to its position on the screen.

 

I agree with what SpirituInsanum said here.


However, in view of 'feasibility', you can change palette in the middle of scanline of course, and it will affect the display immediately, but you'll barely update even one color in CRAM as fast as one pixel draws. This means transferring data will prolong though the line and the results are hardly predictable. Old and new colors will be in a mess, you won't get anything good in the end.


But low transferring rates is only half of problem. Another half is synchronizing VDP and M68K clock in order to start transferring in time. You need to know how many M68K cycles you should wait before VDP reaches certain point of line and get processor waiting for this time. Obviously, the waiting sequence will reduce the performance way a lot, as the processor won't do anything useful during this period. I also doubt it's possible to define this number of cycles exactly, but even if you do, there can be asynchronization in PAL mode as VDP and processor run on different frequencies there. Let alone emulators, each one may have its own way of emulating timings, so I doubt they will emulate this properly.


So I would say this is beyond SMD capabilities, but even if this is somehow achievable, it'd be way too 'hackish'.

 

I would like to clear something up here, the horizontal water line trick isn't actually pulled off via DMA transfering during V-blank (The water tranfer in V-blank only occurs if the screen is completely underwater and no palette swap is required). H-blank is actually used for the horizontal water line trick, as you can pass colour data to C-Ram during the H-blanking interval (when the beam is off and moving back), ready for the next occuring scanlines to draw with the new colour data.


To try and use H-blank to change colours halfway through scanline draw is "impossible" mainly because it's the wrong time to do it, H-blank is when the beam isn't on and moving from left to right, instead it's the reverse, it's off and moving from right to left ready for the next line, as Spiritu and vlad have mentioned however, you can pull off at least something during "display" when the screen is not going through any interrupts, but controlling where the colours swap happens is almost impossible due to uncalculable timing, and transfering all colours at once is impossible due to the vastly slow speed the main processor runs at and the slow speed that the VDP takes in.


I personally wouldn't bother trying to attempt it, and I would also advise against it.