Amstrad Plus and IM2 bug

[arnoldemu]

Also, roud, what is your config for ram/rom tests?

[roudoudou]

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

[Longshot]

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)

[arnoldemu]

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.

[arnoldemu]

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)

[roudoudou]

ok, i clean a little my cartridge code to make many version at different adresses

[roudoudou]

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)

[Longshot]

So the bit 13 of the address trigger the bug! First condition found! 
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.

[arnoldemu]

awesome!

[roudoudou]

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)

[Longshot]

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...

[dragon]

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.

[arnoldemu]

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 I will modify your code that ran at &a000 to run at &0000 then I will find where in the opcode the bug happens.

[arnoldemu]

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?

[arnoldemu]

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.

[roudoudou]

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)

[dragon]

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.

[dragon]

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.

[Longshot]

Thank you roud...
OUCH! 
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.

[Ast]

Next step ?

[Longshot]

Next STEP : AST & KEVIN try the same program on their respective computer 
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

[roudoudou]

Next STEP : AST & KEVIN try the same program on their respective computer 
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

[Ast]

could you test it on real monitor ?
Something may be wrong !

[roudoudou]

could you test it on real monitor ?
Something may be wrong !

Like what?

[Ast]

Like what?

La pâte à tartiner ?