Jump to content
IGNORED

MODE statement


Alkadian

Recommended Posts

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!

Link to comment
Share on other sites

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.

  • Thanks 1
Link to comment
Share on other sites

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.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

  • Like 1
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...