Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


StephenHorn last won the day on November 4 2020

StephenHorn had the most liked content!

Community Reputation

311 Excellent


Recent Profile Visitors

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

  1. I mean, we already have banked RAM that can do all of this "putting data in/out of context" thing you're referring to, except in whole blocks of 8K instead of your subset of registers in the ZP. And if I'm working with heavy A/V data, I care about the quantity way more than the exact cycle count of accessing it, because all the cycle count savings in the world won't help if I have to slurp in new data from external storage - we're talking about multiple orders of magnitude difference to copy from memory versus copying from the SD card. And if I'm stuck with a loading screen, I want to be stuck only and exactly once, if possible. And honestly, if I'm in an A/V situation where I desperately need to maximize the bandwidth to, say, the VERA -- so much so that I can't afford the access penalty of banked himem -- then I'm going to be highly interested in an expansion card that provides hardware DMA. In fact, maybe a card that interfaces with its own SD card and caches the raw binary image of the card (or, ideally, a specified file in a filesystem on the card, maybe through some global launcher that comes with the card, but I'm happy to live within less sophisticated features), and that can then be instructed to use DMA to push selected regions of its local storage to a single address (piping it to the VERA or another device), to an address range (dumping it to RAM), or even to a series of RAM banks. Or hell, even if the card simply provided DMA to copy things between memory ranges and devices on the X16, with no additional memory, that would still be faster than any software copy by an order of magnitude, if it really came down to that. But then, there's already a lot about the X16 that wouldn't have been remotely possible on the C64, just because the X16 is 8x the clock speed. Pushing it further seems likely to run into more basic problems involving the finite amount of memory on the system, requiring different hardware solutions to expand the available memory so that the increased bandwidth is... well, useful. About the only special purpose where I'd even think I'd want DMA is game programming, to quickly transfer large quantities of assets to the VERA without having to sit on a black screen while 128K or whatever is spooled. Really, multitasking seems like the only significant purpose served by swapping the ZP and stack, and I have a whole essay I could go into about that (tl;dr, I'm not a fan and think you really want an entirely different CPU family and system architecture if you really want to look into multitasking as anything more than an extremely fragile parlour trick).
  2. Per the title, are there any plans to limit the number of units that a person can purchase at launch? I'm starting to warm up to the idea of possibly playing around with expansion cards, but since I'd be a novice to that area, I'd want a second unit so I don't need to worry (as much) about literally blowing up the unit. The topic of ordering limits doesn't seem to be addressed by the FAQ. Maybe this is still too early to discuss, but I thought I'd put the question out there. To be clear, I'm only personally thinking about ordering a second X16. I'm not planning to order 16 X16s, though that could lead to an entertaining Youtube video akin to the 3 PS3s, 4 PS4s, and 5 PS5s. So even if there are limits to the number that folks can order, I'm really just hoping the limit is greater than 1.
  3. It looks to me like you're missing a `void (*SystemIRQ)();` declaration somewhere... Edit: That having been said, I haven't done any interrupts in cc65, and I doubt it's safe to just clobber the system IRQ with a cc65 function (`rts` vs `rti`, and all that). Are there any IRQ-related functions in the x16 library for cc65?
  4. This may be a bit of "you had to be there", because at the time the poll was taken, there was no physical kit in the hands of anyone, except for a prototype being passed between the X16 team members. So the question was entirely how the community expected to use the SD Card slot once the final X16 was available for purchase. And the majority of the community (myself included) responded that SD Card swaps would probably be rare. Personally, I'm anticipating that I'll buy a wifi SD card and simply never think about pulling it out, except to replace it should it burn out.
  5. In fairness, that's perfectly reasonable and did happen. The example cassette should really already have a label instead of a blank white rectangle that screams "Write in me!"
  6. Ahh, that early 90s look and sound, such nostalgia... A friend recently managed to lure me into watching Carole & Tuesday, a Netflix original anime series about two girls on a future version of Mars who try to launch a music career together, in an industry that's now dominated by superstar artists and personalities who mostly perform AI-generated music. The biggest selling point of the series is definitely the OST - there's a lot of good music in the show, and some fairly disparate genres represented. I thought the first half of the series was overall pretty great, but the second half felt derailed by a B plot that wasn't central to the girls' journey, and I felt the ending was pretty weak as the B plot took greater emphasis and then ultimately resolved itself without the girls' help. Plus other confusing things that broke my suspension of disbelief at the end. Overall, worth watching at least the first half, for the music. This is what finally convinced me to try the series, if only for the OST. (Fair warning: Coarse language. Lots and lots of coarse language.)
  7. As much as I want to support ambitious projects that aim to push the limits of the hardware, it's only with the understanding that the hardware is what it is, and living on the edge means always being a half-step away from teetering over it entirely. It might be worth planning out what you want to do in your shooter, and figure out whether you have the VRAM to do so at 640x480... or else to drop to 320x240, or make cuts somewhere in order to fit your game into VRAM.
  8. No worries, could just as easily be my fault, on a re-read I see what you meant.
  9. Regrettably, this is not technically feasible, and would never have been. The VERA has always been 640x480 and only 640x480, it has never had the option of supporting multiple pixel clock speeds for multiple native resolutions. So our choices are "scaling with artifacts", "moving the display", or "doing nothing."
  10. I'm not sure what documentation you found, but as far as I'm aware the VERA has never been limited to 64KB of VRAM, and I went looking through the emulator code to build my own documentation as early as r27, which was the first publicly released version of the emulator. The VERA used to think in terms of 24-bit addresses, however, with the most significant byte acting like a bank switch. VRAM was then located in banks 0 and 1, while other memory-mapped registers were located in other banks. It would be easy to mistake this setup as "VERA only has 64KB of VRAM", if the author was forgetting about the entire second bank of VRAM. (Note that, even as early as then, there was no internal division between "the two banks of VRAM", so tilemaps, image data, etc. could overlap the bank boundary without causing any issues.)
  11. That's another good point in favor of including at least some sort of license.
  12. Ack, seems we both flubbed that. Of course I meant GPL.
  13. Honestly, the potential pitfalls and headaches are why I personally use simple licenses that are about as free as possible. My personal projects on GitHub are MIT, mostly because I didn't see "CC BY" or "CC0" in GitHub's list of baked-in licenses. MIT is a short, permissive license that basically says "You can do whatever you want with my code, just-- if you do use my code, keep my copyright notice with it (and, of course, the license). Basically the only thing forbidden is straight-up poaching it and pretending I had nothing to do with it. And liability - hell no I don't warranty my stuff with your random stuff, that's 100% user beware. And the liability clause is about the only reason I can think of not to just use CC BY or CC0. I'm actually not sure, either, to what extent GPL is still protecting or accomplishing their mission of "more and better free software for everyone". Being a bunch of soviet-style communists (you must also be communist or else) tends to scare people away, making it just another walled-garden fortress of the same sort their people claim to be against in the first place (and also claim is unhealthy for the progress of software everywhere). MIT's hippie-style, free-love for code license has no walls.
  14. Yes, the emulator uses the BSD 2-Clause license. It's an extremely permissive license. And yes, if you're going to submit a PR with someone else's work, you should ensure their license permits its inclusion into the emulator. This generally isn't too difficult, as long as you stay away from copyleft licenses, such as most licenses from the GNU people. Still, if there is any question whatsoever whether the author's code would be allowed to be used in this way, you should attempt to contact them and ask. I think you'll be surprised at how many people don't think terrible hard about their license selection and will reconsider the license, issue a one-off license for use, or otherwise permit their code to be used.
  15. Correct, you only need to include rom.bin. There are various symbol files generated by building the rom as well, but even though they've usually been included in the release packages, the emulator doesn't need them and can't load them besides (well, not until or unless the feature gets added).
  • Create New...

Important Information

Please review our Terms of Use