Jump to content

desertfish

Members
  • Posts

    649
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by desertfish

  1. Hi, for full-screen scrolling (in text mode) I'm implementing 4 routines in assembler. They're meant to scroll the whole text screen 1 position up, down, left or right. For the C-64 this is fairly straightforward because the character screen matrix is simply avaiable as a block of memory that you can manipulate directly. But with the VERA this is not the case. What would be the way to do it on the VERA? Is this best done via an intermediate line buffer of some sorts? For scrolling the screen up 1 line for instance, I think I will do something like this: lda #%00010000 sta cx16.VERA_ADDR_H ; enable auto increment by 1, bank 0. lda #1 sta cx16.VERA_ADDR_M ; start at (0, 1) - jsr _copy_line_to_buffer ; now copy the linebuffer back to the line above this one dec cx16.VERA_ADDR_M jsr _copy_buffer_to_line ; next line to copy inc cx16.VERA_ADDR_M inc cx16.VERA_ADDR_M dec NUM_LINES_TO_SCROLL bne - That buffer is required because those copy subroutines make use of the VERA auto increment to first copy one single line of text into the buffer, and the second one copies the line of text in the buffer back to the VERA using the autoincrement. Is this reasonable or is there a more optimal way to do it? I feel I am perhaps too focused on using that autoincrement mode
  2. Interesting, I wonder what the C64 did if you banked out the kernal rom and then caused a hardware reset. I vaguely remember resetting the machine not always working (unless using something like the reset button on a final cartridge) so it could very well be that it didn't bank the roms in before calling the reset vector then..... Anyway I'm using this now to software-reset the Cx16 and it works: sei ; stz cx16.d1prb ; jmp ($fffc)
  3. There have been some mod players for the C64 even (requiring a Ram expander to hold the mod file) the sound quality is abysmal ofcourse compared to the Amiga but it sortof kinda works. So I imagine it's totally doable on the commander x16 https://www.youtube.com/watch?v=D3HPX6FpysY
  4. @SerErris WOW thanks for this info I had not discovered the annotated source code yet, incredible
  5. New version available, here we go, hidden line removal based on that simple surface normal discussed above: Adding more ships to the program and making a slide show of them is currently not possible due to programming language limitations of Prog8, unfortunately (everything has to be statically allocated)
  6. For instance I've uploaded multiple iterations of the program with the same filename and the Try it now no longer works. It used to work fine when there was just the first version.
  7. I am silly. That reference you both mention is also what I initially used to create my clobber-list. So I think you can safely ignore my derived specification file
  8. Yeah the surface normal method is what I experimented with in my Python prototype shown above. It works fairly well and is quite cheap to do however it's not entirely accurate in the simplified version that I came up with. I only check of the Z component is negative or positive and it works "most of the time" but fails for some polygons that are perspective projected. I think it's acceptable though at least for a first solution! As I'm only drawing lines not full surfaces the painter algorithm (back-to-front drawing) can't be used I think.
  9. that video card of his is truly one of the highlights of his channel in my opinion The whole series about the 6502 computer on a breadboard is very cool too but I was really amazed by the video card ones
  10. I've kinda figured that out and wrote it down in the kernel subroutines definition list for prog8 (because the compiler needs that information). You can find it here https://github.com/irmen/prog8/blob/master/compiler/res/prog8lib/cx16lib.p8#L19 Look for the "clobbers" clause, if it's there it tells you what registers get clobbered. Maybe this is of some help to you (It's only correct for the "default" kernel routines that are compatible with the C64, I haven't yet made proper clobber lists in this file for the new Cx16 kernel calls)
  11. Slight update, I'm slowly working towards adding that hidden line removal. The actual math required isn't in there yet but I think I have the ship model data complete for it. Also I've looked at the source code of the text-Elite and it seems a lot more work to convert it to Prog8 than I anticipated. It is still something I would like to complete though, if only to validate the practical applicability of the language.
  12. I just released a new version (4.2) that contains a lot of bug fixes. Most if not all issues I've ran into while attempting to compile for the Cx16 have been solved in this version . I've updated the initial post. Download links can still be found there.
  13. Were you on a business trip or something if I may ask. I live 'near' Rotterdam but am working during the week.
  14. Oh, I assumed it should be possible to use Windows' media codecs from .net... strange that you seem to be limited to .wav No worries
  15. Thanks for the interesting write-up. edit: hm, it's a pretty hefty download due to the uncompressed music files. Maybe an idea to use compressed versions like mp3 instead?
  16. .... did you meet anyone interesting while you were there?
  17. The program should be the same as long as you use kernel routines to print the text (CHROUT). What are you struggling with?
  18. For this program I am not using a fixed point math library perse. The math library that I use only has primitives for calculations on byte and word values. The program (written in prog8) does the actual 3d calculations taking fixed-point scaling into account. So a hand written math library with 3d routines as well is still useful as it will be quite a bit faster that my generated assembly code I can imagine.
  19. You're seeking to do overlays from a basic program? woah, not sure if that's possible at all.... It can be done by loading assembly code programs at certain locations in memory, SYS into them, and just continue trucking in your basic program... But loading alternate pieces of basic code at different locations in memory? I have no idea how to pull that off
  20. awesome, I'm only toying with the emulator for now
  21. The mod trick only works for powers of two because of how binary numbers work.
  22. @SerErris I was impressed with C64studio as well. For my own Prog8 I'm also trying to make the whole process as smooth as possible so you just point it to a source file and it will compile it to assembly, run the assembler for you with the correct options, turning it into a .prg file and then launching that in the appropriate emulator executable. It loads and autostarts the program. From source code edit to running in the emulator in about 1 or 2 seconds on my machine. Works for C64 and CommanderX16. The above is hotkeyed in my IDE too. I'm using IntelliJ IDEA. It's a really nice workflow for me because I'm still developing the compiler itself as well, in the same IDE
  23. The 65c02 cpu can't run that fast as far as I know and remember: constraints spark creativity
  24. "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
×
×
  • Create New...

Important Information

Please review our Terms of Use