Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by AndyMt

  1. Looking really good, the new key caps are a plus! Regarding the colour-scheme: I'm fine with grey. Although the pattern on the rendering with only the arrow and function keys +X16 in grey appeals more to me. Maybe add Pg Up/Dn Home/End to be grey, too.
    It looks very "wild" or "messy" on the prototype now. But as you said: that might change.
    I will like it in any case, can't wait for the real hardware. I even found a 14" CRT VGA monitor I will use with the X16 😀.

    • Like 1

  2. Quote

    I do find that the saturation of the colors in de c64 palette is not very good in the Cx16 emulator though: when the images are displayed on a C64 or in an emulator like Vice for instance, they look much better in my opinion.

    I noticed that, too. In most colors seem to be too dark, a few too bright (Yellow if I recall correctly). Have you tried tweaking the palette for your viewer? 

    Other than that: great tool!

  3. For me the X16 appealed more for the following reasons:

    1. You will be able to look at the board and kind of "see" how it works. I love that!
    2. Memory layout and bank switching is very basic, but also easy to understand. The amount of available memory imposes pressure to optimize. I like that!
    3. Graphics is somewhat in between an ATARI ST and the Commodore Amiga, so more 16-bit era like. Which allows for good 2D graphics and I'm very happy what I've achieved so far. The pixelated 320x240 resolution adds to the nostalgic feel.
    4. The 8 MHz CPU is fast compared to the C64, but still slow enough so that you have to live with certain limitations, which is part of the fun. But it still allows me to use C for programming with some assembler to get around the mentioned limitations.

    I'm looking forward to "real" hardware. I'd like to show it to my nephews (now 3 and 6 years old) in a few years, to explain and "show" them how computers actually work. I find it still very important to know about those basics. Even with modern computers this helps to understand why certain things work and others suddenly don't.

    • Like 3

  4. I also started with a TI99/4A my dad bought for me (and himself) in 1982. It soon turned out be be the "wrong" choice, compared to everyone else in school (some VC20 and mostly C64)... I did some BASIC programming with it, but it wasn't capable enough for what I wanted to do with it.

    But my favorite was the Atari 260ST we got for Christmas 1985. I upgraded it to 1MB of RAM myself with some soldering... also changed the keyboard later to MX switches. Then we got the 20MB external Harddrive, which was incredible!

    Of course I've used it for gaming a lot... But the ST got me into "real" programming (GFA Basic, Pascal, C) and was the catalyst for my career in computer science and software engineering.

    The ST was still easy to understand (it didn't have the "blitter" chip), IO chips, video and audio was all directly memory mapped. I could look at the main board and actually see how everything was connected, where the address and data bus was routed through etc.

    Switching to PC compatibles in the late 8ies/very early 90ies for my professional career was a shock. Compared to the ATARI ST those were crap really. It took until Windows 95 (98) for me to get back the same "multimedia feel" and easy of use with PC compatibles. More than 10 years to catch up with the ST... 10 "lost" years!

    That's why the Atari ST will always have a special place in my memories.

    • Like 1

  5. 2 hours ago, Johan Kårlin said:

    Thanks for noticing! I changed the filenames of the binary files to capital letters. It doesn't seem to work anyway with online emulator. Now I don't know what the problem is. Maybe the emulator has cached the old version? Anyway, glad to see that my error handling works fine : ).

    There is 2 things to make it work, I struggled with this, too:

    1. Binary Files (and PRG file) have to be in upper case letters - this you have done

    2. when you load the files in the source code the filename needs to be in lowercase:

    With cc65 it looks like this:

    result = vload_host("bg-sky.bin"MAIN_SCREEN_BMP_ADDR);

    Don't know how it should be in acme.

    • Like 1

  6. New Version 0.6:

    • More enemy sprites, final designs
      These sprites should now be complete. Maybe I'll fine tune them later. VRAM constraints won't allow more enemies, without loading them in the fly.
    • Animated enemy sprites
      All enemy sprites are now animated with 4 frames each. Despite the number of sprites on the screen this seems to be no performance issue yet.
    • More diverse level compositions
      The formations of enemies is now more diverse

    Next I'll probably try to make some enemies break formation and attack. Or maybe I have them close their ranks from time to time. Let's see 🙂.

  7. 17 hours ago, SerErris said:

    So C with hand crafted Assembly routines optimized for speed might be a good and efficient procedure. However without a profiler you will never know.

    I fully agree on this statement. I use C with some assembler. But even without profiler you can get some indications by looking at the generated assembler code. I do this in case I run into a performance issue. Which until now were surprisingly few. Even though "Invaderz" handles a lot of sprites at the same time, including movements and collision detection, until now these parts didn't require assembler optimisations. Ok - I always consider what the compiler will do with C code I write. So I probably optimise anyway.

    Until now I only coded the interrupt handlers in assembler - for Vera hardware collision detection and for sound effects.

    • Thanks 1

  8. I've used this script for a while now, thanks a lot for this. I'm think I stumbled across something in regards to the conversion.
    As it's a bit complicated I'll try to explain it:

    Colors appear different in emulator:

    Recently I noticed that the colors in the emulator appear slightly different than in Aseprite (using your script). Looking at the script it appears it rounds everything to a palette entry ending with "0" for each rgb value:
    0x00, 0x10, 0x20, 0x30... 0xE0, 0xFF << you can see here that there is a gap of 31 values at then end and 16 in between all others...

    The emulator produces each entry mostly with the same hex digits for each tuple (using screenshots and Gimp to determine color values). So:
    0x00, 0x11, 0x22, 0x33... 0xEE, 0xFF << here the gap is 17 between each color value.

    why this can be an issue:

    The script currently adds 8 and then discards the lower nibble. I think the thresholds for each of the 16 values per color value needs to be different. Right now there is a big gap in the brighter colors, which leads to color bleeding towards the slightly dimmer ones.

    Script algorithm changes:

    What I have done now is to change the script slightly and emit the above RGB values, so Gimp, Pro Motion, Aseprite etc. show the right colors (as the emulator would) and also use those for dithering. Of course VERA then can only use the upper 4 bits of each palette entry. Tools like Aloevera etc. take care of that. Using this delivered better results for me when working with large (320x240 - haha) bitmaps like I used in Brixx and Invaderz.

    It probably doesn't matter that much for sprites and tiles etc.

    I attach my (not very elegant) version of the script so you can see the difference.

    12-bit Palette Quantize V2.lua

    • Like 1

  9. New Version 0.4:

    Some gameplay changes:

    • Level is lost when bottom enemy progresses to shields/fortress.
      You then fall back to the previous level and can try to advance again.
    • If you fail level 1, then the game is over, too (or all lives lost).
    • Enemy movements get more difficult with each level.
      They move faster, they advance faster. Patterns still the same
    • Player sprite now has more realistic lag, when changing direction.
      Let me know what you think about this one. It was just unrealistically fast with the mouse, so I made it more difficult.

    Other improvements:

    • More Levels!
      The background story is now more complete. The descriptions for levels > 2 don't yet match the description in relation to enemy behavior or motherships etc.
    • Different enemy sprites
      I experiment with different enemy styles now. Most will probably be replaces later again. I like the martians, though 😉...  
    • Sprite animation for player sprite
      Player spaceship now shows thruster plumes and tilts when moving.
    • Like 2
  • Create New...

Important Information

Please review our Terms of Use