Jump to content

AndyMt

Members
  • Posts

    208
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by AndyMt

  1. For sure this is possible, but - it takes away time from my budget to actually develop something. I would certainly only develop for one of the 2 platforms and not go into the hassle to do ports. I'd probably also wait until there is a clear indication of which platform "wins". Maybe I'll then not develop for any of the 2 at all because my focus moved somewhere else. I fully agree. Let's assume the X8 gets the same VERA interface as the X16 and is tuned down to 8MHz. I'd probably just develop to the minimum specs. For the 2 games I've released so far I pushed the X16 as far as I could. I've used almost all the VRAM (256 color bitmap graphics, lots of 256 color sprites) and also plenty of banked RAM (for music and sound). My platform jump & run game in the works goes even further: sound track running in parallel, 256 color palette switching to show up to 512 colors at once, partial palette shifting to achieve "water flow" effects etc. I'm not sure what I'll do with it now - probably just wait and see what happens. Here I also agree. If the VERA interface is different, then the software will be incompatible. Or the effort to make it compatible will take away performance, which could be too much.
  2. I thought about the whole situation for a bit more. I still think it's best to release the Phase 1 X16 first. About the next steps I'm not so sure any more... Yes - this! Regarding the X8: If it as the same VERA interface, then I will support it. Ok - I would have to throw away all the bespoke sound tracks for the YM 2151 I have sourced. But because of the limited RAM those would not be usable anyway, so my games then will be without any sound. Also graphics would have to be tuned down, and I personally won't make use of the double VRAM on the X16 in the future. But I won't go into the hassle of supporting 2 different VERA interfaces. If I would, then there were different ways of addressing this, which I don't like: Use wrapper functions: impacts performance. Use conditional compilation (cc65) / macros (assembler): harder to maintain, makes code less readable, no impact on performance Maintain different/mixed code bases: even harder to maintain, but also no impact on performance. Yes all of the 3 options would work and also the additional effort is maybe not that big - but it is there and would take away time from the actual fun development. If it is possible: integrate a YM2151 in fpga. So we would be able to use existing music trackers like Deflemask etc. Otherwise it will be hard to create high quality sound tracks. All the instruments and samples need to be recreated, for the YM everything exists. So: please if you release the X8, then make it's VERA interface identical to the X16. And tune down the CPU speed to 8MHz. It would be so hard to explain why the little brother of the X16 is 50% faster. If possible integrate a YM2151 FPGA implementation.
  3. For me this project alway was about the full retro experience with a modern twist. I want to understand how it works by just looking at the board. I'd order a kit version any time. Also offer it pre-assembled for those who don't want or can assemble it themselves. As for the case: just point to places where we can get them on our own. I will 3d print my own wedge style case anyway. Skip phase 2. I don't think its needed. Then the X8. While it has its appeal, I would not release it. Maybe I would support it, if it had the same interface to VERA. I then could just trim down the programs and games I did for the X16. But different access to Vera would probably drive me away from both. And here is the next problem: few software would use the full potential of the X16. You would end up with mostly X8 only software.
  4. Every tile set can have 2,4,16 or 256 colors - and you can have 2 different tile sets, each of them on it's own layer. So this should be easy to achieve. I did use this for my Brixx game where the bricks etc are a 16 color tile set on layer 0 and the text for highscore etc is the standard character set on layer 1.
  5. When I look at the latest board just posted a few hours ago: We can find a socket labeled "YM2151" at the bottom right. So I'm pretty sure the YM2151 will be in the final design - as is the VERA PSG/PCM. Personally I'm pretty pleased with that .
  6. Because that's version R38. If you want to develop for the upcoming R39, then you need to compile it yourself (or get it from someone else).
  7. I understood that there is no 3d calculations involved. But for Wipeout those might not be needed if we accept some limitations. The course would be pre-calculated (as is the demo) and the perspective would be fixed to a virtual observer following the player in the middle of the course. Tricky would be rendering the player and opponent pods... maybe Spites (ugly)? Or pre-calculated polygons for each object for let's say 10 different distances (more cpu cycles)?
  8. I'm really impressed by this, just wow ! A Wipeout style game could be in reach with the cx16. That's so impressive.
  9. ATARI 520 ST, back in the days around 1987: Piggybacking RAM chips on the existing ones to upgrade vom 512kB to 1024kB RAM. It was quite thrilling soldering all those chips and adding those wires to the MMU ... And it worked !
  10. 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.
  11. Just press the "Try it now" button on the download page of the program . This will run it in the web based emulator in your browser.
  12. 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.
  13. Yes, that's something I was looking at, too. And in the comments there were some references to the X16, so who knows...
  14. 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.
  15. I had the same question here: I settled into detecting which ROM version is present, here are the details:
  16. 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.
  17. 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.
  18. I've updated my Repo so now waitvsync() uses RDTIM instead of the TIMER memory address. This makes it compatible with more ROM versions, but also a bit slower. I'll change this back as soon as the TIMER address has settled. My cc65 repository: https://github.com/AndyMt/cc65
  19. Do you happen to have a Windows build of the latest r39? I could not get this to compile, I have neither Mac nor Linux machine.
  20. Thanks - maybe I should use the Kernal function to get the timer value for the moment. Even though that's less efficient.
  21. 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.
  22. I branched the cc65 repo and started changing the cx16 lib. It now works with Invaderz and Brixx and both would now run on R39. In case anyone wants to check it out: https://github.com/AndyMt/cc65 I'll do some more testing myself before creating a pull request.
  23. 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
  24. Added a Kernal/ROM version check. Will only run on R38, as well as on custom ROMs on your own risk. This is in preparation for the upcoming R39 on which the current game won't work.
×
×
  • Create New...

Important Information

Please review our Terms of Use