GoSub for INTV

[intvnut]

Changing it also allowed me to shoot torpedos with the right CTRL key in jzintv.

 

EDIT: But now you can't hold the fire button down and turn at the same time. But I doubt anyone would want to do that though.

 

Hmm, weird. The action buttons and disc use entirely separate input lines. This isn't a hardware limitation.

[+atari2600land]

 

Hmm, weird. The action buttons and disc use entirely separate input lines. This isn't a hardware limitation.

It's probably just the way my code is written.

[intvnut]

It's probably just the way my code is written.

 

Could be.

 

I'm taking the next week off from work. While I plan to focus my new-found spare time on LTO Flash! and some other commitments, you're welcome to PM. I'm always glad to help. Otherwise, I imagine there's plenty of folks here in the forum that might spot what's up in the code too if you happen to post the relevant excerpt.

Edited November 22, 2014 by intvnut

[freewheel]

Geriatric care, eh? I can see many of us needing special care due to Nintendo Thumb. Or its earlier variants that we never really had names for - basically using an INTV II controller in any capacity, Coleco "joystick"itis, or Atari Wrist.

 

As far as firing and moving, yeah, it's definitely a code thing. Hopefully simple enough to figure out at a casual glance. I fire and move all the time without problems.

[pimpmaul69]

Geriatric care, eh? I can see many of us needing special care due to Nintendo Thumb. Or its earlier variants that we never really had names for - basically using an INTV II controller in any capacity, Coleco "joystick"itis, or Atari Wrist.

 

As far as firing and moving, yeah, it's definitely a code thing. Hopefully simple enough to figure out at a casual glance. I fire and move all the time without problems.

ive always liked the fire and no move glitch. It always made you have to think before shooting and if u missed the octopus it made it possible for the octopus to get you. If you fix that i think it will make the game too easy.

Edit: you say it is a problem now but i never was able to fire and turn at the same time

Edited November 22, 2014 by pimpmaul69

[pimpmaul69]

I found a huge glitch. If you fire a torpedo before moving the torpedo gets stuck on the screen and you cannot fire any other torpedos.

[+atari2600land]

I think I fixed it. Thanks for bringing it to my attention.

Edited May 30, 2015 by atari2600land

[+atari2600land]

So I added a few new levels to bring it to 35. I do have a question. All the INTV roms I see are either 8k or 16k. Does it have to be a total of 8 or 16 (or 32 or whatever), or can it be any size I want? I'm guessing it can be any size I want, but why are all the games a round (computer wise) number?

Edited May 30, 2015 by atari2600land

[intvnut]

Does it have to be a total of 8 or 16 (or 32 or whatever), or can it be any size I want? I'm guessing it can be any size I want, but why are all the games a round (computer wise) number?

 

Answering your second question first: Because the chips they're programmed into are sold in round-number sizes, and most games come close to filling their allotted chip storage budget. When dumping games, the dumpers generally dump the entire chip contents without trying to work out what portions are actually being used and what portions aren't.

 

But, if you're curious, there's 4 decles wasted at the end of the EXEC, so its file could have been 8184 bytes. I doubt anyone's bothered enough to do that, though.

.

 $1FF0:    01FF                   CLRR R7                                     
 $1FF1:    020C 0001              BNEQ $1FF4                                  
 $1FF3:    0008                   INCR R0                                     
 $1FF4:    0004 0100 02DC         JSR  R5,$02DC                               
 $1FF7:    0059                   SLLC R1                                     
 $1FF8:    0229 000B              BNC  $1FEE                                  
 $1FFA:    0220 0023              B    $1FD8                                  
 $1FFC:    0000                   HLT                   ; Unused!                      
 $1FFD:    0000                   HLT                   ; Unused!                      
 $1FFE:    0000                   HLT                   ; Unused!                      
 $1FFF:    0000                   HLT                   ; Unused!

.

