Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by AndyMt

  1. The Kernal actually does automatically increment and switch the bank when using cbm_k_load(). I'm using this in Brixx for loading the game intro music into banked RAM from a single 40kB file.
  2. I actually had similar thoughts - I'm from Switzerland where the situation sometimes is in other ways complicated. But - for Switzerland a CE label is not required for customs. So at least I could get it in here, although customs and taxes (VAT) will likely cost around 100€ in total. My brother is working at customs - he for sure can help to "optimize" the declaration. So - if you live not too far from the border... you could pick it up here. Sending a parcel would not work - because of the missing CE label. I briefly thought about being an importer to provide the CE label, but for this you need to be registered with a so-called "notified body". I'm working in the medical device industry - I know about this stuff. A quick check showed, that this would be impractical, we are talking thousands of € just to get started. Then there is the risk with the German "Fernabgabegesetz" (online purchases), "Produkthaftung" (product liability) and "Gewährleistung" (2 year warranty) one would take to establish a business. No wonder very few do this... A second option would be a kit version or a pre-assembled motherboard. I think CE labelling is not required for those as it would be components, not products.
  3. I must have mixed it with the C64 or some other machine then .
  4. Actually BASIC has to fit into 8KB if I'm not mistaken. Aren't the other 8KB used by the KERNAL ROM?
  5. I updated the game a little: Additional level Added end title music added fade-in/out effects Explosion animation. Have fun
  6. Yes - it's not just this forum, unfortunately it's most websites. OT: I now even start having an issue with my car, because Tesla decided to make the speedometer font smaller ... It may look more "elegant" now, but well... Back in the old days with analoge instruments, with the position of the needle you knew what speed you were going. Now it's in writing only - refocusing and reading on a glance just doesn't work well above 50...
  7. Yes, but then everything else in any other software looks "blocky" in comparison . Unfortunately the CSS parameters "font-smooth" or "-webkit-font-smoothing" were dropped from the CSS3 specs/drafts. Otherwise "-webkit-font-smoothing: none" would have been the solution. I just tried: Chrome, Opera and Firefox ignore the parameter, even though they know it exists... So 110% zoom is the solution for me - I didn't notice the issue, because my aging eyes need 125 anyway...
  8. You cannot imagine the flashback I just had ... The US MAD wasn't available in Switzerland (there was a "softened" German version, though), but my uncle sent them over from the states. So I typed in that code back then in 1985...
  9. That's exactly what I do, too . Maybe not very elegant, but it works.
  10. Ok, then I'm out of ideas atm. I have to try that myself first. Until now I had no need to run it from sdcard. But of course this will be the way the real hardware is going to do it, so I will look into it at some point. Until then simply run the prg directly via the -prg option. I added instructions to the download section.
  11. Gif can be unpacked using zlib if I'm not mistaken. And there is a 6502 implementation: https://github.com/pfusik/zlib6502
  12. I must admit - I've never tried it with a sdcard during development. I always start the prg file directly via command line. And - I develop my games with cc65 on Windows. What you could try is to rename all files to lower case. Windows does't care, but Linux does.
  13. 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 .
  14. 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!
  15. I found a very good guide on the web: https://github.com/ilmenit/CC65-Advanced-Optimizations This helped me a lot .
  16. For me the X16 appealed more for the following reasons: You will be able to look at the board and kind of "see" how it works. I love that! 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! 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. 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.
  17. 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.
  18. The land of chocolate... Probably Switzerland, where I'm from?
  19. 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.
  20. 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 .
  21. 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.
  22. New Version 0.5: Fixed the collision detection - finally! More enemy sprite graphics. Minor speed and game play changes. Have fun!
  23. Impressive! Me - none. I think a MiSTer doesn't count?
  • Create New...

Important Information

Please review our Terms of Use