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?
Every CP/M Plus distribution you can find. Original or patched.
d_kef
Quote from: d_kef on 09:02, 07 January 25Every CP/M Plus distribution you can find. Original or patched.
d_kef
When...?
FUZIX uses C3 to write to the video RAM.
Pac-Man emulator, and... I don't know more "games" using it. Looks to be each time an OS or a tool.
Quote from: McArti0 on 09:04, 07 January 25Quote from: d_kef on 09:02, 07 January 25Every 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
Quote from: d_kef on 12:19, 07 January 25Always.
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.
Just use regular CP/M Plus
CP/M plus works fine... that seems to be promising then.
Quote from: Egg Master on 11:24, 07 January 25Pac-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?
BASIC :D
1 memory &3fff
2 poke &b7c6,&40
3 out&7f00,&c3
Better use &7FFF instead of &7F00 ;)
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.
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.
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.
********************************** RSTOi System Reset
0000 01 89 7F LD BC,7F89 ;U ROM disabled,
0003 ED 49 OUT (C),C ;L ROM enabled
https://www.cpcwiki.eu/index.php/TMPI_speech_synthesizer
For TMPI speech uses A0-A7, then better is &7F00.
Quote from: SerErris on 13:14, 10 January 25In 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.
Quote from: pelrun on 09:40, 10 January 25Because the way the IO devices usually work, 0 bits turn things on.
But always with one null from A8-A15
Quote from: SerErris on 13:14, 10 January 25This 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.
Quote from: SerErris on 13:14, 10 January 25Better (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.
Quote from: SerErris on 13:14, 10 January 25Btw, 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? ;)
Quote from: SerErris on 13:14, 10 January 25LD 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.
QuoteIf you look here https://www.cpcwiki.eu/index.php/I/O_Port_Summary (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.
Quote from: pelrun on 09:40, 10 January 25Because 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! :o And it works! :o
Quote from: McArti0 on 13:55, 10 January 25https://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. :)
Quote from: andycadley on 14:02, 10 January 25Quote from: SerErris on 13:14, 10 January 25In 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". :)
Quote from: GUNHED on 16:07, 10 January 25That'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.
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 ;-) )
Quote from: SerErris on 00:13, 11 January 25, 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:
Screenshot 2025-01-10 at 6.00.28 PM.png
When &7Fxx is accessed, it will never set A10 to 0. As long as the expansion decodes that bit it will never be active.
Screenshot 2025-01-11 at 11.38.50 AM.png
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.
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?
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
Quote from: Egg Master on 12:38, 11 January 25The 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.
Quote from: McArti0 on 13:39, 11 January 25A15-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
0111 10xx 11xx xxxx always deactivate uD765
| #FB7F | %xxxxx0x1 0xxx xxx1 | 765 FDC (https://www.cpcwiki.eu/index.php/765_FDC) (internal) Data Register | Read | Write |
| #FA7E | %xxxxx0x0 0xxx xxxx | Floppy Motor Control (for 765 FDC (https://www.cpcwiki.eu/index.php/765_FDC)) | - | Write |
Quote from: eto on 01:52, 07 January 25I 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.
Quote from: McArti0 on 14:27, 11 January 250111 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 1
111 1100 0100
how should that be in conflict with?
1111 1
0xx 11xx xxxx
A10 is still different. No issue.
Quote from: norecess464 on 14:31, 11 January 25Quote from: eto on 01:52, 07 January 25I 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.
Quote from: McArti0 on 14:27, 11 January 250111 10xx 11xx xxxx always deactivate uD765
| #FB7F | %xxxxx0x1 0xxx xxx1 | 765 FDC (https://www.cpcwiki.eu/index.php/765_FDC) (internal) Data Register | Read | Write |
| #FA7E | %xxxxx0x0 0xxx xxxx | Floppy Motor Control (for 765 FDC (https://www.cpcwiki.eu/index.php/765_FDC)) | - | Write |
I speak about A7.
A10 set custom ext IO.
A7 set FDC
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)
Quote from: norecess464 on 14:31, 11 January 25Phortem (https://www.cpc-power.com/index.php?page=detail&num=10030 (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!)
Quote from: eto on 15:04, 11 January 25phX (https://www.cpc-power.com/index.php?page=detail&num=15102 (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.
Quote from: eto on 20:50, 12 January 25Quote from: norecess464 on 14:31, 11 January 25Phortem (https://www.cpc-power.com/index.php?page=detail&num=10030 (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.
Quote from: norecess464 on 23:42, 12 January 25In 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.
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
Quote from: Prodatron on 02:15, 14 January 25Too 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?