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

Integrated Tashtari Machine: Floppy Drive Emulator

tashtari

Well-known member
Sméagol said it was impossible... Sméagol lied!

Introducing... the Integrated Tashtari Machine!


Elevator Pitch

It's a floppy drive emulator, made using a PIC16F1708 and a standard SPLD. Instead of an aging mechanical component with brittle plastic gears trying to get data off aging save icons, it takes disk images off of a memory card and pretends to the Macintosh that it's a floppy drive.


Project Status

Very nascent. I've been working on this a while and I just got it to boot successfully, so I figured it was time for a forum thread. Currently supports a single read-only 800 KB disk image, that's it.


Caveats

A project claiming to be a floppy drive emulator is bound to draw comparisons to BMOW's Floppy Emu, so I'm going to get out in front of that right now. The Floppy Emu is an excellent and compelling product, I own one myself, and even if I achieve everything I set out to achieve with this project, the Floppy Emu is going to come out ahead by every measure except cost, openness, and ability to be integrated.

ITM will never emulate the HD20 (if you're interested in that, check out another of my projects, TashTwenty) or be compatible with Apple II disk controllers (except maybe the IIgs). ITM will probably never be able to write to 1.44 MB floppy images (though I do intend to make it able to emulate read-only ones.) ITM will not have a user interface controlled with buttons and displays and able to read FAT-formatted memory cards (though it will be possible to connect such an interface to it.)


What's Next

In the immediate future, support for 400 KB floppies, for writing 400/800 KB floppies, and for reading 1.44 MB floppies, and support for connection to a less primitive control interface.

In the less immediate future, an interface for a modern computer to control ITM over USB and select and upload/download images.

In the distant future, an integrated system using ITM that you'll want to install in your old Macs. Notice that I said install in rather than use with - this is intentional. ITM is not a self-contained product like the Floppy Emu, it's meant to be a component of a larger system, and that system can be better integrated with a Mac rather than a "brick on a leash." One idea I have for such a system is a user interface for ITM that can be installed in a Mac's floppy drive bay and be controlled by sticking a circuit board 'disk' through the slot with buttons and a display and a card slot, and thus completely disappear within the machine it's installed in.


Picture

A screenshot would just look like a Mac booted up from an ordinary floppy disk, so have instead a picture of the mess that is my bench setup...

1658095498584.png
 

cheesestraws

Well-known member
one of these in a tiny little box with a System 6.0.8+AppleShare disc plugged into it would be a great little net install dongle...
 

tashtari

Well-known member
Some interesting things have happened, I've done some revisions to the design, and it's making an increasing amount of sense to refer to this as the Disintegrated Tashtari Machine. My design now consists of two functional areas connected by an 800 kHz pair of UART lines, a frontend and a backend.

The backend, which is tentatively complete, consists of an ATF16V8 SPLD and a PIC16F1704, and together they are able to both receive and send both GCR and MFM as they interface to the Mac, meaning that floppy drive emulators based on this design will be able to read and write 400 KB, 800 KB, and 1.44 MB disks! Everything on the backend is designed to make life easy for the frontend, making it relatively easy for me or anyone else to design a new frontend without replacing the backend, making lots of different form factors for floppy drive emulators possible.

Building a frontend is next on my list. What I have in mind will look not unlike the Floppy Emu, accessing images off a FAT32-formatted memory card and having an interactive display and pushbuttons. I've sourced a bunch of alphanumeric LCD displays for the dirt-cheap price of 25 cents each, and while I'm not promising anything, when all is said and done, I think a kit for one of these might come in under $20.

Watch this space!

(And let me know if you're paying attention, it helps me to know someone actually cares about my hare-brained schemes. =D)
 

LaPorta

Well-known member
This is very cool!

A few questions:

-With no interface, how does one choose images?

-If not FAT, how is the SD card formatted?

-Can you mount more than one image at a time?

-What image types are supported?
 

tashtari

Well-known member
With no interface, how does one choose images?
Well, you don't. =D A frontend is a necessary component. It would be theoretically possible to have a PC fill this role, but in my experimentation, they just don't respond quickly enough, it needs to be something that can assign a real-time priority to communicating with the backend. The frontend I'm planning on building, when combined with the backend, should make for a useful tool similar in appearance and operation to the Floppy Emu.
If not FAT, how is the SD card formatted?
My original plan was to set it up such that you put your images in a TAR archive and then wrote that to an SD card as a primitive filesystem. This would have worked well for the microcontroller, as TAR archives are easy for a microcontroller to parse, but would not have been very convenient for users. My plan now is that the frontend I'm building will read a FAT-formatted memory card, so users can interface with it in a familiar way.
Can you mount more than one image at a time?
No, the hardware can only emulate one floppy drive, and the Mac can only connect one floppy drive per port, anyway. However, it'd be possible to combine this with TashTwenty to make a device that emulates both a floppy drive and up to four HD20-style hard drives...
What image types are supported?
At first, just raw .dsk images, for simplicity's sake (they're sector-aligned). There is nothing on the backend that would prevent it from supporting .dc42 images, though, tags and all, which means that this could also be used with a Lisa with support from the frontend.
 

LaPorta

Well-known member
My vote would be for HFS+ formatted SD card capability, and compatibility with .img and .dmg images. Hey...just my personal wishlist :p

This is a great project!
 

tashtari

Well-known member
My vote would be for HFS+ formatted SD card capability, and compatibility with .img and .dmg images.
The neat thing about the frontend/backend split is that these features are all on the frontend, which means that even if I don't end up supporting them in my frontend, half the work (at least) is already done for someone else who wants to make a floppy emulator that supports them.
 

sstaylor

Well-known member
There are a couple of image file types from the Applesauce drive interface that would allow for copy-protected disks. WOZ and another newer one that escapes me at the moment...
Would be very cool to have those supported on the front end.
 

tashtari

Well-known member
There are a couple of image file types from the Applesauce drive interface that would allow for copy-protected disks. WOZ and another newer one that escapes me at the moment...
Aren't those only for Apple II disk images, not Macintosh ones?
 

sstaylor

Well-known member
Aren't those only for Apple II disk images, not Macintosh ones?
It seems like it was for both. Problem is I'm too lazy to google at the moment.
The other file format is MOOF. There's an applesauce discussion going on in the Peripherals section.
 

LaPorta

Well-known member
That would be awesome. I have been looking for a way to use my copy-protected MOOF disk images...
 

tashtari

Well-known member
Reading about the WOZ format a bit, it seems like some of the copy protection schemes used in the Apple II are potentially applicable to the Mac. Some of them could potentially be supported by the backend. Weak bits, the backend will pass through random numbers as happily as real data... synchronized sectors, the backend will put through data at any time it's told to... data stored as flux transitions, though, the backend will not handle, since it deals in terms of bytes. Of course, authors of copy protection schemes had to be a little more careful on the Mac versus the Apple II. With the Apple II, the boot sector was the only thing that needed to be standards-compliant, and the rest of the disk was up to you. With the Mac, I think the disk's filesystem has to be readable without error. I could be wrong, though, my understanding is that copy protection schemes were less common on Macs than Apple IIs. Anyway, copy-protected image formats are not something I'm aiming to support in the initial revision of my reference frontend, but perhaps in the future, depending on interest and technical complexity...
 
Top