• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

TashTwenty: Single-Chip DCD (Hard Disk 20) Interface

warmech

Well-known member
I did not. Just tested.
Well, fudge - I was hoping it was just me, lol. Either way, having HD20 access on a Classic or SE (even if limited to one "volume") is still incredibly valuable. I can't express how grateful I am that you got this running to where it is. With the FloppyEmu potentially no longer being available in the near future, this will help fill a decent sized gap for storage on older Macs.
 

warmech

Well-known member
Bad news on that score, PIC16F1825s don't seem to be a whole lot easier to find... these supply chain issues are hitting everything.
Wow, you weren't kidding - Jan 2023 is the expected in-stock date at Mouser for the one I ordered originally. Glad I bought a few just in case I fried one.
 

tashtari

Well-known member
TashTwenty is getting a rewrite for a new chip! This time around it's the PIC16F1704, a newer PIC that contains three of Microchip's "Configurable Logic Cells", some really neat little bits of circuitry. Using only the three CLCs in the 1704, I've been able to do three useful things:

(1) First and foremost, I've decided I'm not satisfied with TashTwenty only emulating multiple DCDs on the Plus and 512ke and I've been able (I believe) to address this issue. The phase lines as used by DCDs have the useful property that when PH2 is high, RD is always the same logic level as PH1, and when PH2 is low, RD is either in data mode or in sense mode (reading the !HSHK handshake line), making it possible to use a single CLC in "AND-OR" mode to drive RD, comme ça:
1649618294916.png
This will allow the PIC to respond to changes on the phase lines effectively instantly, which should take care of any issue with detection by newer Macs. But what's "data" in that diagram, you may ask? Well, that brings me to...

(2) I've been able to leverage the PIC's USART in its little-used synchronous mode to drive the fourth input to the CLC in NAND mode:
1649618562280.png
With DT set up on the falling edge of CK and clocked out on the rising edge, data is low only when DT and CK are both high, meaning we get one falling edge for each 1 bit clocked out, which is exactly the protocol that the IWM expects on its RD line. No more bitbanging, I can just dump bytes to the USART! Only pain is that I have to reverse them because for some reason the USART only works LSB to MSB and the IWM works MSB to LSB... but this can be done easily with a lookup table and the increased flexibility is more than worth it.

Bonus, because the last bit sent on the DT line remains there, I can use the USART for the !HSHK line, too - just send an 0x00 byte to drive it high and an 0x80 byte to drive it low.

(3) That leaves us with two unused CLCs. What to do with them? Could they be used to spare me the burden of writing a bitbanged receiver for Mac-to-DCD IWM protocol? As it turns out, yes, they can! Put both CLCs in D flip-flop mode and connect one to the other and what do you have but a two-bit shift register:
1649619148376.png
Combining this with some timers and a creatively-written interrupt handler, I'm able to shift off the job of reading half the bits from the Mac to hardware, leaving time for mainline code to execute as though the PIC had a specially-made IWM receiver peripheral. No more bitbanging on the output or input sides, and I'll be able to stream data directly from the Mac to the memory card (and vice-versa) without it having to sit in memory first, so a small speed increase will be realized, too.

So... where does this all leave folks who've done builds already? Not to worry! The new PIC also allows peripherals to be switched between pins as desired instead of hard-wiring them to one pin as PICs did in the past, which means that this new chip will be a pin-for-pin drop-in replacement for the old PIC16F1825 in all boards, current and future. Another advantage: as of the time of this writing, it is currently still possible to purchase PIC16F1704s, while PIC16F1825s seem to be out of stock every-darn-where with more not showing up until 2023.

I want to stress that this new firmware for the PIC16F1704 is not done yet, I've only proven the viability of the important bits so far. However, I've decided to put my money where my mouth is and order fifty PIC16F1704s as a small amount of insurance against them going out of stock in the future, which I will be happy to resell at cost (and pre-programmed) to interested builders.

So now I'm committed. Watch this space. =)
 

tashtari

Well-known member
(Oh, and if you don't mind six legs of the DIP hanging off the bottom of your socket, it's possible to put TashTalk on the 1704 as well...)
 

tashtari

