-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mac Plus write Error - same as with piscsi #82
Comments
@predecker That there is the same issue is not that surprising. But this ticket is most likely a duplicate, as far as I can tell. Please see #71. Can you please check whether the work-around (source code patch) mentioned in #71 also works for you? Please use the current develop branch with this patch applied for testing. |
@predecker One more question: Do you have any real SCSI hard drive that works with your Mac? In case you have, which drive model is it? |
I applied the patch from #71, but I get a slightly different result. Copying system files (6.0.8) from floppy to the image works now, but the messages did not disappear completely: I'll do further testing tomorrow. I have to find out how to compare files. So this is a kind of "hack" as you mentioned in the other issue and not according to the standard. I want to share my piscsi between the Mac Plus and a Classic. Do I have to switch between this hacked version and a normal one everytime I switch the Macs? Can you implement a version with a command line switch or do I have to script something to change the executables for that? |
@predecker I am sorry, but I will not implement anything (also not optional) that is not compliant with the SCSI standard. It looks as if the patch in #71 does not work for you anyway, because there are still errors reported in the DATA OUT phase. As explained in #71, s2p (and also piscsi as far as I can tell) only change the REQ line during the data transfer, and they use the timing required by the SCSI specification, i.e. they wait for a bus settle delay before reading the data byte. These are just a few lines of code and, of course, if somebody finds something wrong I would appreciate feedback. This is the respective code in bus.cpp:
Either ACK is not set correctly by the Mac, so that the handshake terminates before all data have been transferred, or the Mac interrupts the transfer by raising the SCSI RST signal, which also terminates the handshake. A wrong handling of the ACK signal or the RST signal being set are the only ways to prematurely terminate the handshake and produce the "Received x bytes" message, which indicates that less bytes have been received than required. |
I have a Apple SC 20 external disk somewhere in my storage, but I don't actually know which disk is inside. I'm sure it's not 20MB, it's bigger. That enclosure worked all the time with the Mac Plus but I didn't trust the harddisk no more, so I bought the rascsi. |
Moin, |
@predecker Are you running s2p on trace level? Only on trace level all releavant messages are logged. There should be either a message about the reset signal having been received, or about a handshake timeout right, before the warning about the problem with the DATA OUT phase. Maybe you can post a small part of your log, in particular the lines right before the DATA OUT warning. |
This block repeats every few seconds: Mar 4 09:38:31 raspi-rascsi s2p[1860]: [2024-03-04 09:38:31.459] [trace] (ID 6) - All data transferred I booted from floppy. As I messed up this image in previous tests, the system is trying to initlalize the image. Took about 5 minutes to "create directory". |
@predecker Your log shows that there is a timeout (> 3 s) while waiting for the ACK signal to change. You can see that 3 s elapse before the timeout is reported from the timestamps in the log.
With the latest issue_82 sources (from some hours ago) the log will also tell whether the error happens when waiting for a signal to be set or to be cleared. You might want to update and re-compile your sources to also collect this piece of information. It's the Mac that controls the ACK line during a data transfer to the board. SCSI2PI/PiSCSI just wait for this signal to change. Obviously the ACK line is not set/cleared as it should. This either means that the Mac does not handle the ACK signal correctly, or that there is a hardware issue that results in the Pi not noticing that the line status has changed. This problem is nothing that can be compensated for by software. |
I thought I run the issue_82 version. I see the ACK line on the SCSI-side staying on a negative potential for 3 seconds on the oszilloscope. It repeats while copying files. |
@predecker This means that the oscilloscope confirms what we see in the logfile. I'm afraid I do not know if negative potential means whether the ACK signal is true or false. In order to get the latest sources, which report the line status waited for from the SCSI2Pi perspective, please run "git pull" and re-compile. Please shut down the service before running make install. There is no need to reboot. After make install you can just re-start the service. Can you please also check the status of the REQ line during the 3 s SCSI2Pi is waiting for ACK to change? During the handshake the Pi manages the REQ line, while the Mac manages the ACK line. |
I mixed up the pins on the connector, forget about the potentials. The ACK and REQ lines are low (0V) active. When the ACK line is low in the 3 second phase, the REQ line stays high. |
This means that we are at the beginning of the handshake for a new data byte. s2p has set REQ and is waiting for ACK to be set by the Mac (lines 150-152 in bus.cpp of the issue_82 branch):
Please correct me if I am wrong. I would like to confirm this with a logfile from the latest issue_82 branch. Can you please provide the respective log? Or is it the other way round, because you say "low active"? The log will definitely help me ;-). |
I don't know what I'm doing wrong, but the log looks identical to the above one to me. Mar 4 11:04:38 raspi-rascsi s2p[2394]: [2024-03-04 11:04:38.275] [trace] (ID 6) - ++++ Starting processing for initiator ID 7 pi@raspi-rascsi:~/scsi2pi $ git status Änderungen, die nicht zum Commit vorgemerkt sind: Ich hab' noch die Änderung aus Issue #71 drin. Soll ich die rausnehmen? |
sorry, wrong language ... :-/ |
:-) Yes, it is important to remove the changes from #71 and use the unmodified issue_82 branch. Please run these commands:
The commit ID displayed should be |
Mar 4 12:57:20 raspi-rascsi s2p[3094]: [2024-03-04 12:57:20.745] [trace] (ID 6) - ++++ Starting processing for initiator ID 7 I see on the oszilloscope that the after some handshake (and transmission I think) the ACK line suddenly drops to low and stays there without any REQ. The ACK pulse (answer to the last REQ) before this drop however is very short compared to the other (normal) pulses. Is there a minimum pulse length defined? I try to add a screenshot from the oszilloscope. |
No need for a screenshot I guess. There is no minimum pulse length. ACK has to stay asserted until REQ has been released by the target. The target signals this way that it has successfully received the current data byte. So this is actually the affected piece of code:
REQ has been set to false by s2p after receiving a data byte, and while s2p is waiting for the Mac to release ACK, s2p times out after 3 s. |
I am not an eletronics expert, but is it completely impossible that there is a termination issue? Regarding the Mac Plus I found this:
|
No, is not impossible. I switched off both term switches on the rascsi board. The Mac was not amused and hung. After a reset the Mac does not see the disk, does not even try to access it. |
Impossible to see a difference between SC20 and s2p. SC20 simply works and there is no 3 second down of the ACK signal. |
Maybe you can monitor the traffice with the scsimon tool (part of PiSCSI). But I am not sure, I have never used this tool. During the REQ/ACK handshake any other signals remain unchanged, at least s2p/piscsi do not change them. If other signals play a role during the handshake this would indicate a cross-talk issue. |
The Classic complained about missing drivers on the SC20 and wanted the "Aktualisierer" to run. |
I opened the 20SC (not SC20, I'm wrong the whole time). It's completely passive. Only a power supply and a fan. Cabling is from the outside connectors to the disk without further electronics. |
I did not think of Apple modifying the drive electronics but the firmware. Like they did for other drives (hard drives and CD-ROM drives) in order to force users to purchase expensive Apple SCSI drives instead of cheaper standard drives. |
I don't think so. In my 20SC is a random Maxtor 200MB disk and I used the enclosure to connect other disks as well. |
Then at least with your setup there does not seem to be anything Apple-specific. With other setups there is, and this is why s2p/piscsi have a custom Apple mode page. Without this mode page some Apple software/drivers do not work because they expect drives with Apple-specific firmware. |
I'm actually trying a different approach. As everone is telling Silverlining drivers are the best for the Plus I prepare an image with that driver with the Classic. I messed up my main image which worked last year, so I have to rebuild it anyway. |
Good luck, please provide feedback when you have tried the other drivers. |
Good morning. A partition table of a PiSCSI created and with Silver Lining formatted image looks like this (notice the 2nd partition name "Macintosh_SL": `pi@raspi-rascsi:~/images $ hfdisk -l testdrei.hda Block size=512, Number of Blocks=20464 |
Well, I'm afraid from the Pi software perspective I don't see anything that can be done. The analysis has shown that the ACK signal is not set by the Mac Plus, at least not by some drivers, when it has to be. The reason for this is unkonwn, but whatever the reason, the software on the Pi cannot compensate for wrong signals on the bus. |
Sounds good. Thanks for your time. |
Thank you for running all these tests. Even though there is no resolution for everything, the actual cause of the problem has become much clearer. |
When creating a new ticket please provide information on your environment.
The Pi type: 3 B 1.2
The Pi OS version (output of 'lsb_release -a' and 'uname -a'):
pi@raspi-rascsi:/var/log $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
pi@raspi-rascsi:/var/log $ uname -a
Linux raspi-rascsi 6.1.21-v7+ #1642 SMP Mon Apr 3 17:20:52 BST 2023 armv7l GNU/Linux
3.0.0
Mac Plus 4MB, System is 6.0.8 from HD20_512-1GB-MacPlus-6+7.hda downloaded from somewhere
Describe the issue
when writing to an image the log says
Mar 3 20:10:12 raspi-rascsi s2p[852]: [2024-03-03 20:10:12.174] [warning] (ID 5) - Received 32 byte(s) in DATA OUT phase, command requires 512
Mar 3 20:10:15 raspi-rascsi s2p[852]: [2024-03-03 20:10:15.266] [warning] (ID 5) - Received 169 byte(s) in DATA OUT phase, command requires 512
Mar 3 20:10:18 raspi-rascsi s2p[852]: [2024-03-03 20:10:18.602] [warning] (ID 5) - Received 467 byte(s) in DATA OUT phase, command requires 512
Mar 3 20:10:21 raspi-rascsi s2p[852]: [2024-03-03 20:10:21.651] [warning] (ID 5) - Received 57 byte(s) in DATA OUT phase, command requires 512
same behaviour with piscsi in issue #656 ...
PiSCSI is the only device on the bus, it ran flawlessly on a Mac Classic last time I used it. That's a year ago however.
Both termination switches are on the "on" position.
The text was updated successfully, but these errors were encountered: