[sdiy] Xpander

[Roman Sowa]

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