Jump to content

Photo

IntyBASIC compiler v0.7 (now with IntyColor)


79 replies to this topic

#26 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Sat Apr 5, 2014 12:31 PM

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.

#27 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,838 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sat Apr 5, 2014 12:32 PM

 

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.



#28 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,838 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sat Apr 5, 2014 12:32 PM

 

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. :)



#29 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Sat Apr 5, 2014 12:37 PM

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 by GroovyBee, Sat Apr 5, 2014 12:38 PM.


#30 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,838 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sat Apr 5, 2014 12:45 PM

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.



#31 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Sat Apr 5, 2014 12:51 PM

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.

#32 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,768 posts
  • Location:@R6 (top of stack)

Posted Sat Apr 5, 2014 12:53 PM

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.



#33 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,795 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Sat Apr 5, 2014 12:54 PM

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.



#34 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,838 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sat Apr 5, 2014 12:57 PM

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.



#35 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,838 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sat Apr 5, 2014 1:00 PM

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.



#36 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Sat Apr 5, 2014 1:02 PM

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.

#37 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Sat Apr 5, 2014 1:12 PM

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.

#38 Kiwi OFFLINE  

Kiwi

    Stargunner

  • 1,379 posts

Posted Sat Apr 5, 2014 1:21 PM

 

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. 



#39 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Sat Apr 5, 2014 1:25 PM

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

#40 Kiwi OFFLINE  

Kiwi

    Stargunner

  • 1,379 posts

Posted Sat Apr 5, 2014 1:29 PM

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!  :thumbsup:



#41 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,795 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Sun Apr 6, 2014 3:35 PM

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



#42 catsfolly OFFLINE  

catsfolly

    Dragonstomper

  • 704 posts
  • Location:Japan

Posted Thu Apr 17, 2014 10:49 AM

Hi everyone.

 

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

 

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...



#43 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,795 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Thu Apr 17, 2014 11:04 AM

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! :)



#44 catsfolly OFFLINE  

catsfolly

    Dragonstomper

  • 704 posts
  • Location:Japan

Posted Fri Apr 25, 2014 10:15 AM

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

 

 



#45 cmart604 OFFLINE  

cmart604

    Quadrunner

  • 11,241 posts
  • Location:Vancouver

Posted Fri Apr 25, 2014 12:41 PM

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.

#46 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,795 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Fri Apr 25, 2014 12:44 PM

Amazing look! :)

 

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



#47 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,838 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Fri Apr 25, 2014 3:35 PM

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...

 

attachicon.gifblast_it1.gif    <-- Click to Animate.

 

 

Catsfolly

 

 

 

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

 

     -dZ.



#48 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,795 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Fri Apr 25, 2014 4:13 PM

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



#49 vprette ONLINE  

vprette

    Stargunner

  • 1,347 posts

Posted Wed May 21, 2014 10:21 AM

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...

 

attachicon.gifblast_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?

 

:-) ??

blast It

Edited by vprette, Wed May 21, 2014 10:42 AM.


#50 catsfolly OFFLINE  

catsfolly

    Dragonstomper

  • 704 posts
  • Location:Japan

Posted Sat May 24, 2014 9:45 AM

 

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...






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users