Jump to content

LRFLEW

Members
  • Posts

    9
  • Joined

  • Last visited

  • Days Won

    1

LRFLEW last won the day on May 19

LRFLEW had the most liked content!

Recent Profile Visitors

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

LRFLEW's Achievements

Newbie

Newbie (1/14)

  • Week One Done
  • One Month Later

Recent Badges

14

Reputation

  1. I'm a little late to the party, but I figured I might as well yell my thoughts into this void. I have no problems with you dropping the case, especially if it's going to be a big issue. If things change in the future, I may be interested in buying the case separately if it is something where the finance issues can be resolved post-launch. As it is, however, not having a case isn't going to deter me from buying the product. If you are going to half to hand-soldered the phase-1 boards, I'll probably buy the kit for myself. I don't really want to force someone else to spend that much time on just my board, and I'm willing to take the time to do it myself. (It's been a while since I tried soldering, but I think I should be able to handle it). Between phase-2 and phase-3, the only real advantage I ever saw with phase-2 was the one expansion slot, and I just don't foresee the expansion slot being all that big of a feature. I don't see ready-made boards or kits for X16 expansion cards being something that gets made, and the tinkerers who would want to mess with it would probably go for the phase-1 board anyways. With this in mind, I would say skipping phase-2 probably makes the most sense, but I could be wrong about how people feel about the expansion slots. The X8 seems... interesting. Looking over it's features and limitations, a few things stand out to me. The 256-byte window into VRAM is neat, but poses some real cross-compatibility issues. It also says that it has "all of the same [VERA] registers", so I'd hope this includes the original VERA's data ports for X8/X16 compatibility. The use of USB for keyboards and controllers is actually something I sort of want to see on the X16. As someone that doesn't have any old PS2 keyboards anymore, I'm gonna have to rely on the one supplied with the phase-1 release, and as someone who never owned a SNES, nevertheless a controller for it, I'll have to go out of my way to get one to use with the X16. Using my existing USB keyboard and controller seems like it would be a simpler solution, honestly. Also, the bump from 8MHz to 12MHz seems... odd, and I would at least consider making it togglable back to 8MHz through a memory register for better X16 compatibility. Otherwise, it kind of seems like the X8 is both a better and worse machine than the X16, which just seems odd to me. I don't really care too much about the Yamaha chip being dropped. In fact, I kind of think it's something that should have maybe been dropped when the PSG was moved to the VERA. The VERA already provides more channels that I think I'd know what to do with, and I suspect the Yamaha might be underutilized on the X16, especially if the X8 does get released. The RAM and VRAM shrinkage does stand out to me as being potentially problematic. The 64K RAM is probably fine. Nothing I've worked on so far required using the banked RAM, but that's also because most of what I've done has been pretty small-scale data and code wise. It's something I could see being limiting for larger projects, such as games or "productive" projects like text editors, music trackers, or assemblers. The 64K of VRAM does seem somewhat problematic for me at least. Of the two projects I've shared here, only one would fit as it works now. Noise X16 would work as-is, as it only requires 37.5K to store the video buffer (320x240@4bpp). If I wanted to use double-buffering for vsync, it wouldn't work on the X8, but I decided when releasing it that it wasn't worth implementing vsync for it. AES X16 wouldn't work as-is because it requires 75K of VRAM for the video buffer (320x240@8bpp). The only real solution for this is to drop the vertical resolution to 200 to reduce the buffer to 62.5K, but the non-integer scaling just doesn't look very nice. I think I get why the memory is shrunk. I assume that the X8's combined RAM and VRAM is only 128K for the same reason that the VERA's VRAM is only 128K. I assume there just isn't any cost-efficient way of getting more memory onto it, so I get the limitation. I just don't know how much it will restrict developers. I'm not entirely sure about releasing the X8. I do think it will likely end up similarly to the C64/C128 situation, with a lot of software targeting the lower tier, but I worry it could be more complicated than that. I'd worry it might dilute not the image of the X16 so much as dilute the specificity of the X16. To me, as someone who is too young to have really enjoyed retro computers in their prime, the X16 represents a modern-retro computer with an active community that will let me get as close to the experience I missed out on. Releasing a somewhat incompatible version along side the X16 will make the community less centralized, and would make it harder for me to get the experience I want out of buying the computer. It's certainly not a given, and I wouldn't say that you releasing the X8 would scare me away from buying the X16, but it's something I'd be concerned about if it does release.
  2. AES X16 View File I was curious how well the 65C02 could handle modern encryption, so I wrote this program to test it. The program loads the 8bpp image from the old Mode7 demo and repeatedly encrypts then decrypts the bitmap data in VRAM using AES encryption. This provides a nice visual as to how quickly it's able to process the data. The download includes PRG files for 128, 192, and 256 bit key AES, with the Try It Now button using the 128 bit key version. To run it locally, make sure that the two .BIN files are available to the emulator in "drive 8" (either copied to the working directory, which is usually the folder with the emulator executable, or in the disk image used with the -sdcard option). The image was taken from the Commander X16 Mode7 Demo. Copyright David "The 8-Bit Guy" Murray and/or Michael "mist64" Steil. The implementation of AES is based on byte-oriented-aes ( https://code.google.com/archive/p/byte-oriented-aes/ ) by Karl Malbrain. Released into the public domain by the author. The source code is available on Github: https://github.com/LRFLEW/AES-X16 Submitter LRFLEW Submitted 05/18/21 Category Demos  
  3. LRFLEW

    AES X16

    Version v1.0

    18 downloads

    I was curious how well the 65C02 could handle modern encryption, so I wrote this program to test it. The program loads the 8bpp image from the old Mode7 demo and repeatedly encrypts then decrypts the bitmap data in VRAM using AES encryption. This provides a nice visual as to how quickly it's able to process the data. The download includes PRG files for 128, 192, and 256 bit key AES, with the Try It Now button using the 128 bit key version. To run it locally, make sure that the two .BIN files are available to the emulator in "drive 8" (either copied to the working directory, which is usually the folder with the emulator executable, or in the disk image used with the -sdcard option). The image was taken from the Commander X16 Mode7 Demo. Copyright David "The 8-Bit Guy" Murray and/or Michael "mist64" Steil. The implementation of AES is based on byte-oriented-aes ( https://code.google.com/archive/p/byte-oriented-aes/ ) by Karl Malbrain. Released into the public domain by the author. The source code is available on Github: https://github.com/LRFLEW/AES-X16
  4. 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.
  5. LRFLEW

    Noise X16

    Version v1.1

    15 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
  6. 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  
  7. 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
  8. 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