Jump to content

Fnord42

Members
  • Posts

    75
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Fnord42

  1. Okay, having read and thought about this a lot more than I had when I answered the poll, I must admit I changed my mind. I now think very few people here will lose interest in the X16 just because they can have an X8 now, and it will allow Dave to get some money to fund further X16 development while giving the people something to play with and pass the time in return. Regarding compatibility, I don't see why the X8 could not easily be modified to use the X16's Vera addressing scheme, at least optionally. The only thing that I have conflicting feelings about is the speed - it would feel "more right" to me if the X16 was not slower than its little brother. Slowing down the X8 to 8MHz by default might avoid the strange feeling of "not really upgrading" when switching to the X16 later. And it would certainly avoid some porting issues later on. So, my revised opinion is: Gimme the X8 now! (Maybe only 6 or 8 MHz though) Phase 1 X16P Kit next Phase 2 for the non-solderers that still want most of the retro experience and expandability
  2. Speaking of upgradeability - I'm curious: Is there anyone here who does not plan to max out their X16's RAM to 2MB immediately? Leaving the X8 aside for a moment, the availability of an X16 with less than 2MB of RAM could also lead to people developing only for the smallest common platform, couldn't it?
  3. I'd love to be able to buy a professionally-made case for my X16P.
  4. I'd also buy an X8 without thinking twice if it were available(*), but I think the concerns about having two semi-compatible platforms cannibalizing each other's user (and more importantly: developer) base are valid. (*) in addition to the X16 Phase1 Kit, which I still want most.
  5. I think you got the point wrong, or at least incomplete. To appeal to people's (admittedly irrational) love for retro(-like) hardware, the through-hole part is important. Also, it makes the kit version easier to build for beginners. And don't forget the expandability of the X16 which is a very appealing aspect that the X8 lacks. I do agree with your point about the licensing, though. I see the benefits of the current situation, but ultimately I'd love to see the X16 go completely open-source, including the Kernal.
  6. I guess I'll have to retract my earlier criticism about the X16's audio capabilities. This sounds actually quite a lot better than I would have expected. Thank you!
    Just tried it, and it's awesome! Some effects are still missing, which makes the second half of Lotus2.mod sound really awful but everything else I tried sounded great. Great work!
  7. Nope, not possible. Wouldn't give you much of an advantage anyway, except if you want to copy large amounts of data from one area in banked ram to another. Plus, you'd have to deal with the reset and interrupt vectors which are hardcoded at the end of the 65C02's address space.
  8. I think we are missing the true elephant in the room here. What we should really worry about are people/websites that call short video files "GIF" when they are in fact something else (like MP4 for example). That is just wrong, and they deserve bad things happening to them.
  9. Beautiful! Does the X16 support the middle button/wheel? The scroll wheel is one of the more "modern" UI features that I miss most when working on the Amiga. So although it is a bit of an anachronism on an 8bit system (like VGA and SD cards), I would welcome it. I suspect this is purely a software question, and if the Kernal does not support it, you can always write your own mouse driver. But, assuming there'll be a mouse included with the X16, it would of course make sense to have Kernal support for all its buttons (the wheel usually being up/down buttons from a software perspective).
  10. The X16 design has been very expandable already, so lots of these ideas have been floating around for quite some time now. You probably wouldn't want to use the ATtiny84 for that, though. But I really like the fact that we now have I2C, too. (I'm hoping for KERNAL support here - writing your own I2C bit-banging code was obviously already possible before.)
  11. Ah okay, a quick test shows that ESC and Ctrl-C both interrupt a Basic program, so it's probably mapped to the Stop key in the emulator. Using the WASD keyboard, RUN/STOP, 40/80 (and potentially RESTORE, but how do I check that?) don't work as expected. I suspect there's a reason for it, but is it a good reason? I imagine it might be a pain to get Scroll Lock key presses consistently on all supported platforms, or something like that?
  12. Maybe I'm missing the obvious here, but why not use ESC for that?
  13. True. You'll probably want to start here: https://github.com/ghidraninja/
  14. With Nintendo being Nintendo it would probably be better to use any of the numerous devices out there that are actually made for tinkering, like for example the Odroid Go. Doing anything with Nintendo hardware that has a chance of not making them money is just asking for legal trouble. That being said, it is fun to run the retro-go port on this thing, provided that you can solder and don't mind swapping the flash chip for a bigger one.
  15. This might be interesting for some of us: Yes, there are more polished versions from established manufacturers out there, but I like that this one uses a (replaceable) MicroSD card and the antenna would be outside the (probably metal) case of the X16. Also, the firmware is open source.
  16. Good point. The only thing where this might be problematic is developing (for) external hardware. Is there an API in the emulator that allows us to simulate external hardware (like expansion cards and/or hardware on the user port)? If not, is it planned to add it at some point? Or are there arguments against it? (Except developer time, which is of course always short. I guess this feature would be relatively far down on the priorities list, at least until the hardware is more or less finished.)
  17. Maybe it's just one of those things that you imagine to be terribly annoying, but then get used to quickly. But apparently it seems to be an issue for some people. However, it will be fun to see (and/or make) the wlan-based solutions that will inevitably turn up sooner or later.
  18. It should not be too hard to build an extension cable using two of those sd-to-microsd adapters that everybody has a ton of and some ribbon cable, I guess. That way, you can at least have the card at a more accessible location. Of course, any solution that eliminates the need for physically handling storage media would be much preferable to this.
  19. I had the same thought, but: I'm pretty sure a momentary switch is part of the case by default. It might be possible to swap it out against a locking switch. (Is that the correct name? Think of the C64 shift lock key, or those "Turbo" buttons that PCs had back in the 90s.) But since this probably needs to be done by hand, I'm not sure if it doesn't turn out to be more work overall in the end. Regarding the use of a microcontroller for the power switch logic: I would be totally fine with that, since it serves a very narrowly defined purpose. To keep the "only readily available parts" paradigm intact, the firmware should of course be available, in case you ever need to replace the chip. However, I also unterstand the desire to avoid microcontrollers at all when possible.
  20. I just had an idea: It might be enough to have a very simple file format that does not require us to load the whole file at once. This way you could implement all the loader code in your program and keep the additional rom usage at a minimum. Something like: 2 bytes format identifier (illegal address), 1 byte flags (see below), 2 bytes target address, 2 bytes number of bytes to read (size of loader), loader code, other data One bit in the flags would determine if the kernal should jump to the start address upon finishing (so you wouldn't need to type RUN and could omit the basic-sys-header stuff). The loader code in the file could then reopen the file and load all the rest of the data as needed. Lacking the possibility of seeking, it would have to read and ignore the loader code before it can get to the rest of the data. I don't know how fast that would be, but I think it might not be that much of a problem. (Or an incentive to keep the loader code compact. ;-)) Another thought: Is it possible for the kernal to leave the file opened, so the loader could just continue reading at that point? This could then be controlled with another bit in the flags. What do you think?
  21. That's kind of the point of an emulator, though. PS: It is, of course, still exciting and very cool.
  22. I'm undecided as to how much we actually need this (meaning: I am totally unable to judge if it is a good use of possibly scarce rom space), but it seems like a good thing to have. hth313's argument for ELF seems reasonable to me. OTOH, reinventing wheels is undeniably part of the fun in a project like this. I'm curious to hear more opinions about this.
  23. Very nice, I didn't know this existed until @Perifractic showed one in his christmas unboxing video! Then, just one day later, I stumbled across this very interesting talk at the rC3 conference: https://media.ccc.de/v/rc3-80443-hacking_the_nintendo_watch Mine is ordered and should arrive next week.
×
×
  • Create New...

Important Information

Please review our Terms of Use