Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


borgar last won the day on November 8

borgar had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

borgar's Achievements


Newbie (1/14)

  • First Post Rare
  • Collaborator Rare
  • Reacting Well Rare
  • Dedicated Rare
  • Week One Done

Recent Badges



  1. Very nice. My only currently working project (https://www.commanderx16.com/forum/index.php?/files/file/182-petaxian/) still compiles and run fine though there is no reason to rebuild and upload yet. I have made the Git project public (https://github.com/cyborgar/Petaxian) in case anyone want to look at a bit larger Prog8 code example compared to the mostly smaller examples coming with the compiler. I have organized code in multiple files/modules. Though there is no code protection this does require explicit references when crossing modules and that helps a lot with visibility. I have (slowly) started on another clone game (this one is going to copy liberally from Llamasoft's Gridrunner) but I've just gotten started. I'm going to focus on getting it to work on C64 before I'll probably port it to CX16.
  2. Ah, a fellow visitor to Skara Brae. I also played the original on C64 and bought the remasters. I never played the second or third game on C64 and haven't gotten started on those in the remaster either. I have fond memories of playing this (with a suitable stack of gridpaper), though I have to admit that without the new automapper in the remaster I would never consider replaying these today.
  3. Right now I'm fine with 1. I'm basically not going to require the new functionality in the near future so the new compiler work with the old emulator for me.
  4. After the initial burst of work on this game to a reasonable looking state, things have as expected slowed down. Only a few things added this time Changed game over to defeat/victory with score "calculation" (bonus points for any lives at end of game) Some enemies have a chance to drop seeker bombs (slower bombs that move toward player) Made credits more like other info pages
  5. Yes indeed. I have tested this and had no problems importing and drawing a screen from binary input. Many thanks.
  6. Using the namespace prefix gives me .\screen_test.asm:57:9: error: not defined ident '_main' lda #<_main.rawdata ^ .\screen_test.asm:43:1: note: searched in this object only
  7. I have upgraded to BETA2 and Petaxian runs fine I can now use the Prog8 const from my assembly which is excellent. However, I'm still struggling with figuring out how to import raw data. I.e. I want to add full screen char data either as binary or as asm code. AND access this from Prog8. All I basically need is a way to figure out the address to the first byte of this data. Right now I can not e.g. see any way that %asmbinary is even useful. You mentioned using a lable but I can't get this to work. This might not be a bad idea to add an example for this btw. In any case I'm trying something like this: main { rawdata: %asmbinary "data.bin" sub start() { uword charPtr = &rawdata charPtr++ ; Only to prevent removal of variable during compile } } but get the following error .\screen_test.asm:57:9: error: not defined ident '_rawdata' lda #<_rawdata ^ .\screen_test.asm:43:1: note: searched in this object only start .proc ^
  8. Thank you. There is actually a slightly bigger enemy (though marginally so) that appears at stage 9 and later. I guess you just have to practice to get that far. BTW, the enemies are actually 4 (2x2) characters in size. I support movement "within" the characters using the 16 PETSCII characters that cover all the variations of 2x2 "sub bits". I was inspired by PET/C64 Galaga (which this is basically a clone of). I don't currently support any larger enemies though that is of course completely possible, e.g. Galaga had a 3x2 char sized enemy. It is something I have noted down as a possible improvement.
  9. A new update of Petaxian has been uploaded with the following main changes : Added random "attacks" for enemies (with increased bomb frequency) Updated to non-uniform waves. Remixed to 12 stages. Add stage start "announcement" Add stage completion time bonus points Unsurprisingly there is a lot work left after the basic gameplay mechanics is implemented. It certainly makes one appreciate all the other non-coding work that goes into games (I certainly see why having professional level designers and testers are necessary). I want to add some sort of proper "game end" (and show current high score) but after that I suspect updates to this game will slow down. I have a couple of other game ideas I'm considering (none especially original).
  10. There are plenty of tutorials for 6502 assembly out there (here is one that starts gently https://codeburst.io/an-introduction-to-6502-assembly-and-low-level-programming-7c11fa6b9cb9). It might not be a bad idea to do read a few such documents before jumping into videos. I think you probably should not start out with something too ambitious for your first attempts. You probably can a lot of smaller programs without having to deal directly with the stack pointer. You can start by transferring parameters in the registers (A, X and Y) and/or direct memory addresses (Zero Page or not) and limit your self to implicit stack use with JSR/RTS. I'd also recommend taking looking at Prog8 (https://prog8.readthedocs.io/en/latest/#). This gives you something a lot faster than Basic while not being as completely low level as assembly. Prog8 allow inclusion of assembly into the program fairly gracefully when you need "full speed" and if you just need a few really fast (non-recursive) functions you don't not need to learn to use the program stack. And since Prog8 produces assembly output (before producing the binary with 64tass) it will also allow you to learn a lot from looking at the produced output when you are interested. BTW, back in the day (80's) when I did some limited machine code programming I basically had no understanding of the stack and the only stack related commands I used was just JSR and RTS. But what I wrote then was basically stuff gleaned from some assembly examples in various C64 magazines and I probably only understood about half the 6502 instruction set.
  11. And it turns out you are 100% correct here. For Petaxian the output from 7.0-beta compiler runs fine in the current compiler.
  12. Nice! I guess I have to jump over to the 7 real soon. I was waiting for an official release of the new XC16 emulator, but there are so many updates now I'd like to use. I can always test using VICE for a while.
  13. I tried this screen { testlabel: %asmbinary "data.bin" ... } but get the following error : screen.p8:3:9: no viable alternative at input 'testlabel:'
  14. Ok, so I have a questions about adding larger sets of data in Prog8. Since the byte/ubyte data structures are limited to 256 bytes I have so far just split data into multiple arrays. That works well enough for now. However, let's say I want to update a full screen (40x25 for C64, more for CX16). It gets awkward to split this up into many arrays. It looks like perhaps %asminclude might be something but it's not obvious how to use this. I created a file screen.asm which contains my screen data : screen_char BYTE $20, $20, $20 .... and include this in a module screen { %asminclude "screen.asm", "screen" ... } and attempt to get hold of this label with something like uword ref = screen.screen_char without any luck (I tried various with and without various prefixes). According to the doc I should have access to the labels. I expect I'm doing something wrong but without any examples I don't know how to use this beyond this.
  15. Did a quick update of Petaxian with a workaround for the NES keyboard emulation (thanks to desertfish for pointing out that this was pretty trivial to add).
  • Create New...

Important Information

Please review our Terms of Use