Amstrad Plus and IM2 bug

[arnoldemu]

Hi all,

We know the Plus has a bug with IM2 mode where the vector on the bus is not reliable.

I found something.

I made a test with raster interrupts ONLY. DMA was not active. I set IM2 mode. Set value with 6805.

If I use HALT to wait for the interrupt the correct vector is taken. (Raster is used).
If I don't use HALT (I use a loop: jp loop), then the wrong vector is taken (DMA 0 is used).

The bug is well known, but did anyone know about HALT or not being used to control the vector?

Testing done on my gx4000, c4cpc, but dipswitch set so that it boots direct into my cpr. Menu not used.

[arnoldemu]

This loop never allows raster int vector to be used:

Code Select Expand


loop:
rept 128
ld a,(bc)
endm
jp loop


This loop it triggers raster int vector most of the time:

Code Select Expand


loop:
rept 128
rlca
endm
jp loop


In my code

"loop" is always the same location.
jp "loop" is always the same. I picked 1 byte instructions for testing.

[andycadley]

Curious. I wonder if it has something to do with the value on the bus at the time the interrupt triggers?

[arnoldemu]

Curious. I wonder if it has something to do with the value on the bus at the time the interrupt triggers?

I think I have found a pattern:

If an instruction involves a cpu memory read or memory write, that causes the asic to use the dma vector instead of the raster interrupt vector.

ld a,(bc)

that has a memory read

or (hl)

that has a memory read

jp nnnn

that is 1 byte opcode read, 2 bytes memory read for the remaining parts of the opcode.

rlca is only an opcode read.

halt is only an opcode read.

I'll check writes just to be sure. it may just be memory reads...

[arnoldemu]

Yes, memory read and memory write. I don't know if it's the data yet, or just the act of doing that.

rept 64
ld (de),a
endm

rept 64
nop
endm

With this code above in a loop, it's switching between the dma 0 vector and the raster interrupt vector.

[arnoldemu]

Here is my test.

Make cpr, put into slot 1 of c4cpc. Set it to boot from slot 1 (no menu).
On my gx4000 I see:

On the left is the border, it flashes yellow and blue bars.
On the right is some graphics for the screen - it was there for testing but doesn't actually change the result.
Code uses im 2.

[andycadley]

Hmm, I assume this is only with the auto-clear function enabled? I seem to recall it was stable if you kept that switched off. It's been a while since I played around with it though. I'll have to dust off the plus and experiment a little.

[arnoldemu]

Would somebody else confirm that they see the same on their gx4000/plus?

Hmm, I assume this is only with the auto-clear function enabled? I seem to recall it was stable if you kept that switched off. It's been a while since I played around with it though. I'll have to dust off the plus and experiment a little.

I will check.

I think I tried with and without and there was no difference.
I think this problem happens without dma being active.

All of my tests were done on a gx4000, so it's possible a plus may be slightly different.

[arnoldemu]

There is more going on which I am still working out.

I have attached some new more simple tests that show the bug happening for me.
DMA is *not* enabled in these tests.

* It doesn't matter if PRI raster ints or normal raster ints are used
* Bug happens without DMA interrupts or DMA being active.
* It happens even when auto-clear is not active (it happens with "power-on-reset" values).
* Bug happens if DMA is active but doesn't cause any ints

Zip attached which shows this. See intbug1-4 and nointbug1-4.

When DMA causes an INT, then it seems to behave itself a bit. It may be possible to cause an int on all channels and make the bug go away

[Maniac]

There is more going on which I am still working out.

I have attached some new more simple tests that show the bug happening for me.
DMA is *not* enabled in these tests.

* It doesn't matter if PRI raster ints or normal raster ints are used
* Bug happens without DMA interrupts or DMA being active.
* It happens even when auto-clear is not active (it happens with "power-on-reset" values).
* Bug happens if DMA is active but doesn't cause any ints

Zip attached which shows this. See intbug1-4 and nointbug1-4.

When DMA causes an INT, then it seems to behave itself a bit. It may be possible to cause an int on all channels and make the bug go away

I've tried all of the cart images included in this zip file.


intbug1 shows a strobing yellow and blue screen
intbug2 shows a flashing yellow and blue screen slower than intbug1 with a clear split in the middle of the screen
intbug3 and 4 show same as intbug2 but maybe a bit faster flashing


