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

[Tashtari]

While we're about it, this might be a good time to document the firmware's blink code mechanism. This can help give some insight into why the TashTwenty firmware might not be behaving as expected.

Locate the !CS pin (pin 7) on the PIC16F1704. The dimple on the top of the DIP indicates pin 1 and the numbers go anticlockwise from there. If the firmware encounters an issue in initialization, this pin will repeatedly transmit an 8-bit trouble code in the form of eight pulses on a 2-second period, separated by 5 seconds. The pin is normally high, and going low for 0.5 seconds signals a 1, while going low for 1.5 seconds signals a 0. Example:



This is the firmware blinking out a code of 0b00001011, or 0x0B.

If you have a multimeter that samples fast enough (or an oscilloscope, natch), you can make out the width of the negative pulses using that. Otherwise you can use the lower tech solution of an LED and a resistor. Any LED should do as long as it doesn't have a forward current of more than about 20 mA. What you want to do is connect the anode of the LED to +5V and the cathode of the LED (through an appropriately rated resistor) to !CS. This will cause the LED to turn on when the line pulses low and allow you to read the code.

That you can see the pin blinking at all indicates that the firmware is alive and the chip isn't fried. A code of 0x01 means that the card isn't responding at all, and as far as the PIC can tell, it might as well not exist. A code of 0x0D means that the card doesn't contain a valid MBR. A code of 0x11 means that the MBR is valid but contains no partitions that the firmware can use. Other codes indicate low-level failures at various points during initialization of the card and reading of the MBR.

 

[Zhinü]

While we're about it, this might be a good time to document the firmware's blink code mechanism. This can help give some insight into why the TashTwenty firmware might not be behaving as expected.

Locate the !CS pin (pin 7) on the PIC16F1704. The dimple on the top of the DIP indicates pin 1 and the numbers go anticlockwise from there. If the firmware encounters an issue in initialization, this pin will repeatedly transmit an 8-bit trouble code in the form of eight pulses on a 2-second period, separated by 5 seconds. The pin is normally high, and going low for 0.5 seconds signals a 1, while going low for 1.5 seconds signals a 0. Example:

View attachment 42113

This is the firmware blinking out a code of 0b00001011, or 0x0B.

If you have a multimeter that samples fast enough (or an oscilloscope, natch), you can make out the width of the negative pulses using that. Otherwise you can use the lower tech solution of an LED and a resistor. Any LED should do as long as it doesn't have a forward current of more than about 20 mA. What you want to do is connect the anode of the LED to +5V and the cathode of the LED (through an appropriately rated resistor) to !CS. This will cause the LED to turn on when the line pulses low and allow you to read the code.

That you can see the pin blinking at all indicates that the firmware is alive and the chip isn't fried. A code of 0x01 means that the card isn't responding at all, and as far as the PIC can tell, it might as well not exist. A code of 0x0D means that the card doesn't contain a valid MBR. A code of 0x11 means that the MBR is valid but contains no partitions that the firmware can use. Other codes indicate low-level failures at various points during initialization of the card and reading of the MBR.

Unfortunately, despite being a hobbyist, I don't think I have any spare resistors that could be used for this purpose. I assume without a resistor would fry the chip. Don't have a O-Scope or a fast enough multimeter. I'll check around and see though.

 

[Tashtari]

Wrote that image to a floppy disk. The system does detect drive now when I use my HD20 disk, but then gets stuck on the "Welcome To Macintosh" screen and flickering. When booting a disk without the HD20 program, it does not pop up at all on Finder nor does it request to be formatted. Running the HD20 Test results in the activity LED flashing once, then saying "Unit Fails to Hard_Reset."

Is this a machine using the 64K ROM (the Welcome to Macintosh dialog has a drop shadow instead of a double border)? If so, that may explain the flickering, that image has System 6.0.8 on it, which may not play nice with the older ROM if the HD20 Startup disk is trying to boot it. That it won't work with HD20 Test isn't surprising, HD20 Test uses loads of undocumented commands that the firmware more or less just fakes responses to. Do you have any other machines to test on besides the 512K?

 

[Tashtari]

Is this a machine using the 64K ROM (the Welcome to Macintosh dialog has a drop shadow instead of a double border)? If so, that may explain the flickering, that image has System 6.0.8 on it, which may not play nice with the older ROM if the HD20 Startup disk is trying to boot it.

Now that I look at the movie you took, yeah, that's what I think is happening. The 512K only supports up to system 4.1. Give me a few, I'll cook up an image that has 4.1 on it that you can test with...

 

[Zhinü]

It works with my IIsi! Seems like everything is functional. Toss me that HD20 image when you get it. I don't really know how to set up these disks myself. For example, would I edit the icon image by editing the partition data?

 

[Tashtari]

Here's System 4.1 on a card-ready image.

 

