Amstrad Plus and IM2 bug

[Longshot]

Roud :  just try to change the org &9000 to org &9001, just to see if colours swap
Ast : Goinffre!

[Ast]

Border is yellow too !

[Longshot]

Border is yellow too !

So it's not bit 0 of the address (interrupt in E2/E3)
And from code assembled from &8FFF ? (for the bit 1)

[arnoldemu]

confirmed that the instruction that is interrupted should be located in memory where A13=1.

I value is not important (i.e. the location of the Interrupt table is not important).

I tried testing:
LD BC,&FFFF

rept 64
out (c),c
endm

that still makes an error. My thoughts were that I/O address with A13=1 would be ok, but no the bug stil happens.

[arnoldemu]

I tried code at &0000, I=&20. still bug.
I tried code at &0000, int handlers at &2000. still bug
I tried code at &2000, I=&40, no bug.

Seems to confirm to me that the instruction that is interrupted, it's location is important.

[dragon]

But arnoldemu, there is something in the circuit i don't understand.


I mean, If a diode only allow pass the current in one direction, the direction of arrow in the schematic iorq never outside of the nor. And the A13 to


Its  nornal diode not a zener diode in the  schematics.


¿?.

[Longshot]

Seems to confirm to me that the instruction that is interrupted, it's location is important.

Yes, because the bug do not happen anymore. Need to confirm on more amstrad. 

When bit A13 is 0, sometimes the bug doesn't occurs. It seems it's not the bit 0 or 1 of the address (because nothing change according to AST tests)
BUT... We have tried to test replacing the LD B,A (1 nop) by ADD A,(IX+1) (5 nop)
So when each interrupt happen, it's delayed of 4 usec.
In that case, the screen is BLUE for EVERY interrupt on the AST amstrad.

[arnoldemu]

Yes, because the bug do not happen anymore. Need to confirm on more amstrad. 

When bit A13 is 0, sometimes the bug doesn't occurs. It seems it's not the bit 0 or 1 of the address (because nothing change according to AST tests)
BUT... We have tried to test replacing the LD B,A (1 nop) by ADD A,(IX+1) (5 nop)
So when each interrupt happen, it's delayed of 4 usec.
In that case, the screen is BLUE for EVERY interrupt on the AST amstrad.

I wrote in an earlier post that a memory read/write triggers the bug, when A13=0. I posted a test where I used LD B,A or HALT with A13=0 and the error didn't happen. I tried LD (DE),A with all values 0-255 and the bug remained.

LD B,A is 1 opcode read. Bug doesn't happen if only opcode read.
In another test you used LD (DE),A, that is 1 opcode read and 1 memory write.

ADD A,(IX+1)

is DD,86,nn, it is 1 opcode read, 86 could be 1 opcode read or 1 memory read, then 1 memory read for nn.  I need to look at that z80 recreation to know what happens. Then finally 1 memory read for (ix+1).

It would be interesting to know if interrupt requested at DD,86,nn or (IX+1) read causes the problem.

[arnoldemu]

But arnoldemu, there is something in the circuit i don't understand.


I mean, If a diode only allow pass the current in one direction, the direction of arrow in the schematic iorq never outside of the nor. And the A13 to


Its  nornal diode not a zener diode in the  schematics.


¿?.

Sorry I can't help. I know coding and the operation of the signals from z80 but I don't understand that crazy IC.

My guess is that they found the bug, and that is a workaround for some problems. Then when a fixed ASIC would be released they would close the link and remove the IC.

[arnoldemu]

Yes, because the bug do not happen anymore. Need to confirm on more amstrad. 

When bit A13 is 0, sometimes the bug doesn't occurs. It seems it's not the bit 0 or 1 of the address (because nothing change according to AST tests)
BUT... We have tried to test replacing the LD B,A (1 nop) by ADD A,(IX+1) (5 nop)
So when each interrupt happen, it's delayed of 4 usec.
In that case, the screen is BLUE for EVERY interrupt on the AST amstrad.

Yes please use ADD A,(IX+1) and change NOP so that interrupt happens after DD, then 86 etc.

[gerald]

I have made a truth table in paper. That can be bad, because i unsure where it take or drop in asic dependant signals. And the diode in middle i don't like it.


If i asume one component is a13 and the other taken is wait signal and the rest busreq,nmi,nint are not taken from asic signals and are only placed to then. From the nor ics.


Then niorq is 0 only in three cases:
A13=0 wait=1 iorq=0 control signals =1 output nor.
A13=1 wait=0 iorq=0 control signals =1
A13=1 wait=1 iorq=1 control signals =1


Rest of the cases=1 control signals=0


But probably is bad.

In fact this circuit is masking IORQn when WAITn is low and A13 is 0.
That is, IORQn cycle to ASIC is shortened when A13 is low : ie when you do an IN or OUT to DFxx, aka the ROM mapping register.
It looks like the access is has been reduced to only take IO into account during ASIC time (ie when wait is low), and not when the effective cycle from the Z80 point of view is done.
Why did Amstrad have done this ? It may be a bug in the ROM mapping management ?

Now why is this a problem for the interrupt ack ?
The IRQ ack cycle is : M1 low / IORQ low and address bus = PC.
So if you get the IRQ when the PC has A13 low, the IORQ will be shorter and will not be valid during the CPU time (ie when WAITn is high).
Does the ASIC still get the IRQ ACK and drive the bus until the Z80 read it ? If not, the bus is floating and we have chance to grab garbage instead of the IRQ vector.

