Asymmetric multiprocessing...

Nagging hardware related question? Post here!
Derek_Stewart
Font of All Knowledge
Posts: 3932
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Asymmetric multiprocessing...

Post by Derek_Stewart »

Pr0f wrote:How much work would be involved in doing a 'Tube' like the BBC ? There is even an option to have a raspberry pi zero as tube add on, all be it with bespoke code running.
Hi,

There is a BBC Tube add on card for the Acorn Electron and an interface to add a Rapberry PI as a second processor.

I think that hard part woud be the Tube software to the QL or do you think if the hardware was created correctly, the exisiting Electron Tube software would see no difference and function correctly.

I have a Acorn Electron and was looking to a a PI to it, so maube this could be investigated to possible interface to the QL.


Regards,

Derek
User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

Re: Asymmetric multiprocessing...

Post by Pr0f »

The hardware side is quiet simple - it's Dave's dual port RAM idea. But the software - that's a different thing all together.

But the tube I/o or memory map is quite well defined, so it should be possible to create the equivalent calls and interfaces for Qdos


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Asymmetric multiprocessing...

Post by Dave »

The hardware for that would be comically simple. If you develop the calls/traps, the hardware will definitely be available for you to play on.

More interestingly, it would be fairly easy to just have a DPRAM "bridge" card than could then accept one or multiple CPU cards. I have some 64Kx16 DPRAMs that would be able to map in the lower byte for one CPU and the upper byte for the other CPU, or could pair up a 16-bit CPU.


User avatar
1024MAK
Super Gold Card
Posts: 592
Joined: Sun Dec 11, 2011 1:16 am
Location: Looking forward to summer in Somerset, UK...

Re: Asymmetric multiprocessing...

Post by 1024MAK »

The hardware for an Tube “interface” does not even need a DPRAM.
The hardware of the second processor does all the hard work. The Tube “interface” or port is just buffered address and data busses. Plus some control lines. Like this:
Address lines A0 to A2 (A0 to A6 are present on the BBC B and Master 128 external port, but A3 to A6 are not actually used).
Data bus lines D0 to D7.
Control lines: /RESET,
/TUBE (low when the host CPU is addressing the area of memory where the Tube is mapped to),
/IRQ (not used by most second processors),
2MHzE CPU clock (the host being a 6502 CPU, with other CPUs a suitable select signal would be needed instead).
R/W.

Mark


:!: Standby alert :!:
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb :!:
Looking forward to summer in Somerset later in the year :)

QL, Falcon, Atari 520STFM, Atari 1040STE, more PC's than I care to count and an assortment of 8 bit micros (Sinclair and Acorn)(nearly forgot the Psion's)
Derek_Stewart
Font of All Knowledge
Posts: 3932
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Asymmetric multiprocessing...

Post by Derek_Stewart »

Hi,

I like both idesa of using DPRAM (Dual Ported Ram) and the BBC Micro Tube idea.

The DPRAM idea need devloping, where as the Tube idea, needs a QL interface and M68K drivers.

I thought of using exisiting Acorn hardware, like the ATI (Advanced Tube Interface) for the Acorn Electron.

I have an ATI kit on order for my Electron to connect a Raspberry PI as a second processor with PI Tube Direct interface.


Regards,

Derek
User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

Re: Asymmetric multiprocessing...

Post by Pr0f »

1024MAK wrote:The hardware for an Tube “interface” does not even need a DPRAM.
The hardware of the second processor does all the hard work. The Tube “interface” or port is just buffered address and data busses. Plus some control lines. Like this:
Address lines A0 to A2 (A0 to A6 are present on the BBC B and Master 128 external port, but A3 to A6 are not actually used).
Data bus lines D0 to D7.
Control lines: /RESET,
/TUBE (low when the host CPU is addressing the area of memory where the Tube is mapped to),
/IRQ (not used by most second processors),
2MHzE CPU clock (the host being a 6502 CPU, with other CPUs a suitable select signal would be needed instead).
R/W.

Mark
If you look at the notes for the TUBE interface, and inferred from the statement in your response about /TUBE signal - there are few registers that are dual mapped - this is basically dual port RAM - just because it's only a handful of bytes rather than several K. The 2nd processor (what ever it may be) had the responsibility of providing the shared access memory - so it's not in the BEEB itself.


User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

Re: Asymmetric multiprocessing...

Post by Pr0f »



Derek_Stewart
Font of All Knowledge
Posts: 3932
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Asymmetric multiprocessing...

Post by Derek_Stewart »

Ji,

The DPRAM idea sounds a better solution, could schematic be drawn up to show the DPRAM proposal and I could proto-type the interface.


Regards,

Derek
User avatar
1024MAK
Super Gold Card
Posts: 592
Joined: Sun Dec 11, 2011 1:16 am
Location: Looking forward to summer in Somerset, UK...

Re: Asymmetric multiprocessing...

Post by 1024MAK »

Pr0f wrote:
1024MAK wrote:The hardware for an Tube “interface” does not even need a DPRAM.
The hardware of the second processor does all the hard work. The Tube “interface” or port is just buffered address and data busses. Plus some control lines. Like this:
Address lines A0 to A2 (A0 to A6 are present on the BBC B and Master 128 external port, but A3 to A6 are not actually used).
Data bus lines D0 to D7.
Control lines: /RESET,
/TUBE (low when the host CPU is addressing the area of memory where the Tube is mapped to),
/IRQ (not used by most second processors),
2MHzE CPU clock (the host being a 6502 CPU, with other CPUs a suitable select signal would be needed instead).
R/W.

Mark
If you look at the notes for the TUBE interface, and inferred from the statement in your response about /TUBE signal - there are few registers that are dual mapped - this is basically dual port RAM - just because it's only a handful of bytes rather than several K. The 2nd processor (what ever it may be) had the responsibility of providing the shared access memory - so it's not in the BEEB itself.
The chip included on a Tube second processor, the ULA (or a modern equivalent) has a number of registers. Some are simple registers and some are FIFO registers of various depths. Some are for the host to parasite direction, while others are for the opposite direction. Some are for control purposes and some are for data transfer. So that is not quite the same as DPRAM.
I’m not saying that DPRAM should not be used. I was and am just describing the system that Acorn or third party companies used.

This is the Tube ULA registers:
Client -> Host
Reg 1: 24 byte FIFO
Reg 2: 1 byte
Reg 3: 2 byte FIFO
Reg 4: 1 byte
Status 1: 2 bits
Status 2: 2 bits
Status 3: 2 bits
Status 4: 2 bits

Host -> Client
Reg 1: 1 byte
Reg 2: 1 byte
Reg 3: 2 byte FIFO
Reg 4: 1 byte
Status 1: 2 bits
Status 2: 2 bits
Status 3: 2 bits
Status 4: 2 bits

Host <-> Client
Control: 6 bits (except the appnote says this is a byte)

See also this extract from an Acorn service manual: Image

Mark


:!: Standby alert :!:
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb :!:
Looking forward to summer in Somerset later in the year :)

QL, Falcon, Atari 520STFM, Atari 1040STE, more PC's than I care to count and an assortment of 8 bit micros (Sinclair and Acorn)(nearly forgot the Psion's)
User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Asymmetric multiprocessing...

Post by Dave »

Derek_Stewart wrote:Ji,

The DPRAM idea sounds a better solution, could schematic be drawn up to show the DPRAM proposal and I could proto-type the interface.
It is a lot more flexible than the tube method. You have full insight into the whole memory map of a 64k device. You can directly manipulate or observe anything. You could run CP/M or a Jupiter Ace FORTH on the exact same hardware.

I’ll draw something up.


Post Reply