two simple IntyBASIC questions about Border and FRAME

[fsuinnc]

for the screen border, Border ,[mask] - Is the border always there? Is there a way to turn it off. It seems like the border is only on 3 sides which seems a bit odd. Am I missing something?

FRAME - What exactly is FRAME? Looking at the example FRAME.bas I see the On Frame Gosub which I think executes the procedure at each frame interupt (60 times per second on NTSC). But I don't understand the print statement in the exmple.

In a post back in September (http://atariage.com/forums/topic/249058-intybasic-more-advanced-tutorials-suggestions/?p=3585934) Kiwi tried to help me with smoother motion (and I appreciate the effort) and he mentions IntyBasic taking the frame variable (not sure if this was before the 'on frame' was available) and he mentions games slowing down when your doing frame%4.

Not surprising I don't understand, I also don't understand the part about "frame is a 16-bit variable, so use a 8-bit variable to mod from the power of 2s"

[+DZ-Jay]

for the screen border, Border ,[mask] - Is the border always there? Is there a way to turn it off. It seems like the border is only on 3 sides which seems a bit odd. Am I missing something?

 

The screen border cannot be turned off. You can extend it at the top and to the left (which is what the mask does) in order to support smooth screen scrolling, but the base border is always there. What you can do is use the scroll registers to center the play-field on the screen horizontally. That's what I do in Christmas Carol.

 

FRAME - What exactly is FRAME? Looking at the example FRAME.bas I see the On Frame Gosub which I think executes the procedure at each frame interupt (60 times per second on NTSC). But I don't understand the print statement in the exmple.

 

As you may already be aware, a "frame" in this context is an ISR (Interrupt Service Routine) event, when the STIC draws a new frame, which occurs 60 times a second. the FRAME variable is a simple 16-bit internal counter offered by IntyBASIC that gives you access to the current frame number. The counter increments automatically on every frame event (60 times a second) and cycles back to zero when it reaches the maximum, 65,553. This is useful to track time events.

 

The "frame" example in the SDK just prints the current value of FRAME on the screen. The "On FRAME..." statement causes the subroutine "clock" to be called on every frame event (i.e., 60 times a second), and the "Print" statement displays the current FRAME number.

 

 

 

Does this make sense?

 

In a post back in September (http://atariage.com/forums/topic/249058-intybasic-more-advanced-tutorials-suggestions/?p=3585934) Kiwi tried to help me with smoother motion (and I appreciate the effort) and he mentions IntyBasic taking the frame variable (not sure if this was before the 'on frame' was available) and he mentions games slowing down when your doing frame%4.

 

 

All that means is that you have a timed event, just like the clock example mentioned above, but instead of triggering the event on every frame (i.e., 60 times a second), you trigger it on every fourth frame (frame % 4 = 0).

 

For example, say that you want to call a routine on every fourth frame in order to move a sprite at 15 fps. One very easy way to do it is to read the value of FRAME, add four to it, and check on every WAIT event for it to reach that value, something like this:

  f = FRAME + 4
Loop:
  ' do stuff...
  If (FRAME = f) Then Gosub MoveSprite()
  Wait
  GoTo Loop

An even easier way would be to call your routine every time that the value of FRAME is divisible by 4, that is, when FRAME modulus 4 is zero.

Loop:
  ' Do stuff...
  On (Frame % 4 = 0) Gosub MoveSprite)
  Wait
  GoTo Loop

To slow down a game, you could make your entire game loop execute on the fourth frame, skipping when "frame % 4" is not zero.

 

Not surprising I don't understand, I also don't understand the part about "frame is a 16-bit variable, so use a 8-bit variable to mod from the power of 2s"

 

I'll have to read Kiwi's comment to see what he is doing.

 

-dZ.

[Kiwi]

 

for the screen border, Border ,[mask] - Is the border always there? Is there a way to turn it off. It seems like the border is only on 3 sides which seems a bit odd. Am I missing something?

FRAME - What exactly is FRAME? Looking at the example FRAME.bas I see the On Frame Gosub which I think executes the procedure at each frame interupt (60 times per second on NTSC). But I don't understand the print statement in the exmple.

In a post back in September (http://atariage.com/forums/topic/249058-intybasic-more-advanced-tutorials-suggestions/?p=3585934) Kiwi tried to help me with smoother motion (and I appreciate the effort) and he mentions IntyBasic taking the frame variable (not sure if this was before the 'on frame' was available) and he mentions games slowing down when your doing frame%4.

Not surprising I don't understand, I also don't understand the part about "frame is a 16-bit variable, so use a 8-bit variable to mod from the power of 2s"

 

Border surrounds the screen from 4 sides. You can extend the border mask by 8 pixels from the top and the left side. This is useful if you want to use smooth scrolling, but you will have to mask the left side so you can update the tiles on that strip. NES and Sega Master System does the same thing, have the 8 pixels border extension on the left side to update the tiles.

 

The border's necessary since it give CPU access time to update whatever it need like uploading new tiles, and etc. Once it start drawing the picture, it deny CPU access to that memory.

 

FRAME is a IntyBASIC variable. It increase by 1, every video interrupt. I believe it is use as a seed for the IntyBASIC random function. In my Colecovision project, I would name one of my variable frame, so I can use it for animation, enemy behavior, and etc. Usually that variable reset every 8 or 16 frame, depending what I am doing in the game. When I used FRAME as a variable for IntyBASIC, doing a MOD would slow the game down since 16-bit variable is much bigger than 8-bit variable so it would take more CPU time to divide(subtract it 4 times) that number and give the remainder(somehow). It is a 1Mhz processor after all. I tried to fix that until I realize it was being used by IntyBASIC and then had to change the name of the variable to something else to speed it up. So I was sharing in that thread I made an error doing a MOD on a 16-bit variable.

 

PRINT AT SCREENPOS(0, 0),<5>frame

 

PRINT = poke data to the screen area.

 

AT address $200 + 0-239. So "print at 100" will print at line 5 column 0.

 

SCREENPOS(x,y) I think, since it isn't in the manual, will print at specific area of the screen. So 'print at 100' and 'print at SCREENPOS(0,5)' are the same. Open the constant.bas and I believe the function explaination is in there.

 

<5> is how many digit you want the variable to print. So if you want to know what the number a variable is holding, then <5>variable name will reveal it. <3> will print 3 numbers, so I would recommend using that for 8-bit numbers, and <5> for 16-bit numbers.

 

frame.bas just showing you how FRAME variable works by counting from 0-65535. Once it go over 65535, it either crash(unlikely) or reset to 0 and start counting up again.

Edited January 21, 2017 by Kiwi

[fsuinnc]

 

The screen border cannot be turned off. You can extend it at the top and to the left (which is what the mask does) in order to support smooth screen scrolling, but the base border is always there. What you can do is use the scroll registers to center the play-field on the screen horizontally. That's what I do in Christmas Carol.

 

 

As you may already be aware, a "frame" in this context is an ISR (Interrupt Service Routine) event, when the STIC draws a new frame, which occurs 60 times a second. the FRAME variable is a simple 16-bit internal counter offered by IntyBASIC that gives you access to the current frame number. The counter increments automatically on every frame event (60 times a second) and cycles back to zero when it reaches the maximum, 65,553. This is useful to track time events.

 

The "frame" example in the SDK just prints the current value of FRAME on the screen. The "On FRAME..." statement causes the subroutine "clock" to be called on every frame event (i.e., 60 times a second), and the "Print" statement displays the current FRAME number.

 

 

 

Does this make sense?

-dZ.

 

 

Border surrounds the screen from 4 sides. You can extend the border mask by 8 pixels from the top and the left side. This is useful if you want to use smooth scrolling, but you will have to mask the left side so you can update the tiles on that strip. NES and Sega Master System does the same thing, have the 8 pixels border extension on the left side to update the tiles.

 

The border's necessary since it give CPU access time to update whatever it need like uploading new tiles, and etc. Once it start drawing the picture, it deny CPU access to that memory.

 

FRAME is a IntyBASIC variable. It increase by 1, every video interrupt. I believe it is use as a seed for the IntyBASIC random function. In my Colecovision project, I would name one of my variable frame, so I can use it for animation, enemy behavior, and etc. Usually that variable reset every 8 or 16 frame, depending what I am doing in the game. When I used FRAME as a variable for IntyBASIC, doing a MOD would slow the game down since 16-bit variable is much bigger than 8-bit variable so it would take more CPU time to divide(subtract it 4 times) that number and give the remainder(somehow). It is a 1Mhz processor after all. I tried to fix that until I realize it was being used by IntyBASIC and then had to change the name of the variable to something else to speed it up. So I was sharing in that thread I made an error doing a MOD on a 16-bit variable.

 

 

 

Thanks guys. I swear sometimes I can't believe the things that simply don't occur to me. The border around my game screen looks kind of dumb since it is on only three side. "scroll the screen so it is centered" Duh!!!, I should have thought of that.

 

FRAME works and is exactly what I thought it was though I appreciate the explanations. I scanned through the IntyBASIC instruction looking for FRAME and while I found all the references to things happening each frame I did not see a definition of FRAME on its own. Upon looking again this morning, after reading your posts, I found it in the instructions. So, I'm guessing I skipped right over it and that is what caused some of my confusion so thanks again.

[+nanochess]

There is not ON (FRAME % 4)=0 GOSUB, the only syntax available for this statement is ON FRAME GOSUB.

 

Inside the procedure you can do IF (FRAME % 4)<>0 THEN RETURN

[+DZ-Jay]

FRAME works and is exactly what I thought it was though I appreciate the explanations. I scanned through the IntyBASIC instruction looking for FRAME and while I found all the references to things happening each frame I did not see a definition of FRAME on its own. Upon looking again this morning, after reading your posts, I found it in the instructions. So, I'm guessing I skipped right over it and that is what caused some of my confusion so thanks again.

 

Strange, it's in the manual that's included with the SDK as well.

[fsuinnc]

 

Strange, it's in the manual that's included with the SDK as well.

yes it is. But, like so man people, I don't read the manuals

 

also, I tried using the scroll register to center the game screen but the effect I was looking for was for the border to show on the left side when the screen moved a few pixels to the right but this did not happen.

[+DZ-Jay]

There is not ON (FRAME % 4)=0 GOSUB, the only syntax available for this statement is ON FRAME GOSUB.

 

Inside the procedure you can do IF (FRAME % 4)<>0 THEN RETURN

 

Yeah, sorry about that, I didn't know it was a special construct. Here's a suggestion for a future version: allow arbitrary expressions in ON ... GOSUB.

 

The rest of the theory is still valid, though.

 

 

 

Thanks guys. I swear sometimes I can't believe the things that simply don't occur to me. The border around my game screen looks kind of dumb since it is on only three side. "scroll the screen so it is centered" Duh!!!, I should have thought of that.

 

Sorry, I didn't really understand your issue. What I suggested won't achieve what you want. What I do in Christmas Carol is forgo the last screen column and draw the screen as a 19x12 card background. Then I set the horizontal scroll register to 4 (half-way) which causes those 19 columns to be centered on the screen. The ultimate goal of this is to have an entire blank column on either side to cover the tunnel transitions of Christmas Carol (a la Pac-Man).

 

As far as I know, the border actually surrounds the screen on all sides. I think this is how it shows up on the actual hardware. I believe the 3-side border is a jzIntv artefact, although I am not sure right now. I recommend assuming that the left-side border is actually there.

 

-dZ.

[carlsson]

It might depend on TV overscan, but yes even in the first demo video from 1979 you can see the border around the screen area. Fast forward to about 3:30 into the video.

https://www.youtube.com/watch?v=mgbaSN0rVIY

[+DZ-Jay]

It might depend on TV overscan, but yes even in the first demo video from 1979 you can see the border around the screen area. Fast forward to about 3:30 into the video.

https://www.youtube.com/watch?v=mgbaSN0rVIY

 

Yeah, I was just too lazy to hook up my Intellivision to verify, but I seem to remember it being all around the screen. It may be a jzIntv limitation.

[carlsson]

See also this thread: http://atariage.com/forums/topic/260189-jzintv-parameters-for-full-border/

[+DZ-Jay]

See also this thread: http://atariage.com/forums/topic/260189-jzintv-parameters-for-full-border/

Thanks, I knew I had seen that before and was aware of it in the past.

 

So, officially, there is a long-standing limitation in jzIntv that only displays three sides of the border, and just a few pixels of those.

 

In real hardware, the border is a full card's-width all around, so best to count on that.