IGNORED

GoSub for INTV

Recommended Posts

I redesigned the submarine sprite. I also made it face the other way when going the other way. I had a hard time doing this, but my way was to make two sprites, one facing left and one facing right and then point to them at the appropriate time. Still at 7.5kb.

Edited by atari2600land
Share on other sites

I redesigned the submarine sprite. I also made it face the other way when going the other way. I had a hard time doing this, but my way was to make two sprites, one facing left and one facing right and then point to them at the appropriate time. Still at 7.5kb.

Or you could use the X Flip and Y Flip features of the Sprites and save the GRAM cards for things like a pseudo 3d turn animation instead of an instant flip

```CONST MB_Y_XFLIP    = \$0400                ' x flip
CONST MB_Y_YFLIP    = \$0800                ' y flip

SPRITE 0,X ,y,card number

Note how both constants have _Y_ in them, that's because the Y (or second parameter) is where you set either X Flip or Y Flip

Rem Point the Sprite #0 to its default direction, using GRAM card #59, located at screen location x,y
X=10
y=10

SPRITE 0,X ,y, ((256+59)*8+1

Rem Flip the Sprite #0 Horizontally
SPRITE 0,X ,y+MB_Y_XFlip , ((256+59)*8+1

This is also where you can size the sprite

Again, note the MB_X or MB_Y, it tells you which of the sprite parameters to put the value in
CONST MB_X_XSIZE    = \$0400                ' double size in x

CONST MB_Y_YRES     = \$0080                ' 16 bits in y
CONST MB_Y_YSIZ2    = \$0100                ' double y size
CONST MB_Y_YSIZ4    = \$0200                ' 4 times y size
CONST MB_Y_YSIZ8    = \$0300                ' 8 times y size```
```Flip the sprite and make it double wide
SPRITE 0,X+MB_X_XSIZE, y+MB_Y_XFlip, ((256+59)*8+1
or

Flip the sprite, double horizontal, 4 x height
SPRITE 0,X+MB_X_XSIZE ,y+MB_Y_XFlip+MB_Y_YSIZ4, ((256+59)*8+1```

Things got a lot easier once I started to use the constants from one of the samples. (Plus the helpful advice of Nanochess)

Share on other sites

OK. I'll do this.

Edited by atari2600land
Share on other sites

I added a few more sprites to have the submarine turn and was finally able how to figure out the sprite turning thing. I would have never have guessed that sprite x turning was stored in the sprite y coordinates. Anyway, the sub now turns appropriately. But now it's 8kb.

Edited by atari2600land
Share on other sites

I am also wondering how the fancy title screen for Next Street with the guy next to a sign post was made.

I must admit that drawing fancy graphics on the Intellivision is hard, but it is certainly possible. You basically draw your artwork into a grid, making sure to consider all the limitations of the Intellivision; then you split that into 8x8 tiles. If you need multiple colours on a particular tile, you can always overlay it with a MOB or two.

The trick is to keep this under 64 custom tiles (the limit of GRAM), or to re-use the GROM cards as much as possible.

Personally, I draw my graphics on text files, using "." and "#" to mark the pixels and use a tile-ripper script I made myself. It's a lot of work, and it takes some skills, but you gotta start somewhere, right?

The best advice I could give you is to start with a drawing and try to turn it into tiles--not the opposite. Otherwise, you'll artwork will have that typical blocky "programmer's art" look.

Share on other sites

Hello everyone

I am working together along with Atari2600land as the project manager to get GOSUB for the Intellivision published on cartridge.

I am relatively new to the Intellivision community.

Please allow me to introduce myself. My name is Tim Duarte and I have been in the classic gaming community since 1990.

My main focus has been the Atari 2600 for most of these years, and I run the web site 2600 Connection.

http://www.2600connection.com/

I started a print newsletter ( before the internet) and then in 2009 I released and published our fist homebrew, MEAN SANTA ( for the Atari 2600)

So we have published a few more as well and also branched out to Odyssey2 games and now , Intellivision.

Chris (Atari2600land) and worked together and published GOSUB (in 2012), WALLS (in 2013) , and just recently GOSUB 2 (in July 2014) -- all for the Odyssey2

I am publishing NICE ICE, his Christmas themed game for the next game for the Odyssey2 on November 15, 2014. Also doing an artwork contest for that one.

So... I have had some communications with Rev here on the AA INTV forum and he has been quote helpful.

