Alternative Hardware #5
Comments
|
This'd probably work. (Most things will, floppy drives aren't complicated...) My gut feeling is:
I think for the bitbanging approach I'd be more comfortable with about 256kB of RAM, as that'd allow me to buffer two complete revolutions in memory, then I can stop sampling and send it to the PC. (I could be wrong about the USB load, of course.) Regarding mass storage: yes, that'd be really nice, but I'm not sure it's feasible given the current approach. Right now I'm dealing with a track of data at a time and doing off-line processing, which simplifies things hugely. But 200ms of data is about 80kB, which won't fit in the microcontroller's RAM. This could still work, but it'd have to act like a more traditional floppy controller, reading and writing individual sectors at a time by looking for sector headers and turning the heads on and off. (Which of course won't work on Amiga disks at all which doesn't have sector headers...) That's still a really useful thing to have, but it's very much not the same project. |
My prototypes only use about €3.50 worth of components, including the board itself. EDIT: Thinking about it, one could also use an SIP resistor array and bodge-solder it to an existing breakout board. EDIT2: Thinking about it even more, if the floppy drive is TTL compatible – they originally had to be – anything above
I did not realize that. But then again I only ever hooked up one drive to a logic analyzer. The DMA can run faster, but the CPU might not be able to process the data quickly enough.
Yeah. Working with raw data would indeed be a challenge with this approach. |
|
Yep, decoding the MFM on the fly is straightforward... but you also need to listen for synchronisation sequences to make sure you're aligned properly, which means you have to be aware of what disk format you're reading, which means you're limited to just certain types of disk, etc, etc. Possibly you'd want to send the raw bitstream back instead (twice as big, but much more flexible). You would still need to do the analysis to determine the clock rate on-board but that's not as hard. |
|
I would be tempted to use a Teensy 3.2. I know it only has 5v tolerant inputs, but an output buffer does not have to be very complex and it may be possible to drive the 5V logic using 3.3V levels directly depending on the floppy drive. You could use a timer to drive the DMA and reference the index hole on the floppy to read a complete track into RAM before processing the RAM to extract the timings at your leisure. Years ago, I used to create programs to read foreign disk formats on the BBC micro using the Western Digital 1770 including a program to format Wang Word Processing Floppy Disks. Back then you had to buy them pre-formatted from Wang at a ridiculous price. Unfortunately, I have forgotten so much of what I used to know! BTW, I am pretty sure I used to have a book that described a lot of common file and disk formats for the time. The book would be 30+ years old now and I not sure if I still have it but the information in it may be available online. The other place to check for disk formats are the emulation sites like FPGArcade. |
|
Teensy++ 2.0 is true 5V and pretty capable. It has USB, and I've successfully used it to bit-bang Z80 bus protocols, although that didn't need to be fully real-time due to the used of a bus request signal. |
|
The Teensy 2.0 is only 16MHz, so it may not be able to keep up. It's also got very little memory which means there's not a lot of buffering available. The Teensy 3.5 looks like the most plausible option --- SD card reader on board, too. (This thing would probably make a really good floppy emulator.) At least one FDD datasheet claims that the drive has built-in pull-up resistors so it may not need any external components. But they're all more expensive than the Cypress... |
|
If cost is the main consideration, why not use a Cypress CY7C68013A. These are the chips used in low cost logic analysers and simple dev boards can be had for around £3. They only have an 8051 processor, but it does have some nifty features. Specifically, they can be configured to hardware stream an 8 bit I/O port to the host USB at a rate up to 24Mhz (capture rate). This rate should be more than enough to sample any floppy disk track. In this case the 8051 would just provide a means move the heads and start a data capture transfer based on the index hole. The host PC would need to then capture, buffer and process the raw data very much like the sigrok logic analyser software. A quick web search found this https://www.chzsoft.de/site/hardware/preserving-a-floppy-disk-with-a-logic-analyzer/ If you wanted to go down this route I would suggest browsing this site https://sigrok.org/ |
|
That looks ideal. Are there any pre-made boards at a reasonable cost which contain one? (One of the reasons I'm using the Cypress part is that it's the cheapest off the shelf hardware which doesn't require any modification, other than soldering the pins on, of course. Constructing a custom board is beyond the reach of most people, and trying to make and sell one would be prohibitively expensive.) |
|
or a more expensive but better form factor You can get the same boards on alibaba cheaper or from local suppliers for about £8. I have not developed for one of these so I'm not sure about the dev kit. |
|
Of course you could just buy one of the logic analyzers and re-flash it. As far as I know all of the low cost Saleae clones are based on this chip. |
|
It has to be something that can be physically attached to a floppy disk cable --- the second one you mention looks (very nearly) just right. That's a 36 way connector rather than a 34 way one, but that's what wire cutters are for... I found schematics for a suspiciously similar board here: https://www.waveshare.com/cy7c68013a-usb-board-mini.htm Unfortunately it suggests the pinout's not compatible. It's really a 32-way connector with dummy pins at each end and it looks like the pin purpose is hard-wired, so it'd probably need at least a custom connector. Also, can these things reproduce a bitstream from the PC, or are they strictly input devices (as you'd expect for a logic analyzer)? (I like the 8051. It's engagingly weird, and just will not die.) |
|
They can do input and output. They are designed for use in USB keyboards, parallel printer ports and general USB interfacing to microcontrollers. The simple fix for the pin out would be custom ribbon cable or female to female jumper wires (plus hot glue to hold them together in the right order). But I still think a PCB adapter would be the way forward it would not be expensive in any form of quantity. |
|
If I get a chance at the weekend, I'll have a look to see what development environment and sample code is available. I have one of the low-cost logic analysers that I can play around with if I can setup a suitable system. |
|
Compiler-wise, SDCC claims to support the Cypress FX2 (CY7C6801x). |
|
I don’t disagree with you. The STM32's are very powerful devices for their price with a reasonable development environment. Personally, I like the STM F4 series, but David seems to have some strict requirements on price and form factor and wants an off the shelf solution. Price and formfactor could probably be resolved with a custom PCB if 10-20 boards where purchased as a group buy. |
|
My issue is that anything which involves custom hardware because drastically more difficult and expensive --- not just in monetary terms, but hidden costs in having to actually source a board from somewhere, finding the parts, having the skills and time to assemble it, etc. I've seen too many homebrew electronics projects which produced a few devices and then vanished without trace. The Cypress board I'm currently using is really good because it's completely off-the-shelf and I can probably rely on it to continue to exist for at least a few years. I'm not averse to any custom hardware solution, mind. It's just not what I'm looking for as a replacement for the current PSoC5 board. Re input/output with the logic analyzer: keyboards, parallel ports and things sound more like GPIO rather than bitstream. In order to write disks I need to be able to stream data from the PC to the output data pin --- about 75kB in 200ms using the current encoding. Can they do that? |
|
In answer to your question about writing data using the Cypress FX2. I havent developed for one of these devices but from the datasheet: The GPIF has six programmable control outputs (CTL), nineaddress outputs (GPIFADRx), and six general-purpose readyinputs (RDY). The data bus width can be 8 or 16 bits. EachGPIF vector defines the state of the control outputs, and deter-mines what state a ready input (or multiple inputs) must bebefore proceeding. The GPIF vector can be programmed toadvance a FIFO to the next data value, advance an address,etc. A sequence of the GPIF vectors make up a singlewaveform that will be executed to perform the desired datamove between the FX2LP and the external device. So I think the answer is yes it could perform bit (actually byte) streaming. One of the other tasks it was designed to perform was as a USB to ATA and I think SATA interface. |
|
So it turns out that you don't need a 5V or 5V tolerant device to control a floppy drive, which opens up the possibilities a lot more. For output from the device to the floppy: Even if sending a 3.3V signal, that's far in excess of the typical minimum required voltage for the drive to see it as high. For input to the device from the floppy: Apparently all the signals are open-collector. This means that the floppy pulls the signal to ground when it wants to output a 0, and leaves the signal floating when it wants to output a 1. A pull-up resistor is required for the signal to actually /be/ logic high (or perhaps, an on-device pull-up rather than a discrete resistor, but I didn't test this yet). Thus, the attached device can supply a pull-up to whatever voltage it feels like based on what's best for its own IO pins; 3.3V being a working example. I used a Raspberry Pi 3 to verify that this is all true, coupled with a multi-meter to verify the floppy's open-collector outputs. From the Pi, I've successfully driven the following signals: motor on, drive select, direction, step, and received the following signals: track zero, index, read data. I hacked some code into U-Boot to demonstrate all this; you can see it at: |
|
Hmm. According to some floppy drive specs I found, the input signals all have a pull-up to 5V at the drive, so the Pi may see 5V on its outputs when not actively driving them low, which would be bad. I'll have to check if that's happening... The floppy output signals are fine though. |
|
Oh dear, the drive does indeed have pull-ups to 5V on its inputs, so connecting them directly to the Pi (or any device not 5V tolerant) will fail (eventually at least). That's annoying. |
|
I checked both a 3.5" and 5 1/4" drive that I had. Both pull the inputs to 5V and drive the outputs at 5V. On the 5 1/4" drive you can see the 1K SIL pullup resistor pack used on the inputs. I would not recommend a floppy drive to a non 5V tolerant processor. While it may not damage the device immediately but it will definatly reduce the life expectancy of the device. |
|
I investigated using the Cypress FX2 a bit more and have concluded it is probably not the best device to use for this type of project. While it could be used, to do so would involve oversampling the track capture and decimating the resulting stream on the host computer to recover the MFM data a track. The STM32 micros are ideal for this task as generally one of their counters can be configured to increment at a predefined clock rate and to store the result of the timer in a register on the rising and falling edges of an input pin. This happens in hardware, so the measurements are not affected by code timings and an interrupt can be configured store the captured result. This is not my main project at the moment but I have dug out an STM32 Nucleo board, ATX power supply, plus both a 3 ½” and a 5 ¼” drive to play around with. |
|
I don't know why I did not do this earlier but googling "STM32 MFM" found this: https://github.com/Slamy/SlamySTM32Floppy I havent looked at the code yet but on the face of it he has already implemented what I was thinking of doing. I know he uses a closed source library but that should be easy to replace if required. |
|
https://github.com/tinyfpga/TinyFPGA-Bootloader there is a verilog USB serial core in there (an extremely compact one) + picrov32 + some 5v level shifting ought to make it possible to implement this entirely in verilog on ice40 and with an open source toolchain for the MCU core... since you aren't doing any heavy lifting a simpler core like a j1 forth core might also make sense and allow fitting into something like a ice40 1k etc... Previously I've suggested pic3mz, and that might make more sense if you were doing more processing on the device since it has USB target/host support and up to 128MB DDR ram in adition to the normal MCU sram (32MB can be ordered embedded on PoP) |
|
I am doing some processing on-board --- I need to compress the bytecode stream for the sampler to make it fit in the USB bandwidth. There's not much to it, though, and there's nothing there that couldn't be done just as easily in Verilog. https://github.com/davidgiven/fluxengine/blob/master/lib/common/crunch.c The TinyFPGA BX looks promising, but it's very expensive and would require a custom adapter board for the level shifter and pinout changes. I very don't want to do this, as custom boards add greatly to the difficulty of construction. Are there any 5V FPGAs or CPLDs? |
|
Would the new Teensy 4.0 be of interest for this project? |
|
It's more expensive, has an incompatible pinout and is a 3.3V device --- performance wise it would most likely work, but you'd still need an interface board with level shifters that raises the price and complexity too far for my tastes. Looks really interesting, but I don't think it'll work for me. Sorry. |
|
FWIW, this uses a stm32 Blue Pill: https://github.com/keirf/Greaseweazle |
|
Huh, that's really interesting --- I didn't think a Blue Pill was powerful enough. Also, aren't they 3.3V? I'll contact them and see how it works. |
|
Welp, turns out that (a) I had completely misunderstood how the FDD bus works and 3.3V devices are fine, probably; it may be necessary to use external pull-up resistors on the inputs, and (b) the STM32 Blue Pill already has built in to it all the hardware which I've been painfully reimplementing in the PSoC FPGA. So, yes, they would work fine, and are cheaper and open source. The downside is that assembly will be trickier as the form factor doesn't allow the FDD connector to be connected directly to the PCB, and the pull-up resistor question is still open. When I get time I'll look into implementing the Greaseweazle USB protocol directly from the FluxEngine client. Thanks very much for pointing this out! Also, d'oh. I need to rewrite a few sections of the website. |
|
Hi David (danielj from stardot :)) - after the discussion on the greaseweazle issue thread, and having pondered the datasheet I decided to whack the pullups on the inputs (photo attached). Nothing's ostensibly changed performance-wise with my drives, but I feel a bit happier not running the inputs ostensibly out-of-spec. It is fairly easy to put together (I've just stuck a 34pin IDC on the end of the dupont connectors): |
|
Hi @drdpj, I'm having difficulties to see the resistors. Are the resistors hidden underneath the black shrinking tube? My feeling is that all the interesting stuff is not visible on the picture - but I may just not understand where to look. |
|
They're under the heatshrink, yes - bit of a safety measure. You need 4 to
cover the inputs, and there's a 5v pin there too, so it's fairly compact
bodge-wise. It was really just the dupont connections I wanted to
illustrate as being quite straightforward :)
d.
…On Wed, 6 Nov 2019, 16:11 hpingel, ***@***.***> wrote:
Hi @drdpj <https://github.com/drdpj>, I'm having difficulties to see the
resistors. Are the resistors hidden underneath the black shrinking tube? My
feeling is that all the interesting stuff is not visible on the picture -
but I may just not understand where to look.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5?email_source=notifications&email_token=AATU2PDEG4RXSFYQEWPT7FLQSLUEVA5CNFSM4GYOJJP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDHCPHQ#issuecomment-550381470>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AATU2PGDDF2GQNQARNI5YNDQSLUEVANCNFSM4GYOJJPQ>
.
|
I'd like to suggest a potential alternative to the Cypress board: My USB Floppy Adapter
It uses the same STM32F103C8T6 as those ubiquitous $2 breakout boards.
The 5V-tolerant IOs of that 3.3V part are used in open-drain mode with external pull-up resistors to 5V.
The thing is that I identified that chip as probably capable enough, built the board, but did not find the time to write the firmware for it.
So far, I can only move the drive head, blink the drive LED and check the TRK0 pin.
The original plan was to use one of the chip's DMA channels to bit-bang the data line from/to a ring buffer at about 4MHz and simultaneously use the 72MHz Cortex M3 core to pre-/post-process the data and then transmit it via full-speed USB.
Since you have more experience with the software-part: Would you consider this approach realistic?
EDIT: There are libraries for the STM32F103C8T6 that let it act like USB mass storage, a virtual COM port or both. Ideally, one could send a description of the disc layout to the virtual COM port and then access the drive as regular mass storage.
The text was updated successfully, but these errors were encountered: