The Sinclair QL Forum

Peter wrote:I just kept coming back to your original point that DMA was required for faster data transfer rate, which remains wrong, no matter how you turn it.

Sad that you don't admit that a well implemented DMA, able to transfer one word (with word width = bus width) at each bus or memory clock cycle is *obviously* faster than a CPU needing several clock cycles to just transfer one word, not even taking into account the counter-decrement/test/branch instruction overhead. Even when executed from cache, look at the 68060 timing for each instruction, and you will see by yourself.

Can't this 68060-QLiberator problem be solved at it's roots? I lack sufficient knowledge about it, rarely used QLiberated BASIC at all.

It probably could: I gave it a try, back in 2000, but without the sources for QLib_run, and without a debugger/monitor able to deal with the full 68060 instructions set and features (especially the cache related ones) it did not lead anywhere. With the commented sources, finding the culprit code sequence and fixing it seems however quite feasible.

Note also that you description of the copyback burst is only related to writes to memory or I/F (not reads).

smsq4ever wrote:

Peter wrote:I just kept coming back to your original point that DMA was required for faster data transfer rate, which remains wrong, no matter how you turn it.

Sad that you don't admit that a well implemented DMA, able to transfer one word (with word width = bus width) at each bus or memory clock cycle is *obviously* faster than a CPU needing several clock cycles to just transfer one word, not even taking into account the counter-decrement/test/branch instruction overhead. Even when executed from cache, look at the 68060 timing for each instruction, and you will see by yourself.

Sorry, but you are again shifting the scenario away from what we were talking about. You brought up Q60/ISA as a case where DMA would allow higher data rate. If you stay at your own case, you remain wrong. During a block, the cycles created by the 68060 for peripheral and DRAM burst are practically back-to-back. That was not just looked up in 68060 manual, it was even measured by scope. DMA can not be faster on the same bus implementation, especially not if it leaves room for CPU access. What you are effectively mixing in now, is having a different bus system, not just DMA. I'm tired of this style of discussion.

smsq4ever wrote:Note also that you description of the copyback burst is only related to writes to memory or I/F (not reads).

Why should there be no burst on memory read?

Peter wrote:Sorry, but you keep shifting scenarios away from what was previously discussed, instead of simply admitting you were wrong. You brought up Q60/ISA as a case where DMA would allow higher data rate.

Not at all !!!

I simply said that *for a modern design* (the subject of this thread), DMA was a must have.

Citation of my first post:

As for a new 68060 design, the "true thing" (with a genuine 68060RC) is doomed by the lack of available (and affordable) CPUs, but the FPGA approach seems worth investigating... However, I'd recommend implementing DMA support for such a new board, because the (emulated) 68060 cannot deal with modern peripherals (think 100Mbps Ethernet or SATA HDs) to transfer data fast enough.

It looks like you shifted the topic to Q60 and ISA, not I...

Anyway, I'm tired of this fruitless discussion. I said what I had to say and I will not loose any more time.

You came up with your Q60 CDROM experiences, then:

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 !!!!

That's how you started the dispute, of course about Q60/ISA scenario. Even with four exclamation marks...

What followed were your time consuming sideways, and allocating opinions to me that I never had - just not to admit the statement was simply wrong. This type of arguing has a somewhat demotivating effect, when it comes to consider large amounts of work.

Peter wrote:You came up with your Q60 CDROM experiences, then:
That's how you started the dispute, of course about Q60/ISA scenario. Even with four exclamation marks...

What followed were your time consuming sideways, and allocating opinions to me that I never had - just not to admit the statement was simply wrong.

Again, you are turning tables when you are the one who mentioned the Q60 in the first place (when all I was saying was about a future 68060-compatible system), when you 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.

I then replied and I do maintain, that even on the ISA bus, DMA would still allow faster operations, and I explained why, also pointing out that the transfer speed was only part of the gain, the other part, and by far the essential one for non-preemptible system calls, was the offloading of the data transfers from the CPU.

This type of arguing has a somewhat demotivating effect, when it comes to consider large amounts of work.

Indeed, and quite demotivating for me as well. I could have considered writing new drivers in the future, but I guess I will not invest time at all any more on the QL scene.

I'm returning to the silent QL observer role (I'm busy enough with Linux software writing anyway).

Have a nice day.

Hi,

Interesting message thread, I was under the impression that DMA could not be used on the Q60.

I was think about making more Q60 boards, after the Q68 demand is satisfied.

I would be interested in new device drivers for the Q60.

If you can take control of the bus, then you can use DMA.

As far as I know, all the Motorola 68K processors have the ability to share bus with some other processor or device.

Derek_Stewart wrote:I was under the impression that DMA could not be used on the Q60.

It can't since there is no DMA controller on the Q60. Peter apparently took it as a reproach while I was not even speaking about the Q60 but was just saying that for a future design, a DMA mode (or more likely a bus arbitrator with a PCI bus) would be the way to go, given how faster are nowadays' peripherals (100Mbps or even 1Gbps Ethernet, SATA drives, etc).

I was think about making more Q60 boards, after the Q68 demand is satisfied.

Problems: 68060RC availability and price, no LCD display compatible mode, ISA cards availability... Not sure it is viable any more nowadays.

Derek_Stewart wrote:Interesting message thread, I was under the impression that DMA could not be used on the Q60.

On the current Q60, there is no DMA controller. T. just claimed, that it would increase transfer rate, if implemented. Which it can not, because the bus is the bottleneck, and as I have shown, the 68060 is already capable to use it at full capacity. (Note that T. no longer says DMA would increase transfer rate on the Q60. He just repeats similar sounding statements, to obfuscate he was wrong.)

The rest of the discussion were sideways to some obvious advantages of DMA, opinions that I never had, different bus implementation etc. Glad if it had interesting aspects for others, for me it was mostly waste of time.

smsq4ever wrote:Problems: 68060RC availability and price, no LCD display compatible mode, ISA cards availability... Not sure it is viable any more nowadays.

As for Q60 flatscreen support, there is a solution in test phase, just not ideal, as it leaves one third of the screen black. There are three test machines, and I had no negative reports yet. Picture quality is reported to be quite good, just not extremely sharp as on the Q68. This is because the output drivers of the Q60's ispLSI chips have a slower slewrate than the FPGA of the Q68.