The question is to ask:
Will it be more accurate?
What is the most sucessful way to do MFM decoding or that matter GCR from disc?
* Write it in BASIC using INB .. on a single user system?
* Write it in C using inb() on a multiuser system?
* Write it in assemble using inb xx on a bare bones system?
* Code it as an hardware description (HDL) equalient ?
* Wirewrap it with 7400 circuits?
* Etch an ASIC at horrendous cost?
Recall that these signals come at a synchronous specific time and doesn't wait for anything. And you need to listen to them with precision and act on them on time, all the time. There's also DRAM signals, bus responses, video generation, communication etc that all need the right response on time.
Add the complexity of several way more complicated circuits that all act in parallel with defined realtime responses. If you try to implement this on a single CPU system you will need to find out which signals that need hard realtime response and do a check-and respond to all those signals without ever delaying outside time boundaries. This means system response will be dependent on the total service loop execution time. A huge liability. The other liability is that this signal servicing will not be in lock step with the system as a whole and thus introduce time jitter..
(a multi-CPU system makes this easier, but it still suffer from the same fundamental flaw)
When the possibility exist to model a signal system which is what the electrical circuitry really implement. The design thought process can focus on the modeling instead of explicit response times and time critical signal hooks. And when the model is correct it will "just work(tm)". Instead of having to figure out how to implement this as sequential code. So it is in the essence signal path description vs sequential code equalient.
As bonus that comes from being unimpeded by central clock phase, cache, logic bare bone etc one can interact with real hardware interfaces. A PC with a 2 GHz CPU should be able to respond to an I/O within 3 instructions so in the ballpark of 1.5 ns. But real life test rarely finds the parallel port respond faster than 1000 ns.
I hope this gives some understanding on the issues that FPGA/CPLD/7400 etc makes it possible to deal with efficiently.