I contacted Groovybee and he has replied to me about information about his board.

I have contacted Phil (pboland) here on AA for overlay quotes ( I have been in touch with him in the past re: Odyssey2 labels )

Still need to get some direction about producing boxes.

@ 5-11under, I will send you a PM.

thanks

Tim

Hello Tim!

Great to have you and your team here!

Share on other sites

I added a few more sprites to have the submarine turn and was finally able how to figure out the sprite turning thing. I would have never have guessed that sprite x turning was stored in the sprite y coordinates. Anyway, the sub now turns appropriately. But now it's 8kb.

I've made it to level 11 so far...

I like the animated turning of the sub (rather than just flipping the sprite).

Looks good.

You might want to try making the sub two colors, since you have 2 (or more?) sprites in the sub already...

Share on other sites

I just now realized that you're programming with raw Assembly. Kudos for the effort, but I suspect that all of this could be done in a fraction of the time using IntyBasic.

Share on other sites

I just now realized that you're programming with raw Assembly. Kudos for the effort, but I suspect that all of this could be done in a fraction of the time using IntyBasic.

I think he's using IntyBASIC.

Share on other sites

I added a few more sprites to have the submarine turn and was finally able how to figure out the sprite turning thing. I would have never have guessed that sprite x turning was stored in the sprite y coordinates. Anyway, the sub now turns appropriately. But now it's 8kb.

Great work! I like the new sub. I would like to see some windows in it, though...

I played and made it to level #4. I did noticed that I once passed through the tentacles of the octopus without dying. I don't know if that was a bug or by design.

-dZ.

Share on other sites

OK, so I made it to level 5, and I did notice that the collision detection in level 4 is different than in other levels: I am able to touch my periscope against the top seaweeds or the octopus' tentacles without dying.

EDIT: This happened on the different levels as well, apparently randomly.

Edited by DZ-Jay
Share on other sites

And I made it to level #11!! Yay! That's a fun little game. I must say that "solving" the maze and avoiding the octopus is a lot easier than fighting the controls to not crash against the stupid titanium seaweeds. I understand that you intend that to be part of the challenge, but it's a bit frustrating.

Here's a few more comments on the game:

• The alignment of the collision boundaries seems to vary randomly, it is not always the same on a level. Perhaps it has to do with the frame delay of the game engine, causing it to check for collisions on previous positions.
• Once I reached level #5 and got the key, if I restart the game after dying, the key will still show up on level #1. I think this is because the object is not being reset properly after the Game Over.
• Level #3 is exceedingly easy, much more so than #1 and #4, so it seems a bit out of place. Perhaps it's a good candidate for #1?

And here are a couple of ideas that should not be too hard to implement:

• Animated seaweed! It's hard and it's sharp, and it kills you on contact. Why no make it more interesting? You can cycle the GRAM card to simulate it moving. The good thing about this is that changing the GRAM card once causes all the BACKTAB cards referring to it, to automatically cycle.
• Multi-coloured sub. Just overlay it with another MOB to add detail.
• Play the "Ping" sound during game-play, at a low volume to give the game "atmosphere."
• Flip the octopus in the X axis to make him "look" in its direction of travel. This gives him a more menacing feel, since it seems to be intelligent enough to follow you with its gaze. (I do the same effect with the Ghost in Christmas Carol, and it is simple enough.)
• Add a window or two to the sub. It seems that you've tried to change it from a cartoon "Yellow Submarine" sub, to an actual battleship; but in doing so, you lost some details. Part of the trick of making 8-bit games look good is to compromise in the realism and to add the right elements to suggest the object you are representing. The periscope goes a long way towards this, but the body still seems mostly amorphous. I think a row of windows (or "rivets," if you make them a different colour with another MOB), would give it that touch to make it recognizable as an underwater vessel.

Great job, it's getting better and better!

I'll try again later to see if I can pass all levels.

-dZ.

Share on other sites

I think he used a top secret device called the Nonner. They are kinda hard to get ahold of.

Indeed! Rarer than unicorns .

Share on other sites

I am also wondering how the fancy title screen for Next Street with the guy next to a sign post was made.

Nonner and I have done a few of these now. The process is typically :-

- Nonner draws the 1st version in his favourite art package at 160x96 (w x h). He might ask for comments on the general style but I pretty much leave him to it.

- I receive a draft version.

- My "gut feeling" tells me if the image is best rendered using colour stack or foreground/background mode.

