ScutBoy
Well-known member
$WORK has a data center in Cedar Falls. They were having trouble with Internet connectivity yesterday and today. Our other location is OK
Hope things clear up for you soon!
-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
RaSCSI Development Thread
- Thread starter K55
- Start date
Hope things clear up for you soon!
sfiera
Well-known member
How much support do aliases have for AFP? They can link to AFP shares, right?
On the Pi side, you could have an AFP share for every USB stick attached. You could then augment that that with another share containing aliases to each of those USB stick AFP shares. This would be pretty good already, though you could also add some MacOS-side code to watch that directory and mount new aliases when they appear.
There’s no SCSI in that design, so it’s not necessarily relevant to this topic, but I think it’s better than a a SCSI solution, which could run into issues with volume sizes dependent on the model of Mac in question.
On the Pi side, you could have an AFP share for every USB stick attached. You could then augment that that with another share containing aliases to each of those USB stick AFP shares. This would be pretty good already, though you could also add some MacOS-side code to watch that directory and mount new aliases when they appear.
There’s no SCSI in that design, so it’s not necessarily relevant to this topic, but I think it’s better than a a SCSI solution, which could run into issues with volume sizes dependent on the model of Mac in question.
techknight
Well-known member
SCSI still exists here, as that is providing the network interface on Macs which do not have or incapable of having internal Ethernet adapters.
techknight
Well-known member
Haha, my immediate thought is having a kernel driver that does the SCSI bitbanging on the GPIO, but it presents itself in the Linux side as "yet another network adapter", which basically creates a logical bridge between the Mac over SCSI, and Pi Linux. This gives us the ability to bind network services to that interface such as DHCP, AFP, etc, etc, and the Mac just sees it
As far as software can fix anything, Well... thats mostly true. I havent seen it "fix stupid" though. Still looking for that fix.
cheesestraws
Well-known member
No need for a kernel driver. Run it in userspace on the other end of a tap interface. That can then be bridged to the ethernet interface on the pi for "real network", and services can just bind to the tap driver.Haha, my immediate thought is having a kernel driver that does the SCSI bitbanging on the GPIO, but it presents itself in the Linux side as "yet another network adapter", which basically creates a logical bridge between the Mac over SCSI, and Pi Linux. This gives us the ability to bind network services to that interface such as DHCP, AFP, etc, etc, and the Mac just sees it
That said, for HFS, I think treating them as disc partitions according to my previous plan is perhaps more sensible; that way you could, for example, boot off a USB stick which would be entertainingly ridiculous.
cheesestraws
Well-known member
When these boards are done, I'm planning on taking a few days off work just to hack on them a bit, honestly
uyjulian
Well-known member
A SCSI Manager API shim on the Pi side would be nice so you don't have to learn 2 different APIs…
https://developer.apple.com/library/archive/documentation/mac/pdf/Devices/SCSI_Manager.pdf
https://developer.apple.com/library/archive/documentation/mac/pdf/Devices/SCSI_Manager.pdf
Code:
// Constants
enum {
/* TIB instruction opcodes */
scInc = 1, /* transfer data, increment buffer pointer */
scNoInc = 2, /* transfer data, don’t increment pointer */
scAdd = 3, /* add long to address */
scMove = 4, /* move long to address */
scLoop = 5, /* decrement counter and loop if > 0 */
scNop = 6, /* no operation */
scStop = 7, /* stop TIB execution */
scComp = 8, /* compare SCSI data with memory */
/* signature values */
sbSIGWord = 0x4552, /* driver descriptor map signature */
pMapSIG = 0x504D /* partition map signature */
};
// Data Types
struct SCSIInstr {
unsigned short scOpcode; /* operation code */
unsigned long scParam1; /* first parameter */
unsigned long scParam2; /* second parameter */
};
typedef struct SCSIInstr SCSIInstr;
struct Block0 {
unsigned short sbSig; /* device signature */
unsigned short sbBlkSize; /* block size of the device*/
unsigned long sbBlkCount; /* number of blocks on the device*/
unsigned short sbDevType; /* reserved */
unsigned short sbDevId; /* reserved */
unsigned long sbData; /* reserved */
unsigned short sbDrvrCount; /* number of driver descriptor entries */
unsigned long ddBlock; /* first driver’s starting block */
unsigned short ddSize; /* driver’s size, in 512-byte blocks */
unsigned short ddType; /* operating system type (MacOS = 1) */
unsigned short ddPad[243]; /* additional drivers, if any */
};
typedef struct Block0 Block0;
Partition {
unsigned short pmSig; /* partition signature */
unsigned short pmSigPad; /* reserved */
unsigned long pmMapBlkCnt; /* number of blocks in partition map */
unsigned long pmPyPartStart; /* first physical block of partition */
unsigned long pmPartBlkCnt; /* number of blocks in partition */
unsigned char pmPartName[32];/* partition name */
unsigned char pmParType[32]; /* partition type */
unsigned long pmLgDataStart; /* first logical block of data area */
unsigned long pmDataCnt; /* number of blocks in data area */
unsigned long pmPartStatus; /* partition status information */
unsigned long pmLgBootStart; /* first logical block of boot code */
unsigned long pmBootSize; /* size of boot code, in bytes */
unsigned long pmBootAddr; /* boot code load address */
unsigned long pmBootAddr2; /* reserved */
unsigned long pmBootEntry; /* boot code entry point */
unsigned long pmBootEntry2; /* reserved */
unsigned long pmBootCksum; /* boot code checksum */
unsigned char pmProcessor[16]; /* processor type */
unsigned short pmPad[188]; /* reserved */
};
typedef struct Partition Partition;
// Functions
pascal OSErr SCSIReset (void);
pascal OSErr SCSIGet (void);
pascal OSErr SCSISelect (short targetID);
pascal OSErr SCSISelAtn (short targetID);
pascal OSErr SCSICmd (Ptr buffer, short count);
pascal OSErr SCSIMsgIn (short *message);
pascal OSErr SCSIMsgOut (short message);
pascal OSErr SCSIRead (Ptr tibPtr);
pascal OSErr SCSIRBlind (Ptr tibPtr);
pascal OSErr SCSIWrite (Ptr tibPtr);
pascal OSErr SCSIWBlind (Ptr tibPtr);
pascal OSErr SCSIComplete (short *stat, short *message, unsigned long wait);
pascal short SCSIStat (void);
Last edited by a moderator:
NoTrueSpaceman
Active member
Hi folks,
Just joined b/c I'm in the middle of restoring a Mac IIsi. Two questions:
I'm looking forward to contributing to the project, but I want to make sure I'm not barking up the wrong tree, hardware-wise. Thanks!
Just joined b/c I'm in the middle of restoring a Mac IIsi. Two questions:
- Has anyone used RaSCSI as a boot disk? The Quantum I have is corrupt, and I've had no luck making 6.0.8 boot floppies (either b/c the drive is bad or I'm doing it wrong.) I'd like to use RaSCSI as a boot disk instead of SD2SCSI for a bunch of reasons, so I want to know if it works as a boot disk specifically.
- Which PCBs should I be using?
LandoGriffen's version 1.5 available here: https://github.com/akuker/RASCSI/tree/master/hw/Dual_Connector_RaSCSI seems like the best bet right now: I can assemble it myself, it has the 25pin DIN I want, it's been shown to work, I'm familiar with KiCAD, and the gerbers are already there. But is it going to be obsoleted?
- There's this one, but I can't seem to order it https://dirtypcbs.com/store/designer/details/817/5996/rascsi-din-zip
- There's this one, but it looks like it has the wrong connector https://dirtypcbs.com/store/designer/details/lagonium/6236/rascsi-dip
- There are references to K55's, but I'm unsure of what CAD it's in (Eagle?) and if it's not going to be useful in the long-run. https://github.com/fran-cap/RASCSI-68kmlaver/tree/master/design files
I'm looking forward to contributing to the project, but I want to make sure I'm not barking up the wrong tree, hardware-wise. Thanks!
aperezbios
Well-known member
I'd definitely be interested in hearing your reasons, if you wouldn't mind. Are you aware that the firmware for SCSI2SD (not "SD2SCSI") is fully open-source?
You can view the contents of the repo at http://www.codesrc.com/gitweb/index.cgi?p=SCSI2SD.git;a=summary
...and anyone can fetch it via a Git clone:
Code:
git clone --recursive git://www.codesrc.com/git/SCSI2SD
landoGriffin
Well-known member
1) I have successfully booted my Quadra 840av with the “1.5” version without any trouble. I would imagine it should be fine with a IIsi.
2) The “1.5” one is what I’ve been using for the past few weeks. I don’t think it will be considered obsolete by any means. The 2.1 version is the latest one. There are ton of very small surface mount parts that you probably can’t do yourself. In a week or two, I should have a handful of 2.1s to share with interested folks. Within a month or two, I should have plenty to distribute.
if you do order a 1.5, keep in mind that you will need to do a cut/jump to get it to work (detailed instructions on github)
Im looking forward to you contributing! Please don’t hesitate to ask questions or raise issues on the Github repo. This is my first community open source project, so I’m still not sure about etiquette for doing pull requests and such. I’m used to just committing whatever I want to the master
landoGriffin
Well-known member
I’m curious what your reasons are too
For me, SCSI2SD is “done”. I personally wanted a project that could combine my love of Macs, interest in embedded software and Raspberry Pis and hack away at something.
This isn’t intended to “compete” with SCSI2SD in any way. Hopefully it’s just a fun project to keep us from going crazy during a worldwide pandemic.
NoTrueSpaceman
Active member
Great! Thank you for the help. I'm going to order the parts and boards today for the 1.5 version. I suspect I'll end up with extras, although I need more than one (for other projects).
My machine's floppy drive literally lost its magic smoke today so I'm really with no way to boot my Mac.
I just cloned the repo and I'll see what I can figure out while waiting for access for to the hardware.
NoTrueSpaceman
Active member
@landoGriffin Have you tried mounting a right angle male DB25 to the bottom of the "1.5" PCB to avoid having to use a cable? It's late but I think that should flip the pins correctly, right?
Scouring Mouser for parts for another project has kind of scrambled my brain. :scrambled:
landoGriffin
Well-known member
I believe you should be able to do that, though I haven't tried.
Also - if you want the 1.5.... Give me a couple hours, and I'll make a "1.6" that just has the one fix for Issue #10. (I fully acknowledge that the "2.1" version is nearly impossible to assemble by hand)
landoGriffin
Well-known member
@NoTrueSpaceman - I just committed version "1.6", which only has issue #10 fixed. I'd encourage you to review out the Schematic and Gerber files before you order them.
https://github.com/akuker/RASCSI/tree/master/hw/rascsi_1p6
https://github.com/akuker/RASCSI/tree/master/hw/rascsi_1p6
Is this (on the hardware side) capable of being a SCSI host?
SCSI was common on samplers (musical instruments) from the late 80's to the late 90's as a way of transferring audio directly between a computer (which would act as the host) and the samplers memory, using a SCSI-based protocol called SMDI. I think many people would be interested in a Pi that could do this trick.
SCSI was common on samplers (musical instruments) from the late 80's to the late 90's as a way of transferring audio directly between a computer (which would act as the host) and the samplers memory, using a SCSI-based protocol called SMDI. I think many people would be interested in a Pi that could do this trick.
NoTrueSpaceman
Active member
Awesome thanks! I should have all the parts to make a couple boards in a few weeks. Once I get some working hardware with this rev, I’d like to have a go at a version with easier to obtain bus transceivers (as mentioned in the wiki). Any suggestions on which issues in the repo to take a look at that doesn’t actually require anything but an RPi?
landoGriffin
Well-known member
landoGriffin
Well-known member
There's quite a bit of discussion about this earlier in this thread. The 74LS641 is the only one on that list that *really* meets the SCSI spec.
I tried the 74LS245, and it seems functional. But, it technically doesn't sink enough current, so it could have issues in some configurations.
I ordered a boatload of 74LS641's directly from TI, so I'd be happy to send you a couple if you're having trouble finding any.
I'm currently in the middle of issue #16, which will change a lot of code. I'm hoping to get that committed tomorrow. (Hopefully!!)
I'd welcome for you to set up the web interface. You don't really need the hardware to use that. You should still be able to start the RaSCSI service.... it just won't do anything.
Issue #4 could also be done without a Pi. My hesitation would be that Issue #16 might cause a bunch of rework for you :-(
Also - any suggestions on how to make the wiki easier to follow/understand would be very much appreciated!
I'm trying to clean up a few pages here and there. If anyone else wants to pitch in, it's much appreciated.
Similar threads
