Announcing BlueSCSI Toolbox – Web Edition

[eric]

Current Status: Closed Alpha (12/30/2024) ~ 2 weeks
Next: Open Alpha/Beta​

Have you ever wanted to modify settings, create drives, or see what your BlueSCSI was doing but it’s installed in your retro computer and you don’t want to grab it out? Well have I got the solution for you!

Welcome the 9th(!) platform to our BlueSCSI Toolbox lineup – Web!

Desktop & iPhone screen shot​

The BlueSCSI Toolbox – Web Edition provides you a similar experience to how PiSCSI’s web works – allowing you to interface with your BlueSCSI over Wi-Fi and make changes to how your BlueSCSI works and is configured. You can do things like:

• Eject CDs and other Removable devices
• Create blank devices
• View the log file
• Turn on or off features like debugging
• Restart or reload settings
• Edit and save back the ini file
• And a lot more!

The details:

BlueSCSI Toolbox – Web works by using a “Control” Pico-W to run and host the website and issue commands over the qwiic(i2c) bus. Hosting this on a second Pico was required as serving websites while time critical SCSI commands are executing would be problematic!

Open a website and browse to http://bluescsi.local from your phone, modern, (or retro!) computer and take control of your BlueSCSI.

The how:

Documentation is critical for any new feature or project so anyone can set this up. As we are testing we will be making updates to the Wiki, so keep an eye there! For hardware testers will need to wire this up themselves. We plan to make an all in one board with screen, encoder, button, and Pico-W that will fit nicely into a drive bay or external box.

Quick glance at my i2c development setup:

The future:

Features planned for first release (subject to change)

• File management on SD card (Delete, rename, move, etc)
• Small file upload and download from the shared directory.
• Upload new firmware versions.
• What else would you like to do?!

A website is not all this “Control” Pico-W does! I did work last year on making a control interface with screen, rotary encoder, and eject buttons. This code will be integrated into this new platform after the first release.

What we’re also working on:

USB<>SCSI Bridge – Tony from PiSCSI has been hard at work in his free time since November building some pretty cool stuff that will allow you to boot Windows 11 from your old Quantum SCSI drives (slowly!) https://github.com/BlueSCSI/BlueSCSI-v2/pull/221

Interactive USB Serial console – Maybe the web is not for you and you’d like to automate or control your BlueSCSI over a USB Serial interface. That code is actually what started me down the path for this web project! Once all the Web commands are finalized I’ll re-visit the Serial Console. https://github.com/BlueSCSI/BlueSCSI-v2/pull/215

 

[MrTechGadget]

Hmm, here is an inexpensive module that could work for the controls.. https://www.aliexpress.us/item/3256807990095869.html

 

[SharedCow]

All hail, Eric. I very much look forward to this as opening my power book 170 to add and remove files carries great risk.

Thank you so much for your continued work on this project!

 

[eric]

Hmm, here is an inexpensive module that could work for the controls.. https://www.aliexpress.us/item/3256807990095869.html

I'm a bit skeptical when building things like this - where are the i2c docs for commands? how long will they make them for? If we build a cheap opensource one around commodity and well understood parts I think it'll be better in the long run. But it's good to look at designs and form factors and get ideas.

All hail, Eric. I very much look forward to this as opening my power book 170 to add and remove files carries great risk.

Thank you so much for your continued work on this project!

Thanks for your support and using a BlueSCSI - maybe we can make an adapter for the modem port to connect the i2c bus

 

