what software requires C3 RAM banking?

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

[d_kef]

Every CP/M Plus distribution you can find. Original or patched.

d_kef

[McArti0]

Every CP/M Plus distribution you can find. Original or patched.

d_kef

When...?

[ajcasado]

FUZIX uses C3 to write to the video RAM.

[Egg Master]

Pac-Man emulator, and... I don't know more "games" using it. Looks to be each time an OS or a tool.

[d_kef]

Every CP/M Plus distribution you can find. Original or patched.

d_kef

When...?

Always.
OK, not always, but every time you use a disk drive, after a warm start or a cold start of the OS and after you run a program and return to the command prompt.

d_kef

[McArti0]

Always.

OK, not always, but every time you use a disk drive, after a warm start or a cold start of the OS and after you run a program and return to the command prompt.

d_kef

Ok thanks I'll check it out.

[GUNHED]

Just use regular CP/M Plus

[eto]

CP/M plus works fine... that seems to be promising then.

[eto]

Pac-Man emulator,

hmh, so I can run the game with C3 but the sound is just loud noise.

Any idea if that's related to memory or something else?

[McArti0]

BASIC 

1 memory &3fff
2 poke &b7c6,&40
3 out&7f00,&c3

[GUNHED]

Better use &7FFF instead of &7F00 

[eto]

Better use &7FFF instead of &7F00 

why? 

[pelrun]

Because the way the IO devices usually work, 0 bits turn things on. You want every bit position to be a 1 except for the the ones your device absolutely needs to be a 0, because while your device may not care, other devices might.

Of course, for a trivial example like this the issue is moot (hence the smiley), but it's a good habit to be in. Otherwise you can end up wondering why your game/demo/world spanning AI works perfectly on your machine, but crashes other people's machines seemingly at random.

[Prodatron]

Thanks @pelrun for the explanation.
Anway IMHO in this case, it is more confusing than helpful, as the lower 8bits are completely ignored in this case.

This could mislead a programmers to write code like...

LD BC,#7FFF
LD A,#C3
OUT (C),A

...instead of...

LD BC,#7FC3
OUT (C),C

Would be stupid to use the first variant, only because the coder is confused by such background information, which are not affecting the actual case.

[SerErris]

LD BC,#7FC3
OUT (C),C
This is just the quick and dirty hack that is being used alot of times, because you can pack all required information into 2 instructions. instead of 3 and using one register less.
What it does is:
Put #7FC3 on the address bus (+ plus IO signal) and then also send C3 on the data bus.
However C3 is 1100 0011 ... so if you have any peripheral reacting to bits 2,3,4 or 5 then you address this as well. In the original CPC that is not a problem. But it is actually unsafe, which is what @pelrun wanted to point out.
Better (and I mean safer) is actually to use:
LD BC,#7FFF
LD A, #C3
OUT (C),A
That puts #7FFF on the address bus (as C is #FF) and #C3 on the databus. This will have absolutely no conflict and is therefore clean.
The main issue comes from the fact that hardware developers always try to save cost. Instead of full decoding of the 16 bits of the address bus, they only look at single bits. That is true for the CPC internals, but as well for external hardware manufacturers.
If you look here https://www.cpcwiki.eu/index.php/I/O_Port_Summary you see the actual issue for #F8xx .. where the XX part addresses a lot of peripherals. So hopefully everyone does a lot of decoding to understand if it is really #F8xx and not #7Fxx ...

Btw, even Amstrad does not do it right ... directly the first two instructions just assuming that nothing is only looking at the lower 8 bit ports.

Code Select Expand

********************************** RSTOi System Reset
0000    01 89 7F    LD BC,7F89        ;U ROM disabled,
0003    ED 49       OUT (C),C         ;L ROM enabled


[McArti0]

https://www.cpcwiki.eu/index.php/TMPI_speech_synthesizer

For TMPI speech uses A0-A7, then better is &7F00.

[andycadley]

In the original CPC that is not a problem. But it is actually unsafe, which is what @pelrun wanted to point out.

The design of the CPC requires that the entire 7Fxx range is reserved for the gate array. So not only is it perfectly safe, any peripheral that responds when the upper byte is #7F isn't actually compatible with the CPC.

[McArti0]

Because the way the IO devices usually work, 0 bits turn things on.

