Peter wrote:smsq4ever wrote:Peter wrote:Either way, it is the peripheral bus (ISA), not the CPU, which slows down CDROM data transfer on the Q60. DMA would not speed up the transfer.
Oh yes it would !!!!
No. For an ISA bus design with a CPU as fast as 68060, throughput is just a matter of generating optimal repetitive ISA bus cycles to be seen by the card. Whether the CPU or a DMA controller is actually behind those cycles, does not matter for throughput. Not that the Q60 is ideal here, but it is a matter of peripheral bus implementation, not DMA.
You don't seem to understand that in a computer system (and QDOS/SMS is no different in this respect), the CPU is best used doing cleverer things than just moving bytes between an I/F and memory... However you put it, while the CPU is busy dealing with data transfers with interfaces, it cannot do anything else and, in the case of non-preemptible system calls (which is the characteristic of QDOS/SMS) this is a "freeze" experienced by the user each time such a transfer happens !
Which peripheral transfer rate do you find adequate for a 68060 system, in the light of emulators being much faster anyway?
This is irrelevant. If you need maximum speed, then use an emulator. Yet, an emulator is not the "true thing", thus why I personally prefer the Q60 to QPC when I do QL stuff... It does not mean we can't think of a good design for a new QL hardware that would squeeze out the most from a 680x0-compatible "CPU" (or FPGA emulated CPU). Without DMA (or bus arbitration for a PCI bus), you won't get the most out of the hardware. Period.
smsq4ever wrote:DMA allows to free up all the time used by the CPU (in supervisor mode) to transfer the data
No. DMA must access the same bus to RAM, and the CPU can of course not use it concurrently.
It depends: transparent DMA access might be feasible, or cycle stealing, especially with very fast modern memory... Plus, even with burst mode DMA, a 68060-compatible CPU would keep running code from its caches during at least part of the transfer.
smsq4ever wrote:word by word, in a loop, which is very inefficient.
Look what practically happens on the bus during transfer, if you do it with the 68060: The instructions are cached, no bus activity. The 68060 will do repeated slow word access to the peripheral bus, with the same timing as a DMA controller - no disadvantage. At times, the copyback controller will transfer the data from cache to DRAM in efficient 32 bit bursts. That is all you see on the bus. And with decent driver, it practically happens back-to-back, because of the internal design of the 68060. I have no idea why this should be "very" inefficient.
Again, you do not see the problem where it lies: the CPU must be reserved for
noble tasks, not for transferring data, and no, even with its caches, the CPU just cannot match a proper DMA controller able to transfer at a rate equal to the bus or memory bandwidth (whichever is the lower). The problem is even more crucial for OSes like QDOS/SMS where the system calls are non-preemtible: offloading the data transfers to the DMA controller reduces the amount of time the CPU must spend in supervisor mode.
As a side note, on the Q60, the copy back mode cannot be used, short of baring any use of QLiberated programs (and some others, with self-modifying code).
A simple DMA controller could not even match this. You'd need a DMA controller hardware with features like this: Internal RAM for buffering, DRAM burst access capabilities, and a clever bus arbitration. A considerable amount of design work, while there are so many other needs for the QL.
I never said the hardware design would be easy, but I find it worth thinking about it instead of wiping the idea from the back of your hand under the (false and erroneous) pretext that it won't bring any performance improvement.
Regarding "nothing difficult" in DMA driver development: It is all relative... Using IRQ for Q60 mass storage is also "not difficult" then, but didn't happen.
QDOS/SMS IRQs are already pre-affected, so it lets very little choice (IRQ7, IIRC) for implementing IRQ-driven drivers. But it's just a driver design choice and yes, using IRQs is nothing hard at all.