Jump to content

desertfish

Members
  • Posts

    554
  • Joined

  • Last visited

  • Days Won

    14

Everything posted by desertfish

  1. "but you will need C64/C128 with a SuperCPU v2 and 16MB RAM" <- from that wolf3d page.. that's not really a c64 as I remember it
  2. Nah, I'm not going to recreate Elite, the game. That would be way too much work. The 3d code is not a full 3d engine but just capable of showing one spinning object in the center of the screen I'm not going to expand that. I do want to add hidden line removal to it though and the other dozen or so ship models. As a separate project maybe to compile or convert that text-mode Elite trading program. That should be doable and will result in a fun little space trading game program (without fancy graphics though)
  3. Hm, interesting, didn't realize that the IRQ vector might be the same as on the C64. Thanks.
  4. Yay, the exported ship data works in the Commander X16 version! Attempt for the next version to implement hidden line removal in this version too.
  5. Good stuff, @geek504 . I don't have an answer to your question and am struggling with a similar idea myself as you can read on the description of my own demo program https://www.commanderx16.com/forum/index.php?/files/file/71-3d-wire-frame-spinning-cube/ I was wondering if there is a way to wait for Vertical Blank. (won't help much to reduce flicker still I am afraid because I don't think the program will be fast enough to redraw everything within one frame, but hey)
  6. @geek504 cool I made that as well, am currently busy implementing the Elite game's ship models into it How did you make your version of this? In basic or C or something else?
  7. wow I didn't know you actually started making an IDE for it (or did I forget???? ) ! Fantastic!
  8. @sebassco sure, I announced it in the X16 General Chat subforum, there should be the links you asked for ! Here it is:
  9. I agree to try some BASIC first to get a hang of the machine. You'll need some commands anyway to operate it regardless -- as Ender pointed out above. That said, the C64 basic isn't a very good basic. Even the PET that came before it had a better basic... and I remember being extremely jealous about the basic on the BBC Acorn Electron that my friend had in school, it was way more advanced. I think I wouldn't stick to basic beyond the basics (pun intended) and switch to something else once you mastered it a little. Personally I made the jump to assembly code back in the days. But there are a lot more choices available today... My own interests nowadays lie with cross-compilation that allows you to develop comfy on the PC and just run the compiled output on the target machine. This is what CC65 does and also my own Prog8 language and some others too. ( Obviously I'm using Prog8 myself but its kinda experimental and very very new on the CommanderX16 but I think I'm making good progress )
  10. The C-64 allowed this by hooking into the CHRGET parse routine which was sitting in zeropage RAM so you can modify it to call into your own code to add commands. Most well known are the "DOS-wedge" extensions such as DOS"$ that displays the disk contents without destroying the current program as LOAD"$",8 would do. I don't know if the basic implementation in CommanderX16's ROM has a similar wedge option?
  11. Actually, you don't need a MMU, if you are okay with a system that doesn't have memory protection. (Wich is a weird thing to expect from a 8 bit system anyway..) I believe the only thing that you have to do is: save cpu state including status flags on a context switch give each thread access to their own hardware cpu stack. The second point means that you have to write stack swapping code on a plain 65(c)02 because it has its stack fixed at $0100 in memory at all times. I believe the Commodore-128 had a tiny MMU that allowed to remap the zeropage and stack to another page in memory, but I am not sure about this. Here is a multitasking unix-like operating system for the Commodore-64 that uses multiple threads and stack swap trickery: http://www.6502.org/users/andre/osa/index.html It's quite unbelievable to see it in action to be honest https://youtu.be/jtlAOdJmeDI
  12. Ok you put me on a mission I now have to at least put all Elite's ship models into that program https://www.c64-wiki.com/wiki/Elite#Spaceship_types And we also have text mode Elite http://www.elitehomepage.org/text/index.htm So who knows edit: Right, that same site hosts various 3d model source files of the Elite shipts. I cobbled up a quick model viewer in Python.... Going to use that to convert the data into binary arrays that I can read into my 6502 program !
  13. 3d wire frame animated spaceship View File 3d animated Cobra MK3 ship from Elite! Uses 16 bits integer math and has hidden-line removal.. This is an almost 1-to-1 conversion of the same program I wrote for the C64, but it runs a lot faster on the CommanderX16 Here is the (prog8) source code https://github.com/irmen/prog8/blob/master/examples/cx16/cobramk3-gfx.p8 I haven't figured out how to wait for the Vertical blank yet, to reduce the flickering perhaps... Submitter desertfish Submitted 09/07/20 Category Demos  
  14. Version 1.0.0

    120 downloads

    3d animated Cobra MK3 ship from Elite! Uses 16 bits integer math and has hidden-line removal.. This is an almost 1-to-1 conversion of the same program I wrote for the C64, but it runs a lot faster on the CommanderX16 Here is the (prog8) source code https://github.com/irmen/prog8/blob/master/examples/cx16/cobramk3-gfx.p8 I haven't figured out how to wait for the Vertical blank yet, to reduce the flickering perhaps...
  15. never heard of the c256 foenix! interesting!
  16. I'm trying to reset the machine from software, by using JMP ($FFFC) -- FFFC is the 65c02's software reset vector is it not? (The vector points to $DE86- I've also tried a basic program with sys $de86 ) However, this is not really succesful. Best result that I get is that the program simply returns to the basic ready prompt. Worst result is that the emulator crashes and dumps core. Any insights on this?
  17. I programmed in LOGO on the C64 is was pretty enjoyable! (it wasn't only turtle graphics but also string manipulation and pattern matching if I recall correctly)! HOWTO Square; repeat 4 ; fd 100 rt 90 ; end Or something
  18. @geek504 I used the Antlr parser generator library as-is (Kotlin/JVM integrates seamlessly with Java). I did wrap the generated AST classes in easier to use Kotlin versions though. @SerErris yes Prog8 is compiled into assembly code. The cx16 compiler target shares most of its code with the C64 target so no, most of the time the new 65c02 opcodes are not yet used. I have been using STZ and PHX/PLX a bit here and there in certain library routines but that's about it. thanks for your questions!
  19. @geek504 Hi glad you asked, lets answer this here I started working on it about three years ago. I wanted to learn how to create a programming language, a parser, and a compiler (I have written several interpreters over the years but never an actual compiler) . I started implementing it in Python but as the project grew larger, switched to Kotlin as an implementation language because it became too unwieldy to constantly refactor it in Python even with IDE support. Because I like retro computing and the Commodore-64 in particular, I thought it would be fun to try to target that platform to be able to write programs for it in a medium/high level language. With the possibility to directly access the hardware and use inline assembler code when needed for the nitty gritty stuff. Only recently I started adding CommanderX16 support into the compiler. Prog8 the language itself is essentially a C like langue but with heavy Python influences because I really like Python. It would be cool if people would use Prog8 for larger projects, but other than the few dozen example programs I've not actually written a large piece of software in Prog8 yet Mostly because I'm still too busy tinkering with the compiler itself and fixing bugs, and now, CommanderX16 support for it.
  20. Version 4.1 was just released with many improvements in the CommanderX16 support. Most importantly is that floating point operations are now working. (and a few example programs are now included that use this)
  21. @geek504 Discussing Prog8 is probably best done in the topic I made in the "X16 General Chat" subforum? Can you perhaps ask your question again there? Also the C64 (and CX16's) math functions operate on 5-byte floats i.e. 40 bits. Internally they work with 6 bytes I think for intermediate rounding precision, but the float values stored in memory occupy 5 bytes. Of course all floating point operations are implemented in software in the ROM
  22. Btw: I can't get the fractal256.bas to work (garbled screen) and fastfract256 doesn't work either (seems to be missing part of the code at the end). I'm looking in the x16-demo git repository. So I used part of their source to create my own basic version of the mandelbrot program. Turns out the prog8 compiled one is significantly faster (4x) even though it is using the same ROM routines as Basic does for the actual floating point calculations. It took slightly more than 11 minutes to finish the task (256 * 200 * 16 image) whereas the basic one took 45 minutes for the identical picture.
  23. @Bones it's copied from the editor window from IntelliJ IDEA where I configured the major syntax highlighting rules for my language syntax. Which is incredibly easy to do in IDEA. To be honest, it was quite unexpected that pasting the source in here retained the coloring! (it's not a screenshot- it's the actual source code pasted as text) @Johan Kårlin Thank you so much for the kind words it means a lot to me. Yeah it has been a long time coming and there's still much work left to do on the code generation part (projects are never "finished" are they? haha) but I'm really happy today already with where the language and its compiler are.
×
×
  • Create New...

Important Information

Please review our Terms of Use