Amstrad Plus and IM2 bug

[arnoldemu]

But, I think you are doing it bad. I think you should put the ivr (is the autoclear register &6805 right?) first,and  then after that you can put z80 in im2 mode. But i view you made it in reverse.

I only reading the spedification 1.4. he tells"sofware should always set up ivr  before placing the cpu in vectored mode". before=Antes no? ivr=&6805?.

PD:where i can donwload the cpr build?. I have nothing my two ide die from bad sectors. So i have two clean sata hd empty.

good point.

I tried that and still the same bug.

buildcpr is here:
http://www.cpctech.org.uk/download/buildcpr.zip

pasmo is here:
http://pasmo.speccy.org/

I attached all my latest tests. zip has source, bin and the cprs.

intbug1-13 try different things. (intbug13 does ivr before im 2).

if here was no bug, then these should show yellow. But because the bug happens they show blue and yellow.

Some have pixels on the screen. There are marker bytes and pixels above them.
The order is dma 2,1,0 and raster. (vector +0, vector+2, vector+4,vector+6).

In these you can see when bug happens because there are pixels above right two markers. Without bug only rightmost marker should have pixels above it.

noidea1,1b,1c updated, they show the bug, it's not clear if auto-clear makes it worse or not, can't tell.
noidea1,1b,1c run the dma for a short time. I do this because I don't want to make a change to the main loop.

In these there are extra markers. Above the extra markers is the byte from 6c0f.

some of the "noidea" are experiments. I didn't know if the result was bad or good.

nointbug doesn't trigger the bug.

[robcfg]

I know it would be a pain but it may be worth following the ram connected pins of the decapped ASIC picture and see what we find.


Sent from my iPhone using Tapatalk

[dragon]

I think is only one bit the problem. If in the sea of gates you find the register is folow it.


I made test with arnoldemu test 13. And the only can view is the speak in the first post when z80 put   data in the bus appear the bug if you made z80 internal  operation as add or rest. Is no problem

It can be the bus, but it can be a problem in z80 signal controls that go in to the asic.

But there is something we misss. Because really when the z80 pc register go to pc+x he automatically read the next instruction from ram to store and decode it in  the z80 ir register.

Thats mean that every time we excecuted a add, we are reading from memory. And interrupts not are affected!

So we can assume the in the case of ld(de),a.The reading instruction from memory and the asociated control signals don't affect the interrupts. Thats mean that the problem ocours after z80 have decode the instruction internally and it go to the next step, execute the instruction.



but, we know that single internal instructions not affect interrupts.


So what is the diference beetwen automatic read ram from cpu when yo go to next instruction and manual read using a ld?.

More cpu cycles?.


Push pop generated interrupts bug?.


One difference for example is,m1 signal pin go low when fetch instruction is read or interrupt cycle but is high if read write ram cycle. is made normal or in/out instructions are used.


Pd:
Cpr builders is  exe.? windows not open it

[andycadley]