Well-known member
Just for funsies, this morning, I clipped onto the !ENBL2 leg of the SWIM chip in my LC II and confirmed that its ROM does actually support the HD20, even if there isn't an easy way to connect to it. Happy to say this proves the usefulness of that extra jumper on @demik 's board for anyone who wants an internal HD20 on their LC II. =)
 

mg.man

Well-known member
this is where we are - multiple partitions and chaining on the 512ke and Plus, one partition only on everything else (so far).
NO idea if this is at all related... but saw this post in another thread...
 

tashtari

Well-known member
NO idea if this is at all related... but saw this post in another thread...
I'm not as familiar with the particulars as some, but the long and the short of it is "partition tables". SCSI devices have them, but DCDs don't - they're more or less treated as really big floppy disks, hence why TashTwenty needs to be the one to parse the partition table.
 

tashtari

Well-known member
Well, I have further news. It's good news, it just makes me want to go take a nap. =D

It seems that it was never a problem with the PIC16F1825 not responding fast enough to the phase change lines. It is, instead, the behavior of the ROM that I was wrong about. On the Classic II, at least, and probably on other machines newer than the Plus, the following is true. If you have one DCD, it will recognize it. If you have two chained DCDs, it will recognize both. If you have three or more chained DCDs, it will only recognize the first.

Fool that I am, I was testing with cards that were set up with three and four partitions. All you have to do, this works with the existing PIC16F1825 firmware just fine, is have only two partitions on the MBR that have the type code 0xAF for HFS. This will cause TashTwenty to emulate only two devices, and your newer-than-Plus machine will recognize them both. Some experimentation is still necessary to nail down the exact maximum number of chained DCDs supported by each machine, but at least now I know it wasn't a problem with my firmware.

I will probably continue with writing the firmware for the PIC16F1704, it's far enough along that it'd be a shame not to finish it, and the PIC16F1704 has the distinction of not being the biggest device in its class (the PIC16F1705 is the same chip with more SRAM and Flash) so it's a bit less desirable and thus a bit more likely to stay in stock.

So yeah. I was right all along, it was the Mac that was wrong. =D

Postscript: Just for posterity, the leg of R10 toward the back of the real HD20's controller board connects to its !ENBL signal from the Mac.
 

tashtari

Well-known member
The PIC16F1704 firmware is coming along nicely. I haven't yet written the code to handle writes, but it boots and runs programs in read-only mode, streaming data directly off the card without needing to hold it in SRAM first.

It's also got a couple new features:

(1) Custom icons! The default icon will still be the hard drive with the gothic 'T' on it, but the firmware now supports a collection of up to 254 icons being loaded on the card, and your four devices can each use a different one. You, too, can have an HD20 represented by the smug face of the late Steve Jobs:

1650234642769.png

(2) Blink codes! I didn't like that my first question for anyone having trouble with TashTwenty had to be "do you own a logic analyzer", so I decided to do something about it. Now, when the firmware has a failure to launch, it blinks out a trouble code on the !CS pin, and all you need to view it is an LED and a resistor.

Regarding the first one, I'd like to put together a reference TashTwenty image, i.e. "write this to your SD card and you know your MBR isn't set up wrong", and I'd like that image to include a selection of icons for users who don't want to go through the fuss of setting up their own on the card. Does anyone know of a source of monochrome 32x32 icons that'd be good for the purpose? I have a few I collected back in the 90s, but they're mostly cartoon characters (and the Grateful Dead bear, for some reason)...
 

tashtari

Well-known member
Would the PIC16F1704 work with your first pcb-design, shown on the first pages of this thread?
Yup, it's pin-compatible, so it will work on every PCB design that the PIC16F1825 does with no changes necessary beyond popping the chip out and replacing it. (Assuming, of course, that you've installed a socket, which you should.)
 

tashtari

Well-known member
I was having some trouble with slower cards and did a fairly significant upheaval on some parts of the code, now the 1704 firmware does a clever job of concealing slower cards' random programming delays (which can be up to a whopping 200 ms in length, per the spec) in the time between the Mac waiting for us to acknowledge phase changes. I feel really quite good about the 1704 controller firmware.

Anybody who wants a programmed PIC16F1704, I can hook you up for $1.75 each (approximately my cost), plus shipping, just message me. If you got something from me with a PIC16F1825 before, I'll only charge shipping.

If there's enough interest, I can see about getting some more kits made up...
 
Top