- I overlay an 8x8 grid on the image and mark anything I can get from GROM (bloxels etc).

- Anything that is close to a GROM bloxel's shape I'll replace with the bloxel shape just to see how it looks (most of the time it still looks good to me ).

- Check the remaining graphics for cards that need to be assigned to MOBs. These are normally 8x8 (or 8 x 16) cells with more than 2 colours in.

- Check for cards that can be reused if they are flipped and/or scaled in X, Y.

- Check for colour changes needed for colour stack mode.

- Remove all graphics that are GROM cards or will be made from flipped or scaled MOBs.

- All remaining graphics are cut out and placed in a 64x64 bitmap.

- If we are over on the 64 GRAM cards, nonner and I start an iterative process where things are tweaked until we are within the constraints of the system.

- Convert the final 64x64 bitmap to DECLE statements (this phase uses a bespoke tool that is customised for each of my games).

- Spend time creating the DECLE statements that form the image by hand, building and viewing as I go along.

- Send an emulator screen capture of the resultant image to nonner for final approval and sign off. If we are under on GRAM cards he might add extra flourishes "just because" .

- Send a photo of the final image (as seen on TV) back to nonner (PAL and NTSC have colour differences).

Its quite time consuming but the end result is well worth it.

For you own projects you could try using IntyColor to make your title pages. However, you probably need to avoid using more than 2 foreground colours per 8x8 cell in that case.

Share on other sites

I think he used a top secret device called the Nonner. They are kinda hard to get ahold of.

Since Nonners are so rare, the rest of us have to resort to this or similar method. I've been picking away at this for awhile and it could use some more proof reading, but it should help people trying to do title screens (or game screens for that matter.)

IntyColor Tutorial v1.pdf

Share on other sites

Nonner and I have done a few of these now. The process is typically :-

- Nonner draws the 1st version in his favourite art package at 160x96 (w x h). He might ask for comments on the general style but I pretty much leave him to it.

- I receive a draft version.

- My "gut feeling" tells me if the image is best rendered using colour stack or foreground/background mode.

- I overlay an 8x8 grid on the image and mark anything I can get from GROM (bloxels etc).

- Anything that is close to a GROM bloxel's shape I'll replace with the bloxel shape just to see how it looks (most of the time it still looks good to me ).

- Check the remaining graphics for cards that need to be assigned to MOBs. These are normally 8x8 (or 8 x 16) cells with more than 2 colours in.

- Check for cards that can be reused if they are flipped and/or scaled in X, Y.

- Check for colour changes needed for colour stack mode.

- Remove all graphics that are GROM cards or will be made from flipped or scaled MOBs.

- All remaining graphics are cut out and placed in a 64x64 bitmap.

- If we are over on the 64 GRAM cards, nonner and I start an iterative process where things are tweaked until we are within the constraints of the system.

- Convert the final 64x64 bitmap to DECLE statements (this phase uses a bespoke tool that is customised for each of my games).

- Spend time creating the DECLE statements that form the image by hand, building and viewing as I go along.

- Send an emulator screen capture of the resultant image to nonner for final approval and sign off. If we are under on GRAM cards he might add extra flourishes "just because" .

- Send a photo of the final image (as seen on TV) back to nonner (PAL and NTSC have colour differences).

Its quite time consuming but the end result is well worth it.

For you own projects you could try using IntyColor to make your title pages. However, you probably need to avoid using more than 2 foreground colours per 8x8 cell in that case.

So not a very robust process then? Kinda feels like you're half assing it.

Share on other sites

And here are a couple of ideas that should not be too hard to implement:

• Animated seaweed! It's hard and it's sharp, and it kills you on contact. Why no make it more interesting? You can cycle the GRAM card to simulate it moving. The good thing about this is that changing the GRAM card once causes all the BACKTAB cards referring to it, to automatically cycle.

When using the current version of Intybasic this can be done with the DEFINE command in your game loop, just be aware that you have to follow a DEFINE by a WAIT, or it won't work. If you have to update more than one card, make sure the card definitions for two objects are back to back in the card order sequence and DEFINE them both with one command and a DATA statement with two rows of info.

For instance

