• Please review our updated Terms and Rules here

More Hardware Project Ideas

Hi! One idea I've been kicking around for a long time is a high speed floppy disk sampler like a Catweasel but cheaper and completely open source. I think this would be doable using a Propeller or other uC, a SRAM, and some interface logic.

Basically the Propeller (or other uC) has 32 IO pins. Set 18 of them to the Shugart interface. You need 18 because although there are 17 pins, pin 34 (DC/RDY) is bi-directional. The 18 pins would need to be buffered through 3 74LS367 chips.

For the 16 remaining Propeller/uC pins, 2 are needed for the serial programming interface to the PC, 2 are needed for the EEPROM, and 2 are needed for the general purpose serial port. That leaves 8 remaining pins.

Use the 8 remaining pins to interface to a 128K SRAM chip. However, the SRAM would be accessed in a bit serial fashion. Use an 8 bit shift register for the data bits, and a 16 bit counter for the address lines A0-A15.

You would need these pins for the interface

RAM_CS
RD
WR
Address_Clear
Address_Increment
Data_Bit
Data_Increment
A16

I think you'd need these chips minimum
1 Propeller/uC
1 128K SRAM
3 74LS367s
1 8 bit shift register
2 8 bit counters with carry
a small group of passive components and transistors for the serial programming interface
1 EEPROM for Propeller/uC
1 MAX3232 plus components for regular serial interface or hardwire Propeller to 16C550 if installed on a PC prototyping board. Would need IO decoding for 16C550.

What would be cool about this design is that the Propeller (or other uC) runs at 80MHz which should be fast enough for sampling the floppy disks RAWREAD data stream at 4 Mbps (or 2 Mbps if you include the index hole). That should be enough to almost fill a 128K SRAM with a single tracks data (assume 1 bit resolution) and give a pretty good idea of the contents of the track for decoding.

The hardware would be pretty straight forward but the software for the Propeller (or other uC) and the PC post processing software would be quite a challenge.

The idea is generic enough that any uC could probably do it if it were fast enough. I am assuming 10-20 uC clock ticks per sample.

The above circuit could be done entirely with standard DIP chips if you use a Propeller. Possible a 68 pin PLCC PIC if you needed more IO pins.

Does that sound like a fun project?

Thanks and have a nice day!

Andrew Lynch

PS, I recall Phil Pemberton (SP?) on CCTALK was working on a similar idea but I don't know what came of it. I don't think it was every released.
 
Here's another idea. Several times a year, the problem of the DS1287 real time clock module comes up. While Maxim says that the DS12887 might work, they don't warrant it.

On the other hand, the battery-less DS1685 is compatible with the DS1287 (even has Y2K fixes) and needs only a battery and 32.767 ceramic resonator to be a drop-in replacement.

I was thinking that it might be nice to offer a kit that includes the resonator and a header to plug in an external battery.

The DS1685 is less than $3 each from DigiKey.

I like that idea as well, but can the project be made to work with the IBM PC's non-standard (i.e. non-EPROM pin compatible) sockets?
 
Here's another idea. Several times a year, the problem of the DS1287 real time clock module comes up. While Maxim says that the DS12887 might work, they don't warrant it.

On the other hand, the battery-less DS1685 is compatible with the DS1287 (even has Y2K fixes) and needs only a battery and 32.767 ceramic resonator to be a drop-in replacement.

I was thinking that it might be nice to offer a kit that includes the resonator and a header to plug in an external battery.

The DS1685 is less than $3 each from DigiKey.

I replaced the DS1287 in my Amiga A2286AT Bridge Board with a DS12887 and it seems to work. However I would much prefer a replaceable battery.

On the same subject. A no slot clock clone would be nice.

-Matt
 
So you'r talking about a really fast floppy drive controller?

Hi! Well, not really. It is more of a high speed sampler. It could be used to "rip" the tracks off floppy disks regardless of formatting. With the raw data sampled from the disk, it can be decoded with software to extract out the MFM, FM, or GCR encoding and then use software on the PC to post process the metadata and finally extract the data. By keeping track of the data relative to the index hole positions, it is possible to extract data from disks normally unreadable by PC disk controllers like hard sector formats, RX02, GCR (Apple, Commodore) encoding, custom encoding, etc.

Yes, this is very similar to what the Catweasel already does but would do it for significantly less cost (I think) and if completely open source would be available to everyone to extract the data off of their disks and preserve it. In theory, it would be possible to also write data although personally, I think that is a lot less useful.

Certainly Chuck and many other vintage computer hobbyists appreciate the value and power of the Catweasel. There are many things only a Catweasel can do and it is an amazingly powerful device. We are using one right now to help with the development of the FDC CBIOS for the N8VEM Disk IO project. It is able to view inside the disk format and see the metadata normally invisible to the operator of a floppy disk controller.

