Jump to content

AndyMt

Members
  • Content Count

    174
  • Joined

  • Last visited

  • Days Won

    7

Posts posted by AndyMt


  1. 1 hour ago, ZeroByte said:

    the nice thing is I no longer need to keep track of which objects use which sprite slots, so it's faster and easier to add/remove things as I see fit in my main game code.

    This sounds familiar 🙂 . I do something similar in Brixx and Invaderz for the laser sprites and explosions. The main player sprite and some others use fixed slots, though.

    I'm very much looking forward to the end result.


  2. 20 hours ago, EMwhite said:

    For AndyMt: any thoughts around putting a .lib together containing higher level functions for reuse?

    I'm seriously considering planning this! Right now both my games use slightly different variants of a lib for sprite handling and music - due to "historical reasons" and lessons learned. I want to migrate both to the same code base. Then I think it would be time to release it to the public.

    • Like 3

  3. Thank you very much! I'm thrilled to see my games made it into the top spots 🙂. I took inspiration from "Chase Vault" when I started this, so thank you very much that you shared the code on GitHub. I'm still too embarrassed on my code quality, but I promise to share my repos when I've finally managed to clean up the mess.

    Both games were written mostly in C, but some parts in assembler, like the IRQ based soundfx and music player. To my surprise sprite/collision handling, controller and gameplay coding is possible in C, even though CC65 doesn't really optimize. Of course as you mentioned, it is important to be aware what the compiler will do with the code. So in my brain there is a "compiler" running in parallel while coding, to avoid performance issues. I'm sure on a C64 with it's 1MHz CPU this would have been impossible.

    • Like 1

  4. 1 minute ago, pzembrod said:

    is there any pragmatic way how a program could easily tell whether it is running on proto#1 or proto#2, i.e. where the bank switching ports live, whether at 0000/0001 or 9f60/9f61?

    I had the same question here:

    I settled into detecting which ROM version is present, here are the details:

     

    • Like 1

  5. 38 minutes ago, ChrisL said:

    The cc65 joystick driver may need updates as well; it assumes 2 joysticks where there can now be up to 4 SNES controllers. 

    Almost certainly, as the controllers were moved from VIA#2 to VIA#1. I haven't looked into this at all as I don't have a game controller to test this with. Keyboard emulation works in the emu, though, I don't know how that's done.


  6. During the last few days I've spent a lot of time debugging my software in the emulator, running from an SD card (VHD file). This is because some things in the emulator behave differently when loading stuff from SD card instead of the host file system.

    Anyway: in Windows I found it quite fiddly to update the SD card VHD file for every debug cycle, so I came up with a solution to do speed things up.
    After a cc65 build I now only have to run a single cmd file which even puts the LOAD"MYPROGRAM.PRG" and "RUN" into the clipboard. 
    Now I just have to press CTRL+V and the PRG is loaded and started.

    Prerequisites:

    • VHD Attach tool (OSFMount wasn't flexible enough for this, but maybe someone else figures it out)
    • an SD card VHD image (this is the one from the X16 github repo)
    • X16-emulator install directory is added to the system PATH environment variable
    • VHD Attach install directory is added to the system PATH environment variable
    • compiled PRG and BIN files of your software are to be found in the "out" subdirectory

    Preparations:

    • attach (aka mount) the vhd file once by right clicking and selecting "attach"
    • note the drive letter which is assigned (in my case X:, it will stay the same)
    • put a first set of your files into the VHD
    • detach the VHD file (right click)

    Now create a batch or cmd file which does the following:

    • attach the VHD file
    • wait 2 seconds 
    • copy PRG and BIN files to the assigned drive letter 
    • wait 2 seconds
    • detach the VHD file (so the emulator can use it)
    • put the load command into the clipboard
    • run emulator

    Here is a sample .cmd file I've used:

    VhdAttach.exe /attach test.vhd
    ping 127.0.0.1 -n 2 > nul
    copy out\*.PRG X:\
    copy out\*.BIN X:\
    VhdAttach.exe /detach test.vhd
    ping 127.0.0.1 -n 2 > nul
    (echo LOAD"INVADERZ.PRG",8 && echo RUN) | clip
    x16emu.exe -sdcard test.vhd -scale 2 -keymap de-ch 

    Replace "test.vhd" with the filename of your VHD file, the PRG name with yours and also select the correct keymap parameter (or remove it).

    This saved me a lot of time, maybe it helps others, too.

    • Like 3

  7. The PRG format is just about loading a program into memory. Loading other things into VERA memory or banked RAM is independent of how the program got into memory. This happens by using the KERNALs API and for example loading BIN files into any memory type.

    A PRG can optionally contain a small amount of graphics data which then has to be copied into VERA by the program itself.


  8. I've now created a test version running on R39 and maybe (?) on real proto #2 hardware. I won't put this in the download section, but if anyone wants to try, I attach the file here. Not sure if this works on a SD card, I just load from device 8.

    @Michael Steil: I understand you have one of the few existing boards. So just in case you find the time, maybe you can test the attached file 🙂?

     

    INVADERZ R39.ZIP

    • Like 1

  9. On 3/30/2021 at 2:04 PM, AndyMt said:

    And maybe the releases happen before I have updated my stuff anyway 😉.

    Turns out I have to wait for an updated version of cc65 and it's cx16 libs. I tried hard to compile it myself and then fix the .inc and .h files - but failed. Anyone working on this? I can support by updating all the VERA and VIA addresses etc. in the asminc and include files.


  10. 3 minutes ago, Michael Steil said:

    In order to detect Proto #1 vs. Proto #2, check for abs(version) >= 39. This will work for all released emulator + ROM versions. I'm aware that this check won't work for non-official builds.

    Super, thanks! It's anyway just needed for a few weeks until the official release and the web-emulator are updated. So I will just assume a custom ROM is indicating the latest ROM and board revision.

    And maybe the releases happen before I have updated my stuff anyway 😉.


  11. Ok, if I see this correctly, right now in the emulator looking at $FF80 shows -38, which means ROM version equals emulator version? Using the one posted further up (upcoming R39?) gets me $FF, so it's a custom ROM, but presumably will be -39 once the emulator and ROM is released?

    It occurs to me, that what I actually need is to detect the board revision - so I know which RAM banking address to use and all the other hardware memory mappings.

    • Like 1

  12. I'm in the process of updating Brixx and Invaderz to the new emulator and ROM. I want them to be compatible with R38 and R39 - but how can I detect which version the PRG is running?

    I know I can detect if I'm running in the emulator:
        read $9FBE/$9FBF, must read 0x31 and 0x36

    This doesn't seem to be the version, just an indicator that the software is running on the emulator. Is there an official way to detect ROM/emulator version? I found different solutions, but none seemed officially supportet. Like reading $FF80 or $FFFA etc.

    What's the best approach there?

    • Like 1

  13. 13 minutes ago, ZeroByte said:

    since my effect is to make the screen fade to a solid color (fade to black, fade to white, fade to red, etc).

    I do this in "Invaderz" and "Brixx" by changing the palette. Of course this changes the entire screen, on all layers, including sprites.


  14. I'm actually not sure, I chose 3 

    5 minutes ago, Ed Minchau said:

    I was using a logical file number of 1 for SLFS.  So 3 sends it to banked RAM? 

    As Matt already wrote: the LFN doesn't matter. The load address does. But "save" is not possible with the host file system and with the SD card neither does in the emulator.

    Oh - and the files you load need to have the 2 byte header with the target address in, or just 0x0000.

×
×
  • Create New...

Important Information

Please review our Terms of Use