writing to soundprocessor, need delay?

[Crazyboss]

Hi

when converting games from other system. EG msx or colecovision, and knowing to use the sound processor on Memotech you need to out to port 6 and then in to port 3.

Do I need to make some kind of delay after the first out, and before then next in ? or even after the last in, to the first out if its a loop?

I think the sound at memotech sound a bit more weird compared to colecovision, even using the same code

[thewiz]

Hi Claus,

I think you can do an OUT (6) followed by a IN (3) which will be enough of a delay. I think the timings are in the manual If you have my program that outputs the "Lets go" sample, it might be worth looking at.

Never tried to OUT (6) / IN (3) / OUT (6) ... as I always need to get the sound data from somewhere inbetween.

Regards
Paul

[Crazyboss]

Hi Paul

I noticed a my last port "SASA" sound a bit wierd, like a old tape-recorder some times

Compared to the way other MSX conversions.

I changed the AY (MSX) sound emulation a bit, that code might be much quicker than the old code I used.

I am currently working on a new conversion, but the sound seems to be very noisy, it sound better on Colecovision. The way they put out sound the the processor was done by z80 instruction: OTIR.

about OTIR: "Reads from (HL) and writes to the (C) port. HL is incremented and B is decremented. Repeats until B = 0."

this cant be done on Memotech since I need an IN after OUT.

So I made "my own" OTIR called CBOTIR
cbotir:
ld a,(hl)
out (c),a
inc hl
in a,(3) ;mtx
djnz cbotir

Maybe should add more wasting cycles after the last IN ?

In Toado a call is made like:

L9FBD:
out ($06),a
in a,($03)
ret

So ED simply call L9FBD to send the data to the sound processor, so I think no need to waste cycles between the out and in, but maybe its needed between the IN and OUT ? using the call above, will get the return address from the stack and when the RET have to be done, that takes some cycles too. But is it really needed with so large delay ?

[thewiz]

I can't check at the moment but I don't think the delay doesn't have to be that much, like 4 T-States.

Also have you thought of using OTI instead of OTIR, i.e. no repeat? Typing out aloud, it might decrement B so B would have to be checked for zero after the IN if IN changes the flags.

Regards

[Martin A]

You have to allow at least 32 cycles at 4mhz between successive strobes on IN(3). The sound chip has to remain enabled for the whole time that the chip is reading the data from the latch.

The MTX hardware links the ready signal from the 76489 to it's write enable line and a pullup resistor. This is then linked via the AND gate to chip select to ensure the chip remains enabled until it's finished reading.

it's on page 225 of the "newer" manual. .

If you write too fast, the sound chip will still be doing the first read cycle when the new data arrives.

There's no need for a gap between the out 6 and in 3 statements.

The data sheet for the LS374 latch says worst case propagation time is 50ns. Given that the normal MTX CPU is running a 250ns cycle time the latch would be ready long before the end of the next cycle. Since IN (3) takes 11 cycles, (12 if you do IN (C) ) it would take a VERY fast Z80 to complete the instruction before the latch was ready.

The 32 cycles is approximate according to the datasheet in the MTX manual. I found when I was playing with the over clocked 20mhz Z80, that I needed a few more more than 320 cycles at 40mhz to turn off the sound at start-up. Since 350 cycles worked, I've not bothered trying any values in between.

[Crazyboss]

Yes Martin, found that too, 32 cycles

I did try to put 3x push/pop in the code, to be sure, it actually sounds better now.

I think 1x push/pop can do the trick.

I guess that explains why SASA sounds a bit weird:

ld a,(hl)
out (6),a
in a,(3)
inc hl
ld a,(hl)
out (6),a
in a,(3)

i guess a: inc hl and ld a,(hl) is not 32 cycles, might be less, better add a push/pop here i guess.

There should be no problems with earlier conversions like: Telebunny, Comic Bakery and so, cause another AY Sound emulation code is used, the first version use much more cycles and much more code to run, the "new" one (first used in SASA), is more simple and quicker, and also offer simple noise channel emulation

If I am right a "new" SASA will be released later (as MTX,RUN,COM and Wave).

Another game almost done, still keep it a secret

[Martin A]

Cycle count coming up:

Code: Select all

ld a,(hl)  ; (7)
out (6),a  ;(11)
in a,(3)   ;(11)
inc hl     ; (6)
ld a,(hl)  ; (7)
out (6),a  ;(11)
in a,(3)   ;(11)

This code has 35 cycles (T states) between the end of one IN(3) and the end of the next one. However it also has the latch being changed while the sound chip is still reading it.

Getting really technical (possibly too technical!) :

Looking at the timing diagrams in the Z80 manual, it would appear that IORQ goes high on the 4th T state of the final machine cycle of IN(3).
It will go low again at the start of the 2nd T state of the 3rd machine cycle of the following OUT (6), that's the 9th T state over all.

SO to leave a minimum 32 cycle gap between activations of the IORQ line would need 24 Cycles between the end of the IN (3) and the start of the OUT (6) . At the moment there are 13. Push/Pop 21 is cycles, more than enough to work, 3 NOPs would be 12, but that's a byte more if you're short of space.

However if it fits with other code you could also use IX for the pointer instead of HL which would increase the cycle count past 24.

Code: Select all

ld a,(IX+0)  ;(19)
out (6),a    ;(11)
in a,(3)     ;(11)
inc IX       ;(10)
ld a,(IX+0)  ;(19)
out (6),a    ;(11)
in a,(3)     ;(11)

NB a call and return is 25 cycles, so pretty much guarantees that if you put the OUT(6) / IN (3) sequence as a subroutine you can't mess up the timing (at 4 MHz anyway) and may also save space if called from enough locations.