[sdiy] Xpander

Wed Oct 21 20:57:44 CEST 2020

Another great example of multi CPU design is Fairlight Series II/IIx/III
and early MFX3 design which hasn't changed for a decade. In that case it's
truly multiprocessing for dual 6809 performance. In series III Fairlight
also adopted 6800 on each channel card as well (8 total) with waveform bus
and time slices for inter communication and even brought 68k for data
management (Waveform memory, SCSI, sampling), but the core piece 2x6809
running OS9 remained unchanged until mid 90s. It's an interesting piece of
gear to study the design. All documentation is located here:
https://app.box.com/s/8m3t9ud3yy50kz83nmnwbjw80asp4z8h?fbclid=IwAR1sDz1gt9mpWbACmJ44Wu3zATk_F9xkkTd1L8gNRii9pfzKgbDuM8UNxVw

On Wed, Oct 21, 2020 at 11:47 AM Michael E Caloroso <
mec.forumreader at gmail.com> wrote:

> The Oberheim OBMx is one product using a master CPU coupled to slave
> CPUs on voice cards.  The legal battle between the developer Lynx
> Crowe and Gibson (who launched the OBMx) was over the copyright of the
> source code on the voice card; Crowe won that battle, but Gibson
> killed the OBMx to deny any royalties to Crowe as a result of the
> ruling.  The OBMx was a difficult birth and a sad story.
>
> Some OBMx source code is online at
> https://lanterman.ece.gatech.edu/obmx/ but it may not be complete.
>
> MC
>
> On 10/21/20, Roman Sowa <modular at go2.pl> wrote:
> > No, because all 3 processors are isolated by buffers. The bus is shared
> > only when in need for inter-CPU transmission. So each of 3 works with
> > its own bus, memory and all that. If master wants to talk to slave 1,
> > and opens buffers to common bus in slave1 board. Actually toggles them
> > on/off with clock rate, so in one state the bus closes within slave1
> > board, while in the other state it connects to master. And if it wants
> > to talk to slave2, then it toggles slave2 buffers.
> > So according to what Rainer said, the slaves are not even aware that
> > someone is writting their RAM, and don't loose a single clock. To be
> > precase we're talking about Q signal, which is 4x slower than clock, so
> > there goes need for syncing one processor 4 clock cycles behind the
> other.
> >
> > But, I just looked into 6809 datasheet and from timing diagram it's
> > aparent that it would be tricky to fit 2nd memory access cycle in the
> > middle of regular one. That means faster memories must be used, and the
> > firmware is after all written in slow EPROM. In details: the clock is
> > 8MHz, so cycle rate is 2MHz, cycle time 500ns. Read data+hold time
> > required minimum 50ns, EPROM acces time 200ns, so that's already half of
> > the cycle. It would require very precise timing to fit. 10ns shift one
> > way or the other and execution of program in both goes down the toilet.
> > There are plenty of memory chips and buffers on each bus (IIRC about 8
> > ICs), so it won't be easy. I think with that approach the synth would be
> > much more unreliable than it is now. So IMHO using Halt for this was
> > good move. OTOH they could have used DMA.
> >
> > Roman
> >
> >
> > W dniu 2020-10-21 o 18:35, chris pisze:
> >> Hmm. I have to admit I never did anything with 65xx/68xx, I was always
> >> an Intel/Zilog guy. I do get the clock phase thing.
> >>
> >> But if the master could address both slaves in parallel - wouldn't that
> >> mean that the slaves' data and address busses need to be connected to
> >> each other (via the master's bus)?
> >>
> >> Would they be able to do their own work without hitting each other?
> >>
> >> Wouldn't at least some clock phase gated tri state buffers towards each
> >> slave be necessary? That however would water down the simplistic
> >> approach a little.
> >>
> >> Chris
> >>
> >>
> >>
> >> On Wed, 21 Oct 2020 16:23:44 +0200 (CEST) Rainer Buchty
> >> <rainer at buchty.net> wrote:
> >>
> >>> On Wed, 21 Oct 2020, Roman Sowa wrote:
> >>>
> >>>> both boards need different data - different notes are played, and it
> >>>> can be set up so each voice plays different patch. Well I can imagine
> >>>> a scenario when at every even cycle the master CPU can mingle one
> >>>> slave's RAM, and on every odd cycle - the other RAM. Still that seems
> >>>> unnecessary as data transfer is needed very rarely compared to bus
> >>>> speed.
> >>> Aaah, now I understand the confusion.
> >>>
> >>> There's no difference of phase between slaves.
> >>>
> >>> If this is the host clock
> >>>
> >>> ----____
> >>>
> >>> this would be *all* slave's clocks
> >>>
> >>> ____----
> >>>
> >>> So the master can write to any slave board without colliding with that
> >>> slave's own local accesses; it could even write to all slaves in one
> go,
> >>> e.g. in terms of patch data transfers.
> >>>
> >>> But what of course cannot take place is slaves accessing any other
> >>> slave's memory (collision with local accesses) or the master's memory
> >>> (possible collision of remote accesses).
> >>>
> >>>> There is no arbitration logic, only buffers. Just set the Halt line
> >>>> and bus is yours to write those few bytes and go back. That seems
> >>>> simpler than anything else.
> >>> That would be if it behaved like BUSRQ# on the Z80 which indeed
> >>> interrupts a running instruction.
> >>>
> >>> HALT# on the 6809 would however become effective *after* the
> >>> currently running instruction, so you would need to also monitor BA
> >>> and BS for becoming 11. If you would just assign HALT# and access the
> >>> bus, you're likely to create bus collisions.
> >>>
> >>> Why going the extra lenghts of triggering a bus-free interrupt or
> >>> E/Q-clock delaying on the accessing CPU when it's not needed? It's an
> >>> (IMO) wonderful feature of the 6800 derivatives that you can rather
> >>> simply set up multiprocessing environments without the need for any bus
> >>> arbitration.
> >>>
> >>> That's all I was saying.
> >>>
> >>>> There are many thing we can argue over Matrix12 or Xpander. It's clear
> >>>> to anyone they are not perfectly designed. May compromises and bad
> >>>> decisions all the way starting from the worst power supply ever
> >>>> designed. Tell it to Tom Oberheim he did bad. Actually last time I
> >>>> asked him about Matrix12, he told me he wasn't involved in the design
> >>>> on digital/CPU stuff.
> >>> Again: I was neither criticizing him, his team, nor the design of M12
> or
> >>> Xpander, which I think are quite exciting machines.
> >>>
> >>> Rainer
> >>> _______________________________________________
> >>> Synth-diy mailing list
> >>> Synth-diy at synth-diy.org
> >>> http://synth-diy.org/mailman/listinfo/synth-diy
> >> _______________________________________________
> >> Synth-diy mailing list
> >> Synth-diy at synth-diy.org
> >> http://synth-diy.org/mailman/listinfo/synth-diy
> >
> > _______________________________________________
> > Synth-diy mailing list
> > Synth-diy at synth-diy.org
> > http://synth-diy.org/mailman/listinfo/synth-diy
> >
>
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy
>

-- 
Andrei Kudryavtsev,

My last album *Two Match - The 1st Fill* on iTunes
<http://itunes.apple.com/us/album/the-1st-fill/id1241529125>
or Free on Spotify <https://open.spotify.com/album/4aM8DzmN5yi4ho1gcmC8ls>!

Follow me on Facebook <https://www.facebook.com/andrei.kudryavtsev.5>,
Instagram <https://www.instagram.com/deftaudio/>

Music technologies by
Deftaudio (www.deftaudio.ru)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20201021/2dfd97db/attachment.htm>