Amstrad Plus and IM2 bug

[arnoldemu]

One theory i manage, was if the asic examines the opcode that z80 reads. So i examine the binare formats of the know instruction not working and working. But i don' have view a parameter.

interesting, but I don't think it will do that.

I will be testing all the opcodes soon. In my tests I did only a few.

[dragon]

So the test are made from cartridge. And cartridge are connected directly to the z80.

So then halt works becase z80 reads it from rom?.



So... we made a       


Opps. Thank macleod_ideafix for the info.

[arnoldemu]

I am sure I did tests where I copied it to ram.

[dragon]

Ahh, then perfect i no have try all.   i was think all was fromcartridge.

[Longshot]

Hello,
the program attached can test if the bug is related to an instruction not finished when interrupt occurs.
it is auto calibrating the delay for a one-nop instruction.
if you want to test a longer instruction than "ld b,a" like "add a,(ix+1)" (5 nop), just put the instruction at "instruction"
Don't forget to set "nbnopinst" to 5, because the program needs to compensate the delay for the next interruption
The colors are the same used in kevin's tests. 

[arnoldemu]

Thank you I will test it on Sunday.

[arnoldemu]

I noticed recently that Arnold didn't emulate the interrupt request priority on the plus correctly - I will be fixing this. It is related to the IM2 bug too.

I made more tests and ran them on my gx4000. I will report back with my findings because I am sure they are related to this bug.

@Longshot: I tried your test but it always displayed yellow. I'm not sure I set it up correctly. I will try it again.

[arnoldemu]

I am sure I did tests where I copied it to ram.

I did, it doesn't matter if test is run from rom or ram, the result is the same.

[Ast]

The adventure goes on & takes place here !
You could find the result of many and many possibilities.


French only, but who cares ?

[dragon]

The adventure goes on & takes place here !
You could find the result of many and many possibilities.


French only, but who cares ?

Well, google traslator french-spanish is crap. If you can made a resume better.

[roudoudou]

Well, google traslator french-spanish is crap. If you can made a resume better.

the french topic do not describe the IM2 bug but talk about interrupt acknowledgment in IM2 mode with the CPC+ (which has two ack mode: universal & specific ack)

[arnoldemu]

the french topic do not describe the IM2 bug but talk about interrupt acknowledgment in IM2 mode with the CPC+ (which has two ack mode: universal & specific ack)

Yes.

The ASIC listens in on signals from the Z80 (/M1, /IORQ,/RD,/WR,/MREQ).

Combinations of these determine what the Z80 is doing.

/M1,/IORQ is an interrupt acknowledge from Z80. Interrupts are not masked (EI), and Z80 is about to execute maskable interrupt (IM0, IM1 or IM2). The device should put the vector on the bus for IM2.

/M1,/MREQ is an opcode fetch. (I think) For instructions such as LD DE,nnnn it is the first byte only.

/MREQ,/RD is a memory read. For instructions such as LD DE,nnnn it is reading the nnnn value.

/MREQ,/WR is a memory write.

/IORQ,/RD is an i/o read. e.g. IN A,(C)

/IORQ,/WR is an i/o write. e.g. OUT (C),A


When the int is acknowledged, Z80 will set DI, and execute the function. Then to allow interrupts to be accepted again you do EI:RET.

The interrupt is not re-enabled until the opcode *AFTER* EI. So interrupts become active after the RET.

Some devices listen in on RETI (they read the bus and recognise the exact official opcode) - e.g. Z80 PIO, Z80 CTC, but I don't think the ASIC does this.

For the ASIC, if a DMA channel interrupts (from an interrupt command) and DCSR=1, then they will re-interrupt immediately after the EI:RET until you clear the interrupt using a write to DCSR. At this point the DMA will stop interrupting because you told it to.

If DCSR=0, then interrupts are auto-acknowledged - I will test this much more to find the exact operation. In this case you don't need to write to DCSR and the DMA will only re-interrupt once a interrupt command is executed.

The raster interrupt though is cleared automatically because that is what the original CPC did. It is auto-acknowledged by the Z80 acknowledging it. The interrupt can be manually acknowledged by setting bit 4: LD BC,&7f00+%10010000: OUT (C),C <<<<

In IM2 mode, at the point of interrupt request the ASIC decides on the vector - this decision is bugged.

Also, there are priorities for the interrupts, it claims raster then dma, but my testing shows this also is not quite how I expected it and it's related to the interrupt vector decision.
It's possible that there is a bug in the hardware that accidentally sees a memory write as an interrupt acknowledge and it gives the correct vector for 1 byte opcodes, and then a bad vector for more than 1 byte (note. ED and CB operations have two opcode reads.)

I will give more info once I look at the data I got.

I setup various tests, delaying and not delaying and looked at how many times and the dcsr values when the interrupts were triggered.

[Longshot]

The raster interrupt though is cleared automatically because that is what the original CPC did. It is auto-acknowledged by the Z80 acknowledging it. The interrupt can be manually acknowledged by setting bit 4: LD BC,&7f00+%10010000: OUT (C),C <<<<

It's true BUT it's also resetting the R52 counter to 0...
And this counter is also running during the interrupt.
Furthermore, if the counter R52 reach 52 with interrupts disabled, the interrupt is pending.
From that point onwards, the bit 5 of the R52 is cleared when interrupts are enabled.
So, if EI is done while bit 5 of R52 = 1, it misses 32 lines and that can cause a missing interrupt when vbl occurs...

About the bug dma/raster, AST has tested the code on his amstrad plus with multiple instructions set: yellow screen.
So, before trying to analyze further, it would be interesting to reproduce the error on more platforms.
It seems to me that the code attached is very similar to your "intbug1.asm" (excepted ret instead of reti, some initialization (crtc, screen), the interrupt table in &4000 or the fact this code is not executed from the boot and some instructions have already been executed by z80a).
With that code, AST has just a yellow border. No blue...
Can you replace this code in your test in 0000 ?

