Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 01/15/21 in all areas

  1. 2 points
  2. 2 points
    Very nice! But you got the date a year late. Probably [emoji39]
  3. 2 points
    These chips are readily available through our supply channels. This chip was an exception because firstly it met our cost goals and secondly developing an open source FPGA core if the supply dries up isn’t a problem. Yes it is paired with the YM3012. Sent from my iPhone using Tapatalk
  4. 2 points
    Here's a version of the assembler to play with. It doesn't support symbols yet so stick with basic assembly. It also only writes output directly to memory for now. The video shows it in action on a simple hello world program: cx16mf-2021-01-14_22.07.31.mp4 assem.prg
  5. 1 point
    Given VERAsound will now replace the SAA1099, and given some other conversations on the forums (such as the conversation about envelopes in this post), I opted to take another look at my proposed tracker file format, which you can find here: https://gitlab.com/m00dawg/commander-x16-programs/-/blob/master/command_tracker/index.md I've talked about this before on the FB group, but I've opted to stop using FB and thought it would be a better conversation had here anyway. The main issue is that there are 26 channels so to optimize for storage on playback, a sparse format is probably worth the extra complexity in playback routines. I had the idea of supporting multiple effects since this is a common feature in modern trackers (even FamiTracker has this). That may go by the wayside, but even if each channel only had single volume and effect columns, I came up with 5 bytes per channel for VERASound and FM and 3 bytes for DPCM. So a single row would be 126 bytes and a 64 row pattern would be 8064 bytes! The file format I came up with can support multiple effects per channel, and when you include these it balloons to a staggering 41.6k if I did my math right. But given even complicated patterns have empty space in them, by using a sparse format these requirements go down considerably. Only rows which have data are defined and, within that, only channels which have data are defined. So a row can be as few as 3 bytes if there's only one channel playing on that row with no effects. I made an attempt to show the proposal row format here but I can't find a way to insert code blocks and it was really hard to read without a monospace font. So I recommend looking at the link (specifically the sparse patterns link) The trade-off is a playback routine has to track a lot more things as opposed to just reading a pattern row by row. I don't think it would be too terrible since there could be a row counter and if the current row read is greater than the counter, nothing is done. When the counter equals the current row, it then can parse out the row to do the things. This ignores envelopes and some automatic commands (like how the volume slide works in Famitracker as compared to how it works in Impulse Tracker) as those could be firing while there is no row data. Figuring out how to efficiently edit pattern data is another task entirely though. If one adds data to a previously empty row, the sparse file would have to be reorganized. The best solution here is having a non-sparse pattern buffer - which would be fine for a dedicated tracker where we have room to move about. But given the space requirements, it means patterns would span multiple pages and that could get interesting when adding in things like envelope tables and things. I should say I'm not an awesome assembly programmer - just a musician who is very excited about the prospects of a tracker, but given the vast sound capabilities of the X16, it feels like it will take some thought to do well given the "limited" space (which is itself far more than the 8-bit systems of yesteryear). That's why I thought it might be good to try and start the conversation by coming up with at least something that can serve as talking points.
  6. 1 point
    I was curious how fast the Commander can actually read files from disk, so I fired up the emulator and did some quick tests. I wrote a very simple assembly routine that lives in Golden RAM (the section at $400), and timed it to see how fast it ran. With a 32K file, it takes 155 ticks, or 2.58 seconds. That makes file read throughput 12.7KB/s. What does that mean, in terms of real numbers? You can fill the BASIC program area ($800-$9EFF) in 3 seconds An 8K bank will load in 0.64 seconds You can load all 512KB of banked memory in about 42 seconds.. This is far less than the CPU's theoretical maximum throughput, and it averages to roughly 125 machine language instructions per byte read. I'm not sure if the time spent is just due to the FAT32 driver, or if there are some delays in the emulated hardware. That's something else to look at. In the meantime, the next step would be to evaluate the speed of popular decompression routines. Exomizer and PuCrunch seem to be the most common 6502 compression systems right now. ** Edit: this has caused a little confusion, since I revised these numbers. The original result was around 9.8KB/s, and used the code attached. I got a marginal increase in performance by skipping the READST KERNAL routine and reading $286 directly. The problem here is that $286 is not frozen and could change. So I'm going to request (or supply) a small change to the KERNAL to return the current address of the ST variable, so we can query it directly. chkin.asm
  7. 1 point
    Ah, I was wondering what was up with the ORA and STA before getting back to the RTS. That makes sense, and allows them to save a byte from SETMSG as well, since that too runs straight through READST and UDST. Clever. The academic in me wonders if they secretly depend on that execution path anywhere in the kernal. The horrified engineer in me is wondering if those dependencies are documented.
  8. 1 point
    Thanks, I'll keep that one in mind. This particular test is bookended in BASIC code to manage the timing. Anyway, I looked at the original Commodore ROM, and it's the same. However, there is an additional label there, which updates the status byte. So it looks to me like someone decided to save some ROM space by cramming the read and update code together. https://www.pagetable.com/c64ref/c64disasm/#FE07 And yes - it really does add that much time. 208 Jiffys using JSR READST and 155 Jiffys using LDA $0286 I don't think it's worth worrying about for small files, but when you're loading 100+KB into banked RAM, I think that will make a noticeable difference. So it's something to bear in mind. On the bright side, I don't think there's actually anything to lose by reading past EOF... you'll just get back nulls, and if you expect a certain block size in your file, that's not an issue. So calling READST once every block, rather once every byte, is going to save some CPU time.
  9. 1 point
    You get to choose your poison: Copy the VRAM data you want to preserve to somewhere else, where it'll be out of the way. Clobber the VRAM data you would have otherwise been preserving. There is no reason you have to keep the character set at $0F800. If you intend to use it, copy it to somewhere else in VRAM and update the layer data that would use it, accordingly. I also want to point out that the VERA does not have "banks" in the sense that I think you mean. It simply has 128KB of addressable memory, however the tail end of that (starting at $1F9C0) is overlapped with the audio generator, followed by the palette, and finally sprite attributes. So don't clobber that area with pixel data.
  10. 1 point
  11. 1 point
    Short and simple, but a perfect tutorial code to get you up and running with sprites in no time! This is my starting point to the X16.
  12. 1 point
    Valid point to a large degree. Less of an issue here if the system always closes its files, but I can see wear being an issue. To minimize swapping you will have serial. And if you do all your testing in the emulator you will not need to swap cards as much. Sent from my iPhone using Tapatalk
  13. 1 point
    I updated the game a little: Additional level Added end title music added fade-in/out effects Explosion animation. Have fun
  14. 1 point
    I went through (parts of) the same exploration when trying to figure out how to add floating point support to Prog8. Don't hesitate to ask if you have additional questions!
  15. 1 point
    CMDR DOS can seek in files! It's documented in the README. There is one mistake: the Position command works in Read mode, as well as Modify mode.
  16. 1 point
    Oh man, this is why this forum is so useful! I'm really new to this stuff, and although it's been a great learning experience to literally work out floating point, 2s complement etc from scratch, finding out there is a kernal routine is really useful! I will search out some decent references for this and explore my options. Still, definitely time well spent as I've really enjoyed getting under the hood of how some of this stuff actually works. Thanks again for your help!
  17. 1 point
    Your RLE format is somewhat hungry for memory space . I'd use a [RunLength], [Value] format where RunLength's MSB indicates whether it's followed by a single byte value that is repeated N times, or by N bytes that are only used once. So, a data stream that looks like ABCDDDDDDDEFGHIJJJJJJ would be stored as 3,A,B,C,135,D,5,E,F,G,H,I,134,J for a total of 14 values, while your format would be A,1,B,1,C,1,D,7,E,1,F,1,G,1,H,1,I,1,J,6 for a total of 20 values. The difference would be even greater if there are many non-repeated values. Of course, this could be extended to indicate, for instance, that what follows is a pattern of M values that should be repeated N times, by using a few bits of the RunLength byte.
  18. 1 point
    You could also try to use the basic/kernal floating point routines such as FOUT $fe81 to print the floating point values
  19. 1 point
    D'oh, yes, but you got my drift. I was getting excited. I can replace three of those set-up lines with a single: VPOKE %10000, $4000, 0 And yeah, that works! Thanks!
  20. 1 point
    Yup, it just takes the value of the first argument and stores it into $9f22. (Though I think it would be decimal 16, not hex). Actually, taking a closer look at your code, it might not be less lines of code, given the way you're doing runlength.
  21. 1 point
    Actually, I don't think you could use VPOKE in this instance. Under the hood, VPOKE simply sets the address at $9f20-$9f22 and pokes the value into $9f23. Theoretically, you could set the first argument, the bank, to 16 to set the increment bit, since it's just poking that value to $9f22. However, the incrementing wouldn't work with calling VPOKE continuously since it's explicitly setting the address each time. I just tried it with an experiment and it didn't seem to increment. You could probably use VPOKE for the first piece of data though, to set the address, and just poke to $9f23 after that. It should in theory be a tiny bit faster since the setting up of the address is being done in assembly instead of BASIC. Less lines of code too.
  22. 1 point
    It looks like it is BCD-to-float conversion, based on work originally from Compute! magazine?
  23. 1 point
    OK, I reformatted this to look like the C64 promotional at the end of the 1983 Christmas Demo. I figured I could push some of the X16's features while playing that little ditty from Bach. And I backed off a bit on the sprites, so they're more subtle, but still there of course.
  24. 1 point
    Do I understand correctly that this program provides its own code and storage format for dealing with floating points? Or does it use the same binary storage format as what the basic in rom does?
×
×
  • Create New...

Important Information

Please review our Terms of Use