Ready to tear my hair out trying to debug this - please help?

[petit chou]

Hey, all,

 

I've been working on my own implementation of a halfwidth alphabet printer for my current project, a roguelike for the INTV. I am having an incredibly difficult time trying to diagnose an error I'm having in the stub program I intend to turn into my halfwidth print routine, and I could *really* use some help. The program is about 65 lines (not including the INCLUDEd data file full of BITMAP statements) and is attached to this post in a .zip file along with a compiled binary.

 

The problem is somewhere in the math routines in my FOR loops -- it's pushing the right half of my text display ahead in the buffer a little too far, but I can't for the life of me figure out why. Any help you could give me would be so very greatly appreciated.

 

Thank you so much in advance.

 

petit chou - alphabet test.zip

[intvnut]

The issue I think is this:

(WRITE_LOC * 2)

Everywhere you use that, it'll shift you down by 4 rows for odd letter positions.

 

You really want to use something more like (WRITE_LOC AND -2) * 2.

Edited May 7, 2016 by intvnut

[petit chou]

The issue I think is this:

(WRITE_LOC * 2)

Everywhere you use that, it'll shift you down by 4 rows for odd letter positions.

 

You really want to use something more like (WRITE_LOC AND -2) * 2.

 

If I could hug you through the internet I would squeeze the stuffing out of you. Thank you SO much.

[intvnut]

 

If I could hug you through the internet I would squeeze the stuffing out of you. Thank you SO much.

 

Certainly!

[intvnut]

You could probably optimize further. I haven't tested, but I think this works too, for example:

.

            IF WRITE_LOC % 2 THEN
                ' Write right hand
                #LEFTROWS  = #DISPLAYBUFFER((WRITE_LOC * 2) - 2 + J) AND $F0F0
                #RIGHTROWS = ALPHABET((#LETTERBUFFER(I) * 4) + J) AND $0F0F
                #DISPLAYBUFFER((WRITE_LOC * 2) - 2 + J) = #LEFTROWS + #RIGHTROWS   
            ELSE
                ' Write left hand
                #LEFTROWS  = ALPHABET((#LETTERBUFFER(I) * 4) + J) AND $F0F0
                #RIGHTROWS = #DISPLAYBUFFER((WRITE_LOC * 2) + J) AND $0F0F
                #DISPLAYBUFFER((WRITE_LOC * 2) + J) = #LEFTROWS + #RIGHTROWS   
            END IF

.

And, of course, you could optimize quite a bit further (still by staying within IntyBASIC), but I'm not sure how important it is.

Edited May 7, 2016 by intvnut

[petit chou]

You could probably optimize further. I haven't tested, but I think this works too, for example:

.

            IF WRITE_LOC % 2 THEN
                ' Write right hand
                #LEFTROWS  = #DISPLAYBUFFER((WRITE_LOC * 2) - 2 + J) AND $F0F0
                #RIGHTROWS = ALPHABET((#LETTERBUFFER(I) * 4) + J) AND $0F0F
                #DISPLAYBUFFER((WRITE_LOC * 2) - 2 + J) = #LEFTROWS + #RIGHTROWS   
            ELSE
                ' Write left hand
                #LEFTROWS  = ALPHABET((#LETTERBUFFER(I) * 4) + J) AND $F0F0
                #RIGHTROWS = #DISPLAYBUFFER((WRITE_LOC * 2) + J) AND $0F0F
                #DISPLAYBUFFER((WRITE_LOC * 2) + J) = #LEFTROWS + #RIGHTROWS   
            END IF

.

And, of course, you could optimize quite a bit further (still by staying within IntyBASIC), but I'm not sure how important it is.

 

That's much cleaner - thank you! I was just trying to get something up and working before worrying about optimizing it, although faster would probably be better. Right now it takes ~1/10th of a second to print a line, which is acceptable for this particular case (it's a roguelike - nothing is happening all that quickly) but would be nice to have faster for sure.

 

I am having some really bizarre things happen to me if I use the routine to write a full row of text on the bottom -- I don't know if it's good ol' Intellivision quirkiness, an implementation issue in jzintv, something weird with the SCROLL statement or what. If I use BORDER and SCROLL the last two rows of the text in screen location 238 get eaten, but if I comment them out the problem goes away. Also there are strange graphical artifacts that seem to be happening if I write to screen location 239.

 

I've attached a .zip file with the modified source (not with your optimizations yet, unfortunately) and the offending statements. Would you mind to take a look at them and toss me some ideas as to what might be going on?

 

Thanks a ton -- you're amazing.

petitchou - display weirdness.zip

[intvnut]

There's not enough time in a frame to update 20 cards, that's why. :-) BORDER and SCROLL probably eat into that time. The manual even calls it out:

.

    Note there is an approximate limit of loading 18 GRAM cards per frame
    (measured with emulator in NTSC mode)

    This limit is reduced to 16 GRAM cards per frame when using the music player
    (PLAY statement)

.

You can break this up into two DEFINE statements separated by a WAIT:

.

    DEFINE 0,10,#DISPLAYBUFFER
    WAIT
    DEFINE 10,10,VARPTR #DISPLAYBUFFER(10*4)

.

A quick test suggests that works.

Edited May 7, 2016 by intvnut

[petit chou]

There's not enough time in a frame to update 20 cards, that's why. :-) The manual even calls it out:

.

    Note there is an approximate limit of loading 18 GRAM cards per frame
    (measured with emulator in NTSC mode)

    This limit is reduced to 16 GRAM cards per frame when using the music player
    (PLAY statement)

.

You can break this up into two DEFINE statements separated by a WAIT:

.

    DEFINE 0,10,#DISPLAYBUFFER
    WAIT
    DEFINE 10,10,VARPTR #DISPLAYBUFFER(10*4)

.

A quick test suggests that works.

 

I feel very silly for missing that. Thank you so much, again!

[intvnut]

 

I feel very silly for missing that. Thank you so much, again!

 

I only noticed it because I had to look it up to see what it did. :-) I've written probably a page of IntyBASIC total so far, mostly trying to break the compiler, spot-checking things, or tweaking existing code.

[freewheel]

 

I feel very silly for missing that. Thank you so much, again!

 

I think we ALL get caught on this one, at one point or another. I've now forced myself into the habit of breaking up DEFINEs into 16 card blocks (which works out nicely into 4 blocks, or 64 cards total). The worst was when I followed the manual, was using 18 cards per DEFINE - and then weeks later added MUSIC. Suddenly all my graphics were broken! What the hell? So now I just enforce max 16 per WAIT, and problem solved

[First Spear]

That's another reason for an IntyBasicLint program in my opinion. On my list....

 

 

 

I think we ALL get caught on this one, at one point or another. I've now forced myself into the habit of breaking up DEFINEs into 16 card blocks (which works out nicely into 4 blocks, or 64 cards total). The worst was when I followed the manual, was using 18 cards per DEFINE - and then weeks later added MUSIC. Suddenly all my graphics were broken! What the hell? So now I just enforce max 16 per WAIT, and problem solved