Jump to content

LRFLEW

Members
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

4 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm specifically referring to the files here: https://github.com/commanderx16/x16-demo/tree/af282c208c89400b64a977de91e31ec7031b2807/assembly I was using the mode7-bitmap.bin and mode7-palette.bin files for a project, and I'm looking to upload the demo here. Everything else in the project is licensed under the BSD license (mostly 2-clause, but one source referenced was 3-clause, so I'm including both), but I can't find any license for these projects specifically. The only reference to licenses is in the CONTRIBUTING file where it states submitted demos needs LICENSE information in the source files, but there are no such comments in the mode4/mode7 assembly files. Looking at the Git history, I can see the demo was uploaded by Michael "mist64" Steil. Is there an official license the demo would have been released under? On a related tangent, I would like some advice/clarification as to who to credit for some of these things. The mode7 demo image is of "The 8-Bit Guy", so I assume he holds the copyright on the original image, but I assume "mist64" converted it to 8bpp. I was planning on naming both as the credits for the image file, but is there something different I should do? Similarly, I'm not sure how to credit this file in the ROM project. The README states that "All new code, and additions to legacy code" are copyright "mist64" and licensed as BSD 2-clause. However, walking through the Git history (including through file renames) shows that the original file is (almost) entirely submitted by Frank van den Hoef. Who is the proper person to credit in this case? I also assume it's licensed under the BSD 2-clause license due to the README, though older versions of (basically) the same file, such as this one, state it's "License: Public Domain." I would appreciate clarification on this if possible as well.
  2. If I upload multiple files as part of a "community download" submission, can I access them with LOAD commands? For example, if I upload a PROGRAM.PRG and DATA.BIN, could I load the DATA.BIN file from the PROGRAM.PRG with the LOAD kernal command? Similarly, if I upload a BASIC program, can I use LOAD "DATA.BIN",8? I was looking at the demos in the official demos repository and saw the old mode 7 demo with the partial image. I realized that the whole demo could be written in BASIC using VLOAD (or just LOAD? The documentation says it should work, but it wasn't working for me). While messing with it, I made my own variant to demo something I was considering uploading. However, it requires loading the image data from a separate file from the PRG for the same reason as the mode 7 demo was cut off before.
  3. LRFLEW

    Noise X16

    Version v1.1

    9 downloads

    This program simulates TV static using the X16's bitmap mode. This program generates a 320x240@4bpp static effect at just over 26 fps. In other words, it generates just shy of 2 million pixels per second, or uses about 4 clock cycles per pixel. You can check out the source code here: https://github.com/LRFLEW/Noise-X16
  4. Noise X16 View File This program simulates TV static using the X16's bitmap mode. This program generates a 320x240@4bpp static effect at just over 26 fps. In other words, it generates just shy of 2 million pixels per second, or uses about 4 clock cycles per pixel. You can check out the source code here: https://github.com/LRFLEW/Noise-X16 Submitter LRFLEW Submitted 04/16/21 Category Demos  
  5. That makes a lot of sense. I wouldn't suggest making all the ZP be IO, and wouldn't even suggest placing the entire 32 byte VERA IO in the ZP, as I understand how useful the ZP is. The furthest I'd consider doing is suggesting mirroring the two data ports (VERA_DATA0 and VERA_DATA1) in the ZP, but the complexity for that would be even worse, and the mirroring would be very challenging due to how unnatural it would be, so even I'm not taking that idea seriously. I had suspected the Low RAM was used when reading the banking state, in part because of how the high bits of address $0001 are undefined. That was how I got the idea that Low RAM might be used to set the address pins of High RAM/ROM. Using latches to hold the banking state makes more sense, though. I still feel that the complexity required to determine if the latches should update would be farily high (having to test 15 address lines and the write enable, plus one address line to determine which latch to change), but it works if you have a cost-effective way of doing that. The TLDR I got from your explanation about why it works for banking but not VERA IO is basically this: Adding the banking controls to the ZP here doesn't affect whether any of the other components are enabled or not, so it doesn't affect system timings. I'd assume the enable pins on the RAM and ROM (chip enable, output enable, write enable) are the biggest challenges with the system timings. Putting the VERA IO in the ZP would require disabling the Low ROM and enable VERA IO for a narrow address range, which would affect timings. Thanks for your very detailed response @Lorin Millsap
  6. I had checked out the project back in late 2019 (after the part 2 video was posted), but stopped paying attention as I got busy with real life. I recently thought about the project and decided to see how it was going. I had done some programming using the emulator back in 2019, so I checked out what changed. I saw that the memory banking changed from being in the VIA IO range to the zero page. When I saw it, I thought it was a cool change, but the more I think about it, the more confused I get. I don't have much understanding about hardware design (I'm more of a software person), and most of my understanding comes from the Ben Eater videos. What I do understand is that RAM/ROM banking requires something to hold the current banking value and set the address pins on the RAM/ROM chips high or low as needed. I understood how this worked before.; the VIA has the functionality to set and hold output values, which would be used to set the address pins. With the "Proto2" design, the goal was to free up the VIA outputs for other use, but I don't get what's replacing it for banking. Is there another IO chip being added to perform the banking? If so, why wouldn't the banking controls be put in the IO address range? It seems that checking if the address is $0000-$0001 would require a ton of logic gates to make work. My confusion is compounded by the responses to questions about putting VERA IO in the zero page. There have been discussions about it that have been dismissed without discussion (such as this thread). I feel like I get why putting VERA IO on the zero page is impractical (if not impossible), but the same reasoning I have would also apply to the banking controls. What makes banking different from the VERA interface? The only answer that makes sense to me is that writing to the banking addresses just sets the value in Low ROM, and the address pins of the RAM/ROM chips are being set by the Low RAM chip when accessing High RAM/ROM. This would also explain why it wouldn't work for VERA IO, as that technique wouldn't work there. However, I can't imagine how you'd get the Low RAM to do that without interfering with the CPU's Data Bus. I don't need or even want a massively technical answer, as I understand the design is being kept somewhat private for now, and I probably won't understand all of it anyways. I'm just wondering how this is supposed to even be reasonably possible.
×
×
  • Create New...

Important Information

Please review our Terms of Use