Thanks and have a nice day!

Andrew Lynch
 
A 10-inch or less 8-bit ISA EMS 4.0 compatible board. This board should be able to support up to 4MB of RAM. This can be done in two ways. Number one, use 256x4 DRAMs. Number two, use a 30-pin SIMM connector. The interfacing on the typical boards of the day used standard logic and some custom logic, so the glue should be shrinkable into a standard microcontroller.

Hi! Do you have any designs in mind? For example, how does one encode/decode EMS memory paging?

I agree with Chuck although maybe for a different reason. I would recommend using as dense a part as possible and preferrably 5v tolerant. That would be 72 pin SIMMs, AFIAK. I have no idea how one goes about decoding SIMM DRAM although with the older chip DRAM it uses RAS before CAS (CAS before RAS?) and latches to decode the address bus. I suppose there is some sort of similar interface required.

An example schematic would help this discussion immensely since I don't know enough about it to design something from scratch. Maybe Mike Brutman has some examples in his bag of tricks.

Thanks and have a nice day!

Andrew Lynch
 
Andrew,

I've been playing with a floppy emulator using a ATMega128 and external random logic (128K SRAM+a bunch of LS299 counters to cycle through. The interesting part is that the ATMega doesn't need to address the SRAM--when it needs to read or write the SRAM, it does so by resetting the counters, then pulsing the counter clock. The data stream is simply oversampled--I don't try to do the catweasel inter-bit clock thing because that makes it very difficult to process writes into existing data.

There is an issue that makes the scheme a little messy, however--SRAM speed. I'm using a 70 nsec. part, but remember that if you're going to use a shift register, the write gate can come at any point. So you've got to load the shift register, shift it, then write it back (if any writing occured). That makes things a little messy--there's not enough time at 4 or 8 MHz cell time to write the last byte and then read the next byte in the same clock period.

A write-behind/read-ahead will work, but that does complicate the logic a bit. More than I'd want to do in TTL.

So, I got to thinking about coding the logic I needed into a CPLD (which can run at 150MHz with no problems). So far, so good, but I left the project a few months back and still mean to get back to it.

The interesting part is that if fast enough components are used, the same logic will work as a ST506 emulator--the track capacity is about the same as a 1.44MB floppy--it just spins 12 times faster.

But, I found that processor speed is not an issue. An ATMega128 may, in fact, be overkill, but I used it because of the generous allocation of I/O pins and on-chip peripherals that make debugging easy.

It's all doable. I picked up a couple of these some time ago and pulled them apart. There's an Atmel ATS908515 microcontroller, a small gate array (probably started life as a CPLD), TC55257 32Kx8 SRAM, a MAX887H DC-DC converter and a couple of transistors to drive a little coil that sits under the floppy read/write head.
 
Hi Chuck! Well, it seems like we are already thinking along the same lines. I was thinking the data bus shift register would write to the SRAM every 8 clock ticks (Data_Increment) which I had worked out to be every 2 uS or so.

Then the Address_Increment ticks and the RAM_CS and /WR triggers writing the data bus shift registers contents into the SRAM. 70 nS SRAM parts should be plenty fast for that unless I missing something. Again, I am mostly thinking about just making disk images with this and not considering the realtime nature of making disk writes which is what your design does.

Your design seems to be more a replacement for floppy disks in general something along the lines of a SVD but using an AVR rather than a PIC.

Really the two devices are complimentary, one to make images and the other to emulate the floppy drive hardware using the previously made images.

Phil Pemberton on CCTALK discussed such a device a while back but I don't recall anything ever coming of it. If you are interested, I am certainly game for some PCB design work.

This is not my first attempt at building a disk imager device. Previously, I added some design features to the N8VEM Disk IO board along these lines. My theory was the SBC and Disk IO board would serve as a host for a "strap on" uC board that would tap into the Disk IO's RAWREAD signal in the feature connector. Then the SBC would command the Disk IO to seek tracks, command heads, etc and the uC board would sample the RAWREAD and INDEX signals to make the images.

Once the uC has the disk image stored in local SRAM, the SBC would extract the data and use the Disk IO to write the disk image file to the IDE hard drive or send it out the serial port. By leveraging the SBC and Disk IO's i8272 as a mechanical controller, it simplifies the uC's job so it only has to sample that RAWREAD signal from the disk and store it. My thinking is that the uC would be a plug in board to the ECB for power and mounting purposes with a cable and connector to join with the Disk IO board.

