what software requires C3 RAM banking?

[SerErris]

I agree that the gate array is pretty save, but that is just the gate array - other things esp. in the F8 range should be fully decoded and therefore also fully programmed. 

This was maybe a bad example, but still it requires that hardware developers know not to use 7F range in any way. If they do not know then we can figure out whos fault it was (probably hardware guy ;-) )

[eto]

, but still it requires that hardware developers know not to use 7F

I still don't see where this is a problem unless the hardware violates the only mandatory rule regarding decoding:
You cannot view this attachment.

When &7Fxx is accessed, it will never set A10 to 0. As long as the expansion decodes that bit it will never be active.

You cannot view this attachment.
The risk starts when software accesses RAM above 2MB as then A10 will be set to 0. But since there is absolutely no possibility that software is setting RAM banking in the upper 2MB without being aware of it, there is not even a theoretical issue as the software in that case (and only in that case) just needs to set &7xFF to avoid it.But for anything else that is only accessing RAM in the lower 2MB there is no issue as long as the only rules for address decoding is followed.

I still might be missing something but then please explain how out &7Fxx would accidentally activate any feature on an expansion as long as it decodes A10 which all (except for 2) do.

[Egg Master]

The RAM acces use MREQ while the peripheral IORQ. So, I can imagine decoding A10 is not the only requirement? 
The issue is related to the RAM banking by doing OUT, that looks incompatible because it use IORQ too?

[McArti0]

A15-A8 = 0111 10XX <-- This is a problem because it can access other devices.

F8 not access to IO RAM register.
7F not access to uD765

[eto]

The RAM acces use MREQ while the peripheral IORQ. So, I can imagine decoding A10 is not the only requirement?
The issue is related to the RAM banking by doing OUT, that looks incompatible because it use IORQ too?

This discussion is about the commands to tell an RAM expansion activate banking, and of course not the RAM access itself, which is (as you pointed out) not related to the IORQ. But the activation/deactivation of RAM banking also uses the IORQ to address the GateArray/PAL (or RAM expansion logic).

RAM bank activation/deactivation will happen after sending an OUT to &7fxx. E.g. OUT &7f00,&c4 activates a 16K RAM block in the first 64K of additional RAM.

[eto]

A15-A8 = 0111 10XX <-- This is a problem because it can access other devices.

Yes. And that's what I already wrote twice: RAM access above 2MB.

OUT to &78xx,&79xx,&7Axx and &7Bxx

And honestly speaking it's not the fault of the software or the hardware that this is an issue. It's the fault of whoever designed RAM access above 2MB to use A10 as this violates the standard for expansion address decoding as set by Amstrad. But even that can be solved by applying a simple rule:

