General Category > LisaList2
An Arduino-Based Parallel Port Hard Drive Troubleshooter
AlexTheCat123:
Great news! I just finished the code for the ProFile emulator and I plugged the device into the Lisa for the first time (I was using a USBWidEx instead of an actual Lisa to test it up until this point) and it was actually able to boot BLU off the SD card! I was guessing that I'd have to fiddle with the timings some more to get the Lisa to communicate with my emulator properly, but it actually worked first try! Now it's just a matter of trying to install LOS on it to see if it still works with a much more complex operating system!
stepleton:
Did it work? :)
If not, did you run into the issue where the ProFile sometimes has to see a $55 on the bus from the Apple even though the Apple doesn't cycle ~PSTRB?
If so, that's the same thing I ran into after moving Cameo/Aphid from UsbWidEx over to the Lisa. The boot ROM cycles ~PSTRB for those $55 bytes, but the Office System is a different story...
AlexTheCat123:
MacWorks XL 3.0 and MacWorks Plus worked great when I tested them, but unfortunately the Office System did not. I copied an image of LOS 2.0 from my Cameo/Aphid over to my device and after a few seconds of trying to boot the Lisa just restarts itself. I tried LOS 3.0 as well and it just gives a 10707 (Cannot initialize the File System volume) error when I try to boot it.
I don't think the issue has anything to do with the cycling of STRB with a $55 on the bus because my code isn't paying attention to the strobe when checking for the $55. It only looks at the strobe when receiving the command bytes, sending or receiving data for a block, and sending the status bytes.
I tried booting into the LOS installer and initializing my emulated ProFile, but it always fails with an error saying something to the effect of "The Lisa can't write to the disk." The logic analyzer seems to show that reading from the disk is working fine, but that when writing to the disk the Lisa never lowers CMD after sending the command bytes for some reason. The Lisa then proceeds to try the write operation again two more times, with the same result each try, before giving up and showing the error message.
I also realized that I somehow completely forgot about the parity signal and it just stays low all the time. USBWidEx and the other operating systems that I've tried on the Lisa don't seem to care about this and work fine, but maybe the Office System is different?
stepleton:
Interesting! Well, I'm sure you'll track down the error soon!
I don't actually know if the Office System is worried about parity when it reads and writes (I've never checked), but the OS does have two obvious error codes relating to parity, one for reading and one for writing:
662 Parity error while sending command or writing data to ProFile
663 Checksum error or CRC error or parity error in data read
It's interesting that the ProFile is responsible for computing parity on the bus no matter which device on either side of the cable is putting bytes there. A lookup table is an easy way to compute parity, but I'm guessing that you might find it irritating to spend 256 bytes of your available 8K. For computing parity on data from the Lisa, Cameo/Aphid uses a method described here:
http://graphics.stanford.edu/~seander/bithacks.html#ParityParallel
note the text talking about how that method "may be optimized to work just on bytes" by omitting some operations.
AlexTheCat123:
I figured out why the Lisa would sometimes never lower CMD after sending the command bytes. It appears that the Office System will sometimes start a handshake in order to make sure that a drive is there, but never finishes it once it's satisfied that the drive is alive and well. Also, when the LOS installer reads the spare table to determine the drive type, it only cares about the identifying information at the beginning and not the table of spared blocks itself, so it just stops sending stobe pulses after it gets the data that it wants and expects the drive to time out and get back into its idle state, ready to receive the next command. I had my timeouts set to around one second, so I was waiting way too long and was missing subsequent commands from the Lisa. Unfortunately, making the timeouts a lot shorter didn't fix the "Lisa can't write to the disk" error message, but at least we're not missing commands anymore while waiting around in exorbitantly long timeouts!
At this point, I'm guessing that it probably has something to do with the parity since I don't really see much else that could be wrong.
--- Quote ---A lookup table is an easy way to compute parity, but I'm guessing that you might find it irritating to spend 256 bytes of your available 8K.
--- End quote ---
Unfortunately, I think a lookup table is going to be my only option here. I'm already significantly pushing the limits of the Arduino's processing power and the overhead of adding a routine to calculate parity would almost certainly cause us to start missing strobe pulses. Heck, even the lookup table might be too slow. If it is, I might have to add an LS280 to my PCB to handle all of the parity stuff for me.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version