```define 59,1,seaweed1
define 60,1,seaweed2
wait

Seaweed1:
Data data \$0000, \$D67D, \$7DAA, \$0018 Rem Not real seaweed 1
Seaweed2:
Data data \$0000, \$D67D, \$7DAA, \$0018 Rem Not real seaweed 2```
will not work. Only the last seaweed will be redefined.
This will, but each WAIT eats a frame:
```define 59,1,seaweed1
wait
define 60,1,seaweed2
wait```

```rem Update two cards at once
define 59,2,seaweed1_and_2
wait

Seaweed1_and_2:
Data data \$0000, \$D67D, \$7DAA, \$0018 Rem Not real seaweed1
Data data \$0000, \$D67D, \$7DAA, \$0018 Rem Not real seaweed2
```

You may be using BITMAP statements instead of DATA.

Share on other sites

So not a very robust process then? Kinda feels like you're half assing it.

Its a process that works for us .

Share on other sites

Gee. I got the animated seaweed done by myself, but I know absolutely nothing about the INTV hardware. I wonder how inefficient my code is. But I doubt that it doesn't really matter how much frames I waste since all I'm doing is moving the sub and octopus? But the thing is, IT WORKS (at least in an emulator.) Yes, I'm doing this in INTVBasic. I've attached the latest version and the code here. But now I'm at 8.5 kb, so I doubt I'll have much room for a fancy title screen and the one now will have to do.

Edited by atari2600land
Share on other sites

And I made it to level #11!! Yay! That's a fun little game. I must say that "solving" the maze and avoiding the octopus is a lot easier than fighting the controls to not crash against the stupid titanium seaweeds. I understand that you intend that to be part of the challenge, but it's a bit frustrating.

Here's a few more comments on the game:

• The alignment of the collision boundaries seems to vary randomly, it is not always the same on a level. Perhaps it has to do with the frame delay of the game engine, causing it to check for collisions on previous positions.
• Once I reached level #5 and got the key, if I restart the game after dying, the key will still show up on level #1. I think this is because the object is not being reset properly after the Game Over.
• Level #3 is exceedingly easy, much more so than #1 and #4, so it seems a bit out of place. Perhaps it's a good candidate for #1?

And here are a couple of ideas that should not be too hard to implement:

• Animated seaweed! It's hard and it's sharp, and it kills you on contact. Why no make it more interesting? You can cycle the GRAM card to simulate it moving. The good thing about this is that changing the GRAM card once causes all the BACKTAB cards referring to it, to automatically cycle.
• Multi-coloured sub. Just overlay it with another MOB to add detail.
• Play the "Ping" sound during game-play, at a low volume to give the game "atmosphere."
• Flip the octopus in the X axis to make him "look" in its direction of travel. This gives him a more menacing feel, since it seems to be intelligent enough to follow you with its gaze. (I do the same effect with the Ghost in Christmas Carol, and it is simple enough.)
• Add a window or two to the sub. It seems that you've tried to change it from a cartoon "Yellow Submarine" sub, to an actual battleship; but in doing so, you lost some details. Part of the trick of making 8-bit games look good is to compromise in the realism and to add the right elements to suggest the object you are representing. The periscope goes a long way towards this, but the body still seems mostly amorphous. I think a row of windows (or "rivets," if you make them a different colour with another MOB), would give it that touch to make it recognizable as an underwater vessel.

Great job, it's getting better and better!

I'll try again later to see if I can pass all levels.

-dZ.

Other things to add since you have lots of room left is death animation, maybe of the octopus swallowing the sub or the sub imploding with the octopus grinning or laughing at your demise. It looks like you are only using 4 of the 8 MOBs, Definitely add some detail to the sub. I'd add a bonus screen every 5 levels where your sub can shoot a bunch of oncoming octopus (or sharks) Put the sub on the left of the screen, let the player move up and down shooting torpedoes to the right. Bring in fast moving randomly staggered enemies. For every 5 you kill get a bonus chance or two to use, kind of like earning extra lives.

Share on other sites

Gee. I got the animated seaweed done by myself, but I know absolutely nothing about the INTV hardware. I wonder how inefficient my code is. But I doubt that it doesn't really matter how much frames I waste since all I'm doing is moving the sub and octopus? But the thing is, IT WORKS (at least in an emulator.) Yes, I'm doing this in INTVBasic. I've attached the latest version and the code here. But now I'm at 8.5 kb, so I doubt I'll have much room for a fancy title screen and the one now will have to do.

Trust me, from experience you have a long way to go before you are out of room...You'll run into a hiccup when you pass 16k, but one line of code will get you over that. Unless you are artificially restricting yourself to 16k, the PCB's talked about will handle way more that your current 8k.