[Ron's Computer Videos]

Another example of how BlueSCSI leads the way!

 

[ryanhayward]

Eric out doing himself as always! Kudos to the BS team and thanks for all the hardwork and dedication you put into the best SCSi emulator out there!

 

[JDW]

Wow! A great way to end 2024.

Always love to see ongoing development of an existing product in the vintage computing space. It really keeps the fun alive and enhances product usefulness too!

Best wishes to all of you as we ring in the New Year very shortly!

 

[superbenk]

Could this support WebDAV for uploading/managing disk images on the SD card remotely? FujiNet added that recently in their v1.4 release (thanks to Jaime from the Meatloaf project) & it makes adding/removing images extremely handy. Typically you're dealing with floppy disk images or maybe 32MB hard disk images so they aren't often large file transfers so I'm not sure how that would work for multiple-hundred MB to GB images but even if it's slow it could be handy.

 

[wottle]

Could this support WebDAV for uploading/managing disk images on the SD card remotely? FujiNet added that recently in their v1.4 release (thanks to Jaime from the Meatloaf project) & it makes adding/removing images extremely handy. Typically you're dealing with floppy disk images or maybe 32MB hard disk images so they aren't often large file transfers so I'm not sure how that would work for multiple-hundred MB to GB images but even if it's slow it could be handy.

Yeah, creating a blank image is an ok feature, and small file uploads can be handy, but more often than not, I need to load a new image with some additional software or a new OS version to test something. Awesome work, though! Excited to see the changes this can bring!

 

[eric]

I really understand the desire to want full image upload - maybe I'll add a flag like "IDontMindWaitingAFewHours=true" but honestly I'd be quicker to create a blank drive, mount the Apple Legacy Recovery CD and install the OS than try to upload a 100MB image.

Lets say 80k/sec is what we can get "real world" - a 32MB image would take ~7 minutes - ok not too bad - but beyond an Apple II prodos image - who wants a 32MB image? Why not just transfer the file in that 32MB image.

Say it's a 500MB image - now we're talking 1 hour and 45 min. A SD card extender is only a few bux - and you can hot swap the SD card so you don't even need to shut down - or even just use the daynaport emulation and ftp to transfer the file directly to the machine - there's just a lot better and faster options.

Now for floppy disk images, firmware updates, some sit files- that seems reasonable.


Alpha testers are staring to try things out and report back - hope to have time this weekend to put some more polish on it!

 

[superbenk]

@eric totally understand what you're saying & you're right that beyond ~10 mins or so it gets pretty unbearable. All the wishing in the world won't change physics so it is what it is. I guess that's what PiSCSI is for if you want that sort of thing, huh?

 

[eric]

Fixed a bunch of bugs this weekend and some polish on the communication layer, feels much more stable now.

One thing I'm struggling a bit with is if I should stick with pure html to allow older machines to control it that might not have a native toolbox app but web, or go all out and add some javascript to make it feel more modern (and write a lot less clunky server side code in c).

Thoughts?

 

[JDW]

One thing I'm struggling a bit with is if I should stick with pure html to allow older machines to control it that might not have a native toolbox app but web, or go all out and add some javascript to make it feel more modern (and write a lot less clunky server side code in c).

In reply, I should mention that your opening post says this:

Have you ever wanted to modify settings, create drives, or see what your BlueSCSI was doing but it’s installed in your retro computer and you don’t want to grab it out?

So we need to define "older machines" and "retro computer."

Specifically, what machines would become incompatible if you "add some JavaScript to make it feel more modern"? Once that is known, people would probably provide feedback to you pretty rapidly.

For example, if you add JS and then the SE/30 becomes incompatible but machines like the Color Classic remain compatible, many people might balk because the SE/30 is a popular machine.

 

[wottle]

In reply, I should mention that your opening post says this:



So we need to define "older machines" and "retro computer."

Specifically, what machines would become incompatible if you "add some JavaScript to make it feel more modern"? Once that is known, people would probably provide feedback to you pretty rapidly.

For example, if you add JS and then the SE/30 becomes incompatible but machines like the Color Classic remain compatible, many people might balk because the SE/30 is a popular machine.

Given this is just for the control side of things, I would wager nearly everyone (possibly everyone) has a machine new enough that it can use javascript. Although it might be handy to control is on the device, we already have native apps on vintage MacOS for some of that. Also, many of my machines do not have networking (although with v2 BlueSCSIs, I could enable it, but I rarely do). I think most people will do the management from one of their modern computers. The BlueSCSI functionality, itself, will still support all the machines it currently does.

I'd argue having a good experience managing the BlueSCSI from a more modern will be a bigger benefit and result in less headaches than trying to write a pure HTML manager and having the server side code be much more complex / harder to maintain / updated less frequently.

I vote for a js enabled control interface.

 

[eric]

The SE/30 and Color Classic would run the same web browsers and both not support javascript(in a meaningful way), or so little that it would be harder to code just to that. Also we already have Macintosh Toolbox apps. To make it simple: any current browser or plain html for all browsers (but less featured of course).

The real question is would you use this website /from/ the retro computer - or from your phone or laptop - My use case would be my phone/laptop to switch config/etc.

 

[JDW]

The SE/30 and Color Classic would run the same web browsers and both not support javascript(in a meaningful way), or so little that it would be harder to code just to that. Also we already have Macintosh Toolbox apps. To make it simple: any current browser or plain html for all browsers (but less featured of course).

The real question is would you use this website /from/ the retro computer - or from your phone or laptop - My use case would be my phone/laptop to switch config/etc.

Well, what I do in terms of using my MacSD, BlueSCSI or FloppyEMU is yank the SD card, then put it into an Intel Mac (because, very sadly, Apple Silicon Macs make it 100% impossible for me to avoid "fragmentation"), transfer files, then put the SD card back. It's fast and works well (except for the infuriating fragmentation when I forget and insert the SD into a modern Mac). But I need the machine open to do that. Many of my Macs are open all the time, so it's not a barrier FOR ME.

The solution presented in this thread is different. You're taking about a web interface that uses WiFi from BlueSCSI devices that have a Wi-Fi capable Pi Pico in them (which of course, isn't every BlueSCSIv2 out there, and excludes all BSv1 units). So it's only for the more savvy BlueSCSIv2 user who knows the appeal of Wi-Fi and who actually has it and uses it.

