Hardware Changes and Issues

Today I took some time to:

• reconfigure my hardware to use the 74LS161 counter
• replace the 74LS151 with a 74LS251 multiplexer (same but with 3-state output)
• switch some wires around to account for the Disk ][ sending data MSB first
• make a 2x10 (20 pin) header breakout board so I can access all of the lines from the Unidisk cable

A normal solderless breadboard has a gap in the middle that is too wide for a dual row pin header. The breakout board spans the gap.

While making all these modifications I figured out what change I had previously made to get the input from the disk controller working consistently. I was getting strange output because the multiplexer did not have time to set up the data before being read. Through trial and error, I had inverted the clock signal to the counter. Inverting the clock signal gave a half a cycle difference between the multiplexer selecting the line and the UM232H capturing the data, more than enough time for the data to get set up properly. Once I reduced the transfer size, input started working perfectly. I have now implemented this fix in software by selecting SPI mode 2 which captures data on falling clock edge. Exciting stuff, I know!

However, that wasn't the only problem I temporarily bypassed. Reducing the size of my transfers previously fixed the libmpsse stalling problem. Once I wrote functions to transfer full disk sectors, the stalling problem reared its head again. The transfer buffer of the UM232H is 1kB. A raw Apple II disk sector is 416 bytes. When I convert the sector into my SPI stream it quadruples to 1664 bytes. This is too big for a single transfer to the UM232H. libmpsse is supposed to automatically break this up into several USB transfers. Instead, it is stalling the UM232H for some reason. Even if it was working right, the buffer size is a serious problem. I can't take a break in the middle of transferring a disk sector to get more USB data - the Apple II would certainly indicate a disk error. Somehow, I need to reduce the number of SPI bits I transfer to represent a disk bit. I think I may be able to do 2 SPI bits per disk bit and slow the transfer down a little bit. This will cause the read pulse to be slightly longer than ideal and the time between pulses to be slightly shorter than ideal, but it might still work. Incidentally, this wouldn't be a problem on a microcontroller which would not have to wait for a USB transfer to get more data.