Jump to content


  • Content Count

  • Joined

  • Last visited


Recent Profile Visitors

611 profile views
  1. No problem, whatever you'd prefer. If you're OK with the GPL it'll match almost everything else in the repo anyway. Licensing can be a touchy subject and I didn't want to share anything without permission.
  2. If you're OK with that I'd love to post it there, and give credit to you for your work. Do you have a license you'd like to share it under?
  3. That case design is awesome, thank you for designing and sharing it! I'm hoping to get it going in the 4K of the 64A3U, with the thought that it it is the most "elegant" solution and maximizes the number of possible chip candidates during the current silicon shortage. It will likely require modifying FatFs to include more direct streaming functions. I've got two of these built now with the 64A3U, so I'm well motivated to make it work with that chip.
  4. Top is printing now, I'll let you know how it goes. I've been working with Petit FatFs today and have a proof of concept up and running, using chunks of the example code for AVRs. It's been fun booting the same volume in Basilisk II on my desktop and on my IIci. Right now I'm using single-sector read/writes on the flash card, which causes predictably dismal performance: ~200KB/s reads, ~100KB/s writes, and it feels even slower than that just booting/launching apps. Still, not too shabby for a few hours work, and there should be room for major improvements once I can figure out how
  5. That looks fantastic! Whenever you get the STL files in order I'd love to make a copy of that here.
  6. Give that things seem to be (mostly) working I've pushed hardware version 2 to Github. If you build it, please report issues. Good catch, that's been supported for a while but I never updated the README. It is fixed now. I omitted the patch, but hopefully that is easy for people to Google - if it seems like it is being missed I'll add a more explicit note. Ooh, yes, I'd love to try that out! That's definitely on my TODO list. The current SETTINGS.html / EEPROM approach is very clunky: I'd love it if there could be a simple text
  7. Awesome, I'm glad the virtual hard drive is working. Nothing to test yet on networking (unless you want to see if Nuvolink support works), but let me know if you encounter hard drive issues.
  8. That sounds promising! Do you mean the computer booted up off the new scuznet board? If so, are you noticing any other problems?
  9. Got my version 2 board built and programmed. Just like @Chopsticks I had the 3 long/1 short flash on the test firmware; I pushed a permanent fix for that on Github. After the fix I got the pulsing LED indicating basic hardware tests were good. I flashed the regular firmware, took the SD card from a version 1 scuznet, put it in a mini->full SD adapter, and it booted first try on my test SE! Things are not 100% yet. The hard drive is working fine and I can browse my AppleTalk network, but with the normal Nuvolink firmware I cannot mount any remote volumes: after authentication, th
  10. Not problem at all, it will be super helpful to have someone else with the hardware once I fix the firmware bugs! Let me build my copy here later this weekend and I'll post the software changes for you to test. Having no activity at all on the LED is a sign there is something else going on, but I'm not sure what would case that.
  11. If I had a nickel for every missed semicolon! So, no activity at all? If the tests pass it should slow-pulse the LED. Is it just dark?
  12. That's the right place. Is there a missing semicolon at the end of the line?
  13. Sorry for the long delay in responding, it's been a fun week here. I'm hoping to (finally) assemble a V2 board this weekend and verify the firmware on that for @Chopsticks and anyone else interested. Lol, yup, the calculation is ridiculous. This is likely a bug in mem_size() in mem.c. I don't have anything bigger than 16GB in microSD to test, but I do have bigger full SD cards to try out once V2 is up and running. To keep me from losing track of all the outstanding problems I've opened an issue on Github for this one and will revisit it.
  14. Not 100% without verifying there isn't a firmware bug, but I'd guess you have bridged pins somewhere on the data pins of the main chip. Could you double check that with a multimeter if you haven't already? That's been my experience too. The data read/write isn't super efficient and the board will never be a speed demon, but doing updates to that section to squeeze out more performance is on the long-term TODO list.
  15. Would someone with a RaSCSI be willing to do a quick speed test on the Daynaport emulation? Nothing fancy, just a "X" megabytes in "Y" seconds stopwatch test would be great.
  • Create New...