Interrupts/inttim/doubleXX: OCS / ECS difference
dirkwhoffmann opened this issue · comments
Just a suggestion, but it might be a good idea if the test case could be reduced as much as possible. E.g. copper blocks 1 and 2 look like they're not needed (but it's hard to see). Some simple "bisection" method of removing code/parts of copperlist could be useful.
Also your current "syncpu" method makes it quite hard to reason about exact cycle counts. Maybe we could devise a way to use "STOP" w/ VERTB interrupt to make it easier? (caveat: I saw Toni recently reworked STOP handling in WinUAE, but as long as it's predictable on real HW it shouldn't be an issue).
E.g. copper blocks 1 and 2 look like they're not needed
The main problem is that the phenomenon is hard to reproduce. Some specific CPU cycle has to interfere with something else to produce the difference. Whenever I tried to simplify one of my tests, the OCS / ECS went away.
The most simple test is still timcpu2. There is a difference in line 9 of the second block:
Luckily, the orange line indicates that the CPU is at the same position in the OCS and the ECS machine. Hence, the difference must be caused by something happening between the two marked locations. The best way to debug it further would be to record the scanline with a logic analyzer. Unfortunately, I don't have such a device.
This issue needs to be solved. Hence, I am thinking about buying this logic analyzer:
It has 32 channels and a voltage threshold ranging from -4V to 4V. As far as I can see, this should be fine for analysing the Amiga. Or am I missing something important here?
I don't know about the EE part, but isn't amiga logic still 5V TTL? (i.e. above the ~4V listed, absolutely not sure, so check). Here's an EAB thread where Toni posted what he got: https://eab.abime.net/showpost.php?p=1471191&postcount=27. Ignoring cost 32 channels seems like the minimum you'd want (bus+data though 8-9 is probably fine for RGA bus so you still have spares), and 2x would also be nice so you didn't have to move them from OCS to ECS machine...
Here's an EAB thread where Toni posted what he got
Thanks! That was very helpful. I did a quick comparison of the software of both devices. I would say that both aren't master pieces of good UX design, but the DSLogic software seems to be much better in terms of configurability (@tonioni's screenshot is quite impressive where custom registers are shown by names). Therefore, I've ordered the DSLogic. Let's see how long it takes to ship here. I had to order it from Amazon US because it's not directly available in Germany.
Are both bugs also happening when using 100% plain A500? (not even ACA500[plus] connected, cloaking mode does not count as disconnected)
Are both bugs also happening when using 100% plain A500?
Yes, both machines are plain A500s (the ACA500+ is connected to a third machine). What I didn't check is the memory configuration (alI I can say at the moment is that none of them has FastRam installed).
Just arrived... a Rev. 5 board (OCS) from eBay 😎.
Let's see if it matches what we see on the OCS Rev. 3 machine or what we see on the ECS machines and the A1000. Stay tuned...
Ready to go...
And the winner is (test timcpu2)...
The Rev. 5 OCS machine matches what we see on the ECS machines and the A1000.
Summary: All machines produce the same image except my (mysterious) Rev. 3 machine.
Another parcel has been delivered. My new super weapon is here 😎:
Sorry, wrong image. Here it is:
Just done a brief experiment to see if it works...
Red is the 7MHz clock, brown is the E-clock. Grey and orange are two of the three IPL pins.
Now, I need to get familiar with the software...
Here is my plan for tomorrow:
-
Patch test
cputim2by letting the Copper write intoNOOP($1FE) at the end of the suspicious scanline. Once this is done, I can use the write toNOOPas my trigger condition for the logic analyzer. -
Select some meaningful signals to record. My current setup looks as follows:
- This grabs
- CLK and the IPL pins from the CPU
- The RGA bus from Paula
Are there any other signals I should record?
As usual take it with a grain of salt (like my wrong reading of the spec for the alternative probe), but the more the better if you're going to compare with another board. Thinking something like CPU.{A1,[A2,]DTACK} might help with correlating instructions + AGNUS.DBR (for interaction).
Running test case cputim2 on my ECS A500 with an advanced logic analyser setup:
Interestingly, the image is different now 🙈:
So either a) I am doing something completely stupid or b) attaching the logic analyser alters the result. In the latter case, everything might be caused by some subtle race condition on some line. Of course, a) is always an option...
Update: I've removed the probes step by step.
- Removing probes from address and data bus: No effect
- Removing probes from DTACK, R/W etc.: No effect
- Removing probes from IPL pins: Image is back to normal
Remaining probes:
Hence, I think we're dealing with a race condition on the IPL lines here.
Someone that knows electronics made this comment on the above:
probe loading on the inputs will cause a edge rate difference and delay
its probably coming in a clock later
poor metastate implementation
I notied same, at least when aca500plus was also connected that IPL measurement affects IPL timing slightly. Paula probably is not strong enough to pull it down as quickly as without extra hardware.
Difference between models: probably 3 possible options: CPU was manufactured with different process (check Motorola identifier and manufacturer date on top of the CPU), Paula is different (unlikely) or rev3 has different IPL line pullup resistors. (or one of them have changed values).
CPU was manufactured with different process
I've replaced the CPU a couple of days ago which had no effect. I'll try to replace Paula, too. I've noticed that my Rev. 3 machine has a Paula chip manufactured by MOS whereas all other machines are equipped with one from CSG (which is the same company though).
Update: Replacing Paula had no effect. The discrepancy is likely caused by the Rev. 3 board.
Try measuring resistance between each IPL line and +5v. Perhaps one of pull up resistors have changed value or something.
btw, do you want my RGA bus register name decoder code? It is nothing special but writing one can be boring..
btw, do you want my RGA bus register name decoder code?
Based on your comments on EAB, I've already patched the parallel decoder in a similar way:
chipset.zip
However, I'm not sure if I did it the way it is supposed to be done (I never coded in Python before). Without knowing better, I added an array
regs = {
0x000: "BLTDDAT",
0x002: "DMACONR",
0x004: "VPOSR",
0x006: "VHPOSR",
0x008: "DSKDATR",
...
and replaced this line
self.putb([0, [self.fmt_item.format(self.saved_item)]])
by that:
self.putb([0, [self.regs.get(2*self.saved_item, "???")]])
Maybe your solution is more sophisticated. In that case I'd be happy to toss mine and replace it with yours.
Try measuring resistance between each IPL line and +5v.
This is what I've got by measuring between CPU pin 14 (Vcc) and CPU pin 25 (IPL0):
Same result for IPL1 and IPL2.
I've replaced the Rev. 3 board in my OCS test machine by the Rev. 5 board. I'm closing the issue for now because I think it's not worth to debug it further at the moment.