[Tashtari]

It works with my IIsi! Seems like everything is functional.

Excellent!

would I edit the icon image by editing the partition data?

The custom icon functionality is a bit strange in how it works, but we're dealing with a very simple little microcontroller here. =) Custom icons work like this:

MBR has a single byte in each of the four partition entries that denotes the partition type. 0xAF is the standard value for an HFS partition. The TashTwenty firmware will always recognize partitions with an 0xAF partition type and emulate them as DCD devices with the default icon (hard drive with a gothic letter T). If the partition type byte is anything else besides 0xAF or 0x00 (the latter denotes unused space), the firmware will look at that sector on the card and see if the first 256 bytes of it are "ICONICONICON" over and over. If so, then it will use the second 256 bytes as a 32x32 monochrome icon followed by its mask. If not, it will assume the partition is some other type of data and ignore it.

This is definitely the sort of thing that should be made into a utility of some kind for simplicity's sake... maybe someday.

For now, you can take the demo images that I've provided and try changing the partition type (using a tool like fdisk) of either of the two partitions on it to any number between 0x01 and 0x1E. 0x1E is Clarus the dogcow. 0x0A is classic Steve Jobs. 0x19 is modern Steve Jobs. The others... well, explore and find out. =)

 

[Zhinü]

Excellent!

The custom icon functionality is a bit strange in how it works, but we're dealing with a very simple little microcontroller here. =) Custom icons work like this:

MBR has a single byte in each of the four partition entries that denotes the partition type. 0xAF is the standard value for an HFS partition. The TashTwenty firmware will always recognize partitions with an 0xAF partition type and emulate them as DCD devices with the default icon (hard drive with a gothic letter T). If the partition type byte is anything else besides 0xAF or 0x00 (the latter denotes unused space), the firmware will look at that sector on the card and see if the first 256 bytes of it are "ICONICONICON" over and over. If so, then it will use the second 256 bytes as a 32x32 monochrome icon followed by its mask. If not, it will assume the partition is some other type of data and ignore it.

This is definitely the sort of thing that should be made into a utility of some kind for simplicity's sake... maybe someday.

For now, you can take the demo images that I've provided and try changing the partition type (using a tool like fdisk) of either of the two partitions on it to any number between 0x01 and 0x1E. 0x1E is Clarus the dogcow. 0x0A is classic Steve Jobs. 0x19 is modern Steve Jobs. The others... well, explore and find out. =)

Thanks for the image and pointers for changing the icon! Did you use FDISK on Linux for making the image as well? And if so, do you have pointers for where I could get similar software on Windows? I don't typically use Linux but I could set up WSL if needed.

 

[Tashtari]

Did you use FDISK on Linux for making the image as well?

I made up the MBR and converted the icons using some fairly rough Python scripting, then concatenated .dsk images made up in minivMac to it, then wrote the whole image to an SD card.

do you have pointers for where I could get similar software on Windows?

I don't, unfortunately. I'm sure someone's made a good disk partitioning utility for Windows that isn't all nerfed, but I don't know what it is. I can tell you that the utilities included with it (the Disk Management snap-in, DISKPART) are not suitable. The best path that I can suggest that doesn't involve writing code is to create partitions using fdisk and image them using dd (whether on Linux or WSL or Cygwin or something else) - though of course this approach sticks you with the default icon. If you like the icon set I knocked together, you can use the demo image as a starting point, just make sure your partitions all start at sector 0x100 (256 in decimal) or higher.

Speaking of which, I'm still looking for good 32x32 monochrome icons to add to the demo images, if anyone has a source or collection they'd like to share. Whenever I go looking for icons, I find plenty of color ones, but few monochrome ones...

 

[Zhinü]

Ah, yeah, I'm a little too dumb for that sorta stuff. I'll work with the images I got and a hex editor to check what comes up. I'll have to put down messing with this sorta stuff for a bit, but the next project will be installing this into an HD20's case and loading a ton of data on it.

 

[Tashtari]

Did you try the System 4.1 image on your 512K successfully?

 

[Zhinü]

Unfortunately, it didn't work. Same flickering issue. This is a 64K ROM 512K with a 400k floppy if you need that info.

 

[Tashtari]

Hmm. I don't know how to account for that... someone better versed in how a real HD20 was meant to work on a 512K might have to step in. All I can think of is to try deleting the system off the drive and booting with the HD20 startup disk again, so it doesn't try to boot off the HD20.

 

[Iesca]

My understanding is that the HD20 Startup disk is meant to basically patch the ROM on the fly so that a 64k ROM 512k Macintosh (or a 128k with a RAM upgrade) could deal with the then-new HFS disk structure.

 

[demik]

Unfortunately, it didn't work. Same flickering issue. This is a 64K ROM 512K with a 400k floppy if you need that info.

