Combee bitmap patch

[andrew-davie]

Consider adding Ben Coombe's bitmap changes, as listed in the PATCHES file...

From: Ben Combee [mailto:ben.combee@gmail.com] On Behalf Of Ben Combee Sent: Thursday, February 28, 2008 8:56 AM To: atari2600@taswegian.com Subject: Bitmap format patch for DASM

Hi, Andrew... I just started up a 2600 project of my own, and I've done a few local modifications to the DASM source -- most are to make it compile without warnings in CodeWarrior for Windows, but I also added a new integer representation inspired by some of the disassemblies I've seen. I call it bitmap format, and instead of a leading %, you use a leading | followed by dots and Xs. A trailing | is allowed, but not required. Here's an example.

PfDataStart
   .byte |..XXX...|
   .byte |....X...|
   .byte |X..XX..X|
   .byte |.XX..XXX|
   .byte |.XX..XXX|
   .byte |X..XX..X|
   .byte |....X...|
   .byte |..XXX...|
PfDataEnd

I find it easier to visualize the bitmaps in the code using this format, as 0's and 1's aren't that distinctive.

Here's the code change made to exp.c. I added this new function just before pushbin():

char *pushbitmap(char *str)
{
    long val = 0;
    while (*str == '.' || *str == 'X') {
        val = (val << 1) | (*str == 'X');
        ++str;
    }
    if (*str == '|') {
        ++str;
    }
    stackarg(val, 0, NULL);
    return str;
}

Then I modified the case statement around line 314:

    case '|':   /*  13: |   11: ||              */

        if (str[1] == '.' || str[1] == 'X')
        {
            str = pushbitmap(str+1);
        }
        else if (str[1] == '|')
        {
            doop((opfunc_t)op_oror, 11);
            str += 2;
        }
        else
        {
            doop((opfunc_t)op_or, 13);
            ++str;
        }
        break;

I'd be glad to send the other changes, but they're mostly just adding "static" in front of local functions and cleaning up some loops that used a ";" to do nothing into using "{ }" instead (it tells the compiler that you intended on the empty action rather than just using a semicolon accidentally by habit.

[dionoid]

I did experimenting with this, and found that for visualizing bitmaps in code, there are other characters that work even better than dots and Xs. Like for example dashes and @s. IMO the vertical alignment of the dashes make the bitmaps even easier 'see':

PfDataStart
   .byte |--@@@---|
   .byte |----@---|
   .byte |@--@@--@|
   .byte |-@@--@@@|
   .byte |-@@--@@@|
   .byte |@--@@--@|
   .byte |----@---|
   .byte |--@@@---|
PfDataEnd

compared to dots and Xs:

PfDataStart
   .byte |..XXX...|
   .byte |....X...|
   .byte |X..XX..X|
   .byte |.XX..XXX|
   .byte |.XX..XXX|
   .byte |X..XX..X|
   .byte |....X...|
   .byte |..XXX...|
PfDataEnd

[thrust26]

Maybe we can make the chars configurable?

[andrew-davie]

I was about to say what Thomas just wrote! Could just give a range of characters for "0" and anything else is 1? So, space, dot, dash, underscore, quote, zero.... all mean 0.... anything else (except for |) is 1?

[thrust26]

Maybe via pseudo opp?

[andrew-davie]

If only macros had string handling. Then this could all be coded in a macro.

[andrew-davie]

PfDataStart
   .byte |..███...|
   .byte |....█...|
   .byte |█..██..█|
   .byte |.██..███|
   .byte |.██..███|
   .byte |█..██..█|
   .byte |....█...|
   .byte |..███...|
PfDataEnd

[andrew-davie]

PfDataStart
   .byte |░░███░░░|
   .byte |░░░░█░░░|
   .byte |█░░██░░█|
   .byte |░██░░███|
   .byte |░██░░███|
   .byte |█░░██░░█|
   .byte |░░░░█░░░|
   .byte |░░███░░░|
PfDataEnd

[thrust26]

If only macros had string handling. Then this could all be coded in a macro.

Macros have a lot o of limitations, but that's a different issue (or two, three, four...). 😈

[andrew-davie]

If only macros had string handling. Then this could all be coded in a macro.

Macros have a lot o of limitations, but that's a different issue (or two, three, four...). 😈

Yes. But, to just make the point here while I mentioned it... macros already allow you to access the entire string passed to the macro via {0} -- if we allowed some sort of indexing on that, that would be all that would be needed.

[thrust26]

@andrew-davie Do you know how to convert the macro string parameters into values, e.g. to use them for calculations?

[andrew-davie]

@andrew-davie Do you know how to convert the macro string parameters into values, e.g. to use them for calculations?

No. I have tried many many times to do this. I don't think it's possible. I have tried passing the parameters to a 2nd macro... no dice. It's a shame, because it would be incredibly useful to be able to do that.

[dionoid]

If we can enhance the macro engine to support indexing of (string) parameters, then that is the preferred way to solve the original issue, right? See Improve macro parameter handling #15