Jump to content
IGNORED

IntyBASIC compiler v0.7 (now with IntyColor)


Recommended Posts

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.

Edit: Updated Apr/17/2014 to version 0.7.2. For some reason the PC/Linux versions were still v0.6.

Edit: Updated Apr/25/2014 to version 0.7.3. IntyColor utility now can use GROM graphics (put grom.bin in same directory) and tries to discover repeated "complemented" bitmaps.

intybasic_compiler_v0.7.zip

intybasic_compiler_v0.7.1.zip

intybasic_compiler_v0.7.2.zip

intybasic_compiler_v0.7.3.zip

  • Like 10
Link to comment
Share on other sites

Getting better and better :D.

 

One of the space saving optimisations I mentioned previously didn't make it in. You can change this line in the file intybasic_epilogue.asm :-

 

    ORG $327,$327,"-RWB"
to this :-

 

    ORG $310,$310,"-RWB"
And reclaim 23 words of system memory back.
  • Like 1
Link to comment
Share on other sites

Personally, I'd change the MOB placement to something like this for scrolling games :-

 

        ;
        ; Scrolling things
        ;
        MVI _scroll_x,R2
        MVO R2,$30
        MVI _scroll_y,R3
        MVO R3,$31

        ;
        ; Updates sprites (MOBs)
        ;
        MVII #_mobs,R4
        MVII #$0,R5     ; X-coordinates
        MVII #3,R1
@@vi2:  MVI@ R4,R0   ; MOB 0
        SUBR R2,R0
        MVO@ R0,R5
        MVI@ R4,R0   ; MOB 1
        SUBR R2,R0
        MVO@ R0,R5
        MVI@ R4,R0   ; MOB 2
        SUBR R2,R0
        MVO@ R0,R5
        MVI@ R4,R0   ; MOB 3
        SUBR R2,R0
        MVO@ R0,R5
        MVI@ R4,R0   ; MOB 4
        SUBR R2,R0
        MVO@ R0,R5
        MVI@ R4,R0   ; MOB 5
        SUBR R2,R0
        MVO@ R0,R5
        MVI@ R4,R0   ; MOB 6
        SUBR R2,R0
        MVO@ R0,R5
        MVI@ R4,R0   ; MOB 7
        SUBR R2,R0
        MVO@ R0,R5

        MOVR R3, R2  ; Ripple 0 -> Y -> X
        CLRR R3

        DECR R1
        BNE @@vi2
Then you don't have to automatically subtract numbers from sprite positions in your game because the kernel does it automagically :D.

 

The only downside is that disabled MOBs will need to have an X coordinate of 7 (or more), otherwise they'll be enabled (assuming that their INTR and X-SIZE bits aren't set).

  • Like 1
Link to comment
Share on other sites

Getting better and better :D.

 

One of the space saving optimisations I mentioned previously didn't make it in. You can change this line in the file intybasic_epilogue.asm :-

 

    ORG $327,$327,"-RWB"
to this :-

 

    ORG $310,$310,"-RWB"
And reclaim 23 words of system memory back.

 

Thanks. Still I need to check how much stack uses Intellivision BIOS to get into my interrupt routine and estimate stack size for user programs.

  • Like 1
Link to comment
Share on other sites

If you're not using the EXEC to manage MOBs or anything, then the only EXEC stack usage for ISRs is 8 words to push the current program context, in this order:

  1. Interrupted program address (pushed by CPU)
  2. R0
  3. Processor Status Word (ie. the "flags" register)
  4. R1
  5. R2
  6. R3
  7. R4
  8. R5

As with GroovyBee, my default stack size is 32 words. In Space Patrol, I tried to trim that down to about 14 or 15, but ended up reserving 20 words.

 

One way you can crudely check how much stack you're using is to pre-fill the stack area with a known value, and see if it gets overwritten. You can also set a data-watch on locations near the top of the stack range to see if you ever push into these ranges.

 

Sometime back, I experimented with a stack "high water mark" tracker that's built into jzIntv's debugger. It never worked well enough for me to consider productizable. I forget if it's compiled into the current jzIntv. If it is, the "k" command in the debugger toggles it on and off. IIRC, you want to set a breakpoint just after the instruction that initializes the stack pointer, toggle it on, and then run your program. It'll generate a file named "stack.trc" that shows the addresses of instructions pushed your stack to new depths. Or, at least, that was the hope. I developed that back when I was trying to squeeze Space Patrol's stack down to make room for a few more 16-bit words. :-)

  • Like 2
Link to comment
Share on other sites

If you're not using the EXEC to manage MOBs or anything, then the only EXEC stack usage for ISRs is 8 words to push the current program context, in this order:

  1. Interrupted program address (pushed by CPU)
  2. R0
  3. Processor Status Word (ie. the "flags" register)
  4. R1
  5. R2
  6. R3
  7. R4
  8. R5

As with GroovyBee, my default stack size is 32 words. In Space Patrol, I tried to trim that down to about 14 or 15, but ended up reserving 20 words.

 

 

I'll give a look :)

Link to comment
Share on other sites

If you're not using the EXEC to manage MOBs or anything, then the only EXEC stack usage for ISRs is 8 words to push the current program context, in this order:

  1. Interrupted program address (pushed by CPU)
  2. R0
  3. Processor Status Word (ie. the "flags" register)
  4. R1
  5. R2
  6. R3
  7. R4
  8. R5

