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.
This loop never allows raster int vector to be used:
loop:
rept 128
ld a,(bc)
endm
jp loop
This loop it triggers raster int vector most of the time:
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.
Curious. I wonder if it has something to do with the value on the bus at the time the interrupt triggers?
Quote from: andycadley on 19:58, 08 July 17
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...
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.
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.
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.
Would somebody else confirm that they see the same on their gx4000/plus?
Quote from: andycadley on 21:09, 08 July 17
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.
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 :)
Quote from: arnoldemu on 11:43, 09 July 17
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.
Quote from: Maniac on 21:21, 09 July 17
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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=930). 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.
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!
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.
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.
Quote from: dragon on 22:31, 14 July 17
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
You have it, the test arnoldemu have up in this thread.
Anyway, i dobut nobody have made the try.
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
Quote from: tjohnson on 07:47, 15 July 17
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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=350) 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.
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.
Quote from: arnoldemu on 08:09, 15 July 17
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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=350) 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.
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.
Quote from: dragon on 10:44, 15 July 17
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.
Quote from: dragon on 10:44, 15 July 17
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.
Quote from: tjohnson on 10:38, 15 July 17
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.
Quote from: arnoldemu on 11:03, 15 July 17
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.
QuoteI 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
More update (dma ints and raster ints together):
EDIT: Sorry tests were bugged, but auto-clear does something.
Working properly now, both are bugged.
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.
Quote from: dragon on 12:36, 15 July 17
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 (http://www.cpctech.org.uk/download/buildcpr.zip)
pasmo is here:
http://pasmo.speccy.org/ (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.
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
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
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.
@andycadley (http://www.cpcwiki.eu/forum/index.php?action=profile;u=327): 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?
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/
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.
Thanks @dragon (http://www.cpcwiki.eu/forum/index.php?action=profile;u=251) and @andycadley (http://www.cpcwiki.eu/forum/index.php?action=profile;u=327) 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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=251) - very useful to know the exact operation of the instructions.
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.
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)
Quote from: Longshot on 21:13, 17 July 17
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.
Quote from: Longshot on 21:13, 17 July 17
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. :)
Quote from: Longshot on 21:13, 17 July 17
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.
QuoteNo. DMA doesn't affect R52 counter.
Not true on winape... ;D
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 ?
Quote from: Longshot on 23:30, 17 July 17
On a real amstrad plus, is the yellow color stable ?
Stable with Arnold ;D
It's 2017 and people are still using WinAPE as a reference for Plus behavior? :o
It's 2017 and people are still speaking about emulator behavior (and about cpc)... :o
May be in order to improve them...a never ending story!
The question was:
"On a real amstrad plus, is the yellow color stable ?"
If nobody know the cause of one bug. Don't expect someone can program a emulator of the bug. Lol
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
Quote from: Longshot on 18:05, 18 July 17
It's 2017 and people are still speaking about emulator behavior (and about cpc)... :o
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.
Quote from: Longshot on 21:13, 17 July 17
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.
Quote from: robcfg on 19:38, 18 July 17
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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=251) is correct, the IM2 bug doesn't happen on any emulators. (I am updating arnold and I will document the bug on the wiki).
Quote from: arnoldemu on 19:46, 18 July 17
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.
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.
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.
Quote from: Longshot on 00:15, 19 July 17
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. :)
Quote from: dragon on 05:34, 19 July 17
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. :)
Quote from: dragon on 23:43, 18 July 17
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.
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 :laugh: :picard2: :picard:
Opps. Thank macleod_ideafix for the info.
???
I am sure I did tests where I copied it to ram.
Ahh, then perfect i no have try all. :laugh: i was think all was fromcartridge.
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. ;)
Thank you I will test it on Sunday.
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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=128): I tried your test but it always displayed yellow. I'm not sure I set it up correctly. I will try it again.
Quote from: arnoldemu on 18:11, 19 July 17
???
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.
The adventure goes on & takes place here (http://amstradplus.forumforever.com/t321-Amstrad-Plus-et-Acquittements-Interruptions.htm) !
You could find the result of many and many possibilities.
French only, but who cares ?
Quote from: Ast on 19:18, 23 July 17
The adventure goes on & takes place here (http://amstradplus.forumforever.com/t321-Amstrad-Plus-et-Acquittements-Interruptions.htm) !
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.
Quote from: dragon on 23:27, 23 July 17
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)
Quote from: roudoudou on 07:43, 24 July 17
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.
QuoteThe 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 ?
Quote from: Longshot on 23:09, 24 July 17
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.
Quote from: Longshot on 23:09, 24 July 17
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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=128), 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.
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
Hi!
I've had a chat with @Habi (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1314) about this, and this is what we've found:
QuoteIt'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)".
QuoteThere 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.
QuoteAlso 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!
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?
Quote from: dragon on 12:53, 25 July 17
Something is hidden in the asic?. Something feature not finished?.
There is a legend about floppy DMA premises
Quote@Longshot (http://www.cpcwiki.eu/forum/profile/?u=128), 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.
I asked Roudoudou to do the same on his hardware.
So, wait for the result now!
Quote from: Longshot on 18:46, 25 July 17
The DF00 port seems to be a good idea.
Will do some test with or without (youuuuuuuuuuuuuuu) this feature activated
Quote from: Longshot on 18:46, 25 July 17
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. :)
i found something :D
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
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
Quote from: roudoudou on 21:15, 25 July 17
BUT if i select an upper ROM to execute the code in #C000 the bug is here :picard:
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 :)
Also, roud, what is your config for ram/rom tests?
shit, i made a wrong edit so i will try to sum up :)
longshot code (or yours but longshot code disable all ROM before running)
when runing in #0000 -> bug
when runing in #A000 -> no bug
when runing in #C000 -> bug
i have some new ideas for tests :)
Roud, don't forget that Kevin runs the test in RAM (not in ROM)
So the next step is to test the kevin code in A000.
And test the code in 4000 (the test do not need to connect asic page)
Quote from: Longshot on 21:30, 25 July 17
Roud, don't forget that Kevin runs the test in RAM (not in ROM)
So the next step is to test the kevin code in A000.
And test the code in 4000 (the test do not need to connect asic page)
Roud, also try running it from rom, but changing location of lower rom using RMR2 etc.
Also, try a different upper rom, choose both "logical" and "physical" page (e.g. df00 and df80).
I tried "I" at many different addresses and saw the same result, so it must be location of opcodes that is important.
Roud, please also try &2000,&6000,&e000.
&a000 has A13=1. I think I tried &8000 and still saw the bug.
This smells like that IC logic near the cpu to me ;)
Maybe the bug doesn't happen if the code (or perhaps just the interrupt routine has address where A13=1)
ok, i clean a little my cartridge code to make many version at different adresses
I did not test all the range but enough in my opinion ;)
#5000 bug
#6000 no bug
#7000 no bug
#8000 bug
#9000 bug
#A000 no bug
#B000 no bug
#C000 bug
#D000 bug
#E000 no bug
#F000 no bug
source in attachment (for Rasm only)
So the bit 13 of the address trigger the bug! First condition found! ;D
It will be interesting to see if the address of the interrupt code is important or not.
And try to see, when bit 13 of the address is 0, what is the second condition!
May be another bit of the address of the code interrupted.
awesome!
i moved vector table in #3000 instead of #4000, no change
i moved interrupt code #2000 above code interrupted, no change (code in #A000, interrupt code in #C000, no bug)
So if the bit 13=0 is one condition, there is another condition because all the interruption are not failing
The asm attached locate one instruction at a specific address for each interruption
(the previous test is much more anarchic for the low bits of the address)
So if others bits are implied you should have only blue or only yellow on the screen...
Quote from: arnoldemu on 21:43, 25 July 17
This smells like that IC logic near the cpu to me ;)
That ic change from diferent board revisions, diferent brands, diferent technology ls,hc sometimes diferent number but equivalent look the pictures in wiki in 464+ 6128+ and gx4000. They change it many times.
Anyway, the best is put lk106 and try the result. The are more signals apart from bit 13 involved.
Quote from: Longshot on 22:03, 25 July 17
And try to see, when bit 13 of the address is 0, what is the second condition!
I thought I found one of these conditions?
when bit 13 of the address is 0, bug will happen if memory read/write instruction is executed at the time the interrupt is acknowledged.
@Longshot (http://www.cpcwiki.eu/forum/index.php?action=profile;u=128) I will modify your code that ran at &a000 to run at &0000 then I will find where in the opcode the bug happens.
:)
Quote from: dragon on 23:46, 25 July 17
That ic change from diferent board revisions, diferent brands, diferent technology ls,hc sometimes diferent number but equivalent look the pictures in wiki in 464+ 6128+ and gx4000. They change it many times.
Anyway, the best is put lk106 and try the result. The are more signals apart from bit 13 involved.
Yes I was thinking to do this on my 464Plus. Do I need to remove the ics or can I connect the link?
Quote from: roudoudou on 22:36, 25 July 17
i moved vector table in #3000 instead of #4000, no change
i moved interrupt code #2000 above code interrupted, no change (code in #A000, interrupt code in #C000, no bug)
Nice.
Did you put code in &8000 and interrupt table in &a000? I guess that the location of the opcode at the time the interrupt is acknowledge is probably the key thing here.
Quote from: Longshot on 22:42, 25 July 17
So if the bit 13=0 is one condition, there is another condition because all the interruption are not failing
The asm attached locate one instruction at a specific address for each interruption
(the previous test is much more anarchic for the low bits of the address)
So if others bits are implied you should have only blue or only yellow on the screen...
here is what i see (stable image)
Quote from: arnoldemu on 06:49, 26 July 17
Yes I was thinking to do this on my 464Plus. Do I need to remove the ics or can I connect the link?
Yo need remove it, if not the asic recieved two signals at same time. The best is put a socket, then you can easily revert the changes. Or try another variations for example cut the a13 leg only and try. Or connect a13 continusly in 1 or 0 using vcc,ground etc etc...
These circuit appear retroalimentated. Apart of a13, it depend from signals generated by the asic itself.
Its how the problem is the Niorq is activaded(=0). Or not activated (=1)when it should be. And that cheat the asic, that is not ready internally to respond o.k.
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.
Thank you roud...
OUCH! :o
If the asm source is assembled at #9000 :
* EACH R52 interrupt occurs when PC=#90E3 (on the stack)
* OPCODE in #90E2 is LD B,A for each interrupt
* LD B,A is 1 usec
The code between two interrupts is always the same.
But the behaviour (dma/pri) is different only for the second interrupt (bug).
I do not see any difference between 2 interrupts.
I'd tested this under Winape, but maybe the interrupt occurs 1 us closer or later on the second interrupt on a real amstrad ?
Need to track the PC for a frame in extra-ram to confirm.
Next step ? (http://amstradplus.forumforever.com/t321-Amstrad-Plus-et-Acquittements-Interruptions.htm?start=45#p4247)
Next STEP : AST & KEVIN try the same program on their respective computer ;D
Just to see if the blue is always on the second interrupt for everyone.
Other STEP if it's true : I've to modify the program in order to verify if interrupts comes closer or later in that case
Quote from: Longshot on 14:18, 26 July 17
Next STEP : AST & KEVIN try the same program on their respective computer ;D
Just to see if the blue is always on the second interrupt for everyone.
Other STEP if it's true : I've to modify the program in order to verify if interrupts comes closer or later in that case
I have 3 others CPC+, may i try?
EDIT: same things with all my CPC+ / cartridge in attachment
could you test it on real monitor ?
Something may be wrong !
Quote from: Ast on 16:55, 26 July 17
could you test it on real monitor ?
Something may be wrong !
Like what?
Roud : just try to change the org &9000 to org &9001, just to see if colours swap
Ast : Goinffre!
Border is yellow too !
QuoteBorder 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)
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.
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.
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.
¿?.
QuoteSeems 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. ;D
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.
Quote from: Longshot on 19:06, 26 July 17
Yes, because the bug do not happen anymore. Need to confirm on more amstrad. ;D
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.
Quote from: dragon on 19:01, 26 July 17
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.
Quote from: Longshot on 19:06, 26 July 17
Yes, because the bug do not happen anymore. Need to confirm on more amstrad. ;D
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.
Quote from: dragon on 13:25, 26 July 17
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.
I was told that the diodes were used in a configuration that works like an And gate.
Sent from my iPhone using Tapatalk
QuoteIt 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).
@gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250): Nice summary (in your original post) :)
Quote from: gerald on 19:36, 26 July 17
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??
Quote from: robcfg on 19:40, 26 July 17
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.
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.
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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) whoa great explanation.
Quote from: arnoldemu on 19:47, 26 July 17
@gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250): 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 ... :D
Quote from: Longshot on 19:45, 26 July 17
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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=128): I did it for you. :)
a mix of always blue, yellow and blue "loading" and fixed yellow/blue.
Quoteif anyone wants i try a code in another cpc put it here, i have try the last put and is yelow
Attached two sources... ;D
Blue or Yellow ?
Quote from: Longshot on 20:16, 26 July 17
Attached two sources... ;D
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.
Quote from: Longshot on 20:16, 26 July 17
Attached two sources... ;D
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.
Quoteit 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)
M4 is this, becase you send me the source i try execute it here.
http://www.cpcwiki.eu/index.php/M4_Board (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.
Thanks for the test.
Quotea2 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)
Quote from: Longshot on 23:23, 26 July 17
Thanks for the test.
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)
I get black border, then blue.
Quote from: Duke on 23:44, 26 July 17
I get black border, then blue.
Yeah true, i have made a mistach with blue, because cpc starts with border in blue XD. I have expanded the 4:3.
test3=test2.
But i have made now interesting experiment.
With the cpc running the test. If i select directorys in m4 web interface, the border in cpc flickering to yelow when i select one directory.
Quote from: dragon on 00:03, 27 July 17
But i have made now interesting experiment.
With the cpc running the test. If i select directorys in m4 web interface, the border in cpc flickering to yelow when i select one directory.
That would send a BUSRQ and probably skew the test.
In the schematics gx4000 is connected little diferent that the plus, they swap one logic gate in the ic, and it changue the 5v source.To signal controls. But probably is because board layout.
QuoteWith the cpc running the test. If i select directorys in m4 web interface, the border in cpc flickering to yelow when i select one directory.
In the A2 test, if interrupt is delayed of 1 usec, it's not a "add a,(ix+1)" (==> blue) which is interrupted, but a "nop" (==> yellow)
[ but maybe it's another event on the bus ]
In the general case, in A2 test, the interrupt is not delayed with add a,(ix+1) because the int request occurs exactly on the same usec than "ld b,a"
The bug seems not to be triggered with the interrupt delay, but with the instruction itself (arnoldemu first suggestion) when bit A13 of the instruction is 0.
It seems difficult to avoid a bug triggered by the instruction and to create a code where interrupt occurs only on some specific instruction.
The best way to avoid the bug is to locate code in 8 areas of &1000 bytes (50% of ram).
If A13 is confirmed on all amstrad plus, needs now to know if it's the same for rom, extra-ram, and block 3 mapped in 4000 (C3 mode)
I think I need to balance the number of nops?
4 before, 0 after
3 before, 1 after
then I will get either blue or yellow I think.
Do I need to set nbnop to 4 for add a,(ix+1)??
Quote from: Duke on 00:12, 27 July 17
That would send a BUSRQ and probably skew the test.
interesting. M4 uses BUSRQ and holds CPU like Z80-DMA would?
Quote from: arnoldemu on 09:04, 27 July 17
did you see my results from your test with add a,(ix+0)?
with 0 nops, blue
with 1 nop, blue and yellow flashing like a K7 loader
with 2 nop, blue and yellow alternate but fixed.
with 3 nop, blue and yellow alternate but fixed
The test synchronize the interrupt for an exact micro-second in the code. Flashing is not expected.
Full blue or full yellow.
Have you modified nbnopinst ? (best name would be "nop number before the interrupt with the 4 nop before" ;D )
instruction ==> add a,(ix+1)
With 0 nop (from "ouf"), nbnopinst=1
With 1 nop (from "ouf"), nbnopinst=2
With 2 nop (from "ouf"), nbnopinst=3
With 3 nop (from "ouf"), nbnopinst=4
With 4 nop (from "ouf"), nbnopinst=5
If not, the interrupt doesn't trigger exactly at the same point between 2 interrupt
Quote from: Longshot on 08:58, 27 July 17
If A13 is confirmed on all amstrad plus, needs now to know if it's the same for rom, extra-ram, and block 3 mapped in 4000 (C3 mode)
I confirm it's the same for lower ROM execution, but i did not test extra-ram in C2, Cx mode or ROM above #4000
Quote from: Longshot on 09:16, 27 July 17
The test synchronize the interrupt for an exact micro-second in the code. Flashing is not expected.
Full blue or full yellow.
Have you modified nbnopinst ? (best name would be "nop number before the interrupt with the 4 nop before" ;D )
instruction ==> add a,(ix+1)
With 0 nop (from "ouf"), nbnopinst=1
With 1 nop (from "ouf"), nbnopinst=2
With 2 nop (from "ouf"), nbnopinst=3
With 3 nop (from "ouf"), nbnopinst=4
With 4 nop (from "ouf"), nbnopinst=5
If not, the interrupt doesn't trigger exactly at the same point between 2 interrupt
No I didn't. I will do that.
Quote from: arnoldemu on 09:06, 27 July 17
interesting. M4 uses BUSRQ and holds CPU like Z80-DMA would?
Really it also affect the c4cpc to when you are in cpr loader menu. In the same way as running test.
But, the only signals involved are a13,wait,iorq,reset as input, and nrioq as output.
The connection to the other controls signals is only to take +5v to make the and with the diode.
https://electronics.stackexchange.com/questions/131860/diode-logic-gates (https://electronics.stackexchange.com/questions/131860/diode-logic-gates)
Nice link! 8)
Quotebut i did not test extra-ram in C2, Cx mod
Attached a new version (T1/T2 for C1 mode and T3/T4 for C3 mode)
See source for 4 tests
;
; TEST T1 (code in bank 7 mapped in &C000, code in &C000 bit A13=0)
; runc equ &c000
; ramselect equ &c1
; Expected --> FULL BLUE BORDER (dma bug)
;
; TEST T2 (code in bank 7 mapped in &c000, code in &E000 bit A13=1)
; runc equ &e000
; ramselect equ &c1
; Expected --> FULL YELLOW BORDER (no dma bug)
;
; TEST T3 (code in bank 7 mapped in &4000, code in &4000 bit A13=0)
; runc equ &4000
; ramselect equ &c3
; Expected --> FULL BLUE BORDER (dma bug)
;
; TEST T4 (code in bank 7 mapped in &4000, code in &6000 bit A13=1)
; runc equ &6000
; ramselect equ &c3
; Expected --> FULL YELLOW BORDER (no dma bug)
;
Quote from: gerald on 19:36, 26 July 17
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.
I view it with a,new true table.
Basically. Niorq should be 0 in four cases.
All combination of a13,wait + iorq=0 and reset=1. But the circuit cut the 0,0 case and put 1 instead 0
Quote from: arnoldemu on 19:20, 26 July 17
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).
Probably not quite relevant to the discussion per se, but could be helpful:
Both the prefix and the opcode are M1 cycles (instruction- or opcode-fetch).
It is easy to test because the R-register increases after each M1 cycle, and the prefix instructions cause the R-register to increase by two; by one for the prefix-byte and again by one for the opcode-byte.
So this gives us:
ADD A, (IX+1)
DD, 86, 01 = M1, M1, Read, ...
There's however a strange situation when there are two prefix-bytes involved. The offset-byte directly follows the two prefix-bytes and the opcode-byte is last:
RLC (IX + 1)
DD, CB, 01, 06 = M1, M1, Read, Read(faux M1), Read, Write
The R-register is increased by two only, which means that the actual opcode-byte (the fourth and last) must be considered a read cycle.
So, the Z80 seems to consider every following byte after the second prefix a Read or Write once it stops fetching M1's because of the offset-byte, and it doesn't revert back to fetching M1's but Read bytes, even if it is an instruction b-te.
(There's the possibility, of course, that the instruction byte is also an M1-cycle but the R-register is not increased for whatever reason.)
Quote from: Longshot on 10:27, 27 July 17
Attached a new version (T1/T2 for C1 mode and T3/T4 for C3 mode)
For me all 4 tests are as expected:
T1 Blue
T2 Yellow
T3 Blue
T4 Yellow
@arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122)
Yes, M4 uses BUSRQ, when kicking the command that was out'ed. Then the M4 copies responses into the mapped M4 rom (which is really ram) and releases BUSRQ so the z80 can read it.
I didn't change the 4 nops.
nbnopinst = 1, yellow at top, then blue, then yellow. no movement. (change at every 52 lines)
nbnopinst = 2, blue at top, then yellow then blue. no movement. (change at every 52 lines)
nbnopinst = 3, blue, yellow, blue x 104 lines, yellow 52 lines, blue (maybe 104 lines.. split by upper and lower border), no movement.
nbnopinst = 4, blue/yellow k7 loading moving
nbnopinst = 5, blue.
I set nbnopinst to 4. I then put some nops before, some nops after.
1 before, 3 after = yellow
2 before, 2 after = yellow
3 before, 1 after = yellow
I set nbnopinst to 1. I then put some nops before, some after.
1 nop before, 3 after = k7 loading
2 nop before, 2 after = blue ~104 lines, yellow 52, blue ~104 lines. blue starts. no movement.
3 nop before, 1 after = blue, yellow, blue yellow, 52 lines each. no movement.
One of these combinations must be right ???
I tried RMR2 moving ROM to &8000. Same as RAM.
Execute from &8000-&9fff from ROM, bug.
Execute from &a000-&bfff from ROM, no bug.
Quote from: arnoldemu on 19:43, 27 July 17
I tried RMR2 moving ROM to &8000. Same as RAM.
Execute from &8000-&9fff from ROM, bug.
Execute from &a000-&bfff from ROM, no bug.
WTF :o :'( :'( :'( :laugh:
QuoteOne of these combinations must be right
:o
You need some explanations ;)
In this configuration (with 4 nop), you must set "nbnopinst" to number nop of instruction (add a,(ix+1)==>5) nbnopinst=5:ouf
nop ; 1 -- 33
nop ; 1 -- 34
nop ; 1 -- 35
nop ; 1 -- 36
instruction add a,(ix+1) ; instruction to test
Instruction takes 5 usec (us1, us2, us3, us4, us5)
In this config, interrupt triggers at us2, but is delayed after us5
-------------------------------------------
BUT, if you need to see what happens when interrupt trigger at us3, you need to set
nbnopinst=4 and
delete 1 nopouf
nop ; 1 -- 33
nop ; 1 -- 34
nop ; 1 -- 35
instruction add a,(ix+1) ; instruction to test
-------------------------------------------
if you need to see what happens when interrupt trigger at us4, you need to set
nbnopinst=3 and
delete 2 nopouf
nop ; 1 -- 33
nop ; 1 -- 34
instruction add a,(ix+1) ; instruction to test
-------------------------------------------
if you need to see what happens when interrupt trigger at us5, you need to set
nbnopinst=2 and
delete 3 nopouf
nop ; 1 -- 33
instruction add a,(ix+1) ; instruction to test
-------------------------------------------
if you need to see what happens when interrupt trigger juste after the instruction (at us6), you need to set
nbnopinst=1 and delete 4 nopouf
instruction add a,(ix+1) ; instruction to test
-------------------------------------------
Enregistrer
Quote from: roudoudou on 19:55, 27 July 17
WTF :o :'( :'( :'( :laugh:
LOL.
My code booted the cart at 0000. It then copied a small function to 4000 which set RMR2 to move page 0 of cart to &8000. Then I called the code here.
First test it called to &8200 (&200 in page 0).
Then it called &a200 (&2200 in page 0).
Same result as we see for code in RAM at this location.
Quote from: Longshot on 19:57, 27 July 17
:o
You need some explanations ;)
This is for me -> :picard: :picard2:
QuoteThis is for me
In every cases, the result must be stable, because each interrupt occurs on the same instruction, whatever the usec lost in the previous interrupt
The adjustment with "nop" & "nbnopinst" give the ability to trigger the interrupt at different "time" of the instruction.
At that point, A13 is confirmed in Extra Ram (bank 7 in block 3), C3 (bank 3 in block 1), ROM, RAM.
No Amstrad Plus found where the bug occurs with A13=1
=====================================================
With this configuration, the expected result is YELLOW
ouf
instruction add a,(ix+1) ; instruction to test
=====================================================
With this configuration, the result is BLUE
ouf
nop ; 1 -- 33
nop ; 1 -- 34
nop ; 1 -- 35
nop ; 1 -- 36
instruction add a,(ix+1) ; instruction to test
=====================================================
With other configurations, it can show when the bug occurs
Clear, because 13=1 make the niorq work as normal.
This is my truth table scanned.
No laughter, I know the lyrics are bad, it's for me: D
The second line a13=0 wait=0 is the line the cirtuit change should be 0 and is 1 in z80 nomal cycle.
So the most interesting next step was the gerald tells, a logic analizer and a lk6 test.
And another thing is we no know the changes to the circuit between board versions. So i think with software test can be good know what revision is the plus or the gx4000.
We can have made the test in the same revision.
@Longshot (http://www.cpcwiki.eu/forum/index.php?action=profile;u=128): all blue.
I tried with incbc.
all yellow.
Quote from: arnoldemu on 19:12, 28 July 17
@Longshot (http://www.cpcwiki.eu/forum/index.php?action=profile;u=128): all blue.
So each usec of the instruction is concerned.
About "inc bc", the settings are wrong in incbc1.cpr and incbc2.cpr.
---------------------------------------------------------
For the first one :
nop
nop
nop
nop
inc bc
with nbnopinst=2 (for inc bc delay)
---------------------------------------------------------
for the 2nd
nop
nop
nop
inc bc
with nbnopinst=1
---------------------------------------------------------
the nop are dummies nop to fix instruction before the interrupt
[attachimg=1]
(X) NOP is the instruction before the interrupt. the address is on the stack.
When you delete a nop (from the 4), you need to decrease nbnopinst of 1
Hey gerald, you know if the circuit is the same in rev c,d,e with the 74ls127?
They don't have try fix it using m1 right?. I can't folow the tracks.
I am excited to see the results from @gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) and his logic analyzer :)
Quote from: arnoldemu on 11:12, 29 July 17
I am excited to see the results from @gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) and his logic analyzer :)
Here you are :
[attachimg=1]
Red marker is at start of IRQ ack which is immediately seen by the ASIC (INTn goes up) : vector is 0x06
Purple marker is at the effective cycle where the Z80 sample the vector, and where the ASIC sees a second acknowledge. Vector is now 0x04.
Quote from: gerald on 13:34, 29 July 17
Red marker is at start of IRQ ack which is immediately seen by the ASIC (INTn goes up) : vector is 0x06
Purple marker is at the effective cycle where the Z80 sample the vector, and where the ASIC sees a second acknowledge. Vector is now 0x04.
awesome. :)
I guess the second time, the ASIC has already detected the raster int and set bit 7 in DCSR, perhaps also auto-clearing it. Then because the int is still held, it looks at the DMA bits, determines that none are set and defaults to lowest priority DMA.
What happens when A13=1?
Maybe can be fixed gerald?. With minimum invasion from the cpc. For example make new combinational circuit atached into the z80 you are designing, and desactivated the ic116.
PD arnoldemu at finish you go to try the lk106?.
Quote from: arnoldemu on 14:06, 29 July 17
I guess the second time, the ASIC has already detected the raster int and set bit 7 in DCSR, perhaps also auto-clearing it. Then because the int is still held, it looks at the DMA bits, determines that none are set and defaults to lowest priority DMA.
I think the DMA2 vector is selected just as default one like it happen in most priority encoder.
Quote from: arnoldemu on 14:06, 29 July 17
What happens when A13=1?
DId not capture it for the obvious reasons. The ASIC nIORQ will be identical to the Z80 IORQn.
Quote from: dragon on 14:34, 29 July 17
Maybe can be fixed gerald?. With minimum invasion from the cpc. For example make new combinational circuit atached into the z80 you are designing, and desactivated the ic116.
Ideally replacing IC116 with a fixed circuit would be possible. Delaying the IORQ from the Z80 by one clock cycle may fix it. However, I just discovered that the version of the GX4000 (MC0123C) I used for the test use a 74LS27 (3 x 3 input NOR) instead of the 74LS02 (4 x 2 input NOR). So it needs already 2 version.
Also, fixing it is nice, but you split the plus user in two : with and without IM2 fix.
QuoteAlso, fixing it is nice, but you split the plus user in two : with and without IM2 fix.
I do not understand much in the discussions on electronics... ???
However, indeed, I am not certain whether it is a good thing "to modify" cpc to correct this bug, because that won't serve any purpose except to make programs that would only work on the modified cpc. Conversely, a program using the bug will not work anymore on a modified cpc. :o
Quote from: Longshot on 15:13, 29 July 17
I do not understand much in the discussions on electronics... ???
However, indeed, I am not certain whether it is a good thing "to modify" cpc to correct this bug, because that won't serve any purpose except to make programs that would only work on the modified cpc. Conversely, a program using the bug will not work anymore on a modified cpc. :o
Yep, as we know how to avoid the bug, just do it right with the CPC+
As far as i know, there is still no software using IM2 full features so...
...i will prefer softwares ;D
Quote from: dragon on 14:34, 29 July 17
Maybe can be fixed gerald?. With minimum invasion from the cpc. For example make new combinational circuit atached into the z80 you are designing, and desactivated the ic116.
PD arnoldemu at finish you go to try the lk106?.
not yet. If I must remove ics, then it is best I do it on a spare plus or gx4000 because I am sure I will break something :(
If I could do it cutting tracks and joining with wires then yeah I might be able to do that.
Quote from: Longshot on 15:13, 29 July 17
I do not understand much in the discussions on electronics... ???
However, indeed, I am not certain whether it is a good thing "to modify" cpc to correct this bug, because that won't serve any purpose except to make programs that would only work on the modified cpc. Conversely, a program using the bug will not work anymore on a modified cpc. :o
Thats not same as, i release a 128k game and all 64k users are out.?
Is not the same as, i released a avanced new cpc board with new features and these new software not work in old hardware?.
So we cancell 128k games, we cancell new toto motherboard, and some
new modifciation or expansion that made new software incompatible with cpc base?This happend until 1984. Its simply one modification more accesible in the list.
And if he can be done only using the socketet z80
Delaying one cycle without touching the motherboard is perfect.
People modify the cpc case with a dremel, wire the motherboard with wires to make 4mb expansion that have 0 utility and is a crime fix a bug?
:-\
QuoteThats not same as, i release a 128k game and all 64k users are out.?
Amstrad 6128 comes natively with 128k and ram expansion are standard for Amstrad 464/664
Ram expansion do not modify the cpc behaviour.
Modifying the mainboard is not easy for most people (and you lost the guarantee ;D )
Of course, it's not a crime to fix an hardware bug if it's your pleasure.
You can add 10 gb of ram and 4000 hardware sprites in your cpc, but it's no more a standard cpc.
And so, very few people could admire your augmented cpc...
Of course i know that, thats because i say if can be fixed using z80 sockekt. You don,'t modify the motherboard, put a expansion internally thats all. Gerald is making a bluethoot connection that works in same manner.
I don't like modify cpc to :) (because probably i kill it lol)'
Gx4000 don't have expansion port anyway
I think amstrad today building was an hotel,maybe sending the warranty, gif you two spare nights :) .
Quote from: arnoldemu on 15:51, 29 July 17
not yet. If I must remove ics, then it is best I do it on a spare plus or gx4000 because I am sure I will break something :(
If I could do it cutting tracks and joining with wires then yeah I might be able to do that.
I generally not cut traks, but i kill one time a acid cause of heat i supose. Best use a bomb unsolder.
I take a look here, if i can found a cheap gx4000 yelow cheap.
@gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) the rare was the 74ls02, in the pictures of wiki a,b use the 74hct02 or the 74ls27n the rest.
Quote from: Longshot on 16:36, 29 July 17
Amstrad 6128 comes natively with 128k and ram expansion are standard for Amstrad 464/664
Ram expansion do not modify the cpc behaviour.
Modifying the mainboard is not easy for most people (and you lost the guarantee ;D )
Of course, it's not a crime to fix an hardware bug if it's your pleasure.
You can add 10 gb of ram and 4000 hardware sprites in your cpc, but it's no more a standard cpc.
And so, very few people could admire your augmented cpc...
I would advise you to not look at the thread about the msx graphics card on the cpc. :P
@gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) : Please can I put the picture from your logic analyzer on the wiki please?
I want to update the wiki.
Quote from: arnoldemu on 09:31, 30 July 17
@gerald (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) : Please can I put the picture from your logic analyzer on the wiki please?
I want to update the wiki.
Done : http://www.cpcwiki.eu/index.php/File:IM2_Plus_Ack_Bug.png
I would suggest to have a separate page if possible. The IM2 bug seems to be a side effect of a fix for an other bug :D
Quote from: gerald on 09:57, 30 July 17
Done : http://www.cpcwiki.eu/index.php/File:IM2_Plus_Ack_Bug.png (http://www.cpcwiki.eu/index.php/File:IM2_Plus_Ack_Bug.png)
I would suggest to have a separate page if possible. The IM2 bug seems to be a side effect of a fix for an other bug :D
Done.
I hope I explained it well enough for both technical and non technical to understand.
http://www.cpcwiki.eu/index.php/Plus_Vectored_Interrupt_Bug
Quote from: arnoldemu on 11:18, 30 July 17
Done.
I hope I explained it well enough for both technical and non technical to understand.
http://www.cpcwiki.eu/index.php/Plus_Vectored_Interrupt_Bug (http://www.cpcwiki.eu/index.php/Plus_Vectored_Interrupt_Bug)
Little mistakes :
Missing "occurs" :
"The bug also doesn't xxxx with opcodes that don't use memory read/write..."
Have you tried with the inc bc at the right place ?
The last test with incbc was wrong because int trigger in "nop" and not in "inc bc".
"Bits 3..1 are generated by the ASIC based on the interrupt source (one of the DMA channels or raster interrupt). Bits 7..4 are defined "
You mean "Bits 2..1" and "Bit 3..7" :D
Quote from: Longshot on 12:41, 30 July 17
Little mistakes :
Missing "occurs" :
"The bug also doesn't xxxx with opcodes that don't use memory read/write..."
Have you tried with the inc bc at the right place ?
The last test with incbc was wrong because int trigger in "nop" and not in "inc bc".
"Bits 3..1 are generated by the ASIC based on the interrupt source (one of the DMA channels or raster interrupt). Bits 7..4 are defined "
You mean "Bits 2..1" and "Bit 3..7" :D
thankyou. I have updated it.
yellow for inc bc. I hope I got it right.
Quote from: arnoldemu on 11:18, 30 July 17
Done.
I hope I explained it well enough for both technical and non technical to understand.
http://www.cpcwiki.eu/index.php/Plus_Vectored_Interrupt_Bug (http://www.cpcwiki.eu/index.php/Plus_Vectored_Interrupt_Bug)
In fact the bug can happen for any of the vectored IRQ and not only the raster one.
Quote from: gerald on 14:42, 30 July 17
In fact the bug can happen for any of the vectored IRQ and not only the raster one.
I guess the auto-clear (IVR bit 0=0) must be used on the DMA channels to see this?
It needs another test I think to see it happening :)
Quote from: arnoldemu on 11:18, 30 July 17
Done.
I hope I explained it well enough for both technical and non technical to understand.
http://www.cpcwiki.eu/index.php/Plus_Vectored_Interrupt_Bug (http://www.cpcwiki.eu/index.php/Plus_Vectored_Interrupt_Bug)
Seems reasonably clear, nice to see we have got to the bottom of this (although it's curious what the purpose of the added circuitry was), I have to admit to getting lost once logic analysers got involved! I'll have to have a play and make sure I'm clear what the implications are. Am I right in thinking it means that it matters where the interrupted code is, but not the data that it is accessing? That would certainly seem to make avoiding it feasible in some circumstances (presumably not using auto-clear and manually checking on a DMA0 interrupt that it isn't really meant to be a raster interrupt would also work?)
Nobody have the rev a board of the plus.?
Appears amstrad not respect the service manual.
The 464+ b ic116 is diffetent connection that service manual.
Andycalley read choronograme is easy.
The are two states 0 and 1 0 is low so is with the line down.
1 is up so the line is up. The vertical lines is the time is switching between 0 and 1( that in the circuit is change 0v to 5 increasing decreasing voltage.
You view the lines of the ic and z80. So yo are reading what happend in all pins. At same time in diferent moments.
Then you only need know, if the pin is activated in low(0) or high(1)
For example Iorq is active low, reset low, and a13 is low. 0 0 0 so the line is down at same time and niorq is up, because the ic 116 changue it from 0 to 1. As is active low, asic thing is not activated how a light with a switch.
I mean more easy, imagine the asic is a light and the ic 116 is a switch.
Normally if the switch was the z80 it turn the light on to interrupt you, when it ends it turn off the light.
If the switch is the ic 116 it works in same manner. Except if you are not alone. Then it turn out the light, interrupt you, switch off the light. And few moments later switch on the light. Then interrupt you two times. And bug happend two interuptions two responses, first good, two bad.
I expect made a good explanation ;)
Quote from: andycadley on 14:59, 30 July 17
...Am I right in thinking it means that it matters where the interrupted code is, but not the data that it is accessing? That would certainly seem to make avoiding it feasible in some circumstances (presumably not using auto-clear and manually checking on a DMA0 interrupt that it isn't really meant to be a raster interrupt would also work?)
yes to both.
Im stunding my gx4000 revc
With the 74ls27
First nor:
Pin 9+10+11=8
Pin 9,10 wait
Pin 11 a13
Output to pin 8-> pin 5
Second nor
Pin 3+4+5=6
Pin 3 iorq/clk6
Pin 4 unkown, the polimeter not show me continuity between z80 reset pin 26 and pin 4 i can't folow it disapear under the labels of board.
Third nor:
1+2+13=12
1,2,13=pin 6
Output clk6 niorq pobably.
None
About the possibilities to "fix" the hardware:
The problem is different to 128K support. Fixing this would change the interrupt timing, which means existing software (both written for CPC and Plus) which relies on precise timings would stop working correctly. This makes the fix more annoying than the bug.
Also, the bug is well known and has several software work-arounds (not using IM2, putting the code only where A13=1, etc). So fixing it makes writing code for the Plus a little less annoying, but does not suddenly open many new possibilities (it's not like we can suddenly have twice as more DMA channels or something).
The compromise seems not worth it.
Nonetheless, now I'm curious what the original bug which led to LK106 was?
All that was done by amstrad. Even the amstrad fix change, between board revisions.
Looking track with pictures in web appears pin4 in 464+ is connected to the reset of the fdd (asic pin 52).
That in theory is not connected in the console.
Edit: appears,They have made a little change between revision b and the other.
In the original fix(hc chip)they take nreset from z80 line.
In the 74ls27n they use reset in oposite way. So they take the other reset line of the asic in the computers(used by the fdd ic).. As the gx4000 don't have these pin enabled they remade the tracks to take it from asic pin 52 fdc but for the inside part. So at normal look it appears not connected, but is connected to pin 4 ic 116 internally.
I don,t think amstrad have timmings in mind when made the fix, i bet was made by sone chinese guy in orion factory when they view something they not like in the first computer out of factory chain.
Anyway as i say fix it or not is only a option. Don't like, not fix it, like, fix it thats all. In the same manner, the sprectrum guys chosse fix the sound bug in +3 or not.
If amstrad continue selling the plus more son or later they have fix it in new motherboard revision, as he do in spectrum. Thats the true.
Probably was simply as add m1 to the ecuation. When m1 is low if a13 is low wait is low iorq is low and reset was high niorq=0
When m1 is high if a13=0 wait=0 iorq=0 and reset=1 niorq=1
I found a very fun thing about the fix.
Remember the review of gx4000 in 1990 lets take a look! Rewind!
One of the first gx4000 sending for the press to review number "14".
(http://www.nostalgianerd.com/wp-content/uploads/2015/10/amstradgx4000internals.jpg)
Take a look at ic 116. Reset signal is taked from the reset singnal of the ay sound chip. But the most extrange thing was they have connected pin2 of the ic 116 to the ay bc2 port!
bc2 on the ay is wired to 5v.
I remember reading that issue of aa. I read it over and over a few times :)
Is the ASIC the same version everyone else has? It looks like it is.
So, I wonder what is behind the claims that earlier ASICs are a little bit different? One day we'll find out :)
I was also thinking - on broken Pluses, what if IC16 is the one that breaks and the ASIC is fine? It would be interesting to know.
Kevin, will Arnold mimic the bug? ;D
Quote from: arnoldemu on 09:17, 01 August 17
bc2 on the ay is wired to 5v.
I remember reading that issue of aa. I read it over and over a few times :)
Is the ASIC the same version everyone else has? It looks like it is.
So, I wonder what is behind the claims that earlier ASICs are a little bit different? One day we'll find out :)
I was also thinking - on broken Pluses, what if IC16 is the one that breaks and the ASIC is fine? It would be interesting to know.
Who said the asic was little diferent?
Is dificult to tell the gx4000 rev a motherboard in cpcwiki have number 4, the aa motherboard have number 3 and are little diferent, So probably somewhere is 1 and 2 early boards.
Another strange issue is the rev a of the computer not exist in the wiki. ¿Anyone have view it outside the service manual?.There is a posibility that are broken and amstrad retire it from sell.Also there is a posibility, that the cpc works nomal with lk6, And the fix is only to maintaining compatibiliy with early boards that maybe don't have lk6.
The ic is a normal ls chip, he can die of course cost less <1e Maybe bryce can have someone broken.
edit:
This ***In theory*** should fix the bug with systems using 74ls27n, i know nobody want it, but its funny do it. :D
The principle is easy, original amstrad circuit have a13,wait,iorq,reset,This is the same except they add m1 to the equation. So if cycle m1 is on(low), Iorq is not changed with a13=0 wait=0, until m1 finished,The rest works as amstrad original circuit. reset is active high(pin 52 asic) with 74ls27n in boards. (is active low in hc chip)