More than 2 colors per card...

[artrag]

During the rendering of the screen, the raster takes 57 CPU cycles to complete a single scan line (according to INTERRUPT.TXT by Joe Zbiciak)

During the rendering of the screen the back tab ram stay accessible to the CPU.

 

It is, thus, possible to change the value of a tile in the back tab during while it is being plot, even more than once.

 

Writing cycle accurate code is possible, where a loop of exactly 57 cycles is, e.g. this

 

REPEAT 3

NOP          ; 6

NOP          ; 6

TSTR R6    ; 7

ENDR        ; 3*19 = 57 cycles

 

 

You could have the upper part of a tile with a couple of colors, then change its colors after two scan lines, then change its colors after other two scan lines and then change its colors after other two scan lines.

 

The card would have 8 colors... two per lines

Hard but not impossible

[artrag]

It would be interesting to study what you can do in color stack mode by changing the stack advance flag while a tile is being plotted.

It could be a way to change the background colors of a whole line of tiles many times per tile.

 

[+DZ-Jay]

3 hours ago, artrag said:

It would be interesting to study what you can do in color stack mode by changing the stack advance flag while a tile is being plotted.

It could be a way to change the background colors of a whole line of tiles many times per tile.

 

 

The problem is that the STIC does not give you direct access to the raster timing, nor does it fetch one tile at a time.  It actually fetches one whole row of BACKTAB in one call and renders it.

 

The STIC interrupts the CPU with a non-maskable interrupt to request access to the system RAM bus, and at that point copies the BACKTAB data of the next row its internal frame-buffer.

 

You've seen the effects of this when trying to write to BACKTAB too late in the frame cycle, missing the fetch and having the background look "jerky" as it updates from frame to frame.

 

The most granularity that you have is a BACKTAB row, not a raster line, nor even a tile.  If you time your code correctly, you may be able to change the Color Stack advance between rows, but I am not sure what you may gain from that, since you can do that already within the same row writing to BACKTAB normally.

 

     -dZ.

 

Edited November 25, 2022 by DZ-Jay

[artrag]

If the STIC has an internal RAM buffer for a whole line of tiles, it is impossible to get raster effects changing the backtab...

Are you sure that the STIC doesn't read the backtab ram 8 times while plotting a line of characters?

If it were the case, in FB mode you could have more than 2 colors per character 

 

Edited November 25, 2022 by artrag

[Arnauld]

2 hours ago, artrag said:

Are you sure that the STIC doesn't read the backtab ram 8 times while plotting a line of characters?

No. You are correct to assert that the data is read again by the STIC for subsequent scan lines. But it's read from the buffer, not from System RAM.

[+DZ-Jay]

6 hours ago, artrag said:

If the STIC has an internal RAM buffer for a whole line of tiles, it is impossible to get raster effects changing the backtab...

Are you sure that the STIC doesn't read the backtab ram 8 times while plotting a line of characters?

If it were the case, in FB mode you could have more than 2 colors per character 

 

 

4 hours ago, Arnauld said:

No. You are correct to assert that the data is read again by the STIC for subsequent scan lines. But it's read from the buffer, not from System RAM.

 

Yes, that's the problem:  it fetches an entire row into the buffer and processes it from there.

 

When I started working on the Intellivision, I recalled like @artrag, being incredibly frustrated at some of these limitations.  In particular, I was frustrated at the lack of any source of timing beyond the 60 Hz VBLANK, which in itself negated many potential use cases in sound processing.

 

But then again, upon reflection, I was immensely grateful that we got access to the VBLANK vector point of the EXEC at all.  :)

 

      -dZ.

[Walter Ives]

On 11/25/2022 at 12:45 AM, Arnauld said:

No. You are correct to assert that the data is read again by the STIC for subsequent scan lines. But it's read from the buffer, not from System RAM.

 

On 11/25/2022 at 4:56 AM, DZ-Jay said:

Yes, that's the problem:  it fetches an entire row into the buffer and processes it from there.

Good thing, too, because STIC access to System RAM is done using the CPU's BUSRQ/BUSAK facility. If not for that ring buffer the STIC would have grabbed the bus for the entire active picture time.

 

WJI

[artrag]

In CS, could the stack registers be updated while the raster is plotting a line?

[+DZ-Jay]

1 hour ago, artrag said:

In CS, could the stack registers be updated while the raster is plotting a line?

Unfortunately not.  The Color Stack can only be changed during the Vertical Blanking period. The STIC then reads the BACKTAB data during active display, and composes the frame in an internal screen buffer.  After the next VBLANK this buffer feeds the raster to draw the next frame.

 

By the time the BACKTAB is read and the buffer composition starts, the VBLANK period has concluded and there is no more access to the STIC.

 

One of the biggest differences between the Intellivision and its contemporary platforms is that you cannot get access to the video frame data once the frame is composed -- the STIC abstracts the entire thing and handles frame composition and rasterizing as two separate steps, of which we only get limited access to the first.

 

I guess that is the price we pay for not having to wrangle the raster directly, which on balance has been a great thing for the Intellivision.

 

   dZ.