Jump to content

cd-w

Members
  • Content Count

    2,433
  • Joined

  • Last visited

  • Days Won

    2

Blog Comments posted by cd-w


  1. 7 hours ago, root42 said:

    Well, I was just ready to buy the cartridge, but: I can't! There is no 'Add to cart' button for Chetiry. Why? 

    I think this means it is currently out of stock

     

    Chris


  2. To use the approach that I am proposing, the workflow would be something like:

    • Create a file containing the sprite data in the usual DASM format
    • Run D00D over the data to optimize the layout
    • Run a utility to convert the D00D output into C struct format (this would need to be written)
    • #include the C struct containing the sprite data in your code
    Chris

  3. The best way that I know to do this is the following:

     

    1) Use D00D to optimize the data - assume the output is the following:

     

    sprite1:
      .byte 1, 2, 3, 4, 5
    sprite2:
      .byte 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
    sprite3:
    sprite4:
      .byte 1, 2, 3, 4, 5, 6, 7
    
    2) Create a C structure to hold the data - unfortunately you do need to specify the length of each chunk of data (you could probaby write a utility to do this):

     

    typedef struct {
      const unsigned char sprite1[5];
      const unsigned char sprite2[10];
      const unsigned char sprite3[0];
      const unsigned char sprite4[7];
    } SPRITEDATA;
    
    3) Initialize the structure with the sprite data (again this formatting could be done via a utility):

     

    __attribute__((used))
    __attribute__((packed))
    const SPRITEDATA sprites = {
      .sprite1 = {1, 2, 3, 4, 5},
      .sprite2 = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10},
      .sprite4 = {1, 2, 3, 4, 5, 6, 7}
    };
    
    4) Now, you can reference the sprite data easily, e.g:

     

    // Access the data directly
    unsigned char x = sprites.sprite1[6];
    
    // Access the data as an array (C doesn't do bounds checking, so this is actually accessing data in sprite2)
    const unsigned char *s1 = sprites.sprite1;
    unsigned char x = s1[6];
    
    // Copy the sprite data to a queue
    myMemcpy(_QUEUE, (unsigned char*)s1, 16);
    
    // For bonus points you can also access the data as an offset from the beginning of the struct (GCC only)
    #define offsetof(type, member)  __builtin_offsetof (type, member)
    unsigned char *spritedata = (unsigned char *)&sprites;
    unsigned char y = spritedata[offsetof(SPRITEDATA, sprite4) + 3];
    
    // The offsets can also be held in a short array to save memory (over pointers):
    const unsigned short offsets[] = 
    {offsetof(SPRITEDATA, sprite1),
     offsetof(SPRITEDATA, sprite2),
     offsetof(SPRITEDATA, sprite3),
     offsetof(SPRITEDATA, sprite4)};
    

  4. I'd like to see Project Bruce come back at some point. Of course if you want to work on it, I'd be happy to help. icon_wink.gif But the potential for a C&D on that is pretty high, which is why I haven't been doing anything with it.

     

    I thought bus stuffing had been sorted out by ZackAttack. icon_confused.gif

     

    The bus stuffing fix by ZackAttack is quite difficult to use - not really possible with the BUS driver that I previously wrote. I'm still hoping for a tweak to the Harmony hardware, or that the new UnoCart 2600, will make this unnecessary ...

     

    Chris

    • Like 2

  5. Please don't stop working on your homebrews! CDF will make it possible to do some amazing things. Is it possible that the tight PRGE deadline is sucking the fun out of it? Perhaps you should consider pushing the release after the show to give more time to finish things off?

     

    Chris


  6. Can you explain a bit about how the XOR algorithm works as I'm struggling to follow it from the code? I think you start with a base station image in RAM, then draw the pods into a second RAM buffer, then XOR the second buffer into the base station image. I'm curious why the second buffer is required? Could you simply draw the pods on top of the base image, or xor them directly onto the base image without the buffer?

     

    Chris


  7. It is a shame that you had to drop the large Draconian logo. I wonder if it would have been possible to compress the logo data better (e.g. RLL encoding) and decompress it directly into the 4K display data region, but I guess the 96-pixel kernel would still take a lot of space?

    Chris

×
×
  • Create New...