On Thursday, December 29, 2022 at 6:10:05 PM UTC-5, jjhu...@gmail.com wrote:
> On Thursday, December 29, 2022 at 1:15:57 PM UTC-5, Ricky wrote:
> > On Thursday, December 29, 2022 at 1:04:27 PM UTC-5, jjhu...@gmail.com wrote:
> > > Back in the day, I wrote a floppy driver based on the 82077AA for a board I designed. The 82077AA is long gone and I've been away from hardware engineering at this level for a while. I am doing a spare time project where I'd like to revive the FD driver in conjunction with a small SBC. I am wondering what the current chip is that is close to being functionally equivalent to the 82077AA that can actually be bought today?
> > > I did some searching and found the Microchip FDC37C78-HT but it seems to be unavailable. There are other FDCs around at the time that were quite popular (e.g. NEC D765, intel 8272 and of course the WDC FDC) but they too are long gone/unabtanium. I like the intel 82077AA because it could interface to a large number of FDCs.
> > > I also am considering to throw a FPGA at it, but that would probably be more work than I wanted to devote to it....
> > >
> > > I'll keep searching but in the interim I thought maybe someone here may have some thoughts/pointers to FDCs that are currently available?
> > I'm willing to bet you are going to need to roll your own in an FPGA, with analog circuitry to handle the signals from the heads. I don't know exactly what the FDC does, do you? I guess if you have an interface spec, and especially source code for the driver, you can reverse engineer from that.
> >
> > You might try finding computer hobbyist groups on Facebook, Linkedin and the like. I'm willing to bet someone has done this before to keep some gear running.
> >
> > --
> >
> > Rick C.
> >
> > - Get 1,000 miles of free Supercharging
> > - Tesla referral code - https://ts.la/richard11209
> Perhaps I was not clear. The FDC IC controls the data transfer from the disk to the MCU. The disk drive proper contains the analog electronics to position the heads (most often a stepper motor), and pull out the data. The floppy disk controller does not contain any analog processing components and head positioning software/hardware, all that is done on the drive itself.
> Yes, a high end micro could probably do the job, but the FDC is a 'cleaner' approach...and if I had to go a different route, I'd use an FPGA instead of the micro. I do have the data sheets for many of the FDC chips of that era, including the 82077AA. While I've done it before for DEC RK07 drives, I don't want to reinvent the wheel on a FPGA if I don't have to.

An FDC may be a "cleaner" approach in that it requires no software be written, but it's messier in other regards. I have no idea of the scale of your project (home brew one-off or some limited production, etc.) or your over all goals. To be honest, I don't read the posts here like I would a spec document on a paying job.

But it seems very doable with an MCU. I am normally all about FPGAs. They offer many advantages over MCUs that few people understand, much less appreciate. I guess I'd like to see this done in an MCU just to see if it is possible. While I see some posts that say it has been done, I haven't looked hard enough to see how much hardware they use, vs. software.

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

