Jump to content
IGNORED

Copper (raster) bars


Asmusr

Recommended Posts

I have been poking around with bitmap mode color settings to have bars which go behind then over text. Simply using the color table to change the background color (if behind) or the foreground and background color (if in front of) the text. I have been trying to get the 5th sprite bit to work in the borders to make this sync up but have not had much luck any success. Your demo looks like a Picasso compared to the dreck I have put together so far icon_smile.gif

 

I had a thought yesterday. We are doing everything re-actively in an interrupt (assuming here, as I have not looked at your code,) but would it be possible to cycle-count to get effects -- "chase the beam" like on the 2600? What about an interrupt that happens a scan line ahead of the color change we want giving us time to find another synchronization event so the changes occur exactly when we want them?

 

As for splitting the scan line at arbitrary positions, I remember a LOT of C64 demos with not-so-perfect raster effects which look far worse than your demo (which I see as fine in Classic 99.)

Link to comment
Share on other sites

I had a thought yesterday. We are doing everything re-actively in an interrupt (assuming here, as I have not looked at your code,) but would it be possible to cycle-count to get effects -- "chase the beam" like on the 2600? What about an interrupt that happens a scan line ahead of the color change we want giving us time to find another synchronization event so the changes occur exactly when we want them?

 

I am indeed chasing/racing the beam here. The loop goes something like this:

Repeat forever {
  Wait for vsync
  Prepare table of colors for each scanline
  ypos = 0
  While (ypos < 192) {
    Set up 5 sprites on a line at ypos
    Wait for the 5th sprite flag to clear
    Wait for the 5th sprite flag to set
    Change the background color
    ypos = ypos + 2
  }
}

The F18A has both a scanline interrupt and a trigger to start the GPU each time a scanline has been drawn, but I don't know how you would generate an interrupt on a 9918A machine?

Link to comment
Share on other sites

Could you use the 9901 as an auxiliary timer? Its decrementer counts down every 21.3 µs (3 MHz / 64), and it is wired to the interrupt inputs of the CPU.

 

That's about 3 times per scanline so I guess the resolution is OK, but it would not be in sync with the beam. And polling the 5th sprite flag only takes 46 clock cycles according to my calculations, so it has both higher resolution and is in natural sync with the beam. What's not clear to me is whether there is a best x position for the 5th sprite in order to get the cleanest split?

Link to comment
Share on other sites

To show the raster/color bar in front of the characters/text, would something like this work : Set up a second color table with transparent fore and background for the affected patterns. When the 5th sprite flag is set, change both the background color and point to the alternate color table. Revert to the primary color table when no color bar is being displayed.

Link to comment
Share on other sites

To show the raster/color bar in front of the characters/text, would something like this work : Set up a second color table with transparent fore and background for the affected patterns. When the 5th sprite flag is set, change both the background color and point to the alternate color table. Revert to the primary color table when no color bar is being displayed.

 

Yes that should work provided there is enough clock cycles available. We only have about 360 clock cycles for two scanlines, and it takes around 52-62 clock cycles to set up a register depending on the method. Probably a lookup table with the color table for each scanline would be the fastest, to prevent spending time on logic,

  • Like 1
Link to comment
Share on other sites

 

Yes that should work provided there is enough clock cycles available. We only have about 360 clock cycles for two scanlines, and it takes around 52-62 clock cycles to set up a register depending on the method. Probably a lookup table with the color table for each scanline would be the fastest, to prevent spending time on logic,

 

 

post-25764-0-03589100-1488240748_thumb.png post-25764-0-12804900-1488242778_thumb.png

 

Seems to work :) I set up a second color table, with all color attributes set to >00 (transparent on transparent). During the frame loop, immediately after the backdrop color VR#7 is changed to what is in the bar table, the bar color in R7 (MSByte) is tested. If 0, VR3 is set to the primary color table; if <>0, VR3 is set to the transparent color table. (Edit: I should have mentioned this is running on a Geneve. In emulation, it is clean; on real hardware, the bars are there, but the screen has artifacts and general ugliness. On a TI, the raster bar size might need to be expanded to account for the extra cycles). Notes:

* during frame - change backdrop and color table VRs
       MOVB *R7,*R14   ; don't inc R7 yet; 36 register value
       MOVB R6,*R14   
       MOVB @CLRN,*R14   force the current color table here
       MOVB @CLRN+1,*R14
       MOVB *R7+,R0   check raster color and increment table pointer
       JEQ   NORAST
       MOVB @CLRR,*R14   use transparent color table
       MOVB @CLRR+1,*R14
* end of changes
 
* These four bytes could reside in PAD and pointed to be register, if needed.  (R15 and R1 appear to be free during FRAME)
CLRN   BYTE >2C,>83   base color table, reg 3
CLRR   BYTE >2D,>83   transparent color table, reg 3   (copy the table into VDP during setup; or just clear the 32 bytes)
 
Edited by InsaneMultitasker
  • Like 2
Link to comment
Share on other sites

That's about 3 times per scanline so I guess the resolution is OK, but it would not be in sync with the beam. And polling the 5th sprite flag only takes 46 clock cycles according to my calculations, so it has both higher resolution and is in natural sync with the beam. What's not clear to me is whether there is a best x position for the 5th sprite in order to get the cleanest split?

This is something that's still unknown to me, too, and I don't know if we'll ever be able to prove it - whether the VDP makes the flags available mid-scanline or only at the end of the line. I guess mid-scanline makes the most sense since delaying it would cost extra gates. :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...