Intel 82077AA functional replacement?

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.

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.

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

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.

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:

Mouser does have stock of the FDC37C669 which uses the ISA bus:

Theo

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

Groetjes Albert