Category: BlueSCSI

Posted on by

Upcoming Products

Other than the normal-priced BlueSCSI desktop design which is incoming, what else is there to look forward to as we approach the end of the year?

Far too many things for my spare time to be very happy.

First, a product for the Mac Portable which should resolve once and for all the problems that are caused by its Lead Acid battery and the maintenance that requires: The Mac Portable Battery Eliminator.

It hooks up to the Modem slot, requires a small (included) jumper cable to connect to the motherboard instead of the original battery harness, and uses Supercapacitors to take the place of the battery. Plug your power adapter into this card through the Modem port’s cutout, wait 2 minutes for the capacitors to charge, and that’s it. Never bother to charge a lead acid battery again. Also includes solder points for a 9v battery clip if you demand PRAM retention, but supercaps have high discharge so don’t expect great battery life.

Second, an update to the Mac Portable 7 Meg RAM card which includes the switching option by default (I don’t have to solder things to the CPLD any more, hooray). This will entirely replace the base model 7 megabyte card after those are sold out, and will sell in parallel until then.

Third, an entirely new product line. Are you tired of having to find original keyboards and mice for vintage Apple, Sun, and other systems? Say hello to the HIDHopper series. This line of affordable interface adapters is planned to start with USB to ADB, and will expand from there to a variety of vintage systems with impossible to find (or overly expensive) input devices.

Posted on by

BlueSCSI Desktop Hardware Update

The new hardware version has passed my local testing (PM 7300, Beige G3, Mac Portable, initiator mode verification) and the BlueSCSI Distributor Group have started placing orders for it.

As mentioned before, some things are removed. The dedicated USB-C port is gone, as well as the second SD slot (now only full-size like before). And the PCB is back to 2 layers instead of 4, which is probably the largest driver of that cost increase.

Prices for the Desktop version will decrease back to the normal level as soon as the new boards arrive, which are expected the week of the 13th.

Posted on by

Short-Lived Hardware Design

The BlueSCSI Desktop hardware version 2023.09a is going to be very short-lived.

Turns out production costs on this one are rather dramatically more than older designs, and the BlueSCSI Seller Group really doesn’t want to have to raise prices (a good goal). You’ll note that I increased prices for the Desktop model because it really does cost way more to make, and that will decrease back to normal after the new hardware version is available.

I have designed a substantially cheaper to manufacture version which will be hardware 2023.10a. It gives up a few things:
* Dual SD slots will be reduced to one
* No more USB-C port onboard

The Initiator Mode feature will remain intact, don’t worry about that. And the 2023.09a Desktop version will continue to be supported with new firmware releases and such (one binary for all!).

Once the new October hardware version is tested, it’ll be released and start to become available as sellers pick up that design.

Sorry for the confusion, I didn’t expect production costs on the November design to be so crazy high.

Posted on by

BlueSCSI Initiator Mode (And stock update)

You have probably all noticed by now that I’m out of stock of the Desktop BlueSCSI variant. This is due to a combination of working on Initiator Mode support for BlueSCSI hardware, and forgetting to order more of the previous PCB design.

What’s Initiator Mode and why is it kind of a big deal? I’m glad you asked.

Initiator Mode allows BlueSCSI to act as a SCSI Host device. You know how currently BlueSCSI needs a working vintage computer before data can be copied over? Your device (be it a Mac, PC, Amiga, whatever) needs to be bootable so data can be copied onto BlueSCSI. With Initiator Mode you can connect BlueSCSI directly to a target hard drive that needs to be backed up, configure BlueSCSI properly, and it will pull the contents of that drive directly into a disk image on the SD card. A bootable “host system” will no longer be required to take drive backup images.

Why didn’t BlueSCSI support this already? At first I didn’t think it was possible on the Pico stick given the number of additional GPIO signals it seemed to require.

