IntyBASIC compiler v0.7 (now with IntyColor)

[GroovyBee]

But you couldn't use GROM tiles 65-255 with BG/FG mode right?

Correct! 64 to 255 are not available in FB mode. But we tend to go for CS mode to have the extra characters. It all depends on the image you want to make at the end of the day.

[+DZ-Jay]

 

But you couldn't use GROM tiles 65-255 with BG/FG mode right?

 

True, but these are deterministic rules, so they can be programmed. However, I don't want to make it sound like an easy or trivial thing--only nanochess knows the impact on his implementation of adding these features.

[+DZ-Jay]

 

That's correct. And, in fact, you can't even use those cards with MOBs in FGBG mode. (I can give a technical explanation if anyone's curious.)

 

Go for it, I'm sure it'll be interesting.

[GroovyBee]

True, but these are deterministic rules, so they can be programmed. However, I don't want to make it sound like an easy or trivial thing--only nanochess knows the impact on his implementation of adding these features.

One of the first things I do when I get new title page artwork from nonner is slap an 8x8 grid on it and look to see if GROM cards can be substituted. Sometimes the artwork can be adjusted to make better use of the GROM cards as well. That way we get more programmable cards for extra flourishes.

 

However, automating that task with some analysis software is not an easy thing to do.

Edited April 5, 2014 by GroovyBee

[+DZ-Jay]

One of the first things I do when I get new title page artwork from nonner is slap an 8x8 grid on it and look to see if GROM cards can be substituted. Sometimes the artwork can be adjusted to make better use of the GROM cards as well. That way we get more programmable cards for extra flourishes.

 

My "tile ripper," which is nothing as sophisticated as IntyColor, loads a set of GROM cards into a hashmap and attempts to match them against all the tiles read. This way, if any GROM cards are detected, it automagically uses them in the BACKTAB word output.

 

However, automating that task with some analysis software is not an easy thing to do.

 

I've toy with the idea of somehow generating an algorithm that will detect geometric similarities between tiles and point them out, but I'm not really good at that sort of thing, nor am I good at maths.

 

That to me would be a killer feature in a tile ripper for the Inty: to not only automatically detect GROM cards, but to suggest similar tiles and give the programmer/artist the chance of reducing the GRAM tile count.

 

-dZ.

[GroovyBee]

My "tile ripper," which is nothing as sophisticated as IntyColor, loads a set of GROM cards into a hashmap and attempts to match them against all the tiles read. This way, if any GROM cards are detected, it automagically uses them in the BACKTAB word output.

Sounds like a useful tool.

 

 

That to me would be a killer feature in a tile ripper for the Inty: to not only automatically detect GROM cards, but to suggest similar tiles and give the programmer/artist the chance of reducing the GRAM tile count.

 

It also gets more interesting/complex when you factor in MOBs and the fact that they can flip in X and Y, be 8x8 or 8x16 and scale in X and Y too.

[intvnut]

Go for it, I'm sure it'll be interesting.

 

I'll keep it fairly concise: If you look closely at the Intellivision schematic, you might notice something interesting about the System RAM / STIC / GROM bus structure: Bits 0 - 2 of the bus going to the GROM come from the STIC, but bits 3 - 13 are shared between the STIC, System RAM and GROM. Bits 0 - 2 from the System RAM go directly to the STIC only. (And note: When I mention GROM, I mean both GROM and GRAM, since GROM proxies accesses for the GRAM.)

 

What's going on?

 

Turns out that the words you put in BACKTAB for display nearly directly translate into an address for GROM. That's why the card number is shifted over by 3 bits. The color information in the lower 3 bits goes to the STIC directly, while the STIC outputs a scanline row number in place of those three bits to the GROM.

 

In FGBG mode, the STIC needs additional bits for colors, so it repurposes some of the GROM card # bits to hold color information. To make that work properly, the STIC tells the GROM explicitly to ignore those bits. In bullet 3 of the GROM data sheet it says this:

 

 

When BAR' and DWS' are pulsed positive, the memory will not respond to address bit 9 and address bit 10, which restricts the memory to 512 locations. [...] Configuration three may be released by applying a negative pulse on the SR1 pin.

This limits the GROM and GRAM both to 64 cards each. If you had somehow expanded GRAM to 256 cards, those extra 192 cards go bye bye. The masked condition holds until the end of the frame. SR1 is the vertical retrace signal. (You can see more in the STIC data sheet.)

 

Because the mask stays in effect for the entire display frame, MOB graphic fetches (which do not involve BACKTAB, and are otherwise unaffected by FGBG mode) are nonetheless affected by this address mask, and therefore stuck to the lower 64 cards in GROM and GRAM.

[+nanochess]

In fact I want to include the GROM tiles in the IntyColor algorithm for Color Stack mode, just that I didn't have enough time to integrate the tiles and comparison into the program; besides I thought Foreground/Background color is better for most colorful graphics screens.

 

As has been correctly pointed, in Foreground/Background color mode only are available the GROM 0-63 cards and the definable GRAM 0-63.

 

Also currently I don't have plans to include MOBs into screen graphics, that would be far too complicated at this time.

[+DZ-Jay]

Sounds like a useful tool.

 

It's a rather crude and simple tool, written in Perl. It reads a specially-formatted file that contains colour attributes and a tiled background, drawn in ASCII characters. It's hard-coded for Color Stack mode, and allows you to tell when the stack should be advanced. It is very crude, and I'm not sure how useful it would be to anybody else, but it follows my way of work, and so allows me to have a fast "draw-build-test" cycle.

 

However, I can see something like nanochess' IntyColor being extremely useful.

 

-dZ.

[+DZ-Jay]

In fact I want to include the GROM tiles in the IntyColor algorithm for Color Stack mode, just that I didn't have enough time to integrate the tiles and comparison into the program; besides I thought Foreground/Background color is better for most colorful graphics screens.

 

 

Funny that, I find the restrictions in FG/BG Color mode to be more onerous than in Color Stack mode.

 

-dZ.

[GroovyBee]

It's a rather crude and simple tool, written in Perl.

I have plenty of those "single task" tools as well. I also used to write them in Perl too. However, I've moved away from Perl the last 5 years or so and reverted back to C/C++. Its much less hassle when you start to work in teams.

[GroovyBee]

Funny that, I find the restrictions in FG/BG Color mode to be more onerous than in Color Stack mode.

In my mind, it all depends on the image and the artist's drawing style. In FG/BG mode you can end up with inverted data GRAM cards to make more use of the 16 colours that are available to background colours. The key to making good use of CS mode is getting longer stretches of colours that can be cycled through. As with anything to do with making these old gals do your bidding, you have to trade things against each other in order to get something that you want.

[Kiwi]

 

That's correct. And, in fact, you can't even use those cards with MOBs in FGBG mode. (I can give a technical explanation if anyone's curious.)

If I'm familiar with how the word are set up for colorstack mode, and how to use big pixels. I'm guessing that FGBG mode holds the color information for foreground, 3 bits for that, background colors, 4 bits, and then 6 bits to get 64 GROM cards, and one final bit to pick from 64 GRAM cards. 13-bit while 3-bits does nothing like it does with colorstack and big pixels.

[GroovyBee]

Have a look in your SDK1600 in the folder doc\programming . There is plenty of useful stuff in there, especially stic.txt.

[Kiwi]

Have a look in your SDK1600 in the folder doc\programming . There is plenty of useful stuff in there, especially stic.txt.

Found it! Thanks!

[+nanochess]

BTW, anyone has checked if the keypad/button decoder works in real hardware? the controller.bas example is the easiest way to verify.

[catsfolly]

Hi everyone.

 

Here is the version 0.7 of IntyBASIC, the BASIC compiler for Intellivision.

 

Now including an utility called intycolor that converts a BMP of fixed size 160x96 pixels (24-bits) to Intellivision code for proper display, so you can now develop nice graphics screens for your games

 

To support it, IntyBASIC now includes MODE and SCREEN statements. MODE selects Color Stack mode or Foreground/Background mode, and SCREEN copies graphics screens directly to video memory, including the possibility for block animation. Also this means POKE/PEEK aren't further necessary to control Intellivision video.

 

Also I added support to use card codes (numbers of Intellivision letters) in expressions, like this A="C" puts $23 in variable A.

 

Now CONT1.B0 CONT1.B1 and CONT1.B2 distinguish between buttons, and there is support for keypads! (note all this is experimental, I need help with testing in real hardware using the controller.bas file)

 

Edit: Updated Apr/03/2014 to version 0.7.1. IntyColor utility corrects a bug, background colors (8-15) were incorrectly generated.

It looks like only the mac version is updated to 0.7.

The PC and Linux versions seem to be older...

[+nanochess]

It looks like only the mac version is updated to 0.7.

The PC and Linux versions seem to be older...

 

Good catch! I had the files in my computer but for some reason I didn't copied them to the distribution folder...

 

Just I've updated it. Thanks!

[catsfolly]

Currently, as part of my continuing efforts to test IntyBasic, I am working on a "Laser Blast" clone that I call "Blast It".

I thought I could write such a program in a few hours, but naturally it is taking much longer than that (even with IntyBasic...)

 

In the current version, the enemies shoot far too often, but fortunately the player's ship in not yet damaged by the enemy lasers...

 

<-- Click to Animate.

 

 

Catsfolly

 

 

[+cmart604]

Wow. Cool. That's a great start. I'd like to ultimately see more and varied attackers if you decide to keep going on this. I liked the Atari version and played it quite a bit at my friends house many moons ago.

[+nanochess]

Amazing look!

 

This reminds me of uploading an update of IntyColor... soon.

[+DZ-Jay]

Currently, as part of my continuing efforts to test IntyBasic, I am working on a "Laser Blast" clone that I call "Blast It".

I thought I could write such a program in a few hours, but naturally it is taking much longer than that (even with IntyBasic...)

 

In the current version, the enemies shoot far too often, but fortunately the player's ship in not yet damaged by the enemy lasers...

 

blast_it1.gif <-- Click to Animate.

 

 

Catsfolly

 

 

 

Wow! That looks awesome! I really want to play this game.

 

-dZ.

[+nanochess]

Well, I'm glad to say that IntyColor v0.2 is now included in the package (see first post).

 

The enhancements for this version are:

• Support for variations of BMP format (32-bits, extra headers, internal upside down image)
• Support for GROM characters. The file is not included (because of copyright and blah-blah), copy 'grom.bin' in same directory as program.
• Tries to find repeated "complemented" bitmaps (both in your image and GROM), this way it can save some cards.

The GROM support means that you can put text in your images (if you use same pattern as GROM) and IntyColor will automatically choose the GROM character.

 

Remember in Foreground/Background mode you have only access to GROM patterns 0-63 and in Color Stack mode you have access to full GROM 0-255

[vprette]

Currently, as part of my continuing efforts to test IntyBasic, I am working on a "Laser Blast" clone that I call "Blast It".

I thought I could write such a program in a few hours, but naturally it is taking much longer than that (even with IntyBasic...)

 

In the current version, the enemies shoot far too often, but fortunately the player's ship in not yet damaged by the enemy lasers...

 

blast_it1.gif <-- Click to Animate.

 

 

Catsfolly

 

 

 

I would like to see some animation of the main ship when hitted, maybe not falling down at the first hit but resisting 2/3 shots...

and introduce differente enemies in term of shape and number.... maybe a big boss that you have to hit several times?

 

:-) ??

Edited May 21, 2014 by vprette

[catsfolly]

 

I would like to see some animation of the main ship when hitted, maybe not falling down at the first hit but resisting 2/3 shots...

and introduce differente enemies in term of shape and number.... maybe a big boss that you have to hit several times?

 

:-) ??

Nice box!

 

I am still trying to get the basic gameplay working. After that I will look at ways to expand it.

Maybe I could have a "classic mode" and an "advanced" mode?

Thanks for your suggestions. Having different enemies and even a boss would fit well with an advanced mode...