IntyBASIC compiler v0.7 (now with IntyColor)

[+nanochess]

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.

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

[Jess Ragan]

Pretty keen! Still need to actually use this and 7800 BASIC, though.

[GroovyBee]

Getting better and better .

 

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.

[GroovyBee]

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 .

 

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

[+nanochess]

Getting better and better .

 

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.

[GroovyBee]

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.

I have my stack size set to 32 for all my games and haven't encountered any problems using ISRs.

[intvnut]

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

[+nanochess]

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

[+DZ-Jay]

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.

[+nanochess]

I was doing a test and found a bug in IntyColor utility for background colors in range 8-15. I've updated first post to v0.7.1

[Rev]

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

[GroovyBee]

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

Only in the hands of a snow master .

[+nanochess]

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

 

Beautiful, amazing, astonishing snow levels!

[Rev]

Awesome!

[+DZ-Jay]

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?

[Kiwi]

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.

[Jess Ragan]

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?

[+DZ-Jay]

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.

[GroovyBee]

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.

[GroovyBee]

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.

[+nanochess]

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.

[+DZ-Jay]

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.

[GroovyBee]

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.

[Kiwi]

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

 

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

[intvnut]

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

 

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