After several days of struggle and conversation with Madowax, I was able to get the Atmel ATtiny 4313's firmware flashed to version 1.1. A diary of notes follows.
I needed to reset the fuse bits because on my first attempt to update the firmware with my Wellon programmer, I did not set the config page correctly.
I followed the instructions for the simple AVR programmer using the parallel port. I used the software provided, FWT1201I3TH9DY2.rar. To simplify my life, I used Win9x so that the software has direct access to the hardware and I didn't need to use some I/O driver for NT-based operating systems. Unfortunately, was unable to get it working properly. Although the Hardware Check appears to check out OK, I received a verify error upon writing the firmware (Writing HEX, verify failed at Adr: 0001, File 0F, Read 02). Also, when I attempted use the serial programming interface (SPI) to read/write the fusebits, I would well it to write low fuse bits with command AC A0 -- FD, but it would return AC A0 A0 00. Also, If I used the SPI command to read the low fuse bits (80 00 -- --), it would return 00. I connected to the ATtiny while in the PS/2 adapter.
I tried this guy's AVR rescue, but it wasn't working properly. https://www.robotshop.com/community/forum/t/b … cue-shield/2898
I was, however, able to get this guy's AVR rescue working, https://mightyohm.com/blog/products/hv-rescue-shield-2-x/ . It seemed rather finiky though. Sometimes it would do a 1+ increment on the readback of the fuse bits set. It also didn't like you to write the bits more than once on a single power cycle of the Arduino. Note that I didn't use a 5V to 12V boost converter as shown in the schematic ( http://mightyohm.com/files/hvrescue21/HVRescu … 1_schematic.png ), nor did I have a MUN5311DW1T1G to use as the 12V switch, so I used a PNP, NPN, and four 10K resistors (which is what is inside the MUN chip). I also added 100 ohm resistors to the ATtiny's pins.
What finally worked?
1) Use the Wellon VP-390 to write the new firmware using settings such that all are Disabled except for CKSEL1, SPIEN, and SELFPRGEN. Note that I had the external 8 MHz crystal wired to the ATtiny4313 while it was inserted into the Wellon socket. I put the ATTiny back into the PS/2-to-serial adapter, but the DOS driver wouldn't find the mouse.
2) I put the ATtiny into the breadboard and used the AVR rescue technique with an Arduino EtherTen. I used Arduino IDE 0022 with the supplied code and the serial monitor in attempt to program just the fuse bits. Note that I has the 8 MHz crystal wired to the ATtiny with jumpers cables. For some reason, the USB cable must be attached to the Arduino before the 12V cable. I told the interactive mode of the software that I wanted to use for the low bit, high bit, and extended bit: 0xFD, 0xDF, and 0xFE respectively. After burning in the bits, the serial monitor reads back the programmed values of 0xFD, 0xDF, and 0xFF. To my surprised, it did not do the 1+ increment on the low or high bits, but on the extended bit. So what value is the Ebit really at - FE or FF? I'm not sure. If the read back is correct, then SELFPRGEN (SPM instruction) is disabled. Is this needed? I didn't want to mess around with more programming using the AVR rescue technique because I didn't want to bugger up what I had.
3) I put the ATtiny back into the PS/2-to-serial adapter and turned on my 486 with it connected. To my shock, the DOS mouse driver found the mouse! I had done this step 2 dozen times after trying to upgrade the firmware and it didn't find anything. So I ran the Test.exe program to test the mouse speed. It was horrible, in fact, far worse than the original firmware.
4) I ran the setup program provided by Matze79, that is, ps2maset.exe. I ran it with this flag; ps2maset.exe /p:1 /b:19200 /m:0. I tried to reboot and load my usual Logitech driver, and it wouldn't find the mouse. I guess this is because the Logitech driver is set up for 1200 baud? So I then ran the Matze-supplied DOS driver for CuteMouse 2.1. This driver worked and the mouse response time was instantaneous. But this is just at low DOS resolutions. The real trick is for 1280x1024 in Windows.
5) For Windows 3.11, I installed the Matze-supplied Microsoft Intellipoint mouse drivers. The drivers work and I did not notice any lag or delayed tracking was previously noticed with the original firmware.
I am using a KVM and I have noticed significant delayed response with the original Matze adapter and 4 other commercial supplied PS/2 to Serial protocol converters. Note that when not using the KVM, the Matze original firmware did not show noticable lag, though I think some users reported some minimal lag at high resolutions 1280x1024 at such. Now with the new firmware, and still behind the KVM, I am not noticing any lag at 1280x1024. Is this a direct result of the new firmware, or just due to the fact that the mouse is using 19200 baud? Considering all the issues I had flashing this chip, I'm not willing to put the original firmware back to test this out.
Question: Is the Microsoft Intellipoint driver the only Windows driver which supports 19200 baud when using this adapter? I noticed my previous Windows mouse driver doesn't work anymore.
Attached is a photo of the breadboard mess.