nointbug1-3 (can't see 4 in the zip file) all show a static yellow screen with black border


I would run the other bits you uploaded earlier but I can't make the cart file I'm afraid.


The above was all run on a 6128 Plus using a C4CPC. Hope it helps.

[arnoldemu]

I've tried all of the cart images included in this zip file.

...

The above was all run on a 6128 Plus using a C4CPC. Hope it helps.

Thank you @Maniac. That is exactly what I am seeing.

In the tests I have added interrupt handlers. Each interrupt handler sets a different colour. The raster interrupt is yellow. DMA channel 2 is blue.

When the bug is happening the interrupt handler for raster interrupt and dma channel 2 is being triggered.

When the bug is *not* happening the screen remains yellow.

For those that are interested you can use winmerge to diff "intbug1.asm" against "nointbug1.asm" to see the difference.

I will be running more tests and adding them to the acid tests, because I need to find exactly what is happening when dma channels interrupt.

It doesn't seem to be possible to "clear the bug".. I tried.. but some sequences of dma interrupts and raster interrupts together may stop it showing up. I think the reason that dma channel 2 interrupt is chosen is that it's the lowest priority interrupt and somewhere the asic decides to use the vector for the lowest priority interrupt.

[andycadley]

Yup, confirm I can replicate them too. Have a few ideas for some tests I can try too, but probably won't be till later in the week. Reminds me I need to file the case on my C4CPC at some point too as getting the SD Card out is a massive PITA!

[arnoldemu]

Bug also happens with:

IN r,(C)
OUT (C),r

so it's not limited to memory read/write. it's any data on the bus.

Value on the bus doesn't seem to change the result.

[dragon]

Just a idiocy.


I never uses that, but if understand it. This mode is the z80 jumps to i+256+data in bus, and the problem is the data in bus is generated  bad by the asic, it jumps to another interruption code.


And this go bad when z80 put data on bus.


Well the idiocy i was thinking is, if anybody have try the bug with a true z80. A zilog z80 instead of st z80.


Its only a very very utra rare remote posibility that the asic was build around zilog specification. And the st have some obscure diference when put data/read in bus that can, affect the asic timming or so. Its very rare that random in the bug.Sometimes good and anothers not.

[CraigsBar]

Just a idiocy.


I never uses that, but if understand it. This mode is the z80 jumps to i+256+data in bus, and the problem is the data in bus is generated  bad by the asic, it jumps to another interruption code.


And this go bad when z80 put data on bus.


Well the idiocy i was thinking is, if anybody have try the bug with a true z80. A zilog z80 instead of st z80.


Its only a very very utra rare remote posibility that the asic was build around zilog specification. And the st have some obscure diference when put data/read in bus that can, affect the asic timming or so. Its very rare that random in the bug.Sometimes good and anothers not.

I have a zilog z80 and a plus here. If you produce a binary to test and display a result that I can run from my m4 (or a cpr or a dsk), then I can test it.

Sent from my ONEPLUS 3t using Tapatalk

[dragon]

You have it, the test arnoldemu have up in this thread.


Anyway, i dobut nobody have made the try.

[tjohnson]

I've been reading this with interest, however what is the bug?  can anyone explain in more layman's terms the bug and the impact of it. 

Sent from my E5823 using Tapatalk

[arnoldemu]

I've been reading this with interest, however what is the bug?  can anyone explain in more layman's terms the bug and the impact of it. 

Sent from my E5823 using Tapatalk

The impact is minimal. Amstrad knew of this bug.

The feature was first documented in revision 1.4 of the ASIC specification, but because they discovered there was a bug, they removed information in revision 1.5 of the specification. Both specifications have been published.

Pang uses interrupt mode 2 and it seems they either discovered it was broken or they knew and worked around it.

The feature is nice, if it worked, because it allows easier management of interrupts especially dma interrupts. It is much more useful for playing 3 channel sampled sound. The bug happens when using Z80 Mode 2 interrupts, and Z80 Mode 2 interrupts are more useful when running a game from cart.

There is no documentation to say how the bug is triggered exactly because it would be nice to work around it.
For emulators it is nice to know the conditions to make sure this is emulated.

Initially I thought it was related to the "auto-clear"/"auto-acknowledge" of interrupts but that is not true.

I don't think it's related to z80 either.

The ASIC generates interrupts for DMA channels 2,1,0 and Raster. These have a priority. Raster is highest, DMA 2, then DMA 1 and finally DMA 0. For each priority it gives a different number which is used with Z80 interrupt mode 2. It gets confused and gives out the wrong number under certain conditions.

The exact conditions is what I am working out.

BTW, I want to thank @dthrone because he had a reproducable crash which looked like it was caused by this bug, and if it wasn't for that I probably wouldn't have looked into it as much as I have.

[tjohnson]

I presume the bug was never fixed by Amstrad given that the plus model was relatively short lived?  Had it had a longer life they may have made an effort to fix it in later models.

The impact is minimal. Amstrad knew of this bug.

The feature was first documented in revision 1.4 of the ASIC specification, but because they discovered there was a bug, they removed information in revision 1.5 of the specification. Both specifications have been published.

Pang uses interrupt mode 2 and it seems they either discovered it was broken or they knew and worked around it.

The feature is nice, if it worked, because it allows easier management of interrupts especially dma interrupts. It is much more useful for playing 3 channel sampled sound. The bug happens when using Z80 Mode 2 interrupts, and Z80 Mode 2 interrupts are more useful when running a game from cart.

There is no documentation to say how the bug is triggered exactly because it would be nice to work around it.
For emulators it is nice to know the conditions to make sure this is emulated.

Initially I thought it was related to the "auto-clear"/"auto-acknowledge" of interrupts but that is not true.

I don't think it's related to z80 either.

The ASIC generates interrupts for DMA channels 2,1,0 and Raster. These have a priority. Raster is highest, DMA 2, then DMA 1 and finally DMA 0. For each priority it gives a different number which is used with Z80 interrupt mode 2. It gets confused and gives out the wrong number under certain conditions.

The exact conditions is what I am working out.

BTW, I want to thank @dthrone because he had a reproducable crash which looked like it was caused by this bug, and if it wasn't for that I probably wouldn't have looked into it as much as I have.

[dragon]

What is exatly the architecture  of the plus range?. Z80 is connected  to the asic right?(i looking schematics). And asic to ram, but z80 is connected apart to floppy directly.


So, as happend with no data in z80 bus the problem is what asic  recieved from the z80 bus.


Then the question is the bug is caused by the z80 adress lines or the data lines?.


As in instruction in only put data in adress line and recieve in data lines Probably was adress lines, so we have 16bit guilty candidate. That make sense because the asic map substitute cpc ram.


Now. What happend if we try all posible combination  in r,c to cover all diferent values in z80 adress bus?


What happend if we send 16 bit of zero? The bus valor is zero when there is no data to?.


And what happend if instead of read ram, we try read from rom or best another external device as x-ram?. im2 bug is reproduced?.


And why the guy that speak with steve gane not ask it about the bug wtf.

[arnoldemu]

What is exatly the architecture  of the plus range?. Z80 is connected  to the asic right?(i looking schematics). And asic to ram, but z80 is connected apart to floppy directly.
..

I am still testing.. I will tell more when I find it.

It seems to me the bug is on the asic and not the z80 and doesn't depend on the data on the z80 bus.
I made a test that writes different values into ram and there was no change in the result.

And why the guy that speak with steve gane not ask it about the bug wtf.

I talked to him, but there may be others that did too

From memory he didn't remember about the specifics of the asic because it was a long time ago.

[arnoldemu]

I presume the bug was never fixed by Amstrad given that the plus model was relatively short lived?  Had it had a longer life they may have made an effort to fix it in later models.

I guess not.

I keep searching to see if there is other revisions of the asic but so far testing hasn't shown this.

[dragon]

I guess not.

I keep searching to see if there is other revisions of the asic but so far testing hasn't shown this.

So thats history obout colour  border=version finally was urban legend.

I talked to him, but there may be others that did too rom memory he didn't remember about the specifics of the asic because it was a long time ago

Then only gerard can save us  with a microspy.


But i remember read here in the forum he tell he conserved the sun tapes of the design. I understand he not want publish it, but  we only need gerard look the design to document the bugs really

[arnoldemu]

More update (dma ints and raster ints together):


EDIT: Sorry tests were bugged, but auto-clear does something.

Working properly now, both are bugged.

[dragon]

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.