Would I be inclined to use my Color Classic Mystlc (for example) to access your pure HTML web interface, for the purpose of changing files on the BlueSCSI inside that Mystic? Well, if you offer that capability, I might. It's not too different than the experience you get from using FrogFind. You are putting your vintage Mac to good use. It would be fun to do that.

But if the consensus is that beauty and function is better than compatibility, then I won't stand in the way. I would just use a modern computer. And honestly, as we move forward, being able to do transfers this way, rather than suffer through SD card file fragmentation, is going to be a must. Intel Macs will die out and every Mac will eventually be Apple Silicon, which contributes to the file fragmentation problem, thanks to the SD card using FAT32 or ExFAT formats. (This isn't a complaint. It's just reality.)

So if you're gut tells you to implement JS to improve the overall experience, so long as it doesn't slow transfers down any slower than they already are, I don't see any problem with making that improvement.

 

[eric]

FWIW fragmentation has nothing to do with intel vs apple - it is the extended attributes on the file that can not exist on exfat and will cause interruptions when copying. You can see how to remove them in the docs: https://github.com/BlueSCSI/BlueSCSI-v2/wiki/Image-File-Fragmentation#mac-os

(Ability to do this likely coming to a Disk Jockey release near you) - but this thread is not about that.

I also could do 2 interfaces modern and html, twice the work though....

I'll chug along with HTML for now but it'll be a bit clunky. Few things to figure out anyways first.

 

[scj312]

Fixed a bunch of bugs this weekend and some polish on the communication layer, feels much more stable now.

One thing I'm struggling a bit with is if I should stick with pure html to allow older machines to control it that might not have a native toolbox app but web, or go all out and add some javascript to make it feel more modern (and write a lot less clunky server side code in c).

Thoughts?

IMO, it depends a bit what you're looking to enable with JS. If it is primarily UX enhancements, one option is both--implement all of the functionality in HTML, so that as many browsers as possible can use it, but then also layer on some JS that would improve the experience for those with a supported browser.

 

[JDW]

FWIW fragmentation has nothing to do with intel vs apple - it is the extended attributes on the file that can not exist on exfat and will cause interruptions when copying.

Believe me, I've spoken to Steve Chamberlin about this via email and in the comments section of the FloppyEMU page for many months. Even though "it has nothing to do with Intel vs. Apple" in theory, I can tell you from PRACTICAL EXPERIENCE that it actually does have very much to do with an Intel Mac versus Apple Silicon Mac, although the technical reasons why Apple Silicon Macs tend to fragment files whereas my Intel Macs do NOT is still shrouded in mystery. And no, killing Spotlight indexing or deleting hidden files isn't the answer. Trust me, I've spend so many hours on this I can't even count the time. And the reason I mentioned it and felt it was relevant and related is because we are talking about ways to transfer files to/from the SD card of the BlueSCSI, and when you do SD card swaps like I do, then it becomes a living reality.

So the solution present in this thread is a means to get around all that mess, albeit at a cost in performance. I can transfer files to/from and SD card faster than BSv2 WIFI. But that doesn't mean the solution put forth in this thread is bad. It's just something to take note of.

I'll chug along with HTML for now but it'll be a bit clunky. Few things to figure out anyways first.

Like I said in my previous post, leaving things as is for the sake of compatibility is merely to allow people to have a little fun with it. I don't see it as being necessary. So if you go ahead and proceed with adding JS and a modernization, most people would probably welcome it. @wottle cast his vote for it, and I will join him with my vote. Let others reading this post do the same!

 

[eric]

is still shrouded in mystery.

I dont think you read the link I included - also lets take it offline or a different thread.