- RAM access above 2MB is fine if the software (which knows it can run above 2MB) only sends out &7xFF,yy
- RAM access up until 2MB is totally fine and will not be in conflict with other expansions (as long as they don't violate the A10 rule) so the software can continue to use the fast version  ld bc,&7FC4; out (c),c

[McArti0]

       0111 10xx 11xx xxxx  always deactivate uD765

#FB7F

%xxxxx0x1 0xxx xxx1

765 FDC (internal) Data Register

Read

Write

#FA7E

%xxxxx0x0 0xxx xxxx

Floppy Motor Control (for 765 FDC)

-

Write

[norecess464]

I am now working on a RAM expansion for the 464 with C3 support and I would love to test it with some software but I am not sure which software requires C3. I know that FutureOs uses it for the mouse sprite. Any other suggestions what I can try?

I can certify that my demos Phortem (https://www.cpc-power.com/index.php?page=detail&num=10030) and phX (https://www.cpc-power.com/index.php?page=detail&num=15102) both rely heavily on C1/C2/C3.

[eto]

0111 10xx 11xx xxxx  always deactivate uD765

Yes. Of course. Because that is NOT &7F but &78/79/7A or 7B . And that is RAM access ABOVE 2MB where you have to be careful. But not below the 2MB mark. 

OUT &7FC$,&C4 is 

0111 1111 1100 0100 

how should that be in conflict with?
1111 10xx 11xx xxxx 

A10 is still different. No issue. 

[eto]

I am now working on a RAM expansion for the 464 with C3 support and I would love to test it with some software but I am not sure which software requires C3. I know that FutureOs uses it for the mouse sprite. Any other suggestions what I can try?

I can certify that my demos Phortem (https://www.cpc-power.com/index.php?page=detail&num=10030) and phX (https://www.cpc-power.com/index.php?page=detail&num=15102) both rely heavily on C1/C2/C3.

perfect, thanks. I will give it a try. 

[McArti0]

0111 10xx 11xx xxxx  always deactivate uD765

#FB7F

%xxxxx0x1 0xxx xxx1

765 FDC (internal) Data Register

Read

Write

#FA7E

%xxxxx0x0 0xxx xxxx

Floppy Motor Control (for 765 FDC)

-

Write

I speak about A7.

A10 set custom ext IO.

A7 set FDC

[Egg Master]

A10 = 0 : Peripherals
A9 = 0 : Undefined?
A8 = 0 : Undefined?

A7 = 0 : Amstrad FDC
A6 = 0: Undefined?
A5 = 0: Amstrad Serial (used by the Usifac and some mouse)
A4 = 0 : Undefined?

A3 to A0 : Used for peripherals features

If A10 = 0, but nothing else (&F8FF), it looks to be peripherals soft reset
(wiki: MC_BOOT_PROGRAM and MC_START_PROGRAM do OUT [F8FF],FF)

[eto]

Phortem (https://www.cpc-power.com/index.php?page=detail&num=10030)

Visuals perfectly work but sound is just white noise. I had the same with Pac-Man emulator. I guess that means that some kind of memory access doesn't work right. Can you share any details that might help finding the issue?

(btw: the demo looks awesome!)

phX (https://www.cpc-power.com/index.php?page=detail&num=15102)

It starts but then my monitor will no longer sync. I'll have to try again with a CPC monitor.

[norecess464]

Phortem (https://www.cpc-power.com/index.php?page=detail&num=10030)

Visuals perfectly work but sound is just white noise. I had the same with Pac-Man emulator. I guess that means that some kind of memory access doesn't work right. Can you share any details that might help finding the issue?

In Phortem, the music is being accessed by first selecting bank &C5 and then play the music at the address &5103.

[eto]

In Phortem, the music is being accessed by first selecting bank &C5 and then play the music at the address &5103.

thanks. turned out my expansion works fine but I used a Z0840004PSC CPU - at least that's what is printed on it. And it caused problems. Switching to another Z0840004PSC solved it.

[Prodatron]

Little background information about this:

The illegal Z80 command...
DB #ED,#71

does...
OUT (C),#00 on NMOS cpus, but
OUT (C),#FF on CMOS cpus

Too bad, OUT(C),0 is used in many PSG players/drivers, as it's very useful for the PSG access, which sits behind a PPI:

https://www.cpcwiki.eu/index.php/How_to_access_the_PSG_via_PPI#Writing_to_a_PSG_register

[eto]

Too bad, OUT(C),0 is used in many PSG players/drivers

Perfectly explained! I was aware of it but still got by surprise as I was actually using an NMOS CPU. At least that's what I thought. 

When I am doing the tests with the RAM expansion I always use a spare Z80 that remains in the expansion. The expansion in the CPC 6128 had a Z0840004PSC and the expansion for the 464 also had a Z0840004PSC. The 6128 expansion worked perfectly fine, the 464 version had the noise issue. When I removed  the expansion and replaced it with the original CPU sound was also fine, so I suspected my memory expansion to be the root cause. Only after I accidentally put another Z0840004PSC into the 6128 directly the issue appeared there too - and then it became clear that the issue could be related to the CPU. Then I tested all the PSC ICs I had and the behaviour was not consistent. 

So I do have now 3 Z0840004PSC where one behaves as expected and two behave like the CMOS CPU. Sure it might be fake but the CPUs are all from the same seller and they look absolutely identical. Question is now: is there a market for perfect fake NMOS Z80s - or are there genuine Z0840004PSC which also lack the out(c),0 support?