Jump to content

SlithyMatt

Members
  • Posts

    773
  • Joined

  • Last visited

  • Days Won

    57

SlithyMatt last won the day on October 2

SlithyMatt had the most liked content!

Recent Profile Visitors

1137 profile views

SlithyMatt's Achievements

  1. You need to load the upper/lower versions of those fonts. Sounds like you are loading an upper/graphics font. When you use CHROUT/BSOUT to change the character set, it will always load the font in ROM.
  2. Pr0n-bots are constantly scanning YT for new videos and posting links in comments. The most prevalent ones appear to be from Russia. I used to, without fail, receive two comments from the same bot within the first 15 minutes of uploading a video. They would just be URLs, and the shell user posting them would switch up. Seems like the YT spam filter AI has finally learned the pattern and it doesn't happen anymore. Just be diligent about reporting them and the AI will learn and improve. Good luck with your channel!
  3. Is this a joke? All three were mass-marketed, and had substantial budgets for prototype development and marketing from established corporations.
  4. I suppose that's OK, as long as they don't sully it by creating a Gerber file in between.
  5. Here's my latest prototype for a sound card:
  6. I refuse to use PETSCII for designing PCBs. I find BBS-style ANSI art is the only aesthetically acceptable choice, and anything else isn't TRULY retro.
  7. Well, then that would have to be something other than a PRG file. One could have a special loader program in memory that could open such a file and load its segments appropriately. But deployment of separate program and assets is just a much better way to deliver software, especially when you don't have the horsepower or RAM to load and decompress a large file. I think the common deployment strategy will be a zip file that you then decompress with a modern computer into an SD card directory, if you aren't buying a pre-loaded SD card (which I intend to produce for my games).
  8. In a nutshell, there are two ways: make a big PRG file that can be loaded into contiguous RAM and then copied out to other parts, or just have multiple PRG and BIN files and one executive PRG that does all the loading so that the user only has to load the one file, while the others sit in the same directory.
  9. It can be, and I made a video about it:
  10. I didn't realize this worked in warp mode. Good to know!
  11. Good luck with your run! It is difficult to time, especially since "Warp" mode does not give you a consistent speed, so you need to be able to just do 100% speed for the whole run. I see there are still some of the optimizations I listed above not implemented, so you may want to include them, and maybe even ditch the subroutine to clear the screen before plotting.
  12. There are some very low-hanging fruit that I haven't bothered with so far, in the interest of keeping the working, straightforward implementation of the algorithm in BASIC. I don't think any of these will have a huge impact, but they might shave off a bit of time: Line 10: Do a pair of VERA register pokes to set screen resolution to 324x240 After line 50: Set up VERA address registers manually for start of bitmap in VRAM ($4000) Then, replace lines 217-230 with a single line: POKE $9F23,I Lines 120, 130: Pre-calculate 0.000036/320 and 0.000027/240 After line 160: Calculate X*X and Y*Y Then, use pre-calculated squares for lines 170 and 180 This area of the plot is not symmetrical, so I don't think you can just do mirroring to save a big chunk of time. Anything else will take some really digging to come up with optimization. The core driver of the time is the math that just needs to happen.
  13. Also note that my assembly code will not work for this without a significant rewrite to the fixed point library. Being this zoomed in means you need much higher precision. You could probably do it with 8.24 fixed point, if you do some precalculation for the X/Y scaling (i.e. creating constants for the X range divided by 320 and the Y range divided by 240), and then I don't think you will need to deal with any numbers larger than 127, but you still need accuracy to the 10e-6 place, at least.
  14. Fancy Mandelbrot Set Zoomed Plot View File Got a day to kill with your X16? Run this BASIC program and generate this 256-color fractal plot. It's zoomed into a deep part of the Mandelbrot Set that is particularly pretty. This plot does up to 355 iterations and is within an area where all points require at least 100 iterations, so the whole 256-color palette is able to be represented, from white for 100 iterations to black for 355 iterations or more. For fastest results, run in "warp" mode with your emulator: x16emu -warp -bas x16-mandelbrot-vga-fancy.bas At 8Mhz, this will take literally all day, but if you have a beefy enough host for your emulator, it can be cranked out in a couple hours. Enjoy! From: https://github.com/SlithyMatt/multi-mandlebrot Submitter SlithyMatt Submitted 09/16/21 Category Demos  
  15. Version 1.0.0

    33 downloads

    Got a day to kill with your X16? Run this BASIC program and generate this 256-color fractal plot. It's zoomed into a deep part of the Mandelbrot Set that is particularly pretty. This plot does up to 355 iterations and is within an area where all points require at least 100 iterations, so the whole 256-color palette is able to be represented, from white for 100 iterations to black for 355 iterations or more. For fastest results, run in "warp" mode with your emulator: x16emu -warp -bas x16-mandelbrot-vga-fancy.bas At 8Mhz, this will take literally all day, but if you have a beefy enough host for your emulator, it can be cranked out in a couple hours. Enjoy! From: https://github.com/SlithyMatt/multi-mandlebrot
×
×
  • Create New...

Important Information

Please review our Terms of Use