On Thursday, December 29, 2022 at 9:02:14 PM UTC-5, jjhu...@gmail.com wrote:
> On Thursday, December 29, 2022 at 6:10:05 PM UTC-5, Three Jeeps wrote:
> > On Thursday, December 29, 2022 at 1:15:57 PM UTC-5, Ricky wrote:
> > > On Thursday, December 29, 2022 at 1:04:27 PM UTC-5, jjhu...@gmail.com wrote:
> > > > Back in the day, I wrote a floppy driver based on the 82077AA for a board I designed. The 82077AA is long gone and I've been away from hardware engineering at this level for a while. I am doing a spare time project where I'd like to revive the FD driver in conjunction with a small SBC. I am wondering what the current chip is that is close to being functionally equivalent to the 82077AA that can actually be bought today?
> > > > I did some searching and found the Microchip FDC37C78-HT but it seems to be unavailable. There are other FDCs around at the time that were quite popular (e.g. NEC D765, intel 8272 and of course the WDC FDC) but they too are long gone/unabtanium. I like the intel 82077AA because it could interface to a large number of FDCs.
> > > > I also am considering to throw a FPGA at it, but that would probably be more work than I wanted to devote to it....
> > > >
> > > > I'll keep searching but in the interim I thought maybe someone here may have some thoughts/pointers to FDCs that are currently available?
> > > I'm willing to bet you are going to need to roll your own in an FPGA, with analog circuitry to handle the signals from the heads. I don't know exactly what the FDC does, do you? I guess if you have an interface spec, and especially source code for the driver, you can reverse engineer from that..
> > >
> > > You might try finding computer hobbyist groups on Facebook, Linkedin and the like. I'm willing to bet someone has done this before to keep some gear running.
> > >
> > > --
> > >
> > > Rick C.
> > >
> > > - Get 1,000 miles of free Supercharging
> > > - Tesla referral code - https://ts.la/richard11209
> > Perhaps I was not clear. The FDC IC controls the data transfer from the disk to the MCU. The disk drive proper contains the analog electronics to position the heads (most often a stepper motor), and pull out the data. The floppy disk controller does not contain any analog processing components and head positioning software/hardware, all that is done on the drive itself..
> > Yes, a high end micro could probably do the job, but the FDC is a 'cleaner' approach...and if I had to go a different route, I'd use an FPGA instead of the micro. I do have the data sheets for many of the FDC chips of that era, including the 82077AA. While I've done it before for DEC RK07 drives, I don't want to reinvent the wheel on a FPGA if I don't have to.
> One additional point. I firmly believe that controlling devices at the basic level should be the job of hardware. It is a logical separation of concerns as well as reducing cpu utilization to other jobs the processor can do instead of bit banging a disk drive (or what ever). Maintaining sequencing and timing of signals is efficiently done by hardware, leaving the CPU to handle other tasks. Yea, could throw a processor at it as the controller but that would muddy up the architecture (hardware and sw) of the system I am working with.

That's a very archaic philosophy. Small MCUs have essentially become programmable hardware. I try to explain to people how much like MCUs an FPGA is.. On the other hand an MCU is very much like an FPGA. The only complaint I have with MCUs is they are much, much harder to use when there are multiple real time things to be done. If each one is has low enough timing requirements, fine, an MCU can manage to do several things without stumbling over them. But in an FPGA, everything runs in parallel unless you want something different.

The only issue with using a small MCU for this task is being able to deal with the floppy interface while at the same time dealing with the other interface (I guess the computer side). If both sides have timing requirements and can be simultaneous, it might be a trick to make it work without missing a beat on both sides.

I have exactly this problem on the board I supply. I used an FPGA, because there is an SPI like command interface that just can't be done in a CPU, even at 700 MIPS (the GA144)! A 33 MHz clock shifts in the data, address and command. Then on the opposite phase of the last clock, response data has to start shifting out! That's 15 ns, or about ten instructions at 700 MIPS. The GA144 is not really 700 MIPS, only the core ALU instructions. This would require a memory access which is nearly three instruction cycles I believe. So, still requires an FPGA for this interface, while much of the rest of the design could be done in a not very fast CPU. There *is* a data/clock recovery circuit that would be hard to do in an MCU, not unlike the MFM floppy interface, and a clocking scheme for the CODEC that requires some hardware... or a very specialized circuit in a PLD.

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209

