68060 based QL system?

Nagging hardware related question? Post here!

Do you want a 68060 based QL system?

No, better improve speed of FPGA based 68K
12
43%
Original Q60 with video updates
5
18%
New 68060 system design
11
39%
 
Total votes: 28

User avatar
Whopper
Over Heated PSU
Posts: 126
Joined: Tue Oct 24, 2017 4:04 pm

Re: 68060 based QL system?

Post by Whopper »

My 2d worth.

A new 68060 design / build would be great.

Of course it wouldn't be as fast as an emulator, but the point is that it's a retro computer. If I want a fast computer I wouldn't even consider a 68K. For a RETRO computer though the 68060 is the bees knees.

Some things that I think would improve the experience are
  • higher resolution, up to CGA
  • More colours, up to 256
  • More memory, a medium amount to start with but expandable
  • I2C, a must I think
  • Easily accessed IO space
  • Video outputs, VGA, RGB
  • Mass storage, IDE 40 pin & 34 pin
So, to recap. Would I like a 68060 based QL, most definitely yes.

wopper


You woke me for THAT!!!
smsq4ever
ROM Dongle
Posts: 23
Joined: Sat Aug 29, 2015 11:18 pm

Re: 68060 based QL system?

Post by smsq4ever »

As a happy (but worried) owner of a Q60, I'd vote for a video circuit upgrade, since LCD monitors are incapable of properly syncing the Q60 1024x512 mode (the last monitor I tried it with, an Eizo FlexScan EV2455, manages to sync it, but in VGA 640x480 mode, meaning 32 lines are missing and the horizontal pixels are badly distorted/mingled), and I could not find any video converter that could properly sync it either.
My worry is that the last monitor I got that can still display the Q60 screen is over 15 years old and won't last forever (I already repaired it twice)...

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.


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: 68060 based QL system?

Post by Peter »

smsq4ever wrote:My worry is that the last monitor I got that can still display the Q60 screen is over 15 years old and won't last forever (I already repaired it twice)...
As mentioned earlier, I'm currently in the test phase of a stopgap solution. Less than ideal, because it leave one third of the screen black.
smsq4ever wrote: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.
The question is what is "enough"... Even if peripheral data is transferred by DMA, at some point the CPU must process it. E.g. pictures must be decoded, websites must be rendered, etc. Usually the bottleneck will be the processing, not the low-level copying.


smsq4ever
ROM Dongle
Posts: 23
Joined: Sat Aug 29, 2015 11:18 pm

Re: 68060 based QL system?

Post by smsq4ever »

Peter wrote:
smsq4ever wrote:My worry is that the last monitor I got that can still display the Q60 screen is over 15 years old and won't last forever (I already repaired it twice)...
As mentioned earlier, I'm currently in the test phase of a stopgap solution. Less than ideal, because it leave one third of the screen black.
That would be great, nonetheless. Another solution would be to add a 800x600 SVGA mode to the Q60: it would still fit the on board video memory without leaving any such blank gap...
Peter wrote:
smsq4ever wrote: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.
The question is what is "enough"... Even if peripheral data is transferred by DMA, at some point the CPU must process it. E.g. pictures must be decoded, websites must be rendered, etc. Usually the bottleneck will be the processing, not the low-level copying.
Believe me (as the implementer of the ATAPI/CD-ROM driver for the Q60), data transfer via the CPU *is* the bottleneck: for example, with DMA, it would be possible to load a program from a CD-R to the memory without the CPU slowing down the data rate and without experiencing any "freeze" of the OS while the CPU is busy in PIO mode. If the CPU spends 80% of the time just for moving bytes around, the system slows down to a crawl while with DMA, transfers happen at full speed and without any significant slow down of the OS or user programs.


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: 68060 based QL system?

Post by Peter »

smsq4ever wrote:Believe me (as the implementer of the ATAPI/CD-ROM driver for the Q60), data transfer via the CPU *is* the bottleneck
There were several ways to access CDROM by Duncan, Wolfgang and Thierry, so I don't know who you are, and what you mean in particular. Maybe tell us?

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. It would just free more CPU time for other tasks during transfer.
smsq4ever wrote:for example, with DMA, it would be possible to load a program from a CD-R to the memory without the CPU slowing down the data rate
No, because it is not the CPU which slows down the data rate. At least not more than a small percentage. If the DMA controller loads the data, it will load it just as slow as the CPU. Depending on how DMA controller and CPU compete for memory bandwidth, and depending on the management overhead for DMA, it could even be a slightly lower data rate.
smsq4ever wrote:and without experiencing any "freeze" of the OS while the CPU is busy in PIO mode.
Yes in theory, but "freezing" is a driver issue as well. As long as SMSQ/E does not provide an interrupt driven background driver here, that would be the first thing to look at. IIRC CDROM access behaved better under LInux with the same hardware.

Note: Managing a DMA controller would require quite difficult SMSQ/E driver work, while the current driver does not even support interrupts. If nobody is motivated for relatively simple improvements, I have no idea who should be further motivated to write DMA drivers. Especially today, when a 68060 system will be slower than emulation anyway.

