| |
Monte Carlos
Registered: Jun 2004
Posts: 351 |
Left/Right Border switching in middle of rasterline
The last days i experimented a little with bit 3 of $d016. I had the brainfart to broaden the border on the left and keep it normal on the right. Disappointingly, this seems to work only in every non badline. If i try to switch bit 3 of $d016 during a badline i either get both left and right borders equal or i turn off the border completely for the next rasterline. Does somebody have an explanation in terms of internal VIC timing? I also tried modifying the timing with sprites or HSP to be able to write to $d016 in the correct cycle. |
|
... 42 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Quote:DMA usually refers to speed up copying between memory and a true I/O device, or memcopy, etc. usually involves a DMA controller too.
DMA usually refers to "direct memory access" - which is when anything that isn't the main CPU accesses the memory (without CPU intervention). no more no less. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
EDIT: Nothing (but I certainly agree wth Gpz, Lft and others) |
| |
Monte Carlos
Registered: Jun 2004
Posts: 351 |
I now tried the line doubling trick. By decreasing $d011 by one on the right side of the line before the natural badline, the timing can be adjusted so that the left border is broad and the right is small (at least in x64sc). This applies to the first rasterline of the charrow duplicate. However, in the duplicated charrow an idle byte appears in column 39.
However, this could be fixed by using a modified charset with the last char having the desired pattern. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: I now tried the line doubling trick. By decreasing $d011 by one on the right side of the line before the natural badline, the timing can be adjusted so that the left border is broad and the right is small (at least in x64sc). This applies to the first rasterline of the charrow duplicate. However, in the duplicated charrow an idle byte appears in column 39.
However, this could be fixed by using a modified charset with the last char having the desired pattern.
Although I believe we got x64sc mostly right, make sure to verify that on a real c64 first. |
| |
Mixer
Registered: Apr 2008
Posts: 422 |
Picture or screen capture would be worth a thousand words. |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
I guess you could also make the left border small and the right border broad instead. Do you also see an idle byte then? |
| |
Monte Carlos
Registered: Jun 2004
Posts: 351 |
The idle byte seems to be independent of how the border is displayed. Of course i test it on the real thing, however i transferred last time before i made my initial post.
At this time x64sc and my 128D in 64 mode showed same output.
Sorry, the code is on my 13" notebook already packed to use the noon break on work for coding..
I can upload a screenshot tomorrow. |
| |
Monte Carlos
Registered: Jun 2004
Posts: 351 |
Ok, this works. Just follow the link
https://www.dropbox.com/s/4itioa1abhl6oc3/leftBroadRightSmall.P..
Meanwhile i tested it on original. It works and it has the same output as x64sc. You got it right. |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Cool. The idle byte seems to be shifted down by 1 line. Where does it get its color from?
Can't you hide it by making the right border broad instead? |
| |
Monte Carlos
Registered: Jun 2004
Posts: 351 |
From the lo nibble of the opcode following the st? $d011 (?=a|x|y). |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next |
