Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Fnord42 last won the day on August 21 2020

Fnord42 had the most liked content!

Community Reputation

40 Excellent

Recent Profile Visitors

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

  1. 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.
  2. 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).
  3. 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.)
  4. 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?
  5. Maybe I'm missing the obvious here, but why not use ESC for that?
  6. True. You'll probably want to start here: https://github.com/ghidraninja/
  7. 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.
  8. 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.
  9. 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.)
  10. 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.
  11. 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.
  12. 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.
  13. 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?
  14. That's kind of the point of an emulator, though. PS: It is, of course, still exciting and very cool.
  15. 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.
  • Create New...

Important Information

Please review our Terms of Use