Jump to content

borgar

Members
  • Posts

    42
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by borgar

  1. Keyboard isn't as good as a controller that is true. And I may have played the game a few times more than you for some reason . And well spotted, it's a D&D sheet. Though this was printed for my son and not myself. I haven't been able to inspire my son to take up computers and programming, but I did manage get him into D&D.
  2. I've had my old C64, 1741 floppydrive and an old Samsung "portable" TV in the attick so to speak for, well something like 30 to 35 years. During the the Corona period I dragged this out and tested and unfortunately my C64 didn't work anymore. Got the Light Blue/Blue screen without any text so I guess it could one of the ROMs that are bad. However, I did get hold of another C64 a few years ago that I hadn't tested yet. I found out the old power supplies where untrustworthy so I didn't want to risk anything and it took me a while to get around to order a new. Well, now I have new powerbrick (ordered from here : https://www.c64psu.com/c64psu/43-1488-commodore-64-c64-psu-power-supply.html) and the other C64 works without any trouble so far. Even the 1741 workes fine. At least 4 of the 5 old floppies (with hrm, "backups") works. I still didn't have any way to get the game over to the C64 but after looking a bit only I ended up with a TapeCartSD solution (cheap, easy to use for non-disk images like prg files). So today I tested Petaxian on real hardware for the first time. I may have to make the game a bit harder since I beat this on first try even with the terrible joystic (none of the decent joystic I bought back then lasted very long as far as I remember). The screen quality of the TV wasn't great when it was new, and has probably not gotten any better in the last 35 years and the antenna output is pretty bad as well. I actually tested with a monitor I have that takes just about anything as input (including from antenna) and the picture quality was actually worse than the one in the CRT. I'll just have to order C64 to SCART plug. Those are pretty cheap.
  3. It's so nice to see so much regular progress for Prog8. BTW, I first encountered a language with "piping" syntax during my university days. That was in the BETA programming language (https://en.wikipedia.org/wiki/BETA_(programming_language)). There is looked like this (* x = 1 *) 1 -> x ; (* x = f(1) *) 1 -> f -> x ; (* res = fibonacci(1,5) *) (1,5) -> fibonacci -> res; Multiple parameters was supported and "safe" so that (x, y) -> (y, x) did a "swap". This syntax is a lot easier read for long functions chains but I have to admit that I never got 100% comfortable with this syntax style. I guess the traditional Algol syntax was already firmly embedded in my skull by the time I encountered BETA.
  4. I started out using Emacs in plain text mode which worked well enough for me. Though I have mainly switched to Visual Studio Code with Adam Kubiczek's syntax highlighting (https://github.com/akubiczek/Prog8-TmLanguage-VsCode) now. Generally, I prefer fairly basic editors over IDE's and it turns out VSC does the lightweight IDE well.
  5. Sure. I use this on WIndows 7 (old stationary pc) and Windows 10 (laptop). Never had any problems getting this to work. BTW, I have just set up a few small bat scripts to compile and/or run stuff. This on I use just to build the Petaxian code, I have variants that can take program name as argument, build for C64 instead for XC16 etc. SET PATH=%PATH%;.. SET jar=..\prog8compiler-7.5-all.jar IF %computername%==BIFROST ( SET javap="C:\Program Files\OpenJDK\jdk-11.0.9.1-hotspot\bin\java.exe" ) ELSE ( SET javap="C:\Program Files\OpenJDK\jdk-11.0.8.10-hotspot\bin\java.exe" ) %javap% -jar %jar% -srcdirs cx16 -target cx16 petaxian.p8 ..\cmdrx16v38\x16emu.exe -joy1 SNES -run -prg petaxian.prg
  6. 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.
  7. 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.
  8. 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.
  9. 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
  10. Yes indeed. I have tested this and had no problems importing and drawing a screen from binary input. Many thanks.
  11. 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
  12. 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 ^
  13. 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.
  14. 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).
  15. 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.
  16. And it turns out you are 100% correct here. For Petaxian the output from 7.0-beta compiler runs fine in the current compiler.
  17. 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.
  18. I tried this screen { testlabel: %asmbinary "data.bin" ... } but get the following error : screen.p8:3:9: no viable alternative at input 'testlabel:'
  19. 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.
  20. 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).
  21. I've uploaded a new version of Petaxian. Lots of updates since the first version More variations of enemies and movement patterns Simple sound effects Actual "score" counting Joystick control (though the NES keyboard stuff is causing some issues) And lots of various smaller adjustments and optimization of code etc. etc. Just be warned that the NES keyboard emulation seem start up with joystick byte 1 set to 0 (= all buttons pressed) instead of 255. That causes the game to autostart the first time. I could work around this using a non-NES keyboard key to start the game, but since I added joystick support that seems inappropriate. Everything works fine if the game is started with -joy SNES (or NES).
  22. Since I've been doing a bit more programming for my game I thought I should give a bit more feedback about Prog8. I've naturally come across a few things here and there that ideally would be "fixed", but generally I find Prog8 to be a nice and simple language to work in. Since we are working closer to "the metal" than I normally do I think the simple types and limited syntax makes perfect sense. I especially like how easy it's to integrate in assembly functions with the Prog8 code. Apart from the odd actual bug I think this is where I would really like to see a bit of improvement. I've already mentioned the issue with variables only used in assembly being optimized away. I'd prefer to have these in the Prog8 part of the code for a few reasons. One is visibility, perhaps the variable is later needed in the Prog8 code. The other is that we don't really know where we can put this in standalone assembly since Prog8 program might put it's own variable in the same "space" (at least when using ZP variables). I've been using the workaround (having dummy assignments in other code) but think it would be more elegant to have a way to mark a variable as "used in assembly" so it's not optimized away. I was also going to add a ticket about constants being removed in assembly output as well, but found that someone already have covered this (https://github.com/irmen/prog8/issues/22). I'd just like to add that I also think this would be nice. I have found debugging a bit more of a hassle than in my "day work", but that has more to do with the emulator and the nature of the platform. Though when I struggled at worst (and finally did have a look at this using the debug option in the emulator) it turned out to be a emulator bug, at least that is what I believe (Keyboard NES controller emulation kicks off with all bits reversed).
  23. Ah, I'm looking forward to testing the new rnd function. I have noticed that I seemed to get noticable clustering patterns. I'll probably wait a new build of the emulator.
  24. That's basically because I don't really know how to use the assembler (at least not yet), so I just went for the default program declaration the feels natural to me. It's at least 30 years ago since I last touched assembly language (and that was on M68000 systems). So I'm more or less starting over from scratch and haven't really gotten to the the more assembler manual yet. I have started reading up on the 6802 instruction set though. Not too hard to get a basic grasp of that given the small instruction set.
×
×
  • Create New...

Important Information

Please review our Terms of Use