MODE statement

[Alkadian]

Hi,

I have just figured it out by pure trial and error that after defining the MODE statement, for example to change the background to red:

 

MODE 0,2,2,2,2 

 

I need to type WAIT to see its effect.

 

Would someone please explain to me why I need this synchronisation in the code? Thanks!

[artrag]

The access to the video registers and memory is interdicted outside the VBlank period.

The values you set are buffered in RAM and copied to the registers at the next interrupt

 

 

[Kiwi]

52 minutes ago, Alkadian said:

Hi,

I have just figured it out by pure trial and error that after defining the MODE statement, for example to change the background to red:

 

MODE 0,2,2,2,2 

 

I need to type WAIT to see its effect.

 

Would someone please explain to me why I need this synchronisation in the code? Thanks!

Yup.  Same with DEFINE.  Other method is to poke directly to the color stack register, but it may not work since the period of time may be drawing the screen. The 16-bit RAM can only be access either by the CPU or the video processor.  So you can't do race the beam trick like the other system like NES, Colecovision, Atari 2600, and etc.

[+DZ-Jay]

To give context to all the answers given so far, the Intellivision video processor is synchronized with the TV's video signal, which in NTSC TVs is at 60 Hz, and in PAL/SECAM is at 50 Hz.  This is typical of old consoles of that time.

 

As you may know, the raster beam on the TV scans the screen from left to right, top to bottom to draw a picture for each frame several times per second.  When the raster beam finishes drawing a frame, it turns off briefly as it resets back to the top.  This is called "vertical blanking" or VBLANK.

 

At the very moment that VBLANK occurs, the Intellivision video chip (which is synchronized with the TV signal) issues an interrupt request to the CPU.  The Intellivision architecture is wired to react to this interrupt request by calling a program-specified service routine intended to prepare the graphics sub-system to draw the next frame, e.g., updating sprites, background graphics, GRAM pictures, etc.

 

In fact, as mentioned by the others above, this is the only time that the CPU has access to GRAM and the video chip registers, which include the graphics mode, sprite attributes, scroll adjustments, etc.  This is a very strange quirk of the Intellivision: you have to wait until the next VBLANK period happens in order to gain access to the graphics and sprites sub-systems -- and only briefly; once the raster resets, the video chip takes back control of the graphics sub-system and locks out the CPU from access again, until the next VBLANK.

 

IntyBASIC handles most of this complexity for you, abstracting the VBLANK interrupt and it's service routine.  Specifically, the statements related to the video chip -- SPRITE, SCROLL, MODE, etc. -- are buffered, so that he values are held in temporary storage until the next VBLANK interrupt, at which point IntyBASIC will dutifully apply them.

 

As I mentioned above, the VBLANK interrupts occur regularly at 60 or 50 Hz, depending on the TV standard in use.  IntyBASIC offers the WAIT statement to essentially "busy wait" in a loop until the next interrupt.  This allows your program to synchronize its timing with the video signal.

 

The others answered your specific question correctly, and I hope that this additional detail puts those answers into context.

 

    dZ.

[Alkadian]

11 hours ago, artrag said:

The access to the video registers and memory is interdicted outside the VBlank period.

The values you set are buffered in RAM and copied to the registers at the next interrupt

 

 

Thanks. I see now why. 

[Alkadian]

11 hours ago, Kiwi said:

Yup.  Same with DEFINE.  Other method is to poke directly to the color stack register, but it may not work since the period of time may be drawing the screen. The 16-bit RAM can only be access either by the CPU or the video processor.  So you can't do race the beam trick like the other system like NES, Colecovision, Atari 2600, and etc.

Thanks for your notes as well. I am learning a lot from all of you guys!

[Alkadian]

10 hours ago, DZ-Jay said:

To give context to all the answers given so far, the Intellivision video processor is synchronized with the TV's video signal, which in NTSC TVs is at 60 Hz, and in PAL/SECAM is at 50 Hz.  This is typical of old consoles of that time.

 

As you may know, the raster beam on the TV scans the screen from left to right, top to bottom to draw a picture for each frame several times per second.  When the raster beam finishes drawing a frame, it turns off briefly as it resets back to the top.  This is called "vertical blanking" or VBLANK.

 

At the very moment that VBLANK occurs, the Intellivision video chip (which is synchronized with the TV signal) issues an interrupt request to the CPU.  The Intellivision architecture is wired to react to this interrupt request by calling a program-specified service routine intended to prepare the graphics sub-system to draw the next frame, e.g., updating sprites, background graphics, GRAM pictures, etc.

 

In fact, as mentioned by the others above, this is the only time that the CPU has access to GRAM and the video chip registers, which include the graphics mode, sprite attributes, scroll adjustments, etc.  This is a very strange quirk of the Intellivision: you have to wait until the next VBLANK period happens in order to gain access to the graphics and sprites sub-systems -- and only briefly; once the raster resets, the video chip takes back control of the graphics sub-system and locks out the CPU from access again, until the next VBLANK.

 

IntyBASIC handles most of this complexity for you, abstracting the VBLANK interrupt and it's service routine.  Specifically, the statements related to the video chip -- SPRITE, SCROLL, MODE, etc. -- are buffered, so that he values are held in temporary storage until the next VBLANK interrupt, at which point IntyBASIC will dutifully apply them.

 

As I mentioned above, the VBLANK interrupts occur regularly at 60 or 50 Hz, depending on the TV standard in use.  IntyBASIC offers the WAIT statement to essentially "busy wait" in a loop until the next interrupt.  This allows your program to synchronize its timing with the video signal.

 

The others answered your specific question correctly, and I hope that this additional detail puts those answers into context.

 

    dZ.

Oh great, thanks a lot for taking the time to write these additional details for me. As I have mentioned in my previous post I am learning a lot from all of you in this forum and I have already started taking notes on a notebook not to forget all this precious information! Thanks again!

[+DZ-Jay]

47 minutes ago, Alkadian said:

Oh great, thanks a lot for taking the time to write these additional details for me. As I have mentioned in my previous post I am learning a lot from all of you in this forum and I have already started taking notes on a notebook not to forget all this precious information! Thanks again!

No worries.  Who knows, one of these days it will be you responding with authority to someone else's questions.  

 

   dZ.