As with GroovyBee, my default stack size is 32 words. In Space Patrol, I tried to trim that down to about 14 or 15, but ended up reserving 20 words.

 

One way you can crudely check how much stack you're using is to pre-fill the stack area with a known value, and see if it gets overwritten. You can also set a data-watch on locations near the top of the stack range to see if you ever push into these ranges.

 

Sometime back, I experimented with a stack "high water mark" tracker that's built into jzIntv's debugger. It never worked well enough for me to consider productizable. I forget if it's compiled into the current jzIntv. If it is, the "k" command in the debugger toggles it on and off. IIRC, you want to set a breakpoint just after the instruction that initializes the stack pointer, toggle it on, and then run your program. It'll generate a file named "stack.trc" that shows the addresses of instructions pushed your stack to new depths. Or, at least, that was the hope. I developed that back when I was trying to squeeze Space Patrol's stack down to make room for a few more 16-bit words. :-)

 

I used 16 words of stack in Christmas Carol, but I had to do a bunch of wrangling and messy code to avoid using the stack, which is not necessarily conducive to clean and maintainable code. However, all code paths use at most 14 words of the stack at any given time.

 

That said, I also think that a stack of 32 should be sufficient for most games.

 

As for the "high water mark" tracker in the debugger, I used it extensively during Carol's development, and found it extremely useful in identifying the usage ceiling. It was also more than once my first insight into a stack overflow when observing some strange behaviour, which allowed me to focus my debugging effort.

 

-dZ.

  • Like 1
Link to comment
Share on other sites

I just want to know if this new update can make really nice snow levels!

 

Actually, no. You need to wait for nanochess to implement the SNOW statement. Without it, the Intellivision is incapable of displaying snow levels. Perhaps in IntyBASIC compiler v0.8?

  • Like 2
Link to comment
Share on other sites

Intellivision should be able to show snow. Just get a TV box with a slider that let you select TV and game. Adjust it towards TV and voila, snow in all games. I played Adventure for the Atari 2600 and did that to make it seem that it was raining in that game.

I guess the next update will have water levels. ;)

Anyway, on topic. I really need to dig back into this. I do want to figure out how to use FG/BG color mode. I was thinking it was restricted to card 0-63 and not 256 and up. I will experiment with the new functions.

  • Like 3
Link to comment
Share on other sites

Er, that IntyColor is really picky about the files it will accept. Tried it with a BMP of the proper size and bit depth and it gave me a ton of errors, even with the color turned down to four. Is there something I should know about the way this works?

 

Not having tried it, could it have something to do with the colour limitations of the Intellivision? Perhaps it assumes certain combinations as verboten.

Link to comment
Share on other sites

Er, that IntyColor is really picky about the files it will accept. Tried it with a BMP of the proper size and bit depth and it gave me a ton of errors, even with the color turned down to four. Is there something I should know about the way this works?

Maybe if you attached the *.bmp or the list of errors it might help us identify the problem.

Link to comment
Share on other sites

Just out of curiosity I ran intycolor over the title page for Next Street and it complains about more than two colours per block. The extra colours are caused by MOBs, but the tool wasn't to know that ;). It would be kinda neat to have something like Quantizator on the A8s, but thats a whole project in itself. So... Maybe it would be good to have a list of rules stating what the limits of the tool are regarding "valid" input images. Then, after an image is converted, the programmer can add any extra flourishes using MOBs.

Link to comment
Share on other sites

Here are some requirements of IntyColor (to be included in manual):

  1. Your image must be 160x96 pixels.
  2. Your BMP file must be 24-bits (in case of doubt use MS-Paint or Paint .net)
  3. For exact results you should use the colors_reference.bmp file as palette for drawing (top colors are primary, bottom colors are secondary)
  4. Only 2 colors per 8x8 block. You'll be warned if you exceed this limit.
  5. In Foreground/Background mode you can use only one of the 8 primary colors and one of the 16 total colors. IntyColor also checks for this.
  6. There is a limit of 64 different tiles, once you reach this limit, IntyColor will show a warning as the image is undisplayable.

In BASIC mode, IntyColor will generate a IntyBASIC file that can be compiled right away to show your picture.

  • Like 1
Link to comment
Share on other sites

Here are some requirements of IntyColor (to be included in manual):

  1. Your image must be 160x96 pixels.
  2. Your BMP file must be 24-bits (in case of doubt use MS-Paint or Paint .net)
  3. For exact results you should use the colors_reference.bmp file as palette for drawing (top colors are primary, bottom colors are secondary)
  4. Only 2 colors per 8x8 block. You'll be warned if you exceed this limit.
  5. In Foreground/Background mode you can use only one of the 8 primary colors and one of the 16 total colors. IntyColor also checks for this.
  6. There is a limit of 64 different tiles, once you reach this limit, IntyColor will show a warning as the image is undisplayable.

In BASIC mode, IntyColor will generate a IntyBASIC file that can be compiled right away to show your picture.

 

I understand limiting to 64 custom tiles, but it would be better if IntyBASIC could distinguish GROM tiles and not count them towards that total. I know my own tile ripper does this. What do you think?

 

-dZ.

  • Like 2
Link to comment
Share on other sites

I understand limiting to 64 custom tiles, but it would be better if IntyBASIC could distinguish GROM tiles and not count them towards that total. I know my own tile ripper does this. What do you think?

Good suggestion! Nonner and I make good use of the GROM characters. There are all kinds of interesting shapes in there.

  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...