Jump to content

Fnord42

Members
  • Content Count

    63
  • Joined

  • Last visited

  • Days Won

    1

Fnord42 last won the day on August 21 2020

Fnord42 had the most liked content!

Community Reputation

36 Excellent

Recent Profile Visitors

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

  1. 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?
  2. Maybe I'm missing the obvious here, but why not use ESC for that?
  3. True. You'll probably want to start here: https://github.com/ghidraninja/
  4. 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.
  5. 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.
  6. 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.)
  7. 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.
  8. 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.
  9. 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.
  10. 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?
  11. That's kind of the point of an emulator, though. PS: It is, of course, still exciting and very cool.
  12. 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.
  13. 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.
  14. That's awesome news, thank you! (Also: Yay, my Tetris running on real hardware! \o/ Thank you Kevin for including it in the video!)
  15. As far as I can see, it should be absolutely possible to build a free/libre open source firmware for the X16 and also use it with the final hardware. This might be a fun project. Compatibility with software that uses Kernal functions might be an issue though; I don't know how much work it would be to reimplement the API.
×
×
  • Create New...

Important Information

Please review our Terms of Use