Nothing definitive yet, but my tests so far are attached (Kev feel free to put these in with your tests if they're helpful!).


I've basically tried to rule out a few things:


Does it matter if you only use the "Plus" method of changing colours vs the "old" way? Answer: seems to make no difference.
Is it a timing issue, does delaying the interrupt (by creating long "uninterruptable" nop sequences) affect the outcome? Answer: doesn't appear to make any difference.
Does the raster line matter? Answer: nope
Does it ever redirect to a different vector altogether? Answer: so far, appears to only ever accidentally call the DMA channel 2 vector .

Still trying to think of any other tests that might help pin things down.

[arnoldemu]

@andycadley: Thank you for your help I will add them to my tests.

I have made up some new tests which I haven't run yet:

1. Attempt to trigger DMA then raster interrupt but delay the interrupt and see which vector is called.
For this one, I vary which DMA channel interrupts first and I also setup some to interrupt at the same time.

2. Attempt to trigger raster interrupt then DMA interrupt and see which vector is called.
Same as 1, I vary the order and when they interrupt.

3. A test which triggers dma and then raster without delaying the interrupt. The idea here is to check bit 7 of DCSR to see if this has any impact.


What I haven't tried yet:

Use an instruction such as LD HL,nnnn. Vary the number of nops so that the interrupt request for DMA and raster trigger at different points within the same instruction. Does this change the result?

[dragon]

If i in test 13 put under your ld de=&2'000  another instruction with hl and same memory &2000


An later in the loop i change ld de,a  to bit 1,(hl), The colour predominat is yellow, blue appears, but very very little in a miniline.

But set appears have the same effect that ld  instruction flashing blue/light continously.

cp(hl) have the same effect that bit  instruction.


In the other hand i found this great page. It contains the timmings for all instructions. And the signals activated:


http://baltazarstudios.com/zilog-z80-undocumented-behavior/

[andycadley]

Noticed some bugs in tests #6 and #7 so they weren't quite doing as I expected (though the results are still possibly meaningful) so attached are bugfixed versions (as #8 and #9) and a couple more tests with DMA lists running (with and without the Auto Clear Off bit set). Not much to add in terms of actual knowledge from them yet.

[arnoldemu]

Thanks @dragon and @andycadley I appreciate the help

I will do more testing probably next weekend. I'll be too busy in the week to do testing.
Please keep the tests coming if you have time.

I'll look over the link you sent @dragon - very useful to know the exact operation of the instructions.

[dragon]

The last days i try another aproximation, but i don,t know really was happening.


I try used and undocumented opcode ED7E. Im2 mode alternative. I put it with defb substituting the im2 instruction.


The gx4000 show me a grey, but i can made bad it.not sure if defb &ed7e is valid(or is &ed,&7e) Or if the st z80 support the instruction.


Another aproximation, is use out incompatible instructions with the cpc architecture. Sending a with one semicompatible. To port 0 causes blue screen,with lite line in middle flashing. Change a valor, provoques strange effects in the screen. So i not sure if the crt. Is responding me or what happends Wtf.

[Longshot]

Hello

Arnoldemu, is it normal that there are no "di" in your test programs while you do all the initializations? 
Or maybe this code is launched from a code with disabled interrupts?

I don't have the actual amstrad plus available.
Do you confirm that the bug never occurs when the main code wait the interrupt with sequencies of tons of halt ?

I've a question about acknowledge of dma interrupt. (sorry if it's not exactly related to the subject) 
When a raster interrupt is acknowledged (through EI), the Gate Array, bit 5 of the 52 lines counter is cleared.
Is it true also for dma interrupts, whatever the ack method used (ei or dcsr+ei) ?
(winape clear the bit 5 of the R52 counter before executing the first opcode of the interrupt code)

[arnoldemu]

Hello

Arnoldemu, is it normal that there are no "di" in your test programs while you do all the initializations? 
Or maybe this code is launched from a code with disabled interrupts?

Yes it's correct.

I put the test cpr into one of the slots in the c4cpc (normally 1), set the switches and the c4cpc boots direct into the cart without the menu. The code is executed with power-on-state of computer.

This includes:

Z80 set to Interrupt mode 0.
Interrupts are disabled.
CRTC registers all 0
PSG all zero.
Most Z80 registers are FFFF. (PC=0)
Cart page 0 at &0000 and &c000.
Mode 0.
IVR has bit 0 set to 1.
PRI is disabled (standard CPC interrupts)
DMA inactive
ASIC is locked.
Colours are undefined.
RAM is undefined.

I don't have the actual amstrad plus available.
Do you confirm that the bug never occurs when the main code wait the interrupt with sequencies of tons of halt ?

No not yet. I have confirmed it with 1 HALT. I will try your suggestion.

I've a question about acknowledge of dma interrupt. (sorry if it's not exactly related to the subject) 
When a raster interrupt is acknowledged (through EI), the Gate Array, bit 5 of the 52 lines counter is cleared.
Is it true also for dma interrupts, whatever the ack method used (ei or dcsr+ei) ?
(winape clear the bit 5 of the R52 counter before executing the first opcode of the interrupt code)

No.  DMA doesn't affect R52 counter.

Bit 5 of R52 is cleared by PRI or CPC raster interrupts.

I need to check the exact operation for interrupt order and priority.

I did not check yet:
1. I disable interrupts
2. I trigger a DMA interrupt
3. I trigger a PRI interrupt
4. I enable interrupts

Which IM2 interrupt routine is called?

PRI has highest priority so I guess it is called, but it didn't happen first. So I will check to see if ASIC works on which came first or which is highest priority.

I also need to run my IM2 tests on a 464Plus and 6128Plus, all tests have been run on a GX4000 for the moment.

