Jumpy mouse with Indivision ECS v3

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.

    Just got an Indivision ECS v3 and while the video output seems to work great, I'm having issues with the mouse jumping horizontally randomly. I've tested it on two Amiga 500, both with revision 5 PCB.


    One of them has a Vampire 500 V2+. On this one, the cursor jumps to the left randomly. It does not happen when using low res modes, or in high res mode with 2 colors, only in high res mode with 4 colors or more. With the original Denise chip I do not see this issue.


    The other one has a 68000 CPU and a home made RAM/IDE board, stacked under the CPU. I see a similar jumpiness on this one, but it jumps to the right. I have not tried yet without the RAM/IDE board.


    The only thing I see on the wiki that could be even vaguely related is this point in the changelog for the firmware: "Improve compatibility with certain Rev6 boards that showed 'jumpy mouse' behavior. One of the sample points for the mouse has been moved to improve stability." I'm open to taking some oscilloscope measurements if that could help. I assume there is no way of changing the timing of the sampling without making a new firmware.


    Any help or ideas appreciated!

    Indivision ECS V3 acutually changed the way that mouse data is sampled: It is not FPGA-timed any more, but it's CPLD-timed, only looking at the timing signals coming from the A500 board. No matter which FPGA core you will load, sampling the mouse signals will always happen on the same spot, and the FPGA can't do anything about this any more. The advantage I have taken is that the signals are sampled at a spot where other signals (which are multiplexed on the lines to the FPGA) also need to be looked at, so things are running concurrently, which they couldn't on the V2 design.


    The timing signal that Indivision ECS V3 is looking at is the 7MHz CPU clock. Both your setups are most likely loading this signal, slightly moving it, probably making it "later". If you're a DIY guy anyway, you might just try a 3k3 pull-up resistor on the 7MHz CPU clock to 5V and see if that fixes it. I have a hunch that both your CPU mods are not taking into account that the 7MHz CPU clock only has very small drive strength, and the rising edge is especially slow on an NMOS system - it can use a little support.

    Thank you for the reply!


    On the board I made, the 7MHz signal just passes straight through, basically just a tiny bit longer header. Can't imagine it adds more than a few picofarads of load; any CPU relocator would certainly add more. On the Vampire board, it seems to go into a buffer/level shifter (74LVCH162245), so that's the one I've tested the below on.


    When touching an about 15 cm long unconnected wire (acting like a capacitor, an antenna or both :) ) to the 7MHz pin on the Indivision, the problem gets much, much worse. The mouse essentially becomes unusable. I take this as confirmation of your theory!


    I tried adding 3.3k pull-up on the 7MHz signal both at the Vampire and directly on the Indivision, but no luck. I will try and borrow an oscilloscope from work sometime during the week, to get an idea of what's actually going on, how much the boards actually delay the signals, and such.

    It may also be a pull-down that's required. The 74LVCH162245 implements pull-up resistors, so yes, that may be a source of a problem. Kinda weird to use such unusual drivers when an LVC16245 would have done the job. They must have had their reasons...

    I've started taking some measurements, but I'm not sure how accurate they are since when I connect my probe (should be about 10 pF) the mouse stops working, so I'm not sure how the signal looks when the mouse does work.


    In any case. The below measurement is taken with 68000 CPU. Blue is 7MHz and yellow is pin 9 (M0H) on the Indivision.



    Timing wise this looks good to me, though the voltages are perhaps a bit low for some reason.


    Is the mouse sampled on the rising or falling edge of 7MHz?

    Is this a PAL or NTSC-clocked Amiga? I'm not asking for the screen mode, but the base clock of the chipset: PAL=28.37516MHz and NTSC=28.63636MHz.

    I haven't had time to test extensively, but I've found a few things:


    Recapped one of the boards. (Hadn't done this before because lazy.) After this the mouse works much better both with just 68000 and with the homemade board. Not perfect, but almost.


    Still having issues with the Vampire, still only in high resolution mode. Low res works fine. All of this makes me think there might be some sort of interference on bus or power lines, but I've yet to figure out where.


    Oh and also, when testing modes in the configuration tool, the mouse works perfectly fine in high res mode. Very strange.

    Ok, I solved it! Sort of. You can ignore the message above.


    Found a thread in the German part of the forum where the same problem was described, and while my German is not top notch (and Google Translate only helps so far), I saw the Agnus mentioned. And I thought, Agnus does stuff with the clock so why not.


    And as by chance, I bought an entire A500+ chipset for pretty cheap some time back. So I switched to the 8372A and poof, problem gone. Can even attach my oscilloscope without the mouse jumping around!


    There seems to be a bit of jitter on the 7MHz with the 8371, but not with the 8372A. I have no idea if that's the issue, though. Looks like there's a tiny bit less noise too. See attached pictures.



    7MHz line, measured on Indivision, with 8371:




    7MHz line, measured on Indivision, with 8372A:




    Saw you talked about power supplies too. This is with the Vampire and a non-recapped original power supply. Also works with an A-Power supply I usually use with my 1200. I think fixing power supplies will be my next project after this one.

    I have now repaired the second Rev.5 A500 so I have a machine that works with 8371 Agnus. Problem is: I cannot reproduce the problem! I suspect that it's an edge case with propagaion delays of the installed TTL chips. We all know that Commodore used whatever was available on the market, so variations are to be expected. The two Rev.5 A500s that I have use Ferranti and Signetics for U15. I know that Mitsubishi are especially slow in terms of propagation delay (around 40ns), and these caused problems before.


    Further, CCK clocks are inverted and delayed by U33, a 74F04 gate. One of my machines uses Motorola, the other uses Signetics.


    In order to make a machine that lets me reproduce the problem, I'd exchange these two chips for the exact same ones you have in yours.


    The good news is that Timm can reproduce the problem at his place, but the trouble is that it's his private machine, and he's more than 600km away. I can't ask him to un-screw the floppy drive just to see what vendor U15 is on his machine.

    Both my machines use the same chips, Texas SN74LS157N for U15, and a brand I don't recognize (Fairchild maybe? Picture attached) 74F04 for U33.


    For science, I can socket U33 on one of them and try out a few different chips, just to see if that's the culprit. Though I only have 2x 74LS04 (which should be slower) but I'll see what I can get my hands on.

    Using an LS type where Commodore has used F-types on each and every machine may give funny results. I'm not (yet) that desperate!


    I'm currently working with Timm to fix this. I found a possible glitch in the CPLD, but that didn't improve it for him, so "that's not it". Another possibility is that the sample-spot of mouse data between CPLD and FPGA crosses the sampling of the CPLD from the actual lines. So our next step is to move that a little and see if it improves things. That will also be easier for anyone with the same problem, as we can just roll out an update with a the next version of the config tool.

    What a nightmare! I've been working with Timm and Peter on this issue since last week. Timm had to be involved, because he had the only machine that could reproduce the fault. Peter had to be involved, because he knows all the details about the FPGA core.


    We thought that we have found "something" when checking all the timings and sent a core for testing to Timm on Monday evening. I was absolutely convinced that we've found it - an edge case of the communication between the CPLD and the FPGA. And then the sobering news from Timm yesterday morning: The new test-core didn't fix it. Turns out that 2.2ns slack time for inter-chip communication is still enough. Well, it's a good thing we checked it :-)


    So I continued repairing my stock of Rev.5 Amigas - the third one during this search. And FINALLY! Yesterday I got a machine to work that actually has the "jumpy mouse" effect. And it got more and more mysterious, because all timings had LOTS of slack, and everything should "just work". The information with the ECS Agnus is kind-of-misleading, as indeed an ECS Agnus solves it, but the root cause is a totally different one: An analogue edge case.


    I found it after hooking up the logic analyzer to the mouse multiplexer:

    What caught my eye was that the multiplexed output (the one that arrives at the Denise chip) was jumping all over the place when the threshold at the logic analyzer was set to 1.65V - the voltage that a 3.3V-part will use as a threshold, as it's "half IO supply voltage". So I connected an analogue probe to the horizontal signal and found that the "high" level of this signal is in the 1.7V area, with noise in the 100mV area, enough to cause almost random signal to be seen by the CPLD. The input hysteresis of the Xilinx CPLD will make it even worse, as once a "0" has been seen, the "keeper" circuit of the chip will add a weak pull-down resistor in order to simulate hysteresis. Switching this feature off is only possible chip-wide, so we'd lose it on the CCK signal, where it's absolutely needed.


    Long story short: A pull-up resistor will fix this problem. You may even make it out on the picture; it's a 1.2k wired resistor between pins 19 and 9 of the Denise pins. One side isn't even soldered, so I can add/remove the resistor and "switch" the jumpy behaviour on and off with it. Can't get any closer to "reproducable, proven".


    Vertical is also affected, but not as bad as the horizontal signal. While you're at it, you should add that pull-up resistor anyway.


    If you want to fix the root cause, forget about the pull-up resistors, and replace the multiplexer at U15 with something that has a bit more juice on it't outputs - maybe a HC or HCT type.


    I haven't made a decision if this finding should result in a change of the current Indivision ECS V3 stock.

    Interesting stuff. I ordered two Indi ECS V3s yesterday (not shipped yet). For me it's fine without this mod on my two units. I will use them on some A500 ++ replica boards I soldered. All the logic is socketed on them anyway.


    Edit: Speaking of the devil, got a mail that the units have been shipped right after I had made this post :)

    I'm in awe of both you dedication and your troubleshooting! I've never been good at the analog stuff.


    Unfortunately, I can not test the resistor fix as I seem to have killed my Indivision :( With it plugged in, when I turn the Amiga on the power LED does not come on, there is no floppy seek, and the display only shows garbled image (see attached picture). When I unplug it or use a Denise chip it seems to work just fine.


    Seems like my Vampire died too, so I probably did something very stupid. Worst thing is I don't know what.


    I won't even pretend like any sort of warranty should cover this, but if you want I can send it back for a post-mortem. I can't do anything with it in this state anyway.

    Hi,


    we can of course take a look at the unit. If it shows a picture on the VGA output, then the most expensive part (the FPGA) is most likely still alive, as otherwise, it would not generate any sync signals that the monitor would recognize as "picture". As you may know, I'm a big fan of "repair instead of replace", as that's following the sustainability idea: If a solution has the smaller environmental impact, we'll choose it.


    Please read this article for hints about how to send stuff back to iComp.


    In terms of "resistor fix", Peter and I have done some more literature-research by consulting old 74LS157 data sheets. All of them guarantee a minimum-high voltage of 2.3V or more, depending on the manufacturer. Most of them are at 2.4V, and the Motorola part in my half-failing A500 even guarantees 2.7V high-voltage. Motorola doesn't have any historic data sheets online, but the University of Kiel, Germany, has archived it. The DC characteristics table is on page 3 of the document.


    We therefore have to view this low voltage at the mouse-inputs of the Denise chip as a defect of the host computer. Specifically: A defect of the mouse data multiplexer chip. So I have to re-state the obvious: Please replace the 74LS157 chip at U15, ideally with a 74HC157 or 74HCT157. If you can't find any of these, you can safely use a 74HC257 or 74HCT257 in that place. The only difference between the two chip types is the 3-state function of the outputs, which is not used by the Amiga, so the logic function of the two types is equivalent if put into the place of U15 of your A500.

    Just curious if you've had time to check my board. I did not think of writing down the serial number, but I did include a note with problem description and my mail address, and I think I drew a question mark in blue felt tip pen on the label on the box.


    If not, no worries. I'm mostly patient :)

    Unit is here since January 22nd. Employees made a spontaneous "short day" today, so I can only read what's hand-written on the leaflet: Has been checked, confirmed your error description, but did not continue work as there were no clear instructions about what to do with it.


    You wrote that you've "probably done something stupid", but without additional info, we have no way of tracing an error. And without clear instructions for a paid repair, my employees have strict instructions not to spend too much time with such a unit.


    If you can say what happened (like "soldered to the wrong pin" or similar), we may be able to find&fix the fault quickly, without too much try&error. Parts are not as expensive as labour!