The RP2040 microcontroller exposes several more GPIO signals than the Pico does, because the Pi Foundation used them for things like monitoring and power management. For example GPIO 24 monitors voltage input and GPIO 23 can be used to switch the RT6150 buck regulator chip into a lower power mode. Another pin (GPIO 25) controls the LED. And GPIO 29 is used to block leakage through the ADC3 pin when the 3.3v supply is disabled. So that’s a few GPIO pins gone already on the Pico stick. The Pi Foundation seems to have been desperate to stick to 2×20 pin headers, and they could have switched things around to expose USB over the headers but I digress.

So then how is it possible if we’re missing so many pins? Basically every pin which is connected to the SCSI bus does double-duty. They are all either an input and output signal, or inputs for two different signals.

How can a pin be both an input and an output? With resistors and the LVT/LVTH125 bus buffer chip, that’s how. A typical dual-function pin is structured like this:

This is an excerpt from the schematic showing the ACK signal. This signal when in “Target Mode” (acting like a normal hard drive) needs to be an input, iACK. And in Initiator Mode it needs to be an output. This configuration allows the input bus buffer to speak to the Pico pin (going off to the right) while also allowing the Pico to override that signal and drive the output as necessary.

As shown here, when oBSY is asserted (grounded, 0v), the iACK signal there on the left is buffered to the ack input signal pin through R67 shown above. And when oBSY is not asserted (3.3v) the state of the ACK line is determined by that output pin on the Pico. But wait, you say – you can’t just override ACK all the time! You’re right. This is why there are not one but two jumpers which need to be set to switch BlueSCSI into initiator mode.

One jumper switches which input line is being listened to by a certain GPIO pin (can’t just OR them together or they would collide and cause odd behavior, they must be separate). And the other jumper enables the Output ACK (oACK) signal.

The first production versions of Desktop BlueSCSI which support Initiator mode are in manufacturing now.

Posted on by

BlueSCSI V2 WiFi Instructions

If you choose the WiFi option, instructions on how to set up the DaynaPort emulation can be found here:

https://bluescsi.com/docs/WiFi-DaynaPORT

Please note that you will need to add two new files to your SD card.
First, “bluescsi.ini” which is a plain text file. Its contents will look something like the below. Substitute your WiFi network name and password into the file.

[SCSI]
WifiSSID = "NetName"
WifiPassword = "NetPassword"

The other file you need to add defines the SCSI ID for your emulated DaynaPort device. This can be an empty plaintext file, it does not need any contents. Name it “NEx.txt” where the ‘x’ is your preferred SCSI ID. For example, “NE4.txt”. The above instructions say to use “.hda”, but the file extension is unnecessary currently because BlueSCSI stops reading the filename after NE4 anyway.

If you already have other SCSI hard drives defined on your SD card, don’t use the same ID as one of them or the network device will be ignored.

You must configure both the bluescsi.ini file and the network device file or DaynaPort emulation will not work. Your system might not even boot, because wifi configuration without a network device will hang.

Posted on by

Coming Soon: Mac Portable Adapter

I’ve been contacted by a few people lamenting the Mac Portable BlueSCSI I was selling previously – it’s no longer listed in the shop.

Good news! An adapter is on the way from the PCB manufacturer now. This will allow a standard 50 pin Desktop BlueSCSI to be connected to your Mac Portable, for great retro computing (and battery savings).

UPDATE: The adapter has been released and is in the shop now.

Posted on by

BlueSCSI Brackets and Mac Portable Hybrid News

For those of you with things like the Mac TV, LC 550, and similar edge-connector-style machines, there is an update. I have designed a style of bracket for the F4Lite THT V1.1 BlueSCSI that ought to be compatible, but I need a few testers to verify first. If interested, please contact me using the email on the About page.

On the Mac Portable Hybrid project, things are in motion to start making replacements in larger quantities. I am waiting for a dedicated tester board to be manufactured and delivered which will allow me to test every board before shipping.

Also on the Hybrid Recreation front, I am going to be creating some documentation on things to check before ordering. A ‘system pre-check’ if you will. The hybrid does depend on your Portable’s motherboard being in good shape, and these checks will try to assert that your system is not damaged.

