interesting walkthrough video coding a pet to play samples at 60khz

[BSC]

OUTI  ;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. 

[McArti0]

I strongly doubt that what you claim here is possible.

Are you talking about dithering?

[BSC]

I strongly doubt that what you claim here is possible.

Are you talking about dithering?

No, the code snippet containing OUTI. 

[andycadley]

I 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.

[lightforce6128]

I 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."

[lightforce6128]

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.

If it is possible on real hardware to send values continuously, there will be glitches (I know the term hazard 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).

[Maniac]

I 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.

[Targhan]

I 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.

[andycadley]

I 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.

[Longshot]

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

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.

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.

[McArti0]

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.

[McArti0]

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. 

[lightforce6128]

@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?

[lightforce6128]

One level above hardware is hardware description. I had a look into the description of the PPI and the PSG. 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.

[McArti0]

@McArti0 : "soft brown noise" means silence (with some background noise) or an actual sound, although different from the emulator?

No. A distinct loud noise.

[lightforce6128]

@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.

[zhulien]

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

[andycadley]

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.

[Prodatron]

The 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 )

[McArti0]

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. 

[Longshot]

The 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 )

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).

Code Select Expand

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 AY
However, 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.

[lightforce6128]

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. 

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.