The Sinclair QL Forum

Getting back to the real question, do you want a low cost, but very high performance second processor?
If the answer is yes, it makes sense to make the interface compatible with the Acorn Tube.
Why? Well because the Acorn community have already developed a Raspberry Pi solution called PiTubeDirect. See the details here. The required board with the cable connector and level shifters is already available (here is one seller).

Extract from the linked to Github page:

A choice of:

• 274MHz 65C102
• 3MHz 65C102
• 112MHz Z80
• 63MHz 80286
• 27MHz 6809
• 59MHz ARM2
• 35MHz 32016
• null co-pro (to save having to power off the pi)
• 1000MHz ARMnative

Equivalent speeds are approximate. Generally a Pi 3 will run faster than a Pi 1.

All of which only requires a relatively simple hardware interface on the QL.

The hardest part will be running the required software fast enough with minimal latency on the QL side.

Mark

Dave wrote:

Silvester wrote:But that can be better done with fast SERial 68681 (one of the reasons why I'm doing it); 31250 MIDI option with opto-isolators along with full SER.

You'd have to change the crystal to get the right baud rate out of the 68681, so you would need to use a separate 68681 for MIDI and for serial. If the crystal frequency is changed to 3MHz, using the division ratio 96, the MIDI 31.25k baud rate will be matched exactly.

According to the SCC68681 datasheet (also SCL28L92) you can use IP2-5 to externally clock Rx & Tx of channel A or B. I am using 3.6864MHz crystal for UART for standard baud rates (SER3/4) but then feeding 500kHz into IP2 and IP5 for channel B. So if I open SER4 as MIDI1 it will set up clock registers for channel B Rx/Tx to setting 1110 (use IP2/5 as 16x clock source).

(If SER4 is already open then open to MIDI1 gets 'in use', and vice versa).

Dave wrote:Take a look at the NXP SCC2691. It has an auto-repeater feature which make the in/thru/out implementation not require any extra repeater hardware.

Application notes here, for your enjoyment:

https://www.nxp.com/docs/en/application-note/AN405.pdf

Thanks. Surprised it didn't mention possible use of external clock option. I guess the acid test is to prove it works (should get 68681 in next few days).

1024MAK wrote:All of which only requires a relatively simple hardware interface on the QL.

From my simple understanding of the tube, while the processors do run completely asynchronously the beeb side bus is assumed to run at 2MHz. Level shifting is easy, and using the registers and FIFOs is straightforward, but matching the Tube/Pi's expectation of a 2MHz bus is problematic.

So, with the basic groundwork of that it is possible, either by tube or by shared address space, the real question is... If you were able to have a guest CPU or CPU and OS, what would your application be?

If this is a solution in search of a problem and nobody has a problem to fix with it, well, it's quite limited.

I think the notion of running CP/M on a fast Z80 is appealing, but beyond that, I don't really have many ideas. So... Do you?

The lack of response has told me what I needed to know.


So, now to push the conversation in a new direction with a new thread... :O

Hi Dave,

I would not go for a CP/M system, as this is already available by software emulation.

I would like a 6502 based system to run BBC Micro software, or other 6502 systems.

Maybe just adding a Raspberry PI as a second processor to run Linux software or emukated systems.

Derek_Stewart wrote:Hi Dave,

I would not go for a CP/M system, as this is already available by software emulation.

But very, very slow. I have tried both versions, one from DP and even the one from Peter Szymanski as ROM is sooooo slow. Not very good, a real Z80 would make it.

I have CP/M on one of my QLs and it is approximately the equivalent of a 75KHz-100KHz Z80. It's really, REALLY bad.

It would be quite simple to have an expansion aZ80 at 40MHz running CP/M natively, and just peer into the keyboard/storage IO and character ROM area to handle all IO and storage. With a 40MHz Z80, I can estimate that CP/M would run approximately 200x faster on a real CPU. The QL's CPU would also remain mostly free to run QDOS tasks.

That said, I'm still working on that other post, to examine the other side of this discussion - symmetric multiprocessing.

1024MAK wrote:Getting back to the real question, do you want a low cost, but very high performance second processor?
If the answer is yes, it makes sense to make the interface compatible with the Acorn Tube.

By the same token it's an even better idea to implement a socket for a modern Intel PC processor...

The documentation clearly shows that the Acorn Tube is designed around using the BBC operating system, and this extends down to the very hardware, which is tailored to pass parameters the way OS calls do it. How this is relevant to a machine that runs an entirely different OS with a completely different abstraction of it's operations and methods of parameter passing, is beyond me. Just about the only sense I can see in implementing a Tube in the QL is to make it run a QL style OS on the BBC, which is somewhat of an attempt to add awkward to futile.

At the very least, a simple(r) dual port attachment method (and these also implement some mailbox and interrupt mechanisms) and use of general 'mailbox' type access between systems offers a far more universal and flexible mechanism. Since adding a second CPU or uC (for any purpose) requires software support which does not exist already, it's a better idea to implement something requiring less effort to program, and is not constrained by legacy architecture based on a completely foreign OS, and one based on a different abstraction of hardware and processing in general, to boot.

Also, let's note the topic of the thread, which denotes a system where there is a rather clear divide between what the main CPU does (executes applications and the OS), and the other CPUs or uCs do - abstract hardware to implement special functions and hence add or accelerate functionality to the core OS - i.e. they do NOT run applications or the OS as such, and do not directly share the load of said OS and apps on the main CPU. Common applications are abstracting more complex IO operations to a simple set that can be used across many devices (such as a caching controller for hard drives, or a uC implementing a protocol like TCP/IP), human interface devices (from simple keyboard IO to intelligent graphics controllers), signal processing and cryptography (compression/decompression of general or specific data like audio and video, vector and matrix processing) and even simpler functions such as floating point math. Also, emulation of other systems, though this is almost a special category in itself.

so where is this thread going?