Jump to content

jlew715

New Members
  • Content Count

    22
  • Joined

  • Last visited

Community Reputation

11 Good

About jlew715

  • Rank
    Space Invader
  1. Some of the European releases of the Coleco games (i.e. CBS releases) had updated code that bypasses the lockout, which is sort-of weird because Coleco never (to my knowledge) re-released the games in North America with the updated code. The Intellivision II wasn't sold in Europe, so updating the code for European-only releases had no benefit that I can see. Also, these INTV2-compatible European releases have three plastic chines which mechanically prevent them from being inserted into North American consoles. The carts themselves are fully compatible so sanding down the chines allows the Coleco games to be played in the Intellivision II.
  2. Apparently its “real” title is Alien’s Return. https://en.m.wikipedia.org/wiki/Alien%27s_Return James Rolfe briefly touched on it in the Angry Video Game Nerd series (Episode 101, ~19 minutes in).
  3. I like the idea of encoding the card type (wall 1, wall 2, etc.) into the 2 unused bits of the each card. How do I got about setting these when Im PRINTing my walls earlier? Say Im printing a wall along the top of the screen: FOR I=0 TO 19 PRINT AT (SCREENPOS(I,0)), BG00 NEXT I Say I wanted to set the MSB of those 20 cards to identify that they are walls - how can I do that? Something with POKE?
  4. Hey all, Working on an IntyBasic game and I'd like to implement software-based collision detection rather than relying on the built-in Intellivision collision registers (mainly so I don't have to wait for the player-sprite to already be ~1px inside the wall before the collision is reported). This is simple enough for MOB-on-MOB collisions, but I'm not sure how to implement this for collisions with background elements like walls. I'm envisioning the flow will be something like: Draw player sprite Determine target coordinates for next player move (based on Controller input or whatever). Get info about what type of card is currently shown on the target coordinates. If it's open, set player coordinates = target coordinates. If it's a wall, set player coordinates = last known good coordinates. GOTO 1. Where I'm stuck is step 3. I'm guessing there is a way to convert the target coordinates into a "card number" (BACKTAB?), then load information about what is on that card (is it a wall? is it blank?). But I'm not sure how to A). translate the X/Y coords into a card, and B). how to tell what is displayed on a particular card (is it a wall?). Additionally, I'm guessing that the "origin" for sprites is the upper-left corner. so drawing an 8x8 sprite at coordinates 10,10 would occupy the area from 10,10 to 18,18. Please correct me if I'm wrong. Thanks!
  5. As always, DZ-Jay, a fantastic and detailed response. This was very helpful and I was able to get my WAITs figured out! I was able to figure out the animation as well - the issues I encountered before were due to an extra BITMAP line in one of my sprites (counting to 8 is hard). My original approach worked once that was resolved!
  6. Hey all, I tried to spend the weekend learning the basics (ha!) of IntyBasic. And what better way to learn for a "retro" console than to make a PONG clone? So I made a very rough PONG clone called "PONGadelic" to learn: Simple sprite definition and rendering. Controller input and translating input to sprite movement. Simple collision detection. How to handle color-switching on the Inty. I've attached the BAS and ROM files for your perusal. The PONGadelic_title.BAS simple renders the classic title screen (adapted from the SDK's classic title screen example - thanks!). So down to my questions - I've got the Inty in ColorStack mode: MODE SCREEN_COLOR_STACK, STACK_BLACK, STACK_CYAN, STACK_BROWN, STACK_YELLOW 'I have no idea how to use anything after STACK_BLACK BORDER BORDER_BLACK This results in my entire play field being BLACK, which is what I want for now. Great. But say, after either player scores a point, I want to change the whole play field to the next color in the stack - that is everything that was STACK_BLACK should now be STACK_CYAN. I was not able to figure out how to accomplish this. Is there some sort of "advance color stack to next color" command? I saw something about setting $2000 but I'm not sure how or where to do that. I don't want to change the color of a sprite or printed object; I want to make the entire play field a new color. Second question - I have a Ball object (SPRITE 6) that I want to animate in a simple, back-and-forth kind of deal. I have two sprites loaded into GRAM for this purpose; SPR03 and SPR04. SPRITE 6,ballX+HIT+VISIBLE,ballY+ZOOMY2,SPR03 + ballColor 'this is where Id like to animate the ball, (i.e. change to SPR04 for X frames, wait X frames, then change back to SPR03). My assumption is we need some kind of counter that switches the line from using SPR03 to SPR04 every X frames, then starts over and switches back to SPR03 after X frames elapse again - but I struggled with how to implement this. When I had counters swapping the sprites, I ran into collision detection issues. Final question - WAITs - I don't really understand when I should (and shouldn't) be using them. I understand that certain things need to "settle" sometimes, or you can only do certain operations once every "cycle"... but I'm kind of lost . Besides those (probably obvious!) questions, PONGadelic is a totally functional albeit rough PONG clone! If you feel like trying it out, here's how it works: Classic PONG - use your paddle to bounce the ball and prevent it from going out the back of your side. Left Controller - Left Side; Right Controller - Right Side. Player who just gave up a point gets to "serve" the ball using any of the Side Buttons (serving merely sends the ball in a random direction from the center). When the game first starts, Left Player gets to "serve". First player to 9 points wins the game. Walls, Paddles, and Ball have a random color during each round of the game (hence PONGadelic). Thanks in advance for your help! J. Lewis pongadelic_title.bas pongadelic.bas constants.bas pongadelic.rom
  7. This is exactly what I was looking for! Thank you so much for the detailed and speedy reply. I have a fair amount of experience with modern, higher-level languages (Java, JS, Lua, etc.) but that only goes so far. Thanks again!
  8. This is driving me nuts - I totally understand the result of this, but I can't understand how it works! Converting to binary, that line becomes IF #line AND &1000000000000000 THEN PRINT [whatever] So, say my first DATA line is &1000000000000001. During the first iteration of the loop, we would be comparing: IF &1000000000000001 AND &1000000000000000 THEN PRINT [whatever] I understand that because the leftmost bits are both 1, the AND comparison evaluates as true, and my [whatever] is printed. What I don't understand is how this AND comparison is only checking bit 15, and ignoring all the other bits. How does comparing the two Words in this way make the masking happen?
  9. The cartridge that fits on the console (Coleco North America release) has code that does not work on Intellivision II. The cartridge that does not fit on the console (CBS Europe release) has code that does work on Intellivision II. I don’t understand why they bothered updating the code to the Europe release, since Europe only had Intellivision I, where the original code worked anyway.
  10. Hey all, My Sears Super Video Arcade (which I probably overpaid for, but oh well) came today! So I figured Id make a post and show it off a little bit . Some things of note: 1. The SVA has much smoother controller disks than my 2609, Intellivision II, or System III (with the II being the crunchiest). Im talking orders of magnitude smoother. Not sure if this is due to some difference in the SVA or perhaps it has less mileage than my other consoles. 2. The SVA exhibits zero video ghosting in my Vizio LCD, where the 2609 has minor ghosting and the Inty II has severe ghosting. 3. The SVA has its clearest picture on Channel 3 where all three of my other Intellivisions have the best picture on Channel 4. 5. The controller wires, being uncoiled, are much longer but also a nightmare to put back in the console vs the consoles with coiled controller wires. 6. DUNGEADVANCEDAGONS.
  11. I’m thinking of cutting some adhesive rubber feet to put next to the middle chine to function as a “bumper” so it will stop when properly inserted.
  12. Hey all, As we know, when the Intellivision II was designed, Mattel implemented the stricter copyright routine so third-party games, namely Coleco, (and Mattel's own Word Fun) wouldn't work on the new console. It seems like everyone eventually figured out how to get around this, by many already-released games were incompatible. As far as I'm aware, Coleco never re-released their games in the US market with updated code to get around the Inty II copyright check. However, I've read that some versions of the European CBS Electronics release of Coleco's games have updated code and (in theory) should run on an Inty II. The real question is - would you want to? Coleco is somewhat notorious for intentionally gimping their Inty ports to make the ColecoVision look better. In my case, however, Venture is one of my favorite Intellivision games after the AD&Ds! So I decided to order a CBS copy of Venture and got it working. It could just be my imagination, but the CBS version seems to run noticeably smoother than the US-market Coleco version (on the Inty I of course). How-To: Pictures 1 & 2 - Obtain the "Green Dragon w/ White Lines" box version of Venture. The are at least two other CBS box versions; I'm not sure if they all contain Intellivision II compatible code. Pictures 3 & 4 - Great! You have a Venture cartridge that has the right code to work in an Inty II. Only one problem - the cartridge doesn't fit in the console! There are three "chines" above the PCB contacts which prevent insertion into the US-market Intellivision II. Unscrew the two screws on the back of the cart. Picture 5 - The other half of the cart is normal and should fit in any Intellivision. No work needed here. Picture 6 - Break off (ouch! sorry) the three chines with some needle-nose pliers (etc) and sand/file down the remaining nubs. Picture 7 - Reassemble the cartridge (was it really that easy?). Picture 8 - Not quite! Now that you've filed down the chines, the cartridge actually goes too far into the Intellivision II. So when you insert it, insert it about 5mm short of the hard stop. Do that, and you're playing Venture on an Intellivision II!
  13. Using a shielded coax with the Inty II. Some progress has been made - I hooked it up to my Toshiba LCD upstairs, and the ghosting is much less pronounced (still worse than my I and III) - but that’s through RF directly into the TV (again over coax). Worst case, I can use the II on this TV permanently. I have a Super Video Arcade in the mail, so it’ll be interesting to see how it compares to the II in regards to video quality. If anything I would expect it to be the most similar to the Model I.
  14. Tried adjusting the video pot on the RF board; no luck - the color intensity went up and down but the ghosting stayed the same. Strangely, I pulled an old CRT out of the basement and this Inty II comes in crystal clear. Wonder why my LCD shows the ghosts when it doesnt on the other two consoles, yet all three work fine on the CRT. Shouldnt all three have the same RF modulator?
  15. Thanks! I didn’t meant to make it sound like the Inty II was AV modded - it’s still stock. When I said “AV setup” I just meant it was connected to the TV via the same cables and RF-to-Composite tuner as my Inty I and III.
×
×
  • Create New...