TC64 won't boot with Amiga mouse plugged in

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.
  • What are the potential solutions to this? This is unacceptable because the docking station connector is a very tight fit for my Amiga mouse, and plugging and unplugging it puts undue wear on the connectors. The mouse is a 30+ year old piece of hardware with aging plastics. Is it possible to just disable the mouse port for the TC64 menu or something similar?

  • It sounds like Alastair Robinson is willing to add a feature to the Minimig core that will allow the Amiga mouse to be plugged into controller port #3. This would be a good solution, because then the Amiga mouse can probably just be left plugged in even when actively using C64 mode.

  • I am not sure i understand the problem here.....


    First of all, please understand that the TC64 starts as a C64. In a C64, the joystick port lines and the keyboard matrix are connected in parallel to the same I/O ports - so there is no way for one not influencing the other. There is also no way to disable the joystick ports in the menu - because the menu is designed to work without keyboard (and thus joystick). Even if we could do it, anything connected to the joystick ports is still interfering with the keyboard input, as said.


    Now, what exactly is the problem? Where exactly does the boot process hang? If it does, does moving the mouse or pressing buttons make it continue?


    Using port 3 for mouse in the amiga core seems to be a smart workaround to me - it would certainly work better than any other solution i could think of in the menu system.

  • The problem is that the TC64 goes into what I presume is a debugging screen if the joystick in port 1 is held left or down at powerup. There's a pretty good chance that a randomly parked mouse will be pulling down on one of those two lines.


    (A bit of experimentation suggests that pressing the leftmost button on the Chameleon will exit the debug screen - the mouse will then interfere with the menus of course, so as you say, using port 3 for the mouse is a smart workaround, and with some auto-switch logic also means you can play two-player joystick games without having to unplug the mouse.)

  • How would the auto-switch logic know when not to do automatic switching? Most hardware-based auto switchers use the fire button as their switch signal. This would work nicely if you're just swapping ports 1 and 3. However, if you're playing a 4-player game, this automatic switching should be disabled, as you'd swap around players all the time. Might be a nice extra difficulty playing Dynablaster, but probably annoying in the long run :-)

  • How would the auto-switch logic know when not to do automatic switching? Most hardware-based auto switchers use the fire button as their switch signal. This would work nicely if you're just swapping ports 1 and 3. However, if you're playing a 4-player game, this automatic switching should be disabled, as you'd swap around players all the time. Might be a nice extra difficulty playing Dynablaster, but probably annoying in the long run :-)

    The logic I'm using at the moment is to look for "impossible" joystick readings - left and right simultaneously or up and down simultaneously, and to mark port 3 as containing a mouse when such a combination is detected. I clear that flag any time the fire button in port 1 is pressed.

    Then the core switches to port 1 any time port 1's fire button is pressed, and only switches to port 3 when port 3's fire button is pressed while the port_3_mouse flag is set.

    That way it should avoid phantom swapping during 4-player games.

  • I clear that flag any time the fire button in port 1 is pressed.

    It seems like ideally it should also deactivate the flag based on port 1 joystick movement, because when switching to the joystick for a game, in some cases pressing the button may not be the first action you want to take.

  • I believe it's already a good solution as laid out by Alastair. If you start adding complexity, it only grows, but won't improve the solution. Think about it: If you really play a game with four joysticks, the joystick in port 3 will never produce mouse-like events such as "pressing up and down at the same time", as it's physically impossible. I don't see a way of this false-triggering. Since there is no physical parallel port on the Chameleon, I'd even go as far as removing the Port3-mouse flag, because the only way that this could false-trigger would be connecting a parallel port device (printer, sampler, Parnet cable) to a physical port, which isn't there.


    Also, I believe it's not many people using this feature. Most will connect a PS2 mouse and enjoy the precision of an optical pick-up. My guess is that it's going to be very rare to use an Amiga (Tank?) mouse on the Chameleon. Still, it's nice that it's possible, and it's very considerate to minimize wear and tear on the decades-old connector.

  • I think you might be misreading my comment? What I was suggesting isn't about false positives, and it doesn't add significant complexity. I was just suggesting that the circuit check all 5 lines of the port 1 joystick instead of only the fire button for the purpose of deactivating the special mouse flag. It just fixes a minor UX issue. Otherwise you'll sometimes have a situation where you have to start and then abort and restart a game to re-activate the port 1 joystick after using the mouse on port 3. It's not that big of a deal, but I was thinking it should be easy to check the other 4 joystick lines too.


    The ideal operation for me would be: (1) If you move the mouse plugged into port 3 and it detects "impossible" values, then it start using the mouse on port 3 as if it were port 1. (2) If you move or press fire on the joystick in port 1, then it switches back to using the joystick on port 1 as normal. (3) If you move the mouse again and it detects "impossible" values on port 3 again, then it switches back to using the mouse on port 3.


    This seems ideal because then you can effortlessly switch between the port 3 mouse and port 1 joystick without having to change any settings.

  • What you're describing appears to be what Alastair is about to implement. Or I might be mis-reading even more :-)

    More or less - the scheme I described involved clicking the mouse button or pressing the joystick fire button to make the actual switch happen, and Paul has pointed out that you might want to move the joystick before pressing the fire button if the first time you touch it is when a game's menu screen appears. Therefore it would be good if direction events could also trigger the switch to the joystick port.

    (3) If you move the mouse again and it detects "impossible" values on port 3 again, then it switches back to using the mouse on port 3.

    There will need to be a mouse click to switch back to the mouse on port 3, because a parked mouse can emit any combination of direction signals, and can also jitter - so there'd be a danger of it constantly switching back to mouse while you're trying to use the joystick. (I might have considered implementing some complex filtering to avoid this problem, just as a finesse point - but the FPGA is full to bursting, so I have to keep it simple!)

  • can emit any combination of direction signals, and can also jitter

    Good point. It might be nice to ignore that first mouse click if possible, or use the right button to avoid accidentally clicking on something when activating the mouse.


    But I haven't noticed my Amiga mouse jittering at all, and I think you could probably assume that if the mouse is jittering, then it's jittering between two values and not all four possible mouse sensor values. So you could probably filter out jitter by creating a counter for each of the four possible mouse sensor values (00, 01, 10, 11) that keeps track of how many times you've seen each particular state, and then you don't activate the mouse until all four counters reach a certain value. But I'm not an FPGA programmer, so I don't know quite how difficult that is to do, and just clicking the mouse to activate isn't a bad solution anyway.

  • Guys - you're doing something that is known to lead to the wrong path: You're optimizing something without even knowing if it needs optimization. Simplicity is king (not just on a hardware level, but in engineering in general), so I suggest to see if the Port 1/3 mouse swapping feature even needs optimization.

  • So you could probably filter out jitter by creating a counter for each of the four possible mouse sensor values (00, 01, 10, 11) that keeps track of how many times you've seen each particular state, and then you don't activate the mouse until all four counters reach a certain value. But I'm not an FPGA programmer, so I don't know quite how difficult that is to do, and just clicking the mouse to activate isn't a bad solution anyway.

    It'd certainly be possible to set up some kind of elaborate filtering for the mouse (and if I were going to do such a thing I'd probably move the switch into the heart of Minimig itself instead of the board-specific outer layers since Denise already has counters derived from the quadrature signal.) But like I said, the FPGA's full to bursting, so every logic element counts.


    (With FPGA's its not as simple as "fits" / "doesn't fit" - the more spare space there is the easier a time the toolchain has in placing and routing the logic and achieving the necessary timing. The Minimig core has always been squirrelly timing-wise, and the FPGA being 99% full is *really* not helping. I've just done a build on V2 which uses 24,261 logic elements out of an available 24,624, and it fails timing by a mere 83ps on just one path - that's the kind of result that screams "Don't touch a thing!")

    Guys - you're doing something that is known to lead to the wrong path: You're optimizing something without even knowing if it needs optimization. Simplicity is king (not just on a hardware level, but in engineering in general), so I suggest to see if the Port 1/3 mouse swapping feature even needs optimization.

    Indeed - there's always a balance to be struck between finesse and simplicity, so for now I'll go with "any direction or fire button switches to joystick", and "either left or right mouse button switches to mouse."

  • Great, thanks for your work on this. And to be clear, I'd be happy with simply having a switch in the menu to turn on the mouse on port 3, so having any automatic switching at all is fantastic to me.