The question remains, what peripheral speed is "enough"... when actually processing the data for application purposes is limited by the CPU.


smsq4ever
ROM Dongle
Posts: 23
Joined: Sat Aug 29, 2015 11:18 pm

Re: 68060 based QL system?

Post by smsq4ever »

Peter wrote:
smsq4ever wrote:Believe me (as the implementer of the ATAPI/CD-ROM driver for the Q60), data transfer via the CPU *is* the bottleneck
There were several ways to access CDROM by Duncan, Wolfgang and Thierry, so I don't know who you are, and what you mean in particular. Maybe tell us?
The latter (I prefer to keep as anonymous as I can on Internet nowadays). And AFAIK, only the ATAPI/CDROM thing I wrote allows to access a CD-ROM in data mode on the Q60 (and it also works on the QUBIDE v1 I/F, even though I guess the firmware of the latter was since updated in v2 to access CD-ROMs as well), and it was certainly the first ATAPI driver for QDOS/SMS (it was released in 2001, alas shortly before I had to abandon all QDOS/SMS development due to professional constraints).
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 !!!!
Your "feeling" about DMA on ISA speed is probably related to the fact that the first PCs (XTs) had very slow DMA chips (that were clocked at only 4.77MHz when the ISA bus could run at 12MHz) and that by design (segmented/paged memory), the x86 architecture was limited by 64kB transfers: back in that (old) time, PIO modes were faster than DMA, but that was entirely related to the PC architecture.

Plus, for a future design, I'd recommend adopting a PCI bus: ISA cards become a rarity and an ISA bus, while much simpler to interface, won't be very desirable, really...
With PCI "DMA" is actually a bus arbitration system, but the principle (freeing the CPU from the high burden resulting from data transfers) is the same.
It would just free more CPU time for other tasks during transfer, if peripheral bus throughput is low. (Your SATA example would have a fast peripheral bus.)
Note that my ATAPI driver uses packets transfer in the scheduler interrupt loop to avoid as much as possible to "freeze" the system; a slow peripheral therefore does NOT slow down the system (since only small packets are transferred each time).

Nevertheless, without DMA, the CPU gets monopolized by the data transfer and all the other tasks in the system are "frozen" while it happens, especially under QDOS/SMS where TRAPs (or any code running in supervisor mode) cannot be preempted by the scheduler; so, even if the DMA controller was not able to do better than the CPU (which won't be the case anyway), DMA still brings a HUGE performance improvement, seen from the user's point of view (no system "freeze" during large data transfers).
.../...
smsq4ever wrote:and without experiencing any "freeze" of the OS while the CPU is busy in PIO mode.
"Freezing" is a driver issue as well. As long as SMSQ/E does not provide an interrupt driven background driver here, that would be the first thing to look at. IIRC LInux CDROM access behaved better with the same hardware.
Thus why it is utterly essential to minimize the time spent executing driver code in supervisor mode. DMA allows to free up all the time used by the CPU (in supervisor mode) to transfer the data, word by word, in a loop, which is very inefficient.
Note: Managing a DMA controller would require quite difficult SMSQ/E driver work, while the current driver does not even support interrupts. If nobody is motivated for relatively simple improvements, I have no idea who should be further motivated to write DMA drivers. Especially today, where a 68060 system will be slower than emulation anyway.
Nothing difficult. Just telling the DMA controller what to do and coming back later to see if the buffer got loaded with the data... Dealing with ATAPI PIO modes (with handshakes between the CPU and the IDE controller) is in fact more complicated !


User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: 68060 based QL system?

Post by pjw »

Your nom de plume is a dead giveaway, if nothing else ;) Echoes from the past.. Anyway, I hope you are coming in from the cold!


Per
dont be happy. worry
- ?
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: 68060 based QL system?

Post by Peter »

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.
smsq4ever wrote:DMA still brings a HUGE performance improvement, seen from the user's point of view (no system "freeze" during large data transfers).
I'd say moderate to huge, depending on which other improvements are considered as alternative, and what the user actually needs that data stream for.
Anyway, your original performance issue was transfer speed, not that.

Which peripheral transfer rate do you find adequate for a 68060 system, in the light of emulators being much faster anyway?
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.
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.

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.

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.


smsq4ever
ROM Dongle
Posts: 23
Joined: Sat Aug 29, 2015 11:18 pm

Re: 68060 based QL system?

Post by smsq4ever »

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.


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: 68060 based QL system?

Post by Peter »

smsq4ever wrote: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...
Trivial to understand, I had already confirmed that after your first mention, just adding that background behaviour it is a driver issue (currently not even using IRQ) as well.

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.
smsq4ever wrote: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).
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 really makes no sense to optimize a 68060 system to the utmost, as you propose, and then run it without copyback cache.
smsq4ever wrote: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.
No, I never said it won't bring any improvement. I just kept the distinction between transfer rate and background CPU time, explaining why DMA would not improve the former for us. (Or even deteriorate, in case of a relatively simple implementation.)


Post Reply