Going back to your first question: It can be any size you want. Once it gets programmed into a cartridge, it'll likely be "rounded up" to some convenient power-of-two multiple based on the underlying cartridge hardware's needs. That extra space will get filled with padding that nothing will look at.

 

The only real constraint is that your game's memory map jibes with what the Intellivision expects. It doesn't care how much space you use otherwise, and the emulators shouldn't care about oddly-sized game images.

Edited November 23, 2014 by intvnut

[+atari2600land]

I changed the title screen a little bit. When the sub is in the foreground, I made it larger. When it's in the background, it's smaller. I had to experiment with numbers since it's not explained in the manual how to change bits. I figured out that in order to set bits, I'd need to change, for example, the $200 in Y1+$200,(... I'd need to change the number to $600 (binary 11000000000) in order to set the 10th bit. I'm guessing setting the 11th bit in the X position does nothing. I also added a few levels, right now there's 36. I'm aiming for 39. I think I can do it. I'm only at 13k, so when I'm finished, I'd probably have a 16k cart.

Edited May 30, 2015 by atari2600land

[intvnut]

I changed the title screen a little bit. When the sub is in the foreground, I made it larger. When it's in the background, it's smaller. I had to experiment with numbers since it's not explained in the manual how to change bits. I figured out that in order to set bits, I'd need to change, for example, the $200 in Y1+$200,(... I'd need to change the number to $600 (binary 11000000000) in order to set the 10th bit. I'm guessing setting the 11th bit in the X position does nothing. I also added a few levels, right now there's 36. I'm aiming for 39. I think I can do it. I'm only at 13k, so when I'm finished, I'd probably have a 16k cart.

 

In the directory jzintv/doc/programming/ there are several files that explain all the various bits in the various registers. That documentation isn't IntyBASIC related at all; however, it appears it's still relevant to IntyBASIC.

 

In stic.txt, I describe all of the STIC control bits.

 

Here's the relevant bit from stic.txt:

------------------------------------------------------------------------------
  MOB CONTROLS
------------------------------------------------------------------------------

The STIC provides 3 registers for controlling each MOB, and a 4th register
for reading its collision (or "interaction") status.  The registers are 
laid out as follows:

   X Register:    Address = $0000 + MOB #

      13   12   11   10    9    8    7    6    5    4    3    2    1    0
    +----+----+----+----+----+----+----+----+----+----+----+----+----+----+
    | ?? | ?? | ?? | X  |VISB|INTR|            X Coordinate               |
    |    |    |    |SIZE|    |    |             (0 to 255)                |
    +----+----+----+----+----+----+----+----+----+----+----+----+----+----+

   Y Register:    Address = $0008 + MOB #

      13   12   11   10    9    8    7    6    5    4    3    2    1    0
    +----+----+----+----+----+----+----+----+----+----+----+----+----+----+
    | ?? | ?? | Y  | X  | Y  | Y  |YRES|          Y Coordinate            |
    |    |    |FLIP|FLIP|SIZ4|SIZ2|    |           (0 to 127)             |
    +----+----+----+----+----+----+----+----+----+----+----+----+----+----+

   A Register:    Address = $0010 + MOB #

      13   12   11   10    9    8    7    6    5    4    3    2    1    0
    +----+----+----+----+----+----+----+----+----+----+----+----+----+----+
    |PRIO| FG |GRAM|      GRAM/GROM Card # (0 to 255)      |   FG Color   |
    |    |bit3|GROM|     (bits 9, 10 ignored for GRAM)     |   Bits 0-2   |
    +----+----+----+----+----+----+----+----+----+----+----+----+----+----+

   C Register:    Address = $0018 + MOB #

      13   12   11   10    9    8    7    6    5    4    3    2    1    0
    +----+----+----+----+----+----+----+----+----+----+----+----+----+----+
    | ?? | ?? | ?? | ?? |COLL|COLL|COLL|COLL|COLL|COLL|COLL|COLL|COLL|COLL|
    |    |    |    |    |BORD| BG |MOB7|MOB6|MOB5|MOB4|MOB3|MOB2|MOB1|MOB0|
    +----+----+----+----+----+----+----+----+----+----+----+----+----+----+

Notice that there are a variety of flag bits packed into each of the 
registers.  The various flag bits affect the MOBs as follows:

    INTR    If set, this MOB will interact with other MOBs, background
            cards and the screen borders.  If clear, it will not interact.
            For two MOBs to interact, both of their INTR bits must be set.

    VISB    If set, the MOB is visible onscreen.  If clear, it is not
            visible.  The MOB does not need to be visible in order to
            interact with other MOBs, background cards or the screen border.

    PRIO    If set, the MOB appears behind background cards.  If clear,
            the MOB appears in front of background cards.  This ordering
            applies to the visible pixels of the MOB only.  MOBs are first
            ordered according to their number, with MOB #0 being visible
            over MOB #1 and so on.  The PRIO bit does not affect MOB-to-MOB
            priority ordering.

    XSIZE   Controls the magnification of the MOB along the X axis.
            If clear, the MOB is displayed at normal width (8 pixels).
            If set, the MOB is displayed at double width (16 pixels).

    YRES    These three bits controls the size and magnification of the
    YSIZ2   MOB along the Y axis.  To explain their interaction, consult
    YSIZ4   the following table.  Note that MOBs display with half-pixels
            vertically, so the displayed height is given in terms of card
            pixels.

                YRES  YSIZ4  YSIZ2    MOB Resolution   Displayed height
                  0     0      0          8 x 8            4 pixels
                  0     0      1          8 x 8            8 pixels
                  0     1      0          8 x 8           16 pixels
                  0     1      1          8 x 8           32 pixels
                  1     0      0          8 x 16           8 pixels
                  1     0      1          8 x 16          16 pixels
                  1     1      0          8 x 16          32 pixels
                  1     1      1          8 x 16          64 pixels

            When YRES is set, the MOB takes its picture information
            from two consecutive card bitmaps.  The upper half always
            comes from an even numbered card, and the lower half always
            comes from an odd numbered card.  Bit #3 in the A register 
            (the least-significant bit of the card number) is ignored
            when YRES is set.

            When both YSIZ4 and YSIZ2 are clear, the MOB is displayed
            using half-pixels vertically.  That is, they have double
            the vertical resolution of background cards.  The displayed
            heights above are in terms of full pixels.

    XFLIP   Display the horizontal mirror image of the MOB.

    YFLIP   Display the vertical mirror image of the MOB.

    GRAM/   If set, the bitmap image comes from GRAM.  Otherwise, it
    GROM    comes from GROM.  

    CARD #  Determines the card # displayed.  This field combines with
            the GRAM/GROM bit to create a 9-bit card # field.  This allows
            addressing all 320 pictures contained in GROM and GRAM.  Some 
            of these bits are ignored in certain circumstances, though:

            Bits 9 and 10 of the attribute register (bits 7 and 6 of 
            the card #) are ignored when the bitmap comes from GRAM, 
            or when the display is in Foreground/Background mode.  
            (This means that only 128 of the 320 pictures are available
            when the display is in FGBG mode.  GROM cards #64 - #255
            are unavailable in FGBG mode.)

            Bit 3 of the attribute register (bit 0 of the card number)
            is ignored if the YRES bit is set. 

            Bits that are ignored by the hardware may be used by 
            programs to store flags or other information.

    COLL    Set when the MOB interacts with the display borders.
    BORD

    COLL    Set when the MOB interacts with a set pixel in a background
     BG     card.  Note that colored-squares colors 0 through 6 are
            treated as "set", and color 7 is treated as "clear".

    COLL    Set when the MOB interacts with one of the other MOBs 0 through
    MOBn    7.  Note that a MOB *never* interacts with itself, so its
            self-collision bit will *never* be set under any circumstance.

            All 10 collision bits are "sticky", meaning that once set by
            an interaction, they remain set until the CPU clears them.
            They will remain set even if the INTR bit is subsequently
            cleared.  The CPU may also artifically set collision bits by
            writing to the collision registers, although bit #N for MOB
            #N will never read as 1 even if the CPU tries to set it.
            Also, writing a new value in bit #X for MOB #Y will not
            automatically change the value for bit #Y for MOB #X.

In particular, you are correct that the 11th bit does nothing for the X size. You get two sizes: Normal and doubled.

 

At one point, I was rewriting much of this on IntelliWiki. It looks like I never got around to writing everything I intended to write. But, I did upload several diagrams that might be interesting. Have a look here: http://wiki.intellivision.us/index.php?title=Category:STIC

 

I could have sworn I wrote the text to go with these, but it's not there.

 

The most relevant images to go with the above are:

 

 

 

Edited November 23, 2014 by intvnut

[+atari2600land]

I don't understand much of that, but I do understand (now) the MOB controls (STIC) part. I wouldn't have understood it had I not experimented with the numbers. I'm still new to Intellivision programming (and the machine in general, I've only had one for a year now), and thanks to the INTVBasic can actually know how to program stuff on it. So what do people think of the new title screen?

[pimpmaul69]

I like big sub little sub. It gives it depth. Also tested and the torpedo problem is gone. Cant wait to see this finished. I have not taken the time to play every level from the beginning. I am trying to save that for the finished version with the endings. When i wake up i will check out the new levels and give input if there is any needed. You are pretty good with the levels so i suspect no issues. I am a hardware guy not software so i know nothing about programming but i have to say in the short time you have spent working on this you have managed to make one of my favorite games. Keep up the great work and thank you for an awesome game.

[JoeM_Intellivision]

Nice Work - Why Stop At 39 - Make It An Even 40:-)

[JoeM_Intellivision]

2nd the sentiments of Pimpmaul69 - thanks for your efforts. I'm not clear of this game's history - can someone tell me if it was in arcade or what systems it appeared on as I don't know. Thanks.

[+DZ-Jay]

So what do people think of the new title screen?

 

I don't like it. I guess the idea of giving the screen depth is a good one, but just blowing up the MOB without increasing its resolution, looks cheesy.

 

Notice how even the large octopus is drawn with smoother curves and smaller pixels. Perhaps you'll need to create a submarine by combining multiple double-resolution MOBs to get the same style.

 

-dZ.

[+DZ-Jay]

Here are a few thoughts on the latest version. I've written them as I play all levels:

• The ping sound is back to normal, and my wife and I were commenting how it adds to the atmosphere of the game.
• I like the torpedo action, a lot. Being an OCD-driven "completist," I am compelled to try to kill an octopus with every single one. This forces me to coordinate my sub navigation with the torpedo aim, while avoiding the octopus; which adds to my challenge. (I keep losing now on very low levels!)
• I like that the octopus comes out from a random corner whenever I kill it. It adds to the challenge by making it a bit unpredictable, just like enemies should be. That said, the random routine used may not be very random. It seems that most of the time, the octopus comes out from the same place after shooting it from specific areas on the screen.
• As I mentioned before, I am not keen on the "big-sub/little-sub" feature when just doubling the pixel size. I don't think it is needed, but if you really want to pursue the motif, then I suggest re-drawing the submarine to a higher resolution, like you did with the octopus.
• The icons at the bottom row look cool except for two things:
  • The submarine icon is misaligned vertically, and one pixel too close to the digit horizontally. You notice this best when the counter turns to zero (see attached screenshot #1).
  • The "bomb" looks like a rotten apple. Or a cooking gas container. Or a myriad other things that are decidedly non-torpedo-ish. How about using something like the graphic I offered a week ago (see attached screenshot #2).
  • Whatever you decide on the torpedo icon, make it the same colour as the one in play. This makes it easier to relate intuitively.
• When the "Game Over" message shows up, it overwrites the kills counter. Perhaps the message should appear in the center of the screen instead? I think it is important for the player to be able to see the extent of his achievements at the end of the game.
• In Level #15, a wall moved when I picked up the key. This surprised me, but introduced a new play mechanic. However, I'm now up to Level #20 and haven't seen this behaviour again, which makes it seem like a bug or glitch. (UPDATE: It came up in Level #21, but still, there doesn't seem to be any logic or reason to the change, which makes it look capricious instead of challenging.)
• In some levels, the walls are not defined on one side, which means that if you wander too close to the edge, you'll "cross over" and crash against the killer-seaweed on the other side. The problem is that the transition from one side to the other is not smooth; it seems that if your sub goes just one pixel across the loosely defined boundary, it fully transports to the other side. This is one of those "features" that should be an added challenge, but feel more like clunky design. When there are no walls, it is hard to gauge the actual boundary, and the game is unforgiving by transporting the sprite fully instead of just rolling over smoothly.
• There is either something wrong with Level #37, or you have introduced some inscrutable play mechanic that I am not able to pick up. There doesn't seem to be any way to move (see screenshot #3). (UPDATE: Never mind, I just read your post that there are only 36 levels.)

Overall, the game is coming along very nicely. It is very enjoyable and challenging. The only reason I am able to advance to the latest levels is by using the "warp" functionality, but I can see myself playing this game repeatedly in order to complete it (which is what I was doing before).

 

One last note I'll add is that, for the sake of us OCD freaks, could you aim to make the game have 40 levels instead of 39?

 

 

 

Sample icons for torpedo counter:

	BITMAP "........"
	BITMAP "........"
	BITMAP "...#...."
	BITMAP "..###..."
	BITMAP "..###..."
	BITMAP "..###..."
	BITMAP "...#...."
	BITMAP "..#.#..."

	BITMAP "........"
	BITMAP "........"
	BITMAP "........"
	BITMAP "#.#####."
	BITMAP ".#######"
	BITMAP "#.#####."
	BITMAP "........"
	BITMAP "........"

Screenshot #1:

 

Screenshot #2:

 

Screenshot #3:

Edited November 23, 2014 by DZ-Jay

[+DZ-Jay]

Oh, and for the sake of showing the marvelous progress this game has made, check out the original title screen:

 

Hand-basket, or UFO?

[+5-11under]

Oh, and for the sake of showing the marvelous progress this game has made, check out the original title screen:

 

Hand-basket, or UFO?

 

Curling!

[+nanochess]

I don't understand much of that, but I do understand (now) the MOB controls (STIC) part. I wouldn't have understood it had I not experimented with the numbers. I'm still new to Intellivision programming (and the machine in general, I've only had one for a year now), and thanks to the INTVBasic can actually know how to program stuff on it. So what do people think of the new title screen?

It's better

 

BTW, you know can define two separate GRAM in same frame with IntyBASIC v1.0 in case you want to do some more complex graphics.

[+atari2600land]

I redid the torpedos so they look less like blocks. As for the sub being too close to the 0, I think that it's the font's fault, not mine. The sub is 8 pixels wide and so is the number 0.

 

And for the record, I can't draw sprites very well. The reason the sub looks the way it is now is that I copied the front of the GoSub 2600 cartridge manual's sub. Otherwise, it would still look the way it does.

Edited May 30, 2015 by atari2600land

[intvnut]

Nice Work - Why Stop At 39 - Make It An Even 40:-)

 

I dunno... stopping at 39 worked well for Jack Benny.

[JoeM_Intellivision]

Sorry that went over my head - there were 39 original Honeymooners episodes though:-)

[intvnut]

Sorry that went over my head - there were 39 original Honeymooners episodes though:-)

 

For about 40 years, Jack Benny turned 39 ever year.

[+atari2600land]

As to why I want to make 39 levels. The reason is because of the level select feature. If I made forty, I would have to make two separate lines of code dealing with picking 40, then picking a number between 41-49. I just don't want to do that.