However, at this point I would be thrilled to just see a working FDC CBIOS for the N8VEM Disk IO board. The good news is that last week I finally got my first floppy successfully formatted using new FDC monitor program. Still there are a lot of things left to work on.

Thanks and have a nice day!

Andrew Lynch

PS, I think the DS1287 replacement project has merit. Certainly designing the PCB is not the limiting factor. We'll see if anyone picks it up. The memory board idea might have legs too if there are examples on how to implement a EMS LIM style memory mapping decoder. Using DRAM makes me leery though. It is notoriously unreliable and is sensitive to grounding issues.
 
As I understand, you wish to make a device that allows PC to read any floppy disk format. This would indeed be useful for backing up copy-protected floppies or non-PC floppy standards. But what about writing back bit-perfect floppies back to a floppy drive instead of an emulator? Could it also act as a standard floppy disk controller (uPD765 functionality) as well with support for HD disk drives?
 
My proposed device replaces a floppy drive entirely. Like MFM hard disks, they're not going to be around forever and the media is slowly degrading. It seems that almost a third of the problems reported on VCF are disk problems of some sort.

Andrew, you can write every 8 ticks when the byte is assembled, but when do you load the SR with the next byte following? At a 4 MHz clock rate, you've got 250 nsec to do both--and if you include setup times, it gets a little uncomfortable, although still doable. At 8MHz it's not possible.

On the other hand, if you don't mind a little more complexity in the design, you can issue your reads at your leisure during any of the preceding 8 bit times and issue writes during any of the following 8 bit times. (read ahead-write behind). This brings the design into target range of being able to emulate an ST506 drive.

I know about Phil's project--I've exchanged some email with him. He's going all FPGA, and while that's great, he's got to tackle issues that aren't a problem if a commodity microcontroller is employed.

To read arbitrary floppies, one can pretty much hook up a floppy drive to a moderately fast PC parallel port and sample the data stream by brute force. I've tried it and found that it works well with 250Kb/sec floppies.
 
Hi Chuck!

How about using a strap on UC on the N8VEM Disk IO board?

The SBC sends motor, head, and track commands to the uC board with one of these PIC 18F series chips in 68 PLCC format:

http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=PIC18LF6585-I/L-ND

I see it has 68 pins total with 52 IO pins. I would allocate them like this:

128K SRAM interface:
17 Address pins
8 Data pins
3 Control pins (RD, WR, CS)

ECB IO port interface:
4 pins (CS, RD, WR, A0)

Disk sampler interface:
4 pins (/READ, /INDEX, /WDATA, /WGATE)

I count 36 used pins which leaves 16 pins available for other applications or unused. /WDATA and /WGATE are only useful if planning on writing floppy disks as well as reading them.

The PIC 18F series appears to be capable of upto 40MHz speed which may be fast enough to do some decent sampling. I don't recall the fastest clock rate of the Catweasel but it was like 14 MHz or so?

Using 28 pin SRAM interface eliminates the need for serial counters/shift registers and simplifies the interfacing significantly. You might even be able to just hook up the rest of the 16 unused IO lines to control the rest of the Shugart floppy interface. I think you'd only need 14 more pins leaving 2 pins for UART/USART interface.

At least in my mind's eye, this is design is literally three chips; the PIC, the SRAM, and a 74LS367 or 74LS06 for interfacing to the floppy drive via Disk IO. Alternatively, adding two more 74LS367's or 74LS06's for a complete floppy interface. Either mount it as an ECB IO port device or access over a serial port (add a MAX232 plus caps)

Either way the hard part is writing the software for the controller. Do you think the 40 MHz part is fast enough for decent sampling?

Thanks and have a nice day!

Andrew Lynch
 
Hi! One idea I've been kicking around for a long time is a high speed floppy disk sampler like a Catweasel but cheaper and completely open source.

A very interesting project. How would it be connected to a PC?
PCI card, usb or what?
 
Andrew,

40MHz in a PIC or AVR should certainly be fast enough for a floppy. Recall that most of the bigger uC chips also have the ability to to sychronous serial I/O.

But remember that the output of a floppy read is a stream of pulses, with each pulse represnting a domain magnetization change. If you try to sample for the raw pulses, the chances are that you'll miss one. What you want to do is take the raw read output of the floppy and use it to drive a T flip-flop, so you get an NRZ stream.

Here, I prefer AVR to PIC because the upper AVRs can directly interface to 65K of external RAM. Add a bit or two for bankswitching and you can handle larger memories.

Adapter boards from QFP to 0.100" grid are available and cheap for the ATMega128, so there's no issue with prototyping.
 
A very interesting project. How would it be connected to a PC?
PCI card, usb or what?

