Not sure if it's a quirky setup issue or something, but when I switch from jack to HDMI for sound, the audio playback is god awful stuttering and slow. Is there a known fix? I have a feeling this was discussed somewhere before, but I can't find it.

This video shows the Amiga AGA chipset combining 3 full screen 8-bit layers (or playfields, if you prefer) using various 8-bit alpha values.

https://www.youtube.com/watch?v=8YBfCrU0aK0


LAYERS

Background:
 * PTDQ system
 * 320x200 dots
 * max 256 colors

Middleground:
 * PTDS system
 * 160x200 logical dots, 319x200 physical dots
 * max 16 non-transparent colors
 * each base color can have an arbitrary 8-bit alpha (actually used: 0 for complete transparency, 128 for dark colors, 255 for bright colors)
 * "native" chunky dots (i.e. each byte in the layer buffer corresponds to a dot)
 * triple buffer

Foreground:
 * PTDQ system
 * 320x200 dots
 * max 81 non-transparent colors
 * each base color can have an arbitrary 8-bit alpha (actually used: 0 for complete transparency, 192 for see-through graphics, 255 for solid graphics)


NOTES

* The color model is RGBW for all the layers, but each layer could use a color model of its own without making any difference performance-wise.
* If the middleground had used PTDQ, its size would have been 320x200 dots and its maximum number of non-transparent colors would have been 81. However, that would have required the PTDQ C2P conversion.
* If the middleground did not use 100% transparent dots, its maximum number of colors would have been 81.
* If the foreground did not use 100% transparent dots, its maximum number of colors would have been 256.
* The display size is actually 319x200 dots to hide the leftmost column of dots, as PTDS requires a 1-dot shift to the right for the even bitplanes.
* The ball is rendered by scaling and flipping in real time a 128x128 chunky bitmap.
* The ball is wiped by means of both CPU and Blitter. The logic that handles the geometry still needs to be refined in order to provide a massive speedup.
* For convenience, the video has been recorded with WinUAE.
* On a stock Amiga 1200, the demo runs at 50 fps except when the ball covers most of the screen (in that case, the frame rate drops proportionally to the size of the ball); the slowdowns will be greatly reduced once the wiping is optimized.
* On an accelerated Amiga, the demo runs at steady 50 fps.
* YouTube's encoding reduced the saturation of colors.


CREDITS

The graphics have been obtained by processing the following pictures:
 * boing ball: from OBLIGEMENT / http://obligement.free.fr/gfx4/boingball_enregistree_amigacorporation.png
 * Earth: from https://cronianverse.fandom.com/wiki/Earth
 * plate: from Freepik / https://www.freepik.com/premium-ai-image/steampunk-frame-brass-metal-plate-with-empty-sheet-design-white-background_277147660.htm
 * porthole: by winwood1, from Wallpapers.com / https://wallpapers.com/png/round-porthole-window-png-05042024-zmsra0nm6gp8hvuv.html

Q: How can I fix the issue with the stuck mouse buttons during boot-up?

The stuck mouse buttons are a valid clue and something solid to work with.  The report shows that both middle and both right mouse button inputs are active, which is definitely not normal.  The common factor is that these are all analogue to digital inputs on U3 (Paula).  Check the DC voltage on all of these lines to start with, U3 pins 32, 33, 35, 36.  They should normally be around 4 to 5V when in an idle state.  What you find will determine where to look next.

Q: Should I try another terminal, such as RealTerm, as PuTTY obviously isn't working right, or is something still wrong with my cable setup, even though that the loopback tests shows that TX and RX work? It obviously was working as I got to the main menu, so the connections on the DB9 F - DB25 F are right and the RS232-USB is fine.

The output you've copied above shows that the serial data and terminal is working, and the A500 is fundamentally alive.  I've no idea why PuTTY was working and now it isn't.  There is no hardware or software flow control with DiagROM, so configure the terminal to Flow Control = None.  Maybe something related to the USB serial port, I've seen instances where they randomly stop working, or they do something unexpected such as transmit data working but not receive data; then it starts working again when you disconnect/reconnect the USB cable.  I mainly use Term 4.8 on the Amiga, which works reliably.

Q: Maybe there is something wrong with Paula's busses after all?

It's not completely broken because you're getting valid serial data out.  The UART (serial port communication) is a function of U3/Paula, so if the data or address bus had a problem there, the serial output will usually not work, or be corrupted.

You could sanity check that the data looks valid on each of the 16 data lines and 8 address lines at U3 if you wanted to, that's quick and easy to do with an oscilloscope.

You could always try exchanging U3 with a known good 8364.  It's the same part between A500, A1000, A2000, A3000.

Would anyone happen to know the part number for T121 in an NTSC 110v 1084D monitor? In the PAL 220v it is listed as a "SMPS, TSW4210".

Thats very interesting, as Switch mode PSU's were very expensive back then, however that SMPS means Switch Mode Power Supply (meaning it can be plugged into either 110v and 240v).
Problem is, there are 4 different variants of that monitor. What back ports does it have.

Thank you for checking. I can't remember my original account name. I remember I didn't follow the steps to keep it through the transition to the newly hosted Amiga.org site.

If it's a hassle no problem. Thanks anyway. 

It would have been preserved, so your account issues whould have been before change of server.