My understanding is that the HD20 Startup disk is meant to basically patch the ROM on the fly so that a 64k ROM 512k Macintosh (or a 128k with a RAM upgrade) could deal with the then-new HFS disk structure.

First good job on getting your kit up to a working state.

As for your flickering, I had a similar issue with Floppy Emu with one system version, but I'm running Mac Plus ROMs.

As for the HD20 Startup Disk, as @lesca said, it may need to be in the floppy drive before powering the Machine or the 512k will try to boot from the HD20.

Do you have Mac Plus ROMs around by any chance ? If you have a TL866 or similar, they are easy to create.

 

[Tashtari]

try deleting the system off the drive and booting with the HD20 startup disk again, so it doesn't try to boot off the HD20.

According to this, System 6.0.8 should run on the non-Ke 512K. It might be that the HD20 Startup disk is only capable of bootstrapping its own version of the system, or only certain versions that don't include 4.1 or 6.0.8. I think what I'd try next is deleting the System Folder off the emulated HD20 and booting from the HD20 Startup floppy, then copying the System Folder from the HD20 Startup floppy over to the emulated HD20 and seeing if you can boot that...

In any case, the fact that it works on the IIsi demonstrates that the hardware/firmware is working, so that's good. =)

 

[aihk]

According to this, System 6.0.8 should run on the non-Ke 512K. It might be that the HD20 Startup disk is only capable of bootstrapping its own version of the system, or only certain versions that don't include 4.1 or 6.0.8. I think what I'd try next is deleting the System Folder off the emulated HD20 and booting from the HD20 Startup floppy, then copying the System Folder from the HD20 Startup floppy over to the emulated HD20 and seeing if you can boot that...

In any case, the fact that it works on the IIsi demonstrates that the hardware/firmware is working, so that's good. =)

Can TashTwenty use the built-in interface? I'm plugged into the logic board and it doesn't work. I use 1704

 

[Tashtari]

Can TashTwenty use the built-in interface?

Short answer: No, not typically.

Long answer:

The floppy controller chip (IWM or SWIM) has two drive enable outputs called !ENBL1 and !ENBL2. In the typical case, !ENBL1 is routed to the internal floppy header and !ENBL2 is routed to the external floppy connector. Apple reasoned that the HD20 would only ever be plugged into the external floppy connector, and as a result, any Mac that supports the HD20 (or TashTwenty, or the Floppy Emu in HD20 mode) will only recognize it if it's on !ENBL2. Because you've plugged it into the internal floppy header, which has !ENBL1, your Mac's ROM won't talk to it.

Like any rule, there are some exceptions.

The easy exception is if you're using an LC, or if you're using a IIx with the ROM SIMM replaced with a ROMinator. These machines have two floppy drives, the primary one on !ENBL1 and the secondary one on !ENBL2. As such, you can just plug it into the secondary floppy drive header on the motherboard, and it should work like a charm.

The hard exception is if you're willing to get creative with the wiring. All the signals on the internal floppy header and the external floppy connector are common except !ENBL. As such, you can get all the other signals from the internal floppy header and get !ENBL2 from somewhere else, such as soldering a wire to the correct pin on the IWM/SWIM chip. demik's board, a.k.a. TashTwenty Tiny, is designed to accommodate this sort of hack easily.

 

[aihk]

Short answer: No, not typically.

Long answer:

The floppy controller chip (IWM or SWIM) has two drive enable outputs called !ENBL1 and !ENBL2. In the typical case, !ENBL1 is routed to the internal floppy header and !ENBL2 is routed to the external floppy connector. Apple reasoned that the HD20 would only ever be plugged into the external floppy connector, and as a result, any Mac that supports the HD20 (or TashTwenty, or the Floppy Emu in HD20 mode) will only recognize it if it's on !ENBL2. Because you've plugged it into the internal floppy header, which has !ENBL1, your Mac's ROM won't talk to it.

Like any rule, there are some exceptions.

The easy exception is if you're using an LC, or if you're using a IIx with the ROM SIMM replaced with a ROMinator. These machines have two floppy drives, the primary one on !ENBL1 and the secondary one on !ENBL2. As such, you can just plug it into the secondary floppy drive header on the motherboard, and it should work like a charm.

The hard exception is if you're willing to get creative with the wiring. All the signals on the internal floppy header and the external floppy connector are common except !ENBL. As such, you can get all the other signals from the internal floppy header and get !ENBL2 from somewhere else, such as soldering a wire to the correct pin on the IWM/SWIM chip. demik's board, a.k.a. TashTwenty Tiny, is designed to accommodate this sort of hack easily.

Thank you very much for your enthusiastic answer!

 

[Tashtari]

Thank you very much for your enthusiastic answer!

Glad to help. =) If you're working on a build, feel free to share pictures and details!