Posted on by

Many Project Updates

It’s been too long since posting here, sorry about that. Many updates are posted to the Tinker Different forum.

BlueSCSI: The F4 XCVR and F4Lite XCVR products are now available. These are intended for use with systems such as Sun, SGI, and others which are natively SCSI2 and often do not work with the original BlueSCSI or my F4 BlueSCSI fork.

I will also work on a mounting bracket which enables XCVR model use with systems such as the Macintosh TV and others that use an edge connector with sliding bracket. The measurements have to be very precise and I don’t have one of these machines, so it’ll be a back and forth with someone that does.

Macintosh Portable Hybrid Recreation: This project is about 80% done. A new revision PCB is on the way which should fix a few issues, and it’s basically time to test this in a real Portable to see what happens. The last challenge is a signal called the “A/D line”. This reports battery level information to the Power Manager chip, and is an incredibly sensitive circuit. If it continues to fight and cause problems, I may replace the A/D circuit with a simpler and less fiddly design. This simpler design won’t be as accurate, but it will allow the Portable to function on both battery and while plugged in.

Backlit Macintosh Portable Display Flex Cables: A new round of these cables has arrived, which needs to be quickly tested and then I’ll put up a listing on this site. Note that I don’t have any of the connectors, and those would need to be moved over from your original cable. I will offer a connector transplant service, which involves sending in the original cable and a small charge for actually performing the operation.

Newton eMate Display Cables: Continuing my trend of recreating flex cables, a design for the eMate has been produced and is in testing. I came across a large set of eMates and will be refurbishing them for sale.

Newton eMate DRAM Upgrade: After the unfortunate failure of my eMate DRAM + Flash project, I pivoted and redesigned for DRAM only. These have a much higher success rate, and will be listed on this site at some point.

Original LC Series Replacement Power Supply: These are power supplies for the LC, LC II, and LC III. This project has stalled for a variety of reasons, from cost to opinions on whether there should be an external power brick or not. I have two designs, one which puts everything internally and another which uses an external power brick. The internal design would cost more, and the design using an external power brick would cost a little bit less. Unsure on the direction to go for the future of the project.

Posted on by

Backlit Macintosh Portable Screen Cable and Product Stock Update

You may recall from awhile back that I have been working on a new screen flex-cable for the backlit macintosh portable. These cable are cracking, delaminating, and reaching the end of their usable lifespan.

Fortunately, my latest cable design works just fine – has been tested in two backlit portables so far. The design needs some basic tweaking to make assembly easier for future orders, and it needs to be wrapped in packing tape to increase durability. But other than that, they work!

The design changes will be made whenever I have time to get back to it.

https://tinkerdifferent.com/threads/recreating-backlit-macintosh-portable-display-flex-cables.567/

Now, the product stock update. I’ve had very little time the last few weeks to work on kits and assembled products. But this upcoming week I will be building as many kits and assembled as possible, and will be working on the main F4_BlueSCSI GitHub repo to improve documentation and make hardware designs more available. So bear with me as I work through the process.

I’m becoming more aware of interest in my Newton / eMate products / projects too, so that’s on the roadmap to get moving again. Trying to do all of this as a solo operation means things will regularly get dropped because I lack the time to do it all.

Posted on by

New Hardware Support For BlueSCSI™

For the last few weeks I’ve been working on porting the BlueSCSI software to the “black pill” F401/F411. Getting close to something usable now (it boots), and it comes with a speed increase.

“Blue pills” will run at about 900k read, 650k write. The black pills run at about 1100k read and 800k write. So, not a huge speed increase but it’s something.

Will be getting some prototype PCBs made for testing in desktops and powerbooks to see if compatibility is different. The higher clock speed and faster response times of the black pills probably mean that timings on the bus have changed, and I don’t really know how well the software complies with standards anyway.

My next targets are probably the STM32L412 and STM32G431, as these are pretty low cost and could be integrated into the board (no more ‘pill module’ required).