QL replica

[pjw]

<>
The Qzero has dual SDRAM onboard, allowing more than 100% speed increase in 1024x768 highcolor mode over the Q68. A new Q68 could re-use this hardware, either by Qzero as a module (faster development) or an all-in-one PCB (cheaper). I diverted to the QIMSI project for a while. But if interest in the Q68 remains, a follow-up is something I would seriously consider.<>

[My emphasis] I am interested, and would support it by buying one. For my taste It still wont be fast enough to be a real "work QL" for the 21st century, of course but I live in hope ..

IMO it isnt the lack of hardware that is the gating factor here, but the lack of developers improving smsq/e. Peter is a super clever guy, he can design a super modern QL. But who would write all the drivers required?

We seem to have muddled along fine so far! Which particular driver(s) are you missing?
While development may be slow, drivers for dangling hardware may appear eventually, viz the network driver. Its more likely than the other way round: that anyone will attempt to write a driver for non-existing hardware.

[Peter]

While development may be slow, drivers for dangling hardware may appear eventually, viz the network driver.

This only worked (within modest limits) because:
1. All my hardware was designed with units that were especially simple and well suited for QL driver development. No USB for example.
2. I wrote/ported test software for everything myself and could prove the concept and the working hardware.
3. I provided working and tested lowlevel routines in C that could later be ported to assembler by others.

Bringing out a hot new piece of hardware, and then just wait for QL drivers to be written, has not worked for the last 25 years and will - in my humble opinion - never work. Within 25 years, we have not even managed to get rid of the SLAVE buffering that slows down every mass storage to a crawl if large files have to be accessed incrementally. (Except for Tobias, who understandably does not have the time to finish his work.)

This shows the very limited possibilites we have. If not even relatively simple mass storage can get adequate driver support, it is unrealistic to hope for something really complex like native USB.

Of course, not having drivers can be worked around by "outsourcing" tasks from the 68K side to external CPUs - but I doubt this is what we mean, when we talk about native hardware.

[Derek_Stewart]

HI,

I do not think writing device driver for non-existent hardware can be done, as everyone has their own idea of what the hardware should be.

But what about getting SMSQ/E running on BBQL that does not require a Super/Gold Card.

[pjw]

While development may be slow, drivers for dangling hardware may appear eventually, viz the network driver.

<>
Bringing out a hot new piece of hardware, and then just wait for QL drivers to be written, has not worked for the last 25 years and will - in my humble opinion - never work.

If you look at whats been going on in this forum for the past few years,
its rarely been about "hot new hardware" but on improving what we've
already got, bit by bit. That would be my idea for improving the hot new
hardware we actually have (not least of all thanks to you!)

Personally I dont feel an urge for USB, which seems to be the only example
of hot new hardware mooted that doesnt currently have any native drivers on
QL systems. QL, Aurora, Qx0, Q68 currently have all the drivers they need
to function as stand-alone computer systems. Faster versions of the latter
wont necessarily require new drivers; at worst existing drivers may need to
be tweaked for higher performance hardware. This community seems to be
pretty adept at tweaking..

Examples of how this has worked is the amazing variety of SD card drivers,
WIN container drivers, QUB, etc. Correct me where Im wrong, but almost all
of these drivers are adaptations, many by people who would only with
difficulty, or with plenty of time, have been able to write such a driver
from scratch.

Within 25 years, we have not even managed to get rid of the SLAVE buffering that slows down every mass storage to a crawl if large files have to be accessed incrementally. (Except for Tobias, who understandably does not have the time to finish his work.)

Perhaps not, but the "temporary hack" to limit the memory available to
slaving has virtually neutralised any symptoms. I dont see how this would
cause problems for any furture hot hardware.

This shows the very limited possibilites we have. If not even relatively simple mass storage can get adequate driver support, it is unrealistic to hope for something really complex like native USB.

I have no idea how complicated the physical aspects of USB hardware is to
implement, but if it is "easy" then Id say: Just add it! "Let not
perfection be the enemy of sufficient." Theres a 1000% greater chance that
someone, at some time, will produce a driver, or find some other mad
solution to make use of it, than if it werent physically present.

Of course, not having drivers can be worked around by "outsourcing" tasks from the 68K side to external CPUs - but I doubt this is what we mean, when we talk about native hardware.

