X-MEM, a new memory expansion for all CPC.

[Ast]

It's possible... I have to see my source code!

[Ast]

Here is a sample of my own code used in "r'n i coop"

Code Select Expand



ld bc,#7fb8:out (c),c
ld hl,#6400 ; copy anciennes couleurs
ld de,oldcol ; dans oldco
ld bc,#20
ldir
;
ld hl,#6000 ; Raz position/zoom Sprite Hard
ld de,#6001
ld bc,#7c
ld (hl),l
ldir
;
call sproff ; on planque les sprites hard derriere
; le plastique du moniteur (x=-64)






hop ld hl,tbout2:call tbout
ld hl,color1
ld de,color1+1
ld bc,32
ld (hl),0:ldir
ld bc,#7fa0:out (c),c
call clearinit
fininit
;
ei
ld bc,#7fc7:out (c),c
call intro



So after seeing the code, i can affirm that :


Asic i/O on
...blabla...
Asic i/O off
Bank x connected
...
Asic i/O on
... Blabla 2...
Asic i/O off
Bank y connected
..etc...

[arnoldemu]

Small question, is your demo code reading from the ASIC ram while extension RAM is also selected ?

I see writes to the soft scroll and split screen.. and that the crtc is reading from &4000-&7fff.

For split screen it loads a new address into the crtc so it should read from base 64kb.

expansion ram active, asic registers active, split screen at &4000. 

[Ast]

What do you mean exactly?

[arnoldemu]

What do you mean exactly?

I am thinking of another thing to test.

I looked at your demo in arnold's debugger. I could be wrong with these facts:

when the logo is moving I think you make this using asic split screen and asic soft scroll register I think. asic ram is active so you can access the registers.

I think, split screen is pointing to pixels at &4000-&7fff.

I don't know if the extra ram is also active at this time.

I am thinking that the x-mem ram causes problems (or the asic has a bug) and the asic reads pixels from the extra ram and not the base 64kb of ram. So you get pixels in the wrong place? I think the photo of your monitor is showing repeated graphics for the logo?

I will write a test  tomorrow to try this idea.

[gerald]

My question was to check if we could have a clash between the active exp ram and the mapped asic ram during a read.
This would happen if the RAMRDn signal is active during this access (and the signal should not be active).

expansion ram active, asic registers active, split screen at &4000. 

Well, the video access should not do any harm, the demo works well without the external expansion RAM.

I am thinking that the x-mem ram causes problems (or the asic has a bug) and the asic reads pixels from the extra ram and not the base 64kb of ram. So you get pixels in the wrong place? I think the photo of your monitor is showing repeated graphics for the logo?

That's not possible at all. The ASIC would need to be able to drive the Z80 address/contril bus to do so.

I don't know if the extra ram is also active at this time.

This is something you need to add to the debugger 

[Ast]

Normally, the RLL technic i used in this demo is nearby rvi without exceptions. So I use asic pri, sscr and ssa to display the good line at the good position, but, but, but.... no extra ram seems to be connected in the same time...
Code is like that :

Code Select Expand


ld bc,#7fb8 : out (c),c
call rll ; Rvi Plus Emulation
ld bc,#7fa0 : out (c),c
;
ld bc,#7fC7 : out (c),c
...do what you want...


[TFM]

That's not possible at all. The ASIC would need to be able to drive the Z80 address/contril bus to do so.

Maybe it can do that. It was Amstrads idea, but never worked well, so they didn't use it. Now it's undocumented.

[CraigsBar]

At least it is not xmem only related, my own interface has the same problem.
@CraigsBar, can you test with your symbiface ?

OK


Created a Cart with NoCart as the 464 plus has no Disc interface.


tested the cart on the 464plus with no memory Expansion - "6128 plus required" message
tested the cart on the 464plus with the x-mem - Same errors as on the 4128plus and 6128plus with x-mem
tested the floppy on the 4128plus with SymbifaceII (As the C4CPC selector does not work with the Symbiface plugged in) - Same errors as with the x-mem and the 128k machines.


Looks like it affects all expanded memory machines the same

[TotO]

Strange that problem not exist 6128plus with its 64K expansion. (and no user see it before)
When has occurred? using 128K or more?
If we can find a way to fix the problem I will send a new CPLD for plus users.

[arnoldemu]

@CraigsBar: Thank you for testing

[arnoldemu]

I am thinking of two more things now:
1. the timing is altered with the expansion ram, perhaps an extra /wait, or something different. The timing then changes when the split screen and scroll values are used; and therefore the display will show the artifacts in the picture.
2. something with memory refresh; perhaps some ram inside plus is not being refreshed (arnold docs mention disturbances with memory refresh; split screen and soft scroll). memory starts to degrade, wrong value read, but not enough to crash it.

@Ast: thank you for the confirming the asic ram is not active.

@gerald: yes, something I will need to add to the debugger. My expansion implementation has simulated ROMDIS, RAMDIS, ROMEN and RAMEN, it seems I need to expose these into the debugger now and a way to determine which device is asserting them. Then it would be possible to see - if my emulation is correct which device is active.

