https://www.youtube.com/watch?v=3SlRbYfyNRY
can a CPC do that fast? if not, is the issue the fastest the CPC can feed the sound chip?
A scanline takes 64 NOPs, there are 312 scanlines on one screen, and there are 50 screens in one second. Therefore 64 x 312 x 50 = 998'400 NOPs are available per second. If 60 kHz should be reached, this means for each sample 998'400 / 60'000 = 16.64 NOPs can be used. With some compromises a sample can be output with less than 16 NOPs.
If the PSG is initialized, then the following (unrolled) code sends the sample data:
LD C,#80
LD HL,sample_data
REPEAT block_length
LD B,#F4 : OUTI ;; 7
LD B,#F6 : OUT (C),C ;; 6
;; ;; --
;; ;; 13
RENDSome drawbacks with this approach:
- This does not do any, not even the simplest compression on the sample data, so this will need much memory.
- The unrolled code also will need much memory.
- There will not be one, but multiple blocks. Switching from one to the next block will create a short, maybe audible delay.
- The correct protocol requires to close the data transfer from PPI to PSG with a 'OUT (C),0'. It seems this can be left out in this case (because we are only sending data to always the same register), but this might depend on the chip versions.
If instead of the internal PSG e.g. the Digiblaster is used, then there is no intermediate chip (Z80 -> PPI -> PSG), what makes the output code smaller and faster and also provides linear 8-bit instead of logarithmic 4-bit sound.
The fastest way is to use a Plus, it can do three register writes per scanline via DMA and the you have the CPU to augment that (although the shortcut above might not work with the Plus PPI, but it'll still be faster).
Orchestrating all of that, plus the memory requirements, would make it mostly impractical in real terms though.
A second of sampled sound won't be very impressive anyway.
Quote from: lightforce6128 on 04:17, 10 May 25LD B,#F6 : OUT (C),C ;; 6
this is not necessary. INC B is enough
Quote from: andycadley on 07:55, 10 May 25The fastest way is to use a Plus, it can do three register writes per scanline via DMA and the you have the CPU to augment that (although the shortcut above might not work with the Plus PPI, but it'll still be faster).
This is of little interest, but to assess the technical limit, we can establish that on the Plus, it takes 8 µsec to modify a register. (The three DMAs do not operate in parallel with each other).
By generating an Hsync every 8 µsec, we can achieve a frequency of 125.8 kHz (or every 24 µsec with three active DMAs).
The ASIC must read one word per register at each Hsync, or 32,768 occurrences without looping for all usable main RAM, which gives 32,768 x 8 = 262,144 µsec (approximately 13 frames = 0.26 sec :-\ ).
The DMA REPEAT+LOOP instructions, however, allow looping with a loss of 8 µsec per loop.
Quote from: eto on 15:29, 10 May 25A second of sampled sound won't be very impressive anyway.
This is one of the biggest problems with samples on an 8-bit system. (The other one is the logarithmic volume that only fits well with square signals and produces strange artifact noises for any other signal.)
In another thread I asked about how additional memory can be used. If e.g. 4 megabytes are used instead of 64 kilobytes, then the duration rises from a second to a minute - still not enough for a normal song. If 30 kHz are used instead of 60 kHz, then we reach 2 minutes. If two nibbles are compressed in one byte, then we reach 4 minutes - finally enough for a (short) song.
Quote from: McArti0 on 16:39, 10 May 25Quote from: lightforce6128 on 04:17, 10 May 25LD B,#F6 : OUT (C),C ;; 6
this is not necessary. INC B is enough
The OUTI instruction is tricky. I always do it wrong - and did so also in this example. Register B is decremented, not incremented. And it is decremented before the data is transferred to the device. This means we have to start with value #F5, what will output #F4. From there two INC instructions would be necessary to reach the required #F6. But at least some time can be saved by using register DE:
LD C,#80
LD DE,#F5F6
LD HL,sample_data
REPEAT block_length
LD B,D : OUTI ;; 6
LD B,E : OUT (C),C ;; 5
OUT (C),0 ;; 4
;; ;; --
;; ;; 15
REND With this we get a bit of free time to send the missing 0 to complete the transfer what should work on all chip versions and machines.
Quote from: McArti0 on 00:59, 11 May 25No. Writing to register F6 is completely unnecessary.
Thank you very much for this information. From a former experiment I remembered that sound was only there if at least 'LD BC,#F680 : OUT (C),C' was used after sending a sample. But this was a wrong interpretation. As you said this is not necessary. It is enough (and required) to do this once at the begin of the sample loop. With this we get:
LD B,#F5
LD HL,sample_data
REPEAT block_length
OUTI ;; 5
INC B ;; 1
;; ;; --
;; ;; 6
REND We can send samples at 166 kHz. Should be enough ...
Especially this frees time to replace the long unrolled code with a normal loop. Also a minimum of decompression (4-bit nibbles instead of bytes) should be possible.
Quote from: lightforce6128 on 01:24, 11 May 25We can send samples at 166 kHz. Should be enough ...
What is the use of sending samples at such a high frequency? For audio that is supposed to be consumed by humans (and not dogs or bats, for example) 44 Khz is sufficent. See https://en.wikipedia.org/wiki/Nyquist_frequency. Everything higher than that is a waste of computing power and would also need audio data sampled at this crazy high rate.
Is this supposed to be some kind of competition for the retro-computer sample-replay world-record?
you didn't take dithering into account
Well, using Amdrum, LambdaSpeaks Amdrum Emulation or the CPC-Booster+ (also Digiblaster) can allow more then 60 kHz actually. :) High end should be at something like 240 kHz. :)
Quote from: McArti0 on 00:59, 11 May 25No. Writing to register F6 is completely unnecessary.
Really? I mean everyone in history of CPC always used 3 OUTs for sending one "sample" to the PSG (e.g. see actual Arkos Tracker MOD player).
See here:
https://www.cpcwiki.eu/index.php/How_to_access_the_PSG_via_PPI#Writing_to_a_PSG_register
This part, which is using 3 OUTs...
ld b,&f4 ; setup register data on PPI port A
out (c),a ;
ld bc,&f680 ; Tell PSG to write data on PPI port A into selected register
out (c),c ;
ld bc,&f600 ; Put PSG into inactive state
out (c),c ;...is done in every sample player, see e.g. AT MOD player:
ld b,e
out (c),a ;#f400 + value.
ld b,#f6
out (c),a ;#f680
out (c),0
Same for Lightforces first example.
Would be funny, if we were all wrong in the past.
I have a sneaking suspicion you may not get audio on a Plus machine if you don't, but someone would have to try to be sure. Shortcutting what you were supposed to do with the PPI was the tip cause of incompatibilities.
Quote from: BSC on 20:08, 11 May 25For audio that is supposed to be consumed by humans (and not dogs or bats, for example) 44 Khz is sufficent.
You can lower the value even by a considerable amount if you consider the age of your audience. :laugh:
Quote from: andycadley on 12:38, 12 May 25I have a sneaking suspicion you may not get audio on a Plus machine if you don't,
Yup, you're right!
By the way, we have a cow sound running at 44khz in the "CPC Meuuuuhting" (can't find the link, sorry) party demo with SuperSylvestre. Well, it's not as impressive as you may think. We could have used a higher frequency, but you wouldn't hear the difference, as BSC mentioned. It was just made for fun.
Quote from: Prodatron on 11:10, 12 May 25Quote from: McArti0 on 00:59, 11 May 25No. Writing to register F6 is completely unnecessary.
Really?
Would be funny, if we were all wrong in the past.
;D :laugh:
org #4000
di
call init
ld d,#F5
ld bc,#F400
loop
inc c
out (c),c
vsync1
ld a,d : in a,(0) : rra : jr nc,vsync1
vsync2
ld a,d : in a,(0) : rra : jr c,vsync2
jr loop
ret
init
ld bc,#F782 ;PC set PA as OUT
OUT (c),c
ld bc,#F407 ;PA has R sel (vol A channel)
OUT (c),c
ld bc,#F6C0 ;PC move PA to sel R
OUT (c),c
ld bc,#F600 ;PC dis AY
OUT (c),c
ld bc,#F43e ;PA set
OUT (c),c
ld bc,#F680 ;PC open AY and connect PA with Rsel
OUT (c),c
ld bc,#F600 ;PC dis AY
OUT (c),c
; R8
ld bc,#F408 ;PA has R sel (vol A channel)
OUT (c),c
ld bc,#F6C0 ;PC move PA to sel R
OUT (c),c
ld bc,#F600 ;PC dis AY
OUT (c),c
ld bc,#F409 ;PA set
OUT (c),c
ld bc,#F680 ;PC open AY and connect PA with Rsel
OUT (c),c
ld bc,#F600 ;PC dis AY
OUT (c),c
; R0
ld bc,#F400 ;PA has R sel (vol A channel)
OUT (c),c
ld bc,#F6C0 ;PC move PA to sel R
OUT (c),c
ld bc,#F600 ;PC dis AY
OUT (c),c
ld bc,#F400 ;PA set 0
OUT (c),c
ld bc,#F680 ;PC open AY and connect PA with Rsel
OUT (c),c
ret
Quote from: Targhan on 20:15, 12 May 25"CPC Meuuuuhting"
That one?
https://www.youtube.com/watch?v=2yfTQV8yT3g (https://www.youtube.com/watch?v=2yfTQV8yT3g)
Quote from: lightforce6128 on 01:24, 11 May 25We can send samples at 166 kHz. Should be enough ...
Quote from: BSC on 20:08, 11 May 25Is this supposed to be some kind of competition for the retro-computer sample-replay world-record?
Quote from: McArti0 on 21:52, 11 May 25you didn't take dithering into account
Dithering? ... Yes that is exactly what I had in mind: Dithering ...
No :-[ In fact I remembered a glorious article about high-end sound with the C64 at 48 kHz (and a big bunch of memory). So yes, I had some kind of competition in mind. Also you are absolutely right: Everything above 44 kHz will not be audible.
What brings us back to dithering (https://en.wikipedia.org/wiki/Dither#Digital_audio): The idea of dithering is to mix a signal with a low resolution (e.g. 1 bit or 4 bit) with noise that will push the single samples sometimes below and sometimes above the bit levels. With this the resolution can be enhanced greatly, lowering or even removing noise artifacts caused by the low resolution.
But the dithering noise itself is added. Although this is a neutral sound, it nevertheless is clearly audible - except you push it above the 16 kHz level. With 44 kHz there is not much room to do this, but with 166 kHz there is. With this, the audio resolution can be increased, noise artifacts can be reduced, and the dithering noise maybe can be lowered until it gets inaudible.
However, professional equipment uses frequencies of more than 1 MHz for this trick (https://en.wikipedia.org/wiki/Noise_shaping).
In our Wiki (https://www.cpcwiki.eu/index.php/PSG) I found this additional information about the sound chip AY-3-8912:
1) There are four different known versions of the chip used for the CPC. Maybe these versions behave differently, maybe not.
2) Internally the chip works with 125 kHz. This means even if its registers are updated with 166 kHz, it will nevertheless only update the volume with 125 kHz.
3) There are no additional control lines on the chip to acknowledge or synchronize with something. This means: If the chip is programmed to read in register values written by the CPU through the PPI (BDIR=1, B1=0), it will do this non-stop. The PPI will remember the last written value and keep it available (latch). What is not clear is if the PSG stops normal operation as long as registers are written. From my observation: It does not care and simply continues its normal work. This means: One can change register values (e.g. the volume level) during operation without altering the mode. This saves two OUT commands per sample.
4) Only the envelope shape register (#0D) somehow recognizes writing and restarts the envelope.
OUTI ;5
INC B ;1
NOP ;1
NOP ;1
1000/8=125kHz
Quote from: lightforce6128 on 23:41, 12 May 25The idea of dithering is to mix a signal with ...
In other words, it is local PWM.
Samples 33333333444444444
Can be replaced with...
333334343434344444
This means that
33333 /3.5, 3.5, 3.5, 3.5/ 44444
Quote from: MaV on 22:56, 12 May 25That one?
Probably the right meeting, but not this demo. Ours was subtitled "the vache from hell". Couldn't find it on CPC Power...
Quote from: Targhan on 20:15, 12 May 25Quote from: andycadley on 12:38, 12 May 25I have a sneaking suspicion you may not get audio on a Plus machine if you don't,
Yup, you're right!
Does any emulator show this?
It would be a very absurd design. Blocking the F4 port to switch something in F6? After all, AY works the same way.
Quote from: McArti0 on 06:13, 13 May 25OUTI ;5
INC B ;1
NOP ;1
NOP ;1
1000/8=125kHz
I love your comprehensive style of posting. You clearly explain why you have a certain opinion, provide evidence or links to existing code, awesome - not! I strongly doubt that what you claim here is possible. I did my fair amount of experiments with the AY in the last 10ish years and it never occurred to me that what you claim here is possible. At least not without glitches, on a real machine.
Quote from: BSC on 12:46, 13 May 25 I strongly doubt that what you claim here is possible.
Are you talking about dithering?
Quote from: McArti0 on 13:57, 13 May 25Quote from: BSC on 12:46, 13 May 25 I strongly doubt that what you claim here is possible.
Are you talking about dithering?
No, the code snippet containing OUTI.
Quote from: McArti0 on 11:22, 13 May 25Quote from: Targhan on 20:15, 12 May 25Quote from: andycadley on 12:38, 12 May 25I have a sneaking suspicion you may not get audio on a Plus machine if you don't,
Yup, you're right!
Does any emulator show this?
It would be a very absurd design. Blocking the F4 port to switch something in F6? After all, AY works the same way.
I don't think so, most emulators will quite happily ignore situations where a real Plus keyboard stops responding for example.
You have to remember there is no 8255 in a Plus at all, the ASIC mimics it's behaviour based on the spec and also has to be able to do things like write to the AY regardless of PPI state (because DMA sound). So it can be very finicky about doing things the way they were supposed to be done, rather than what necessarily could be gotten away with.
Quote from: McArti0 on 11:22, 13 May 25Quote from: Targhan on 20:15, 12 May 25Quote from: andycadley on 12:38, 12 May 25I have a sneaking suspicion you may not get audio on a Plus machine if you don't,
Yup, you're right!
Does any emulator show this?
It would be a very absurd design. Blocking the F4 port to switch something in F6? After all, AY works the same way.
I tried on WinAPE. Configured to 6128 and 6128 plus it did not show a difference. In both cases it works. Would be good to know how different actual hardware behave.
@Targhan : Does "Yup, you're right!" mean: "I got the same feeling. I agree with this." Or does it mean: "I tried this on real hardware. It did not work as expected."
Quote from: BSC on 12:46, 13 May 25I did my fair amount of experiments with the AY in the last 10ish years and it never occurred to me that what you claim here is possible. At least not without glitches, on a real machine.
If it is possible on real hardware to send values continuously, there will be glitches (I know the term hazard (https://en.wikipedia.org/wiki/Hazard_(logic)) for this). E.g. while switching between register selection and register update, if the PPI is not programmed to stop it will send the next register index also as register value for the last register index. For operation in music trackers where all or at least several registers are updated in a row this clearly needs to be considered.
But while playing a sample, only a single register is changed. If there is a glitch/hazard in the value, there will be a minimal creaking in the output until the right volume value arrives. But here we are talking about microseconds. Is this audible?
One detail question we can think about: The tone frequency of a channel is divided into two registers. What happens if one updates the first register, but is not fast enough to update the second? Does the PSG stops counting during these operations? Or does it simply continue and possibly will output a wrong frequency until the second register is also updated? Usually the ICs used back then do not contain buffers, caches, or complex internal logic, but simply do their main work and rely on a bit good will of the surrounding (e.g. timing).
Quote from: lightforce6128 on 02:30, 14 May 25Quote from: McArti0 on 11:22, 13 May 25Quote from: Targhan on 20:15, 12 May 25Quote from: andycadley on 12:38, 12 May 25I have a sneaking suspicion you may not get audio on a Plus machine if you don't,
Yup, you're right!
Does any emulator show this?
It would be a very absurd design. Blocking the F4 port to switch something in F6? After all, AY works the same way.
I tried on WinAPE. Configured to 6128 and 6128 plus it did not show a difference. In both cases it works. Would be good to know how different actual hardware behave.
@Targhan : Does "Yup, you're right!" mean: "I got the same feeling. I agree with this." Or does it mean: "I tried this on real hardware. It did not work as expected."
Don't count on WinAPE being accurate for this. When I was patching Split Personalities to work on the Plus the audio was fine on WinAPE. When I then tested on my Plus it has odd sound interference. The emulator seems to take a few shortcuts with this side of things.
Quote from: lightforce6128 on 02:30, 14 May 25I tried on WinAPE. Configured to 6128 and 6128 plus it did not show a difference. In both cases it works.
To my knowledge, if you don't #f600 on CPC Plus, there is no sound.
Quote from: Maniac on 08:42, 14 May 25Quote from: lightforce6128 on 02:30, 14 May 25Quote from: McArti0 on 11:22, 13 May 25Quote from: Targhan on 20:15, 12 May 25Quote from: andycadley on 12:38, 12 May 25I have a sneaking suspicion you may not get audio on a Plus machine if you don't,
Yup, you're right!
Does any emulator show this?
It would be a very absurd design. Blocking the F4 port to switch something in F6? After all, AY works the same way.
I tried on WinAPE. Configured to 6128 and 6128 plus it did not show a difference. In both cases it works. Would be good to know how different actual hardware behave.
@Targhan : Does "Yup, you're right!" mean: "I got the same feeling. I agree with this." Or does it mean: "I tried this on real hardware. It did not work as expected."
Don't count on WinAPE being accurate for this. When I was patching Split Personalities to work on the Plus the audio was fine on WinAPE. When I then tested on my Plus it has odd sound interference. The emulator seems to take a few shortcuts with this side of things.
WinAPE is a lovely emulator and it is great for playing the main cart releases. It's accuracy of Plus emulation is very buggy though in lots of ways, so I'd never rely on it for checking what real hardware does.
Quote from: McArti0 on 22:24, 12 May 25org #4000
di
call init
ld d,#F5
ld bc,#F400
loop
inc c
out (c),c
vsync1
ld a,d : in a,(0) : rra : jr nc,vsync1
vsync2
ld a,d : in a,(0) : rra : jr c,vsync2
jr loop
ret
init
ld bc,#F782 ;PC set PA as OUT
OUT (c),c
ld bc,#F407 ;PA has R sel (vol A channel)
OUT (c),c
ld bc,#F6C0 ;PC move PA to sel R
OUT (c),c
ld bc,#F600 ;PC dis AY
OUT (c),c
ld bc,#F43e ;PA set
OUT (c),c
ld bc,#F680 ;PC open AY and connect PA with Rsel
OUT (c),c
ld bc,#F600 ;PC dis AY
OUT (c),c
; R8
ld bc,#F408 ;PA has R sel (vol A channel)
OUT (c),c
ld bc,#F6C0 ;PC move PA to sel R
OUT (c),c
ld bc,#F600 ;PC dis AY
OUT (c),c
ld bc,#F409 ;PA set
OUT (c),c
ld bc,#F680 ;PC open AY and connect PA with Rsel
OUT (c),c
ld bc,#F600 ;PC dis AY
OUT (c),c
; R0
ld bc,#F400 ;PA has R sel (vol A channel)
OUT (c),c
ld bc,#F6C0 ;PC move PA to sel R
OUT (c),c
ld bc,#F600 ;PC dis AY
OUT (c),c
ld bc,#F400 ;PA set 0
OUT (c),c
ld bc,#F680 ;PC open AY and connect PA with Rsel
OUT (c),c
ret
As Prodatron, Targhan and Bsc said, you must use 3 OUTs to send a value to an AY register, even if you don't change registers in the meantime.
So you have to enter the data on F4. Then on F6, select the type of data (bdir/bc1>>#10) and validate everything (bdir/bc1>>00).
Otherwise, the data in other AY registers becomes corrupted quite quickly. Lbb and I studied this in 1992. He deduced that if, after 1040 nops on his machine, there has been no validation, all the registers begin to be masked with an AND that is related to the last value sent to port A (F4). I think this can be explained by the way registers are assigned in these old circuits, often based on AND and OR.
If validation is done, your register is no longer in write mode. So you have to put #80 back in port C.
The example given by McArti0 doesn't work on my real machines (Plus or not). No sound.
Winape does generate a progressive sound with this code, but it's not the reference. :laugh:
In its settings/general menu, Winape has an option to enable (or not) the Plus's PPI emulation, but it's far from sufficient because there are several bugs.
For example, the read frequency registers return 16-bit values. Not to mention the lack of PPI lock for managing DMA sounds.
In my opinion, DMA sounds remain the only way to reach 125 kHz.
I see here another problem of synchronizing the F4 change with the edges of the AY clock. To stiffen it, We would have to exit from the interrupt to handle AY.
For R7=3F, and sel R8 (Level ch. A) with sequence:
F4<-0,
1040 nop,
F4<-15,
next frame
WinAPE gives 25Hz sharp brum.
Real AY .... soft brown noise. 8)
@Longshot ,
@McArti0 : Thank you for doing experiments with real hardware. That's it what any software finally is intended for.
@McArti0 : "soft brown noise" means silence (with some background noise) or an actual sound, although different from the emulator?
One level above hardware is hardware description. I had a look into the description of the PPI (https://github.com/jotego/jt8255/blob/master/hdl/jt8255.v#L100) and the PSG (https://github.com/lvd2/ay-3-8910_reverse_engineered/blob/master/rtl/ay_model.v). The PPI description is surprisingly compact.
In short: Data send via OUT to port A of the PPI is forwarded to the PSG if there is a transition from writing to non writing. This will happen when the OUT command on the CPU ends.
In more detail (and translated to something BASIC-like):
- Line 61: writing = writeData AND chipIsSelected
- Line 100ff: IF NOT writing AND wasWriting AND portAisAccessed AND portAconfiguredForOutput THEN latchA = inputData
- Line 241: Continuously transfer latchA to portA.
So at least from the description this does not seem to be the source of problems.
The description of the PSG is much more complex and nested into several levels. I did not find anything obvious that blocks incoming data from updating the selected register or to screw up other registers. But due to the complexity maybe I just did not find it.
Still, there can be differences between hardware description and actual hardware. But the PSG description was created based on reverse engineering the given hardware. So it should really be close.
Quote from: lightforce6128 on 18:25, 15 May 25@McArti0 : "soft brown noise" means silence (with some background noise) or an actual sound, although different from the emulator?
No. A distinct loud noise.
Quote from: McArti0 on 19:13, 15 May 25Quote from: lightforce6128 on 18:25, 15 May 25@McArti0 : "soft brown noise" means silence (with some background noise) or an actual sound, although different from the emulator?
No. A distinct loud noise.
Would be interesting to examine how this noise can be influenced. In those old circuits usually there is not much random. If one understands what exactly is going on internally, this can be used reliably afterwards. Updating CRTC registers several times per scanline probably was not intended by the developers, but nevertheless works. Maybe the PSG is able to produce sounds never heard before.
Using up to 4mb ram, the fastest way to bank switch is to setup a small 3 instructions at the end of the playback routine which goes to the next 64kb bank in a single hit, since all banks have almost the same 3 instructions at the same addresses except the bank number hopefully those 3 instructions don't make an audible sound given it only occurs once every 64kb
Let's say you don't want to use main memory we can use all the 64kb banks.
At the start of each 64kb bank put the looping playback routine, at the end of the routine, change banks
Ld bc,#7fxx
out(c),c
jp #0000
The last jp could be a jr, go to start of playback routine since you are now in a new bank. The last bank can either put alternate code or just put the first bank if you want it infinitely looping through 64 banks.
About 1 minute if 8bits, maybe 2 minutes if 4 bits at 60khz
Ultimately WinAPE is generating sound by sampling at up to 44kHz. Generating sound faster than that is always going to cause issues.
And doesn't really answer the question of what a Plus does.
Quote from: Longshot on 12:39, 14 May 25The example given by McArti0 doesn't work on my real machines (Plus or not). No sound.
@Longshot , thanks a lot for this info! I was already going to modify my super-old Digitracker player (but I still have to do it thanks to
@Targhan s crazy optimizations :D )
AY Datasheet shows that write consists of tds=50ns before write signal, tdw = min. 1800ns write signal, and tdh=100ns HOLD write data AFTER write signal. :-X
Quote from: Prodatron on 23:29, 15 May 25Quote from: Longshot on 12:39, 14 May 25The example given by McArti0 doesn't work on my real machines (Plus or not). No sound.
@Longshot , thanks a lot for this info! I was already going to modify my super-old Digitracker player (but I still have to do it thanks to @Targhan s crazy optimizations :D )
At the end of 2021, I released an AYC file player (originally written by Madram), which I had modified to run in fixed time while maintaining very respectable performance.
http://logon.system.free.fr/down/TFixAYC.rar
In this source code, I also added a "PPI_Experimental" option based on the work we did with Lbb and Naminu in the 1990s. The idea was to use the OUT (nn),A instruction (3 µsec, faster than OUT(C),C) to send values to port C (F6) without having to modify B, which points to port A (F4).
ld h,#86 ; PPI port C BDIR.BC1=Write Data
ld bc,#f406 ; B=IO Addr PPI Port A / C=PPI Port C BDIR.BC1=Valid
ld de,#00c6 ; D=No Reg AY cur / E=PPI Port C BDIR.BC1=Sel. Reg AY
ld a,e
out (0),a ; Select Reg AY+Validate
...
ld l,a ; 1 Value to send
ld a,c ; 1
out (c),d ; 4 Send "No Reg AY" (F4)
out (0),a ; 3 Valid (eq F6)
out (c),l ; 4 Val Reg AY (F4)
ld a,h ; 1
out (0),a ; 3 Select Type Val Reg AY
ld a,e ; 1
out (0),a ; 3 Valid & Select No Reg AYHowever, we found that this didn't work on all CPCs.
On some machines, the sound deteriorates, as the other registers are likely affected.
Rereading this source code, I think it would be more appropriate to use OUT (#ff),A instead of OUT (0),A (to minimize number of sollicited circuits), but I'm not sure that would solve the problem.
Quote from: McArti0 on 07:53, 16 May 25AY Datasheet shows that write consists of tds=50ns before write signal, tdw = min. 1800ns write signal, and tdh=100ns HOLD write data AFTER write signal. :-X
Data is transferred from Z80 to PPI and stored there. It is made available to the PSG non-stop afterwards (when the command 'OUT &F400,nn' finishes). The PSG will react to this data when its control lines (BDIR and BC1, the upper two bits of port C in the PPI) are set accordingly.
The shortest time the Z80 can influence something is 4000 ns for the 'OUT (C),r' commands and under some circumstances 3000 ns for the 'OUT (nn),A' command. In between there will be always sufficient time for the PSG to copy values.
If there would not be sufficient time for copying the values, then some parts of the circuit would work with newer bits, and other parts would work with older bits. For some circuits this would lead into disaster, for others it would only create some short-lived glitches. I guess the volume level is not critical in this case.