On Thursday, December 29, 2022 at 11:58:43 PM UTC-5, Jan Panteltje wrote:
> On a sunny day (Thu, 29 Dec 2022 10:04:23 -0800 (PST)) it happened Three Jeeps
> <jjhu...@gmail.com> wrote in
> <7bd48288-ee79-47ed...@googlegroups.com>:
> >Back in the day, I wrote a floppy driver based on the 82077AA for a board I
> >designed. The 82077AA is long gone and I've been away from hardware engineering
> >at this level for a while. I am doing a spare time project where I'd
> >like to revive the FD driver in conjunction with a small SBC. I am wondering
> >what the current chip is that is close to being functionally equivalent
> >to the 82077AA that can actually be bought today?
> >I did some searching and found the Microchip FDC37C78-HT but it seems to be
> >unavailable. There are other FDCs around at the time that were quite popular
> >(e.g. NEC D765, intel 8272 and of course the WDC FDC) but they too are long
> >gone/unabtanium. I like the intel 82077AA because it could interface to
> >a large number of FDCs.
> >I also am considering to throw a FPGA at it, but that would probably be more
> >work than I wanted to devote to it....
> >
> >I'll keep searching but in the interim I thought maybe someone here may have
> >some thoughts/pointers to FDCs that are currently available?
> >Thanks
> >J
> As somebody else suggested: ebay for the chip.
> That said I wrote a driver for the 8072 and designed some hardware PLL
> with a 4046
> http://panteltje.com/panteltje/z80/system14/diagrams/index.html
> scroll down to floppy disk controller.
> http://panteltje.com/panteltje/z80/system14/diagrams/fdc-2.jpg
>
> That was for 8 inch Kaypro II type floppies...
>
> All that said, I still have an old PC with a floppy drive
> and one day long ago bought an USB floppy drive.
> That may be the fasted way,,,
> But if you want to prove yourself ...
>
> These days with 64 GB USB sticks and micro SD cards ...
> recording HD movies on those...
> Amazing.

It was all predicted by Carnac the Magnificent! Well, by someone in the industry. In the early days, I could not imagine how fast the digital world would advance. I remember people talking about *someday* being able to put Unix computers in toasters. Well, of course there's no *real* need for that, but at this point, I'm certain you can get a toaster with wifi, controlled by an app on your phone.

--

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209

