Search results

Tested putting a 10/100 switch between this CS II card and my gigabit network, no change in download speeds from Macintosh Garden. ~100kB per second on the 6400 CS II running 7.6 using Netscape ~150kB per second on the 6400 CS II running 9.1 and iCab ~150kB per second on my 7300 original PCI...

Almost certainly, yes. 100 megabit Ethernet would probably saturate NuBus entirely - though it's a 660, very nice 68k machine overall. If you could just download something "large" from the Maintosh Garden like the Tie Fighter install sit file (over 200 megabytes total, don't need to pull it...

It's 150KB per second, kilobytes (not bits). Maybe something is up with my switch, just haven't been able to run down the networking permutations yet. I do have an older 10/100 switch that could be placed between the device and upstream to see if it helps - was hoping the native 100 megabit...

This is a two-layer PCB. The extra-long length to match the original doesn't add a lot to the overall cost when made in larger batches. Adding a second half that sits where the bracket goes is complexity that I would like to avoid. Help me understand what the TAM/CSII riser is for - two PCI...

This is a stealth project I've been slowly working through for some time now. With Comm Slot II Ethernet cards being hard to come by, and often for high prices, it seemed like a decent target for recreation / re-engineering. My approach here was originally going to be "remake the official...

Looking at the schematic, PDS pins 2 through 4 on columns A, B, and C are all the main 5v source. There aren't any control signals mixed in over there to cause problems. This gives me one idea for why it might cause problems: accidental inversion of the intended pin. If the measurement was...

A new version of the BlueSCSI V2 Centronics 50 Pin is now available: https://androda.work/product/bluescsi-v2-centronics-50-pin-shorter/ Like it says in the URL, this is literally a shorter version of the previous design. Similar to the smaller DB25, it's over 1cm shorter than the prior version...

It's quite unlikely that use of the battery eliminator would cause different BlueSCSI behavior. As has been mentioned, it acts as a forever-charged battery. The Portable's power system is designed to run off the battery anyway, with the power adapter acting only to recharge the battery when...

The pull resistors situationally hold those pins high. It's expected that both of them are able to transition between high and low as needed. When the Pi Foundation created the RP2040 microcontroller they made one design decision which I think is completely wrong. All GPIO pins are "pull...

Just to double check, you are referring to GPIO #27? That GPIO pin is controls the SCSI BSY signal and is not expected to have a consistently high or low voltage. The SCSI protocol will cause that pin to bounce around from high to low rapidly. The only place to reliably check 3.3v regulation...

Hmm, do you mean the 3.3v line "slowly rises from 0 to 3.3v" like 0.5v, 1v, 2v, etc. or that it rapidly jumps from 0 to 3.3 but it takes a long time to come back on? I've done some testing over lunch and discovered a very interesting behavior on the Portable. If you put it to sleep, wait a...

I don't know what causes this presumption. The BlueSCSI PCB does not connect to the Pico's USB data pins on a 2022.12a hardware version. The only common connection is ground, as the USB ground flows through to the Pico's ground pins. This situation has come up a few times in the BlueSCSI...

5 flashes means the Pico is unable to connect to the SD card, as mentioned in the troubleshooting document. One important note is that the SD card is powered from the Pico's 3.3v regulator. So when your standard Pico's regulator started generating over 4 volts, the SD card may have been...

Your repeated at-mentioning me and Eric on this issue does not increase its visibility - both of us are already watching this thread. Paolo's comment asking for help with the non-functional BlueSCSI was two days ago. Not a week, not a month, two days. Given that people have responsibilities...

I've been totally unavailable the last few days, but the previous post saying the Picos "get hot" when plugged in very strongly pointed to hardware issues on the Pico units. The added 4.7k ohm resistors are unlikely to cause these hardware failures, as later BlueSCSI versions use exactly this...

That's really quite strange. I just modified one of my units based on the instructions here and it boots right up on my Portable. Tested sleep, and that works too. It's even a 2022.12a like yours. Don't have much to go on for why this wouldn't work properly.

With the Portable fully "turned off" there should be no SD card access going on. It should be relatively safe to pull the SD card and manipulate files / images in this scenario because there's no drive activity.

A modification such as the below would probably work for your Portable-specific board. Take the voltage from PDS A2, pass it through a diode, and connect to the side of C16 as shown. No additional grounding should be necessary, just this one connection. Though I suggest checking with the...

This is almost certainly because your BlueSCSI is an older hardware revision which is known to have issues waking from sleep. A fix is documented here: https://github.com/BlueSCSI/BlueSCSI-v2/wiki/Hardware#hardware-tweaks--fixes JDW has tested these changes on his Portable-specific fork PCB...

Actually a great many people use the DB25 style specifically for this kind of usage. Plug it in when enjoying your vintage system, and unplug or put away when finished. Allows use of a single BlueSCSI across many systems. In terms of "how best to avoid the BlueSCSI turning off in a sleeping...