Now looking at mother board (464/6128Plus or GX4000) there is a collection of added resistors or diode or nothing, it looks like Amstrad had trouble finding a sweet spot for this fix.
LK106 hint that Amstrad expected to fix this internally later.

Now what of we close LK106 after removing IC106 ? Who knows, but the CPC may not work as expected if it's related to ROM mapping.

[robcfg]

I was told that the diodes were used in a configuration that works like an And gate.


Sent from my iPhone using Tapatalk

[Longshot]

It would be interesting to know if interrupt requested at DD,86,nn or (IX+1) read causes the problem.

The next try is to remove the 4 nop (label "ouf") in the test code (with nbnoinst=1)
So the interrupt will occur just after the last "usec" of add a,(ix+1), exactly like the "ld b,a"
So if the delay is the problem, we will be fixed (yellow screen instead of blue).

[arnoldemu]

@gerald: Nice summary (in your original post)

Does the ASIC still get the IRQ ACK and drive the bus until the Z80 read it ? If not, the bus is floating and we have chance to grab garbage instead of the IRQ vector.

I don't think it's garbage in this case, the tests don't  show that. I think it chooses the lowest priority vector for DMA 0.
Maybe it asserts the raster vector too early, then it re-asserts but with the dma 0 vector??

[gerald]

I was told that the diodes were used in a configuration that works like an And gate.

The diodes (D201 / D202) and the pull-up (R210) form a wired AND gate. The second signal is nreset to force IORQn high during reset.

[arnoldemu]

0 nops - always blue (never yellow)
1 nop - blue/yellow cycling (bars are alternate yellow/blue but moving like K7 loading)
2 nop - blue/yellow fixed. fixed, alternate yellow and blue.
3 nop - blue/yellow fixed. fixed, alternate yellow and blue.

[dragon]

I have my  6128 plus connected, so if anyone wants i try a code in another cpc  put  it here, i have try the last put and is yelow.

@gerald whoa great explanation.

[gerald]

@gerald: Nice summary (in your original post)

I don't think it's garbage in this case, the tests don't  show that. I think it chooses the lowest priority vector for DMA 0.
Maybe it asserts the raster vector too early, then it re-asserts but with the dma 0 vector??

I fact there is a good chance that the vector is OK during the shortened ack cycle, but if the bus is floating afterward, some bit may be corrupted.
There is also an other possibility :
The ACK cycle is inserting an additional internal wait (to allow arbitration on the Z80 interrupt system priority).
Could it be that the ASIC see 2 ack instead of one because of the masking and that the Z80 waits longer?
Let me explain : the WAITn signal is only valid for one Z80 cycle at a time.
- If the ack cycle start a bit ahead of the WAITn cycle, the Z80 will have this 1st cycle partially masqued and keep ack until next waitn low. This result in 2 ack from the ASIC point of view
- If the ack cycle is just in synk with waitn cycle, the 1st cycle is totally masqued, and the ASIC only sees the last cycle.   
I think I will get my LA out this week end ...

[arnoldemu]

The next try is to remove the 4 nop (label "ouf") in the test code (with nbnoinst=1)
So the interrupt will occur just after the last "usec" of add a,(ix+1), exactly like the "ld b,a"
So if the delay is the problem, we will be fixed (yellow screen instead of blue).

@Longshot: I did it for you.

a mix of always blue, yellow and blue "loading" and fixed yellow/blue.

[Longshot]

if anyone wants i try a code in another cpc  put  it here, i have try the last put and is yelow

Attached two sources... 
Blue or Yellow ?

[arnoldemu]

Attached two sources... 
Blue or Yellow ?

I will try these tomorrow. I hope somebody tries them earlier.

inc bc - this is one of those instructions which doesn't fill the full 2 NOPS and has a cycle (or more) at the end which is free for the Z80 to use (e.g. for interrupt acknowledge). This one *will* be interesting.

[dragon]

Attached two sources... 
Blue or Yellow ?

it supposed i need made a cartridge or execute it from ram?.

I have try execute it with m4 and i have problems with m4, is yellow/black

Loading the .bin it from basic.

[Longshot]

it supposed i need made a cartridge or execute it from ram?.

Don't know if it matters ram/rom for this bug.
What is "m4" ?
Border yellow : no bug. what source have you used ? Ok (see the bug.dsk)
It's the INC BC test. So here each interrupt is delayed of 1 nop with a 1 byte instruction in a memory area (bit 13=0)
The delay of 1usec doesn't trigger the bug.
Need to know what happen with the other test (alignement-inter-instr-addaix-lastnop)

[dragon]

M4 is this, becase you send me the source i try execute it here.

http://www.cpcwiki.eu/index.php/M4_Board

A1 return me yellow.
a2 return me a little flashing and then black border, but it can be the  m4.

In the other hand someone know how made a .bin file with winape especify the star adress?

I try write [direct],"prueba.bin",&9000 but not works.

[Longshot]

Thanks for the test.

a2 return me a little flashing and then black border, but it can be the  m4.

The only possibility to have a reset with A2 in this code will be an interrupt on dma1 or dma2
To confirm that, i've made an update. red for dma2, white for dma1 (blue dma0/yellow:pri or r52)