Theres no shame in compromise between everything and nothing.. Its not
black or white, but a continuum. Eg FPGA vs "real" hardware.

My horizon for the "QL" - in particular Qdos/SMSQ - is 2097 - way past my
smell-by date! (and I guess that includes just about everyone here..) None
of us can know what the future brings. But if we create deliberate dead-
ends now we can be pretty certain that thats where they lead. If we leave
things open ended, theres a much greater chance that they will continue..

[Peter]

Perhaps not, but the "temporary hack" to limit the memory available to slaving has virtually neutralised any symptoms.

No it didn't. Still only FS.LOAD works at full speed on native hardware, even under SMSQ/E which contains this hack.
We lack the manpower to get rid of a 40 year old performance hog, even for simple hardware.

I dont see how this would cause problems for any furture hot hardware.

It was just an example, illustrating that we don't have the software manpower for something beyond retro computing.

[Derek_Stewart]

Hi,

What about Q68, QIMSI, they both see hot hardware to me, why not write enhanced drivers for those platforms.

Or maybe enhance SMSQ/E to use long filenames, seemingly impossible, but I those programmers like a challenge.

[pjw]

Perhaps not, but the "temporary hack" to limit the memory available to slaving has virtually neutralised any symptoms.

No it didn't. Still only FS.LOAD works at full speed on native hardware, even under SMSQ/E which contains this hack.
We lack the manpower to get rid of a 40 year old performance hog, even for simple hardware.<>

I don't doubt your word, Peter, but since my experience on the platforms I
normally work with don't appear to present with this "bottleneck" I ran a
batch of tests.

You are right that on QL hardware, that is to say on SLOW platforms, I get
that iof.load/iof.save is between 3 and 10 times faster than
iob.fmul/iob.smul, the latter affecting, for example, COPY operations
(which can be worked around when it really matters). On fast platforms,
such as QPC and SMSQmulator its negligible. On Q-emulator running at full
speed even with Qdos and Minerva the difference in day-to-day usage is
virtually unnoticeable.

In other words, the fact that such a bottleneck exists (and KNOWING its
there!) is annoying and unnecessarily slows some things down, in practice
the main bottleneck is down to the SPEED of the hardware (CPU, memory),
not software. Yet on really slow systems with limited memory, such as the
BBQL, slaving is a positive.

[Peter]

On fast platforms, such as QPC and SMSQmulator its negligible.

Those are software emulators using Windows/Linux drivers. The issue was native hardware drivers.

Yet on really slow systems with limited memory, such as the BBQL, slaving is a positive.

True for floppy and microdrives, but with QL mass storage of the last 25 years, it is the opposite. The effect of SLAVEing is devastating on slow systems like the BBQL!
Example: While a Q68 can still play sampled sound despite SLAVEing, the BBQL hardware fails on such a task. The only workaround is to allocate nearly all BBQL RAM so there are practically no SLAVE buffers anymore. Which is what my rudimentary demo sound player does.

Already since ROMdisQ days, SLAVEing for QL mass storage is obsolete. Conseqently Tony Tebby wrote drivers without SLAVEing for ROMdisQ. But the sourcecode is lost, and we had no manpower anymore to achieve drivers like that again in decades.

[Derek_Stewart]

Already since ROMdisQ days, SLAVEing for QL mass storage is obsolete. Conseqently Tony Tebby wrote drivers without SLAVEing for ROMdisQ. But the sourcecode is lost, and we had no manpower anymore to achieve drivers like that again in decades.

It is a little worse position, with regards to the Romdisq.

A few years ago, I made arrangements to reproduce the Romdisq, I agreed a licence to manufacture the hardware. When I asked for the construction files to make the PCB, programme the CPLD, driver source code, I was told that the computer that had held these files had been disposed of. No backups...

I was thinking about reverse engineering the Romdisq I have and disassembling the CPLD code and software driver.

Then the QIMSI was released, which a good replacement for the Romdisq.

The Rondisq had a nice feature of allowing ROM images stored on the Romdisq to be loaded into the QL as a valid ROM. A good feature, but this can be done in another way.

[Peter]

Then the QIMSI was released, which a good replacement for the Romdisq.

Yes. Except for the SLAVEing...