Almost got it, but now a sticky mouse on A500?

hoptoit

New member
Joined
Oct 2, 2010
Posts
25
Country
USA
Region
Portland Oregon
Anybody having some input on this would be greatly appreciated. I've nearly completed updating and restoring our A500 to full operation. I did a Chip RAM upgrade by adding x4 DIP sockets and chips, modified JP2 and JP7A, replaced the floppy drive.

But I'm noticing an occasional glitch with the mouse sometimes. Every so often it will hang in place on the screen when I'm trying to move the cursor, usually when moving down or to the right. It seems to be momentary, then corrects itself. But it is very noticeable playing Marble Madness, as the marble goes off in the wrong direction suddenly.

I tested the phenomenon happening on both ports, and with 2 different mice - one optical and one ball driven. It's hard to tell if this is occurring with the joystick very much.

Capacitors wearing out? Did the memory modification interfere with something? I ran a few memtests and the new memory showed no errors. This isn't the worst, but any ideas?
 

skippy

New member
Joined
Jun 3, 2008
Posts
106
Country
BRISTOL, UK
Region
Avon
Was this an issue before you modded the motherboard?

If you've ruled out the mouse itself and possible port fault you'll need to determine if it's isolated to Marble Madness or a global issue, so try Workbench too.

The mouse coordinates are controlled by the Custom Registers, in particular JOYDAT0. Registers are normally controlled by the DMAc but in this case the Processor is used so perhaps check around JP2 where you soldered and also around the DATA PATHS of JP7 near GARY.


Check/Reseat CPU and CIA-A chip.

Failing that try tracing and testing the resistors/caps from CN1 (port #1)

Paul.
 

rkauer

Amiga fanboy
Joined
Dec 17, 2007
Posts
10,337
Country
Brazil
Region
São Leopoldo, RS
Mouse movement is controlled by Denise. So first port of call is replacing it for a counterpart from another machine to test it again.
 

skippy

New member
Joined
Jun 3, 2008
Posts
106
Country
BRISTOL, UK
Region
Avon
Aye rkauer, (y)


Well pointed out, common misconception of Denise is that it is solely a graphics related chip.

However, Denise (M0H, M1H, M0V, M1V) also receives the coord inputs from U15, although it doesn't technically "control" them.

I'm thinking too much along the programming lines.

Interesting Fact:

Only 4 pins were available on Denise so Commodore devised a synchonised switching technque between the 2 ports (8 lines) using it's clock and dividing into 2 internal registers. - Clever stuff.
 

hoptoit

New member
Joined
Oct 2, 2010
Posts
25
Country
USA
Region
Portland Oregon
Mouse movement is controlled by Denise. So first port of call is replacing it for a counterpart from another machine to test it again.

I don't have another Denise around, but I pulled/reseated Denise and CPU with no change. Here's what I got from over at amiga.org :

Next logical step is to replace EMI400 and EMI401, but I'm pretty sure the problem is U15 (74LS157)

A few people are aiming me at U15, and it costs next to nothing so I will give it a try. I forgot to reseat/swap the CIA's also.
 

PymerOne

Noob pur sang
AmiBayer
Joined
Jul 16, 2010
Posts
515
Country
Netherlands, Europe
Region
NoordHolland, Far side of civilisation's border.
Dear HopToIt,

You have the chips thing down in no time, if the problem is there you find&cure it no doubt about that.
also, a you mentioned, check you caps ;)
They are oldfashioned 2-legs-through-pinholes components, rather eazy to repace.
Also check all solderpatches around mouse/joy port carefully, it gets a lot of physical abuse when inserting connectors.

Grtz, PymerOne.
 

skippy

New member
Joined
Jun 3, 2008
Posts
106
Country
BRISTOL, UK
Region
Avon
You overlooked the question "Was this an issue before you modded the board?"

Which was why I pointed you back to JP2 and JP7a - JOY0DAT (p-Processor) and the I/O data paths near GARY. (Solder splash, trace cuts, Board markings, etc)


REF: Rev 5/6a M/b & schematics.

FROM: LEFT JOY CN1 PORT

E411, E412, E413, E414 (Pin 1-4 Vert/Hor Signals and Pin 7 [E401] 5v+)

FROM: Denise - U15

Pin 08 -> [E442] M1H
Pin 09 -> [E443] M0H
Pin 38 -> [E441] M0V
Pin 39 -> [E444] M1V

You mention it's a "momentary" glitch so I'd be more incline to believe it's a component issue as oppose to a chip.; IE: CAP.


Hope that helps.

Paul.

*Edit*
Try removing the mouse ball and running your finger back and forth over the individual rollers to see if you can isolate it to just the Vertical or Horizontal Coord, as a process of elimination.
 
Last edited:

skippy

