Jump to content

SlithyMatt

Members
  • Posts

    790
  • Joined

  • Last visited

  • Days Won

    59

Everything posted by SlithyMatt

  1. It can be, and I made a video about it:
  2. I didn't realize this worked in warp mode. Good to know!
  3. 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.
  4. 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.
  5. 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.
  6. 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  
  7. Version 1.0.0

    42 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
  8. Makes sense when you think about it. The difference between BASIC and 8.8 fixed point in assembly was 7x. The individual BASIC math operations are no more costly in the higher-res plot, but they are in assembly when moving to 16.8 fixed point. So, considering that number representation was 50% larger, it's a pretty small performance penalty going down to only 6x faster than BASIC.
  9. Now it's time to see just how much power the X16 has:
  10. Here's my handy chart: Further explanation in one of my videos:
  11. When I put on my tin foil hat, I'm fairly convinced that this bubble, just like the NFT one, were manufactured for the purpose of money laundering. It's the only way it makes sense to me.
  12. Exactly when did Apple "understand" this? They have never been in that price point.
  13. I've created an adventure game engine for the X16, like Sierra's SCI or Lucas Arts' SCUMM, but I am using 16-color graphics. However, since you can have custom palettes, the results are much nicer than the EGA games you may remember. Here's the intro to a game I'm developing for that engine: And a bit more of the game:
  14. I plan on making one for assembly development as soon as that kernal code is stable and fully functioning in the emulator. Unfortunately, progress on that has been stalled for many months.
  15. I purposely kept those value computations in there, as that was part of the original algorithm, and I wanted to make sure all the calculations were happening, even if some were needlessly repetitive, like re-computing the bottom half instead of just mirroring it. I'll take a look and see if I can merge some of it in.
  16. There are really only two text modes, both of them 80x60, with the default being 16 colors for any character's background and foreground, and the other being a fixed background color with 256 foreground colors. You can then adjust the vertical and horizontal scales if the display. Pixel-for-pixel scaling means setting each scale value to 128, which is the default. You can double up the pixels in both dimensions by setting them to 64, which gives you 40x30, and so on. Also, the text layer can be scrolled around, and and the default tile map is actually 128x64, so there are a bunch of characters off screen. Scaling up allows you to make the tile map smaller, giving you more VRAM for other things, like a second layer or sprites.
  17. Best practice is whatever is best for your program. The thing about the eventual ROM address is that it's subject to change, whereas the address that jumps to the RAM vector is set in stone, as CHROUT is $FFD2 in the C64, too, as is the location of the RAM vector. But if you really need to shave some cycles, you can hotwire your code at the risk of it breaking after a ROM upgrade. Most of the C64 Kernal is in the X16 Kernal, with only a few non-applicable routines left out. The Programmer's Guide in the x16-docs repo documents all of that, including the addresses for them in the ROM. You will need to refer to C64 docs to know how each of them works until the X16 docs are completed.
  18. If you are using cl65, the .org and . segment statements are required, or the build will fail. The discrepancy between the addresses is because of the RAM vector that the Kernal uses. In the case of CHROUT, the suggested address to use is $FFD2. What this will do is is jump to the address stored in RAM at $0326. By default, that address is $FEDE back in the ROM, so you could just JSR to there directly if you want to ensure you are calling the ROM routine instead of a custom one that has been injected into the RAM vector. A lot of the Kernal routines work like this.
  19. There are many contract fabs that will convert FPGA code to ASICs. It all comes down to the unit order. It's very expensive to do in small batches. That's why it's pushed off post-stage 3, which will still be FPGA, which is much cheaper until you hit that magical unit count. Once you are moving Raspberry Pi-level scales of SBCs, it makes more sense to go ASIC, and it would be truly a dream come true to have the X16 get that kind of demand.
  20. Not only that, but I use Faraday cage-free electrons for all testing, and cruelty-free ceramic packages.
  21. I'm going to start an artisanal fab in my basement that produces organic, GMO-free ICs. Come visit my table at the Farmer's Market.
  22. My patrons and subscribers are folks who really want to learn about assembly development, and 8-bit homebrew in general. This is what they are coming for, as "mainstream" channels aren't going deep enough for them. I do make some videos at a higher level, but they don't always do as well. So, back to the niche I go!
×
×
  • Create New...

Important Information

Please review our Terms of Use