[arnoldemu]

It's true BUT it's also resetting the R52 counter to 0...
And this counter is also running during the interrupt.
Furthermore, if the counter R52 reach 52 with interrupts disabled, the interrupt is pending.
From that point onwards, the bit 5 of the R52 is cleared when interrupts are enabled.
So, if EI is done while bit 5 of R52 = 1, it misses 32 lines and that can cause a missing interrupt when vbl occurs...

Yes. The same is true on old CPC.

About the bug dma/raster, AST has tested the code on his amstrad plus with multiple instructions set: yellow screen.
So, before trying to analyze further, it would be interesting to reproduce the error on more platforms.
It seems to me that the code attached is very similar to your "intbug1.asm" (excepted ret instead of reti, some initialization (crtc, screen), the interrupt table in &4000 or the fact this code is not executed from the boot and some instructions have already been executed by z80a).
With that code, AST has just a yellow border. No blue...
Can you replace this code in your test in 0000 ?

Yes i will try it. 

@Longshot, what is your configuration? (Which Plus, mainboard, system cartridge, hardware connected etc..?)

I tried the interrupt table at &4000. I think I also tried EI:RET but I will check again.

There is some interesting logic near the CPU on the Plus, it's related to A13,/WAIT,/IORQ,/INT,/NMI.
See this:
http://www.cpcwiki.eu/index.php/File:GX4000_CPU_Schematic.png

IC16.

I don't know what it does and I don't remember if I got an answer before...

It's possible there is something related to the rom paging port (dfxx) with the interrupt bug because of this logic.


My investigations for interrupt request do this (and these are run from 0):
- set raster interrupt
- enable dma
- setup a list to make an interrupt
- do not acknowledge dma interrupt, let it keep interrupting

If raster comes first:
- raster interrupt function is executed once.
- dma interrupt function is then executed (if dma2 is active - and because it's highest priority - this always runs, the others do not get their go)

Strange, raster has priority over dma, so raster interrupt should execute when it comes?

If dma comes first:
- mostly the raster interrupt function is never executed (if dma2 is seen first it is the only interrupt function called)
- *sometimes* the raster interrupt function is called but not often (if dma 0 comes first this happens)

I will continue testing to find the exact cause of this strangeness.

[dragon]

Also the use of lk106 is unkown in the wiki, it also appears enable direct operation from z80 without the extra logic.


Is a buch of nor, so the truth table is:


0+0=1
0+1=0
1+0=0
1+1=0

[robcfg]

Hi!


I've had a chat with @Habi about this, and this is what we've found:

It's possible there is something related to the rom paging port (dfxx) with the interrupt bug because of this logic.

http://www.cpcwiki.eu/index.php/I/O_Port_Summary lists 0XDFxx as "Upper ROM Bank Number (as decoded within CPC664, CPC6128, 464+, 6128+, decoding in ROM expansions may be different)".

There is some interesting logic near the CPU on the Plus, it's related to A13,/WAIT,/IORQ,/INT,/NMI.

Habi told me that teh logic is there to block some ports.

Also the use of lk106 is unkown in the wiki, it also appears enable direct operation from z80 without the extra logic.

Right. Using LK6 would bypass the gates, but Habi warned me not to use it without removing the NOR gates chips.


Hope this helps!

[dragon]

Remove it  or cute 5v power.


But why amstrad search block some ports?.


Something is hidden in the asic?. Something feature not finished?.


That only increase the cost. And what ports are blocked?

[roudoudou]

Something is hidden in the asic?. Something feature not finished?.

There is a legend about floppy DMA premises

[Longshot]

@Longshot, what is your configuration? (Which Plus, mainboard, system cartridge, hardware connected etc..?)

I've no access to my original amstrad plus.
About tests, i wanted AST to try my code on his amstrad plus, but the bug never occurs
So i wrote a test that is very similar to your first test ( ;; CPC style raster ints, no DMA, leaving at default h/w values)
With that test, you got: flashes yellow and blue, 52 lines between each
But on AST's Amstrad Plus, the bug does not happen.
So i wanted you to test my code on your hardware and ast to test your code on his hardware 

The DF00 port seems to be a good idea.

[Ast]

I asked Roudoudou to do the same on his hardware.
So, wait for the result now!

[roudoudou]

The DF00 port seems to be a good idea.

Will do some test with or without (youuuuuuuuuuuuuuu) this feature activated

[arnoldemu]

I've no access to my original amstrad plus.
About tests, i wanted AST to try my code on his amstrad plus, but the bug never occurs
So i wrote a test that is very similar to your first test ( ;; CPC style raster ints, no DMA, leaving at default h/w values)
With that test, you got: flashes yellow and blue, 52 lines between each
But on AST's Amstrad Plus, the bug does not happen.
So i wanted you to test my code on your hardware and ast to test your code on his hardware 

The DF00 port seems to be a good idea.

no problem. I'll do a test tomorrow.

[roudoudou]

i found something 


if the code is executed in "lower" memory (near 0 like Kevin's code) the bug is here
if the code is executed in "upper" memory (#A000) there is no bug
disregarding if the code runs from RAM/ROM


very strange

[roudoudou]

BUT if i select an upper ROM to execute the code in #C000 the bug is here 

Next step keep longshot code in #A000 (without bug) and simply connect an upper empty rom doing nothing

[arnoldemu]

BUT if i select an upper ROM to execute the code in #C000 the bug is here 


Next step keep longshot code in #A000 (without bug) and simply connect an upper empty rom doing nothing

If possible please post your code changes so I can run them