On 12/29/2022 5:16 PM, Don Y wrote:
> On 12/29/2022 3:50 PM, Dimiter_Popoff wrote:
>> Possibly but it won't be an easy ride. IIRC the bit stream is 1 MHz
>> clocked, was it 2 at high density (don't remember). Then it is coming
>> from a mechanically rotating media plus noise so clock recovery is
>> not the easiest thing to do - but doable, I think what I did was
>> to reset a counter or something to stay in sync, was simple anyway
>> and worked rock stable. Don says it has been all done with a Z80,
>> which must have been quite an achievement if it could do standard
>> MFM floppies.
>
> The ZDS used 8" *hard* sectored floppies.  And, they were dog slow.
> The processor basically just sat watching the index and sector holes
> on the disk (to find the correct sector) and then just sopping up
> the bits coming off the disk.  No such thing as overlapped I/O  :>
>
> "Back then", it was common to have access to the schematics and source
> code for the development tools; the manufacturers were in the business
> of selling *chips* and only made development systems as a "cost of
> doing (that) business".  So, I looked at both (HW/SW) to see where
> we were "waiting" (engineers' time being far more expensive than
> the cost of tools).
>
> IIRC, RIO? (the OS that ran on the boxes) was designed to support
> multitasking but the horsepower just wasn't there to *do* much.

Here's the schematic for the floppy controller:
<https://mega.nz/file/4rgQTRaT#3RMDSk3mzEg0_w_em5vgwXFmW3_qmhPcH6RcnjC1K68>

Note that, once you discount buffers for on/off-board signals,
latches for disk control signals that must remain stable beyond
a single CPU cycle and serializer/deserializer... there's very
little "junk logic" involved.

[Remember, the Z80 has a separate "I/O space" disjoint from the
"memory space".]

IIRC, the ZDS CPU ran at 2MHz (because my colleagues running Moto
kit would often argue that 2MHz Zilog = 1MHz Moto based on instruction
timing).

A *modern* MCU with an adequate number of I/O pins could easily interface
directly to a drive and do all of the work in software. And, likely have
time to do something "real", as well!

I haven't, yet, found the RIO sources but there likely won't be any
magic in the floppy "driver".

On Friday, December 30, 2022 at 2:01:02 AM UTC-5, Don Y wrote:
> On 12/29/2022 5:16 PM, Don Y wrote:
> > On 12/29/2022 3:50 PM, Dimiter_Popoff wrote:
> >> Possibly but it won't be an easy ride. IIRC the bit stream is 1 MHz
> >> clocked, was it 2 at high density (don't remember). Then it is coming
> >> from a mechanically rotating media plus noise so clock recovery is
> >> not the easiest thing to do - but doable, I think what I did was
> >> to reset a counter or something to stay in sync, was simple anyway
> >> and worked rock stable. Don says it has been all done with a Z80,
> >> which must have been quite an achievement if it could do standard
> >> MFM floppies.
> >
> > The ZDS used 8" *hard* sectored floppies. And, they were dog slow.
> > The processor basically just sat watching the index and sector holes
> > on the disk (to find the correct sector) and then just sopping up
> > the bits coming off the disk. No such thing as overlapped I/O :>
> >
> > "Back then", it was common to have access to the schematics and source
> > code for the development tools; the manufacturers were in the business
> > of selling *chips* and only made development systems as a "cost of
> > doing (that) business". So, I looked at both (HW/SW) to see where
> > we were "waiting" (engineers' time being far more expensive than
> > the cost of tools).
> >
> > IIRC, RIO? (the OS that ran on the boxes) was designed to support
> > multitasking but the horsepower just wasn't there to *do* much.
> Here's the schematic for the floppy controller:
> <https://mega.nz/file/4rgQTRaT#3RMDSk3mzEg0_w_em5vgwXFmW3_qmhPcH6RcnjC1K68>
>
> Note that, once you discount buffers for on/off-board signals,
> latches for disk control signals that must remain stable beyond
> a single CPU cycle and serializer/deserializer... there's very
> little "junk logic" involved.
>
> [Remember, the Z80 has a separate "I/O space" disjoint from the
> "memory space".]
>
> IIRC, the ZDS CPU ran at 2MHz (because my colleagues running Moto
> kit would often argue that 2MHz Zilog = 1MHz Moto based on instruction
> timing).
>
> A *modern* MCU with an adequate number of I/O pins could easily interface
> directly to a drive and do all of the work in software. And, likely have
> time to do something "real", as well!
>
> I haven't, yet, found the RIO sources but there likely won't be any
> magic in the floppy "driver".

Mega is not a good choice for sharing schematics. It opens in a small window on the web page and I can't find a way to full screen it. So the writing is not viewable unless I want to zoom in on each chip where I can't see the context. Too much effort for a newsgroup post.

--

Rick C.

--+ Get 1,000 miles of free Supercharging
--+ Tesla referral code - https://ts.la/richard11209

On 2022-12-30, Ricky <gnuarm.deletethisbit@gmail.com> wrote:
> On Friday, December 30, 2022 at 2:01:02 AM UTC-5, Don Y wrote:
>> On 12/29/2022 5:16 PM, Don Y wrote:
>> > On 12/29/2022 3:50 PM, Dimiter_Popoff wrote:
>> >> Possibly but it won't be an easy ride. IIRC the bit stream is 1 MHz
>> >> clocked, was it 2 at high density (don't remember). Then it is coming
>> >> from a mechanically rotating media plus noise so clock recovery is
>> >> not the easiest thing to do - but doable, I think what I did was
>> >> to reset a counter or something to stay in sync, was simple anyway
>> >> and worked rock stable. Don says it has been all done with a Z80,
>> >> which must have been quite an achievement if it could do standard
>> >> MFM floppies.
>> >
>> > The ZDS used 8" *hard* sectored floppies. And, they were dog slow.
>> > The processor basically just sat watching the index and sector holes
>> > on the disk (to find the correct sector) and then just sopping up
>> > the bits coming off the disk. No such thing as overlapped I/O :>
>> >
>> > "Back then", it was common to have access to the schematics and source
>> > code for the development tools; the manufacturers were in the business
>> > of selling *chips* and only made development systems as a "cost of
>> > doing (that) business". So, I looked at both (HW/SW) to see where
>> > we were "waiting" (engineers' time being far more expensive than
>> > the cost of tools).
>> >
>> > IIRC, RIO? (the OS that ran on the boxes) was designed to support
>> > multitasking but the horsepower just wasn't there to *do* much.
>> Here's the schematic for the floppy controller:
>> <https://mega.nz/file/4rgQTRaT#3RMDSk3mzEg0_w_em5vgwXFmW3_qmhPcH6RcnjC1K68>
>>
>> Note that, once you discount buffers for on/off-board signals,
>> latches for disk control signals that must remain stable beyond
>> a single CPU cycle and serializer/deserializer... there's very
>> little "junk logic" involved.
>>
>> [Remember, the Z80 has a separate "I/O space" disjoint from the
>> "memory space".]
>>
>> IIRC, the ZDS CPU ran at 2MHz (because my colleagues running Moto
>> kit would often argue that 2MHz Zilog = 1MHz Moto based on instruction
>> timing).
>>
>> A *modern* MCU with an adequate number of I/O pins could easily interface
>> directly to a drive and do all of the work in software. And, likely have
>> time to do something "real", as well!
>>
>> I haven't, yet, found the RIO sources but there likely won't be any
>> magic in the floppy "driver".
>
> Mega is not a good choice for sharing schematics. It opens in a small window on the web page and I can't find a way to full screen it. So the writing is not viewable unless I want to zoom in on each chip where I can't see the context. Too much effort for a newsgroup post.
>

hit the big green download button. or the smaller fullscreen or
printer buttons

--
Jasen.
pǝsɹǝʌǝɹ sʇɥƃᴉɹ ll∀

On Friday, December 30, 2022 at 12:52:17 AM UTC-5, Ricky wrote:
> On Thursday, December 29, 2022 at 9:02:14 PM UTC-5, jjhu...@gmail.com wrote:
> > On Thursday, December 29, 2022 at 6:10:05 PM UTC-5, Three Jeeps wrote:
> > > On Thursday, December 29, 2022 at 1:15:57 PM UTC-5, Ricky wrote:
> > > > On Thursday, December 29, 2022 at 1:04:27 PM UTC-5, jjhu...@gmail.com wrote:
> > > > > Back in the day, I wrote a floppy driver based on the 82077AA for a board I designed. The 82077AA is long gone and I've been away from hardware engineering at this level for a while. I am doing a spare time project where I'd like to revive the FD driver in conjunction with a small SBC. I am wondering what the current chip is that is close to being functionally equivalent to the 82077AA that can actually be bought today?
> > > > > I did some searching and found the Microchip FDC37C78-HT but it seems to be unavailable. There are other FDCs around at the time that were quite popular (e.g. NEC D765, intel 8272 and of course the WDC FDC) but they too are long gone/unabtanium. I like the intel 82077AA because it could interface to a large number of FDCs.
> > > > > I also am considering to throw a FPGA at it, but that would probably be more work than I wanted to devote to it....
> > > > >
> > > > > I'll keep searching but in the interim I thought maybe someone here may have some thoughts/pointers to FDCs that are currently available?
> > > > I'm willing to bet you are going to need to roll your own in an FPGA, with analog circuitry to handle the signals from the heads. I don't know exactly what the FDC does, do you? I guess if you have an interface spec, and especially source code for the driver, you can reverse engineer from that.
> > > >
> > > > You might try finding computer hobbyist groups on Facebook, Linkedin and the like. I'm willing to bet someone has done this before to keep some gear running.
> > > >
> > > > --
> > > >
> > > > Rick C.
> > > >
> > > > - Get 1,000 miles of free Supercharging
> > > > - Tesla referral code - https://ts.la/richard11209
> > > Perhaps I was not clear. The FDC IC controls the data transfer from the disk to the MCU. The disk drive proper contains the analog electronics to position the heads (most often a stepper motor), and pull out the data. The floppy disk controller does not contain any analog processing components and head positioning software/hardware, all that is done on the drive itself.
> > > Yes, a high end micro could probably do the job, but the FDC is a 'cleaner' approach...and if I had to go a different route, I'd use an FPGA instead of the micro. I do have the data sheets for many of the FDC chips of that era, including the 82077AA. While I've done it before for DEC RK07 drives, I don't want to reinvent the wheel on a FPGA if I don't have to.
> > One additional point. I firmly believe that controlling devices at the basic level should be the job of hardware. It is a logical separation of concerns as well as reducing cpu utilization to other jobs the processor can do instead of bit banging a disk drive (or what ever). Maintaining sequencing and timing of signals is efficiently done by hardware, leaving the CPU to handle other tasks. Yea, could throw a processor at it as the controller but that would muddy up the architecture (hardware and sw) of the system I am working with.
> That's a very archaic philosophy. Small MCUs have essentially become programmable hardware. I try to explain to people how much like MCUs an FPGA is.. On the other hand an MCU is very much like an FPGA. The only complaint I have with MCUs is they are much, much harder to use when there are multiple real time things to be done. If each one is has low enough timing requirements, fine, an MCU can manage to do several things without stumbling over them. But in an FPGA, everything runs in parallel unless you want something different.
>
> The only issue with using a small MCU for this task is being able to deal with the floppy interface while at the same time dealing with the other interface (I guess the computer side). If both sides have timing requirements and can be simultaneous, it might be a trick to make it work without missing a beat on both sides.
>
> I have exactly this problem on the board I supply. I used an FPGA, because there is an SPI like command interface that just can't be done in a CPU, even at 700 MIPS (the GA144)! A 33 MHz clock shifts in the data, address and command. Then on the opposite phase of the last clock, response data has to start shifting out! That's 15 ns, or about ten instructions at 700 MIPS. The GA144 is not really 700 MIPS, only the core ALU instructions. This would require a memory access which is nearly three instruction cycles I believe. So, still requires an FPGA for this interface, while much of the rest of the design could be done in a not very fast CPU. There *is* a data/clock recovery circuit that would be hard to do in an MCU, not unlike the MFM floppy interface, and a clocking scheme for the CODEC that requires some hardware... or a very specialized circuit in a PLD.
>
> --
>
> Rick C.
>
> ++ Get 1,000 miles of free Supercharging
> ++ Tesla referral code - https://ts.la/richard11209

With respect, it may be archaic to you but when considering all the cross cutting 'ilities' of the (system) design, there are valid reasons for my approach to the architecture both hardware and software. Just because one can, doesn't mean one should. I'll do what seems reasonable with the system qualities and design constraints that I must deal with/wish to address. You pointed out potential timing issues and jitter in a system is a cause of nondeterministic behavior (something I am very well aware of), better served (in most cases) by a hardware solution, hence my general 'functional hardware specific' approach. Seems to work well with avionics systems I've engineered where reliability, maintainability, testability, and diagnosability are key system attributes that must be paid attention to. Anyway, I appreciate the comments.
J

On Saturday, December 31, 2022 at 11:09:06 AM UTC-5, jjhu...@gmail.com wrote:
> On Friday, December 30, 2022 at 12:52:17 AM UTC-5, Ricky wrote:
> > On Thursday, December 29, 2022 at 9:02:14 PM UTC-5, jjhu...@gmail.com wrote:
> > > On Thursday, December 29, 2022 at 6:10:05 PM UTC-5, Three Jeeps wrote:
> > > > On Thursday, December 29, 2022 at 1:15:57 PM UTC-5, Ricky wrote:
> > > > > On Thursday, December 29, 2022 at 1:04:27 PM UTC-5, jjhu...@gmail..com wrote:
> > > > > > Back in the day, I wrote a floppy driver based on the 82077AA for a board I designed. The 82077AA is long gone and I've been away from hardware engineering at this level for a while. I am doing a spare time project where I'd like to revive the FD driver in conjunction with a small SBC. I am wondering what the current chip is that is close to being functionally equivalent to the 82077AA that can actually be bought today?
> > > > > > I did some searching and found the Microchip FDC37C78-HT but it seems to be unavailable. There are other FDCs around at the time that were quite popular (e.g. NEC D765, intel 8272 and of course the WDC FDC) but they too are long gone/unabtanium. I like the intel 82077AA because it could interface to a large number of FDCs.
> > > > > > I also am considering to throw a FPGA at it, but that would probably be more work than I wanted to devote to it....
> > > > > >
> > > > > > I'll keep searching but in the interim I thought maybe someone here may have some thoughts/pointers to FDCs that are currently available?
> > > > > I'm willing to bet you are going to need to roll your own in an FPGA, with analog circuitry to handle the signals from the heads. I don't know exactly what the FDC does, do you? I guess if you have an interface spec, and especially source code for the driver, you can reverse engineer from that.
> > > > >
> > > > > You might try finding computer hobbyist groups on Facebook, Linkedin and the like. I'm willing to bet someone has done this before to keep some gear running.
> > > > >
> > > > > --
> > > > >
> > > > > Rick C.
> > > > >
> > > > > - Get 1,000 miles of free Supercharging
> > > > > - Tesla referral code - https://ts.la/richard11209
> > > > Perhaps I was not clear. The FDC IC controls the data transfer from the disk to the MCU. The disk drive proper contains the analog electronics to position the heads (most often a stepper motor), and pull out the data. The floppy disk controller does not contain any analog processing components and head positioning software/hardware, all that is done on the drive itself.
> > > > Yes, a high end micro could probably do the job, but the FDC is a 'cleaner' approach...and if I had to go a different route, I'd use an FPGA instead of the micro. I do have the data sheets for many of the FDC chips of that era, including the 82077AA. While I've done it before for DEC RK07 drives, I don't want to reinvent the wheel on a FPGA if I don't have to.
> > > One additional point. I firmly believe that controlling devices at the basic level should be the job of hardware. It is a logical separation of concerns as well as reducing cpu utilization to other jobs the processor can do instead of bit banging a disk drive (or what ever). Maintaining sequencing and timing of signals is efficiently done by hardware, leaving the CPU to handle other tasks. Yea, could throw a processor at it as the controller but that would muddy up the architecture (hardware and sw) of the system I am working with.
> > That's a very archaic philosophy. Small MCUs have essentially become programmable hardware. I try to explain to people how much like MCUs an FPGA is. On the other hand an MCU is very much like an FPGA. The only complaint I have with MCUs is they are much, much harder to use when there are multiple real time things to be done. If each one is has low enough timing requirements, fine, an MCU can manage to do several things without stumbling over them. But in an FPGA, everything runs in parallel unless you want something different.
> >
> > The only issue with using a small MCU for this task is being able to deal with the floppy interface while at the same time dealing with the other interface (I guess the computer side). If both sides have timing requirements and can be simultaneous, it might be a trick to make it work without missing a beat on both sides.
> >
> > I have exactly this problem on the board I supply. I used an FPGA, because there is an SPI like command interface that just can't be done in a CPU, even at 700 MIPS (the GA144)! A 33 MHz clock shifts in the data, address and command. Then on the opposite phase of the last clock, response data has to start shifting out! That's 15 ns, or about ten instructions at 700 MIPS. The GA144 is not really 700 MIPS, only the core ALU instructions. This would require a memory access which is nearly three instruction cycles I believe. So, still requires an FPGA for this interface, while much of the rest of the design could be done in a not very fast CPU. There *is* a data/clock recovery circuit that would be hard to do in an MCU, not unlike the MFM floppy interface, and a clocking scheme for the CODEC that requires some hardware... or a very specialized circuit in a PLD.
> >
> > --
> >
> > Rick C.
> >
> > ++ Get 1,000 miles of free Supercharging
> > ++ Tesla referral code - https://ts.la/richard11209
> With respect, it may be archaic to you but when considering all the cross cutting 'ilities' of the (system) design, there are valid reasons for my approach to the architecture both hardware and software. Just because one can, doesn't mean one should. I'll do what seems reasonable with the system qualities and design constraints that I must deal with/wish to address. You pointed out potential timing issues and jitter in a system is a cause of nondeterministic behavior (something I am very well aware of), better served (in most cases) by a hardware solution, hence my general 'functional hardware specific' approach. Seems to work well with avionics systems I've engineered where reliability, maintainability, testability, and diagnosability are key system attributes that must be paid attention to. Anyway, I appreciate the comments.
> J

I've kinda lost the thread of the discussion with this post. You are talking in very general terms, that I can't connect back to my comments.

Certainly every design is different. Every engineer is different. I, in particular, have found I prefer to not fight the timing issues of using software to manage hardware. I think you are actually agreeing with me when you say you want hardware to handle the time critical portions of the design. My only other point is that if there are many processors available, they can, in essence, be treated as hardware. That's why I mentioned the GA144 chip. I don't think it has found a niche, but the concept is very interesting. The CPUs are very tiny, and numerous enough that they can be thought of as functional elements, the ultimate in a programmable peripheral.

I have a money paying project in front of me right now. But, when I am done with that next year, opps, later this year, I will return to my idea of reusing the logic for a small processor, to make multiple logical processors via time slicing. Rather than have a single process dominate the CPU for some amount of time, each of the processes will get a percentage of the CPU, interleaved at the instruction level. Then, in just a small amount of resources in an FPGA, many small processors can each emulate peripherals or run various software functions without using much resources in the FPGA.

--

Rick C.

-+- Get 1,000 miles of free Supercharging
-+- Tesla referral code - https://ts.la/richard11209

Three Jeeps <jjhudak4@gmail.com> wrote:
> Back in the day, I wrote a floppy driver based on the 82077AA for a board
> I designed. The 82077AA is long gone and I've been away from hardware
> engineering at this level for a while. I am doing a spare time project
> where I'd like to revive the FD driver in conjunction with a small SBC. I
> am wondering what the current chip is that is close to being functionally
> equivalent to the 82077AA that can actually be bought today?

The successor of the standalone floppy disc controller were 'super I/O'
chips which combined floppy with IDE, serial, parallel, keyboard and other
functions, and the current iteration of those hook onto the Low Pin Count
(LPC) interconnect. These chips are still in production:

https://www.microchip.com/en-us/product/LPC47B272

That says it's compatible with the 82077AA core. Although it seems nobody
has stock of those. Digikey has some other LPC47xxx parts but I didn't
check which ones have FDCs.

Mouser does have stock of the FDC37C669 which uses the
ISA bus:
https://eu.mouser.com/ProductDetail/Microchip-Technology/FDC37C669-MS

(about 25 years ago I wrote drivers for it)

Theo

In article <7bd48288-ee79-47ed-8daa-37ff02733534n@googlegroups.com>,
Three Jeeps <jjhudak4@gmail.com> wrote:
>Back in the day, I wrote a floppy driver based on the 82077AA for a
>board I designed. The 82077AA is long gone and I've been away from
>hardware engineering at this level for a while. I am doing a spare time
>project where I'd like to revive the FD driver in conjunction with a
>small SBC. I am wondering what the current chip is that is close to
>being functionally equivalent to the 82077AA that can actually be bought
>today?
>I did some searching and found the Microchip FDC37C78-HT but it seems to
>be unavailable. There are other FDCs around at the time that were quite
>popular (e.g. NEC D765, intel 8272 and of course the WDC FDC) but they
>too are long gone/unabtanium. I like the intel 82077AA because it could
>interface to a large number of FDCs.
>I also am considering to throw a FPGA at it, but that would probably be
>more work than I wanted to devote to it....
>
>I'll keep searching but in the interim I thought maybe someone here may
>have some thoughts/pointers to FDCs that are currently available?
>Thanks
>J

I'd look into the Raspberry pico, with its 10 independant IO processors.
Buzzing community too.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -