Page 3 of 5

Re: Put 2 YM2149 into the ST

Posted: 31 Oct 2019 16:07
by Gunstick
Or maybe the YM does this too, i.e. it knows it was not addressed by the previous address bus cycle, and so ignores the next data bus cycle.
At least that's how I interpret the text. You address a supposedly differently that 0000 coded YM, and then just write data on the bus, and that YM takes the data in, independent if there is another YM on the same bus.

My simulator just does not have that logic built into the YM chips.
I think you are right. If we had an 0001 coded YM, there would be no external logic required at all.

Is there a circuit diagram of this part of an YM or AY chip available? Then I could rebuilt it 1 to 1, hehe.

One could create a PCB for an YM, with just a couple of dip switches which will change it's address from 0000 to something else. i.e. using inverters, which are only active on address write but not on data write.
Then you could effectively stack 16 chips, LOL.

Re: Put 2 YM2149 into the ST

Posted: 31 Oct 2019 19:36
by keli
Yes the YM knows and disables its output, but the buffer used for data reads does not and will drive possibly random data onto the 68000 data bus, as its input will be left floating.
That's why I suggested using an analog switch instead for both data reads and writes instead of the tri-state buffers, as it will simply make a electrical connection instead of driving random data.

Re: Put 2 YM2149 into the ST

Posted: 31 Oct 2019 20:18
by keli
Here's my latest attempt at doing this correctly. This version should be able to add 3 additional YM chips for a total of 12 audio channels!
The first extra chip should replace it's DA4 pin connection with DA4_FLIPPED, the second should connect its DA5 pin to DA5_FLIPPED, and the third one should connect both DA4 and DA5 to DA4_FLIPPED and DA5_FLIPPED respectively. The additional registers should show up as registers no $10-$1F for the second sound chip, $20-$2F for the third, and finally the fourth will be at $30-$3F.
quad_ym2.png
Edit Changed so that the analog switches are only active when the CPU is either reading or writing register values from/to the YMs

Re: Put 2 YM2149 into the ST

Posted: 31 Oct 2019 20:25
by Cyprian
keli wrote: 29 Oct 2019 18:50 Hmm does the SND_CS output depend on the LDS abd UDS signals from the CPU? If not, could these be combined with SND_CS to put the second YM chip on the odd byte of the same address (Wen LDS is active).

So the address map would become:
Addresssize chip function
$FF8800 byte Primary YM Read data/Register select
$FF8801 byte Secondary YM Read data/Register select
$FF8802 byte Primary YM Write data
$FF8803 byte Secondary YM Write data
Edit But after reading Gunstick's method of latching bit 4 of the data written to register select (ie. D12 when BDIR is write and the address is $FFF8800) sounds awesome to me.
Extending that to latching D12,D13,D14, and D15 would allow in theory up to 16 YM chips on the same address space(!!)
(That's 48 chanels of audio and 256 GPIO pins)
Nice idea.
It would work when we use move.b or movep instruction for addressing YM chip.
I saw somewhere instruction move.w/l D0,$FFFF8800.w which will not work well with that YM addressing mode.

Re: Put 2 YM2149 into the ST

Posted: 31 Oct 2019 22:53
by Gunstick
I will try to implement the method of the analog switch in the sim.

Addressing the YM: using additional registers on the same addresses has the advantage to also work on falcon (which bus errors an everything outside of ff8800-ff8803). Also some demos use other shadow registers so you can't put an YM there.
Digisound is usually done with movem.w d0-d3,$ff8800.w, using 2 additional pairs of shadow addresses. Some digisounds use movep, but still using shadow addresses.
So hiding the second YM behind the first is the most transparent way.

Re: Put 2 YM2149 into the ST

Posted: 01 Nov 2019 23:25
by Gunstick
As expected, the simulation is not powerful enough to make an analog switch work correctly. It keeps tri-state and active signal sticking on the same bus segment. But well, I get the idea and it should work.
https://circuitverse.org/simulator/edit/34126
Circuit is simple and small. If I find for all this DIL versions I could quickly prototype it on a breadboard. (plus needing to get some YM chips!)

With a bit of trying again and again (and making the tri-state gates ideally fast at 0ms) it seems to work sometimes. At least I managed to load into R1 of both YMs 2 different values. i.e. R1 = $19 and R17 = $11
Screenshot_2019-11-02_00-18-11.png

Re: Put 2 YM2149 into the ST

Posted: 02 Nov 2019 00:07
by keli
Gunstick wrote: 01 Nov 2019 23:25
With a bit of trying again and again (and making the tri-state gates ideally fast at 0ms) it seems to work sometimes. At least I managed to load into R1 of both YMs 2 different values. i.e. R1 = $19 and R17 = $11
Yes there is probably a timing issue. I think you will have to delay the BC1 and BDIR signals seen by the YMs long enough for the modified DA lines have stabilized.

Re: Put 2 YM2149 into the ST

Posted: 02 Nov 2019 09:44
by exxos
I'm assuming LDS UDS might need to be used to ensure there is valid data on the bus.

Re: Put 2 YM2149 into the ST

Posted: 02 Nov 2019 10:03
by keli
exxos wrote: 02 Nov 2019 09:44 I'm assuming LDS UDS might need to be used to ensure there is valid data on the bus.
It's not the original data, it's the delay caused by manipulating the data bits when writing the register number to the YM. Originally we know that when BDIR and BC1 are valid, the data bus is already valid (otherwise the original setup in the ST would not have worked), but since I'm using BDIR and BC1 to know when to manipulate the data going into the PSG, there might be a slight delay required.

Re: Put 2 YM2149 into the ST

Posted: 02 Nov 2019 10:25
by exxos
keli wrote: 02 Nov 2019 10:03 It's not the original data, it's the delay caused by manipulating the data bits when writing the register number to the YM. Originally we know that when BDIR and BC1 are valid, the data bus is already valid (otherwise the original setup in the ST would not have worked), but since I'm using BDIR and BC1 to know when to manipulate the data going into the PSG, there might be a slight delay required.
ah yeah if the data itself is delayed.. but data is only normally latched when control signals are de-selected (data would be valid longer if your going via buffers for example) so I can only see it failing if your control pins are de-selected faster than the buffer logic.. In which case that would malfunction.

Maybe using a GAL for this job may be better ? The delays are more uniform than using individual logic gates.