New member
Joined
Jun 3, 2008
Posts
106
Country
BRISTOL, UK
Region
Avon
You also never clarified if this problem pertained to just Marble Madness or everything.


Here is a small 68000 mouse routine I coded back in the day. Might be worth running it through Genam. (had to .zip so upload accepted.)

(Or find a coords mouse app on Aminet to help before metering the motherboard and swapping things out.)

Run Monam Debugger and whilst moving your finger over the individual mouse rollers check to see if the corresponding X / Y values de/increment with some consistently and that the mouse SPRITE pointer follows in sync.

1. If you find the values are uniform but the mouse pointer is jumping/glitching/16*16 bar the length of the screen or in the wrong place then your fault comes back to the Custom Registers / Processor as I mentioned earlier.

(In other words, the correct values are being intrepreted but not correctly transcended to the Playfield area *see* the SPRITE data (p) [$120-$13e] and position/control registers (dp) [$140-$17e] )

2. If the X / Y coords are jumping and inconsistent then your fault rests between the mouse -> port - > denise stages.

Cheers,

Paul.
 

Attachments

  • mouse.zip
    2.6 KB · Views: 0

hoptoit

New member
Joined
Oct 2, 2010
Posts
25
Country
USA
Region
Portland Oregon
You overlooked the question "Was this an issue before you modded the board?"

Which was why I pointed you back to JP2 and JP7a - JOY0DAT (p-Processor) and the I/O data paths near GARY. (Solder splash, trace cuts, Board markings, etc)

It's true that I didn't have adequate opportunity to do much testing prior to chip RAM mod. So this will have to be a long process of backwards elimination.

Here are few pics of the jumper blocks that I added at JP2/JP7A. I used the fine edge of a Dremel tool to make some very clean trace cuts, a little heavy with solder to support the new pins, cleaned up with denatured alcohol at the end:

5185473278_1f88e02c0d.jpg

5185473282_a2e4c8da7d.jpg


JP7A looks suspiciously close together in this pic, but I inspected carefully to make sure that the two pins were not in any contact.

Try removing the mouse ball and running your finger back and forth over the individual rollers to see if you can isolate it to just the Vertical or Horizontal Coord, as a process of elimination.
Now that I think about it, the problem only seemed to arise when I was trying to move the mouse while holding down the left button, as in Marble Madness to move the marble faster. I will have to reconfirm whether the problem exists during regular mouse movement when the left button is not being pressed.
 

skippy

New member
Joined
Jun 3, 2008
Posts
106
Country
BRISTOL, UK
Region
Avon
When you've done some more testing share the results as this may also benefit others.

I would personally advise against drilling through the Amiga motherboard as it's multi-layered. (IE: Try tracing JP7a -> JP7b you'll notice it disappears into the board up by the CIA [A]. You'll notice the same if you meter the control signals from the JOY0DAT port to Denise.)

I forgot to mention that $140-$13e is (p) Angus and $140-$17e (dp) is Agnus and Denise.

Paul.

*Edit*
Run a Mem too on those new modules you added. (MBR Test-2 is a nice app is use.)
 
Last edited:

skippy

New member
Joined
Jun 3, 2008
Posts
106
Country
BRISTOL, UK
Region
Avon
You need to rule out that computer game "Marble Madness" too in case the mouse coding is not very accurate.


The reason I stressed that earlier is because the way the Amiga interprets the optical mouse signals.

Remember:
E411, E412, E413, E414 (Pin 1-4 Vert/Hor Signals and Pin 7 [E401] 5v+)


NB: The Vertical Pulse/Quadranture and Horizontal Pulse/Quadranture phase relationship to the Overflow Counter.

Refer to JOYTEST $036.

In other words, if you look at my source code you'll see how the programming side breaks down the X / Y values (JOYDAT0 $00A = Bits 15-8 = Y0-7 Coord Y and Bits 7-0 = H0-7 Coord X) and then obviously because
the mouse optical counter creates 200 pulses per inch movement a count register must be used to read at intervals checking for overflows.

The point being, if this is NOT measured properly by the programmer during the vertical blank interrupt the mouse will jump.

In your case the DOWN-RIGHT *could* be a result of an overflow (NB:Counter Overflow) when comparing the value 127 between TWO successive vertical blank reads. IE: Two sporadic values.


If you later can't find any possible faults with your A500 motherboard you *might* need to go "deeper" with the metering and test the actual signals generated from mouse through the M/B. Referencing those four signals VP,VQ,HP,HQ pulses as these are the basis of your truth table which will then be translated to the X / Y coords.

This might require a modern Digital Sampling Oscilloscope for those shenanigans. :ninja:

Paul.

*Edit* If it's any consolation I tried that game and didn't experience any mouse issues.
 

Attachments

  • A500 002.jpg
    A500 002.jpg
    44.6 KB · Views: 1
Last edited:
Top Bottom