But always with one null from A8-A15

[Prodatron]

This is just the quick and dirty hack that is being used alot of times, because you can pack all required information into 2 instructions.

It's quick, but not dirty.

Better (and I mean safer) is actually to use: [...] This will have absolutely no conflict and is therefore clean.

It's not clean, it is just wasting memory and CPU time.

Btw, even Amstrad does not do it right ... directly the first two instructions just assuming that nothing is only looking at the lower 8 bit ports.

Because they knew, that this is not unsafe.

This is what I was speaking about in my previous port. The only thing, which you reach with such explanations is, that programmers may write more inefficient code.

Since >40 years hundrets of software and Amstrad itself executed OUT #7Fxx with other lower bits than #FF trillions of times, and suddenly this is unsafe and not clean. That is... erm... funny? 

[eto]

LD BC,#7FC3
OUT (C),C
This is just the quick and dirty hack that is being used alot of times,

And that is the point. It is already widely in use.

If you look here https://www.cpcwiki.eu/index.php/I/O_Port_Summary you see the actual issue for #F8xx .. where the XX part addresses a lot of peripherals. So hopefully everyone does a lot of decoding to understand if it is really #F8xx and not #7Fxx ...

Please correct me if I am wrong (still learning).

I don't see how &7Fxx and &F8xx should ever be in conflict with each other. Even if they limit decoding to the bare minimum all of those expansions at least need to decode A9-A11 - and then out &7Fxx should never activate them as 7F always sets A9-A11.

The only conflict with a memory expansion that I can see is if you would have a 4MB RAM expansion and your particular software activates a bank in the upper most 2MB (out &78xx-&7Bxx) while you have one of those expansions attached. If the expansion is only decoding A9-A11 but nothing above, then out &78xx will have the same effect as out &F8.

But I don't think that should be an issue since software that can address 4MB always knows that it can address 4MB it has to make sure that it always needs to set &7xFF.

[GUNHED]

Because the way the IO devices usually work, 0 bits turn things on. You want every bit position to be a 1 except for the the ones your device absolutely needs to be a 0, because while your device may not care, other devices might.

Of course, for a trivial example like this the issue is moot (hence the smiley), but it's a good habit to be in. Otherwise you can end up wondering why your game/demo/world spanning AI works perfectly on your machine, but crashes other people's machines seemingly at random.

Perfect explanation!  Thanks! 

As you told: It's a "good habit" and should be used when doable. 

EDIT: Well, I know at least one hardware expansion - the Hegetron Graphpad - which is completely driven by the low byte!   And it works! 

[GUNHED]

https://www.cpcwiki.eu/index.php/TMPI_speech_synthesizer

For TMPI speech uses A0-A7, then better is &7F00.

No, because the "0" turns thing on! Therefore use &FF as low-byte to keep everything else off. 

[GUNHED]

In the original CPC that is not a problem. But it is actually unsafe, which is what @pelrun wanted to point out.

The design of the CPC requires that the entire 7Fxx range is reserved for the gate array. So not only is it perfectly safe, any peripheral that responds when the upper byte is #7F isn't actually compatible with the CPC.

That's the theory. But in reality at least two expansions were mentioned, which ONLY decode the lower-byte.

Yes, in case of &7Fxx there seem to be few problems actually (I did encounter one device only, which gave problems with xx not &FF).
But it's just good practice of programming not to set bits to "0" if they can be set to "1". 

[eto]

That's the theory. But in reality at least two expansions were mentioned, which ONLY decode the lower-byte.

Any expansion that is only decoding the lower byte is violating the standard defined by Amstrad.

And all of expansions that violate the standard are at risk of being accessed incorrectly. The example with the Hegatron Grafpad or speech synthesizer perfectly illustrates that: If it's only decoding the lower byte and nothing else, than you must not only avoid it being attached when you use software that even potentially could use the quick out(c),c solution but you also must not use it in parallel to any hardware that actively uses the lower byte for addressing.

That hardware was not meant to be used in parallel with anything else or with any other software than the one it was bundled with.

It's bizarre to set up software development rules for theoretical situations that could happen with few obscure hardware expansions that are not following the standard and probably have been made for other Z80 computers and have not been modified to properly work on the Amstrad CPC.