Share on other sites

.You'll run into a hiccup when you pass 16k, but one line of code will get you over that.

OK, so what's the one line of code? Tell me now so I don't have to worry.

Share on other sites

OK, so what's the one line of code? Tell me now so I don't have to worry.

I could give the code, but it isn't as simple as that. You have to understand the Intellivision memory map. As Nanochess explains:

==============================================

The areas you can use for basic cartridge ROM are:

• \$5000-\$6FFF (8k words)
• \$D000-\$DFFF (4k words)
• \$F000-\$FFFF (4k words)

So there are 16k words (32k bytes)

==================================

Once you pass 16k .bin file size, the JZINTV emulator will stop working (it did for me.)

Once you reach the 16k .bin crossover point, put this line before your last data statement

ASM ORG \$D000

In simple terms, this will redirect your last DATA statement into the next hole in the memory map. Then keep all new DATA statements at the bottom. As you add code to the top, you'll keep moving the ASM ORG statement up. It isn't quite as simple as this but it works for me so far. Mind you I haven't been able to test on a real Intellivision yet so I could be in for a rude awakening

Share on other sites

Sounds complicated. I guess this will have to be 16k then?

Share on other sites

Its a process that works for us .

I think he meant that it needs more steps.

Gee. I got the animated seaweed done by myself, but I know absolutely nothing about the INTV hardware. I wonder how inefficient my code is. But I doubt that it doesn't really matter how much frames I waste since all I'm doing is moving the sub and octopus? But the thing is, IT WORKS (at least in an emulator.) Yes, I'm doing this in INTVBasic. I've attached the latest version and the code here.

I saw that you added the windows... cool!

One thing I will point out is that the GRAM cycling is impacting the speed of your game. You see, it really does matter how many frames you "waste," since the game reads controller input and updates sprites position information on every display frame. Consequently, if you "pause" and skip a frame, that's one frame that doesn't update.

I tried playing the new version and it feels sluggish because it pauses the sprites for a frame whenever the seaweed animates. This is obviously not what you want.

Perhaps nanochess can provide a more direct and optimal way to support GRAM cycling in IntyBASIC? If not, I can try helping you make an assembler routine that we can plug-into your game.

Sounds complicated. I guess this will have to be 16k then?

It really is not. Here's the skinny on "ROM segments": Regardless of how much memory the Intellivision's CPU can theoretically address, the fact is that some hardware decisions limit the available address space. The first thing to know is that, like many components devised at the time before "virtual memory" was common, the Intellivision addresses all its peripherals within its memory space.

This means that the ECS, the Intellivoice, the STIC (video chip), the PSG (sound chip), etc., all have pre-determined blocks of the address space to which they are mapped.

The bottom line is that there isn't a single continuous block of addresses that you can count on for a very large game. It's all spread out throughout the memory space in chunks of 4K or 8K, and even 16K, hither thither.

Obviously, this was never even a concern at a time when 16K cartridge was such an expensive item to produce, that it was unthinkable making something 42K big!

So the Intellivision memory map, although theoretically big, is limited by some hardware constraints and splintered into multiple segments. This is not really a big problem. All you have to do is to tell the assembler which memory location to use as its "base" and it will happily start using those as it assembles your code.

IntyBASIC, I suppose, compiles your code at the "default" base address used for game cartridges since the early Mattel days--that's the \$5000-\$6FFF address range mentioned by Tarzilla, about 8K. If you fill that up, no worries, look for the boundary in your code (probably, the point where you know your code got too big for its britches), and tell the compiler to tell the assembler to switch to another ROM segment. The line below does that:

```REM Tell the assembler to switch to the to \$D000-\$DFFF segment.
REM All code from now on will assemble in that segment until
REM it overflows (which is bad), or you switch again.

ASM ORG \$D000
```

As Tarzilla suggested, it may be better to group all your DATA statements in one segment and let the code breath openly on a larger one by itself (I do this myself in my games).

But now I'm at 8.5 kb, so I doubt I'll have much room for a fancy title screen and the one now will have to do.

Keep in mind that, as I explained before, 8.5 kilo-bytes are a mere 4.25 kilo-DECLEs (16-bit words). In Intellivision-cartridge parlance, that's a bit over 4K. Trust me, your game is far from running out of space.

-dZ.

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.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.