Hi! Well, I am still mulling that over. I think this could be done on either a PC prototyping board using an IO port for access or via the uC's UART/USART serial interface. The latter is a bit more general since it could be either stand alone or integrated into a PC prototyping board with a UART to communicate with it. The problem with serial communications though is they are slow. However we are not talking about lots of data here though.

Something like this for a uC might be a good choice:

http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=AT89C51ED2-SMSUM-ND

Using PLCC sockets makes things relatively easy although I don't know how suitable the uC would be for this application.

Thanks and have a nice day!

Andrew Lynch
 
Andrew,

40MHz in a PIC or AVR should certainly be fast enough for a floppy. Recall that most of the bigger uC chips also have the ability to to sychronous serial I/O.

But remember that the output of a floppy read is a stream of pulses, with each pulse represnting a domain magnetization change. If you try to sample for the raw pulses, the chances are that you'll miss one. What you want to do is take the raw read output of the floppy and use it to drive a T flip-flop, so you get an NRZ stream.

Here, I prefer AVR to PIC because the upper AVRs can directly interface to 65K of external RAM. Add a bit or two for bankswitching and you can handle larger memories.

Adapter boards from QFP to 0.100" grid are available and cheap for the ATMega128, so there's no issue with prototyping.

Hi Chuck! Is this what you were referring to regarding QFP to 0.100" adapter?

http://www.schmartboard.com/index.asp?page=products_qfp&id=70

Thanks!

Andrew Lynch
 
Hi!The problem with serial communications though is they are slow. However we are not talking about lots of data here though.

Andrew Lynch
Yes,serial comms can be to slow.

Another question: would using a FPGA for this be a good choice, overkill or simply wrong?

Have a nice day.
Torfinn Ingolfsen
 
Yes,serial comms can be to slow.

Another question: would using a FPGA for this be a good choice, overkill or simply wrong?

Have a nice day.
Torfinn Ingolfsen

Hi! I think an FPGA would work fine assuming you could do the hardware description language needed to describe the circuit. I believe using the FPGA approach is what Phil Pemberton is doing. Presumably it would be a pretty straight forward approach too as Xilinx chips like Spartan 3, etc have enough IO pins to do all the floppy, bus, and external SRAM interfacing needed. I believe this may have even already been done.

I don't think FPGA IO pins have enough drive current ability to push a Shugart interface so you'd probably need buffers for it. I also think you'd need the external SRAM for storage but that's about it.

The real issue is I prefer older chip technologies, DIP spacing and the like. I am more comfortable with uCs, TTL chips, and am not thrilled with FPGA/CPLD and SMT type solutions not that they are inherently bad.

I like the PIC and Atmel 8051 uC and the ATmega128 Chuck suggested seems a reasonable compromise (with the 0.100 adapter of course). Propeller would be cool too but I don't think it has enough IO pins to pull off such a project.

There are very few people interested in this sort of thing so the demand for it is necessarily pretty specialized and narrow. Also the Catweasel does an admirable job already (I own two and love them) so there isn't the overwhelming need for it either. Still it is an interesting problem that might lend itself to a group effort like the XT-IDE or AT2XTKBD solutions did. Some people do software others hardware, testing, making PCBs, etc. It's magic when it works but that's not very often.

Thanks and have a nice day!

Andrew Lynch
 
Hi Chuck! Is this what you were referring to regarding QFP to 0.100" adapter?

http://www.schmartboard.com/index.asp?page=products_qfp&id=70

Hi Andrew,

Actually more like this. Lots cheaper.

Be careful with some adapter boards--I've got a couple from Circuit Specialists here that convert 162 pin TQFPs to 0.100" contacts--but the horizontal and vertical contact rows are not on even 0.100" boundaries (I had them confirm it). Makes it really interesting to work with one on 0.100" grid prototyping boards!
 
Thanks Chuck! Speaking of neat projects and stuff, I just remembered I made a PIC based keyboard protocol converter of my own a while back. It used a PIC to converter KayPro 300 bps serial to parallel ASCII. Probably that design could be easily extended to use AT or PS/2 keyboards as well.

Any interest in that? Spinning up a PCB for it would be a no-brainer assuming I can find my original technical data.

Thanks and have a nice day!

Andrew Lynch
 
Any interest in that? Spinning up a PCB for it would be a no-brainer assuming I can find my original technical data.

Hi Andrew,

I don't know what the "market" for this would be--but essentially converting PS/2 keyboard to anything else is fairly easy if there's a need. As far as I'm aware, the majority of vintage gear used serial interfaces to the keyboard, however--which each being somewhat slightly different. This could be useful for someone who managed to find an old terminal, but without the keyboard, for example.
 
Back
Top