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:
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:
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:
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. =)