[arnoldemu]

@Ast: Please can you post a photo of Roudoudoduodu's asm demo running on your plus with x-mem?

[arnoldemu]

One more idea!

@Ast: you had different results... one time the screen was bad, one time the sprites were bad??

So.. I had an idea.

Please try this to see if results are consistent.

1. Insert this disc
2. memory &9fff:load"ivr.bin",&a000:call &a000
3. now run your demo.

Is it fixed, or are the results always the same when you follow these steps?

The idea behind this demo:
- When interrupts are acknowledged, asic will use IVR and register I to put an address on the bus.
Maybe there is an interaction here, or a delay because IVR and I register are possibly not initialised, or are set to values which cause a problem.

[gerald]

I've found what's wrong.
It looks you are writing to the ASIC ram while having the extension ram selected as well.
- When using the internal extension, the ASIC knows that the ASIC ram is active or not and will write either to its internal RAM or to the expansion ram.
- When using the external extension, the extension does not know anything about the ASIC ram configuration and does the write.

In fact the extension should monitor the write to IO 7Fxx for %10111ppp value and inhibit access.

[arnoldemu]

@gerald:
The write goes to asic ram AND to expansion ram?

Does the asic assert any signals to indicate it's a internal asic ram access?

Should ALL expansion rams will suffer from this problem?

Ast said that he used 7fc0 to restore base ram before he did asic writes?

[arnoldemu]

the test program should show the error gerald has discovered.

it enables extra ram.
it writes &aa to it
it then enables asic ram
it writes &55 to it
it then disables asic ram
it reads the value

if it's changed, then value has gone to asic and extra ram. pen 0 changes colour.
if pen 0 is black, no write through.

[gerald]

The write goes to asic ram AND to expansion ram?

Yes I guess. I will make some test to confirm.

Does the asic assert any signals to indicate it's a internal asic ram access?

There is no signal like this. Remember that the extension port did not change with the plus.

Should ALL expansion rams will suffer from this problem?

To not suffer from this problem, the extension need to decode the ASIC ram mapping register. And to to it properly, it also need to emulate the ASIC lock/unlock mechanism ...
So I guess that all memory extension made suffer from this problem.

Ast said that he used 7fc0 to restore base ram before he did asic writes?

I've seen the problematic write with a logic analyser. I cannot say for sure the ASIC RAM was enabled but writes clearly targeted ASIC register (sprite position &6000 and further), and the ram extension did the write as well.

[gerald]

the test program should show the error gerald has discovered.

it enables extra ram.
it writes &aa to it
it then enables asic ram
it writes &55 to it
it then disables asic ram
it reads the value

if it's changed, then value has gone to asic and extra ram. pen 0 changes colour.
if pen 0 is black, no write through.

Pen0 :
- black without external ram extension
- yellow with external ram extension

Problem confirmed !

[Prodatron]

So I guess that all memory extension made suffer from this problem.

Wow, that explains a lot! Thanks so much for this finding!

[arnoldemu]

Pen0 :
- black without external ram extension
- yellow with external ram extension

Problem confirmed !

Great. One more test. 7fc0 is selected.

If this shows black, which I hope it does, then to work around the issue, 7fc0 must be selected before asic registers are enabled.

[arnoldemu]

Yes I guess. I will make some test to confirm.

Perhaps it can be worked around?

There is no signal like this. Remember that the extension port did not change with the plus.

I hoped an existing signal would indicate it somehow.

To not suffer from this problem, the extension need to decode the ASIC ram mapping register. And to to it properly, it also need to emulate the ASIC lock/unlock mechanism ...
So I guess that all memory extension made suffer from this problem.

ouch!

So, lets look on the positive side:
1. we know about the problem now
2. we can detect it.
3. if we detect it, writes could be done to the unmapped area in asic ram, now we can keep asic ram open AND make writes to extra ram! BONUS! 

EDIT: What happens to the a memory read? Is it visible in the unmapped area exactly, does it conflict with read/write registers like sprite data...?

I can do some more tests to answer all of these

[TotO]

Is this "bug" should allow to exchange the sprites content by swapping the external expansion banks? 

[gerald]

So, lets look on the positive side:
1. we know about the problem now
2. we can detect it.
3. if we detect it, writes could be done to the unmapped area in asic ram, now we can keep asic ram open AND make writes to extra ram! BONUS! 

EDIT: What happens to the a memory read? Is it visible in the unmapped area exactly, does it conflict with read/write registers like sprite data...?

Read is not a problem. The ASIC is generating the RAMOEn signal that the extension should use, and Amstrad engineer did they work properly ! (I've already checked this)

Great. One more test. 7fc0 is selected.
If this shows black, which I hope it does, then to work around the issue, 7fc0 must be selected before asic registers are enabled.

This obviously work 

[gerald]

Is this "bug" should allow to exchange the sprites content by swapping the external expansion banks? 

no