[Longshot]

No.  DMA doesn't affect R52 counter.

Not true on winape... 

1. IM1 mode
2. Vbl trigger a Dma-list and color yellow
3. Dma-list :
    * pause of 100 lines (from the vbl)
    * int + stop
4. Interrupt code test if interrupt is dma or not.
    not dma (normal cpc interrupt)  : interrupt ends (acq ei/ret)
    dma interrupt : color blue : interrupts ends (dcsr acq + ei (both mandatory))

When dma interrupt occurs, R52 is bigger than #20
In Winape, the bit 5 is cleared. So, R52=R52-#20, and so, the next int is delayed of #20 lines
So yellow swap with blue color each frame on winape

On a real amstrad plus, is the yellow color stable ?

[roudoudou]

On a real amstrad plus, is the yellow color stable ?

Stable with Arnold 

[PulkoMandy]

It's 2017 and people are still using WinAPE as a reference for Plus behavior? 

[Longshot]

It's 2017 and people are still speaking about emulator behavior (and about cpc)...
May be in order to improve them...a never ending story!
The question was:
"On a real amstrad plus, is the yellow color stable ?"

[dragon]

If nobody know the cause of one bug. Don't expect someone can program a emulator of the bug. Lol

[robcfg]

But, if the bug happens on the emulator, then it's easier to debug rather than looking at thousand on transistors on a picture...


Sent from my iPhone using Tapatalk

[arnoldemu]

It's 2017 and people are still speaking about emulator behavior (and about cpc)...
May be in order to improve them...a never ending story!
The question was:
"On a real amstrad plus, is the yellow color stable ?"

yes. Tested on my gx4000.

The colour transition yellow->blue is also stable with no movement.

[arnoldemu]

Do you confirm that the bug never occurs when the main code wait the interrupt with sequencies of tons of halt ?

I made a loop of 1000 HALT and the bug did not happen.

EDIT: I am confident it will not happen with these kinds of opcodes:
NOP, LD B,A, OR A, CP B etc

They are 1 byte long and do not read/write memory when they execute.

I will make a test with these instructions.

[arnoldemu]

But, if the bug happens on the emulator, then it's easier to debug rather than looking at thousand on transistors on a picture...


Sent from my iPhone using Tapatalk

@dragon is correct, the IM2 bug doesn't happen on any emulators. (I am updating arnold and I will document the bug on the wiki).

[dragon]

I made a loop of 1000 HALT and the bug did not happen.

EDIT: I am confident it will not happen with these kinds of opcodes:
NOP, LD B,A, OR A, CP B etc

They are 1 byte long and do not read/write memory when they execute.

I will make a test with these instructions.

Yeah, but the problem is bit instructions and cp instruction needs read from ram to compare it with the register, the diference is the z80 not stored new data in the registers, but i'cant view how that can affect the asic.

Also i know bit instruction recieves a diferent tratament that the rest, the z80 send it directly to the apu.I read about the internal structure and he es multiparallel. He can made a sum, where he acces the memory or read another opcode(have three internal bus for that).

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.

[Longshot]

It seems that the confusion is always between dma0 and pri.
So the problem is the bit 1 of the formed address (I, ivr, peripheral) which is cleared or not settled when pri occurs.
Maybe it depends of the duration of the instruction, when the interrupt needs to be serviced, and when instruction is not finished. 
All the opcode you have given take 4T states.

[dragon]

In  the page i put  tell bit 1(hl) uses 4+8 states. Four for the first pcode and seven for the second. Also the signal rd and rw is used in diferent istructions. Working and not.

[arnoldemu]

It seems that the confusion is always between dma0 and pri.
So the problem is the bit 1 of the formed address (I, ivr, peripheral) which is cleared or not settled when pri occurs.
Maybe it depends of the duration of the instruction, when the interrupt needs to be serviced, and when instruction is not finished. 
All the opcode you have given take 4T states.

dma0 is the lowest priority interrupt, so I think asic is confused about interrupt priority.

I tried with other opcodes including ld hl,nnnn (I repeated them).

I will make a test that triggers the interrupt at different points in an instruction.

[arnoldemu]

In  the page i put  tell bit 1(hl) uses 4+8 states. Four for the first pcode and seven for the second. Also the signal rd and rw is used in diferent istructions. Working and not.

you see the same with bit 1,a for example?

I will try this.