Here are some of the configuration settings I see when using the Wellon VP-390 to program the ATTiny 4313-PU. Perhaps changes are needed to get this working?

EDIT: Looks like Vogons split up the pages. This current post and my previous post on page 15 go together.

EDIT2: I managed to reset the efuses using this schematic on a breadboard and an Arduino. Thanks to Madowax for this suggestion. http://mightyohm.com/files/hvrescue21/HVRescu … 1_schematic.png

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.

I've been doing some testing with firmware v1.1 and using the Microsoft Intellipoint Mouse drivers within Win3.11. After installing the Intellipoint drivers, I was no longer able to boot into Win3.11 if I have my 3Com Etherlink III 3C509B ISA network card installed. The system will hang just before the point in which it asks you for your username and password. I don't even need to have the mouse or PS/2 adapter installed - the system will just hangup with Intellipoint drivers + 3Com Etherlink III. If I remove the network card, I am able to use the Intellipoint mouse drivers. Or, if I uninstall the Intellipoint drivers, I am able to use the network card. Anyone know if there is a workaround for this? Are there any other Windows mouse drivers which will work with the mouse at 19200 baud? Thanks!

Edit: I should point out that this adapter is not going into the 386 test motherboard I was using. My cased 386 already has a native PS/2 adaption using the keyboard controller. This adapter is targeting systems not easily adapted for native ps/2 mouse fixes, like my NexGen system.

Here is what I did with my PS/2 adapter to get it mounted onto a slot bracket. Found some flat slot covers on eBay, the tinner the better, but with a 90 degree reinforcement bend. If your slot cover is too thick, the ps/2 mouse pins might not make contact with the female DIN. I then JB Welded it (epoxy) to the bracket along the whole edge of the PCB and around the metal din housing. Be sure to scratch up the shiny stainless steel contact surfaces so that the epoxy can adhere firmly. Use wood joiner clamps to secure the bracket to the PCB while JB Weld is drying. Solder on a pin header for the 12 V power connector. Find some longer bolts of appropriate threading to screw in the serial cable. Upgrade to firmware v1.1.

I was previously using a Logitech Bus mouse on my NexGen build, but I'm hoping to swap this little guy in the case and ditch the bus mouse. Before doing so, I want to run Quake timedemo with the mouse enabled and compare it with the results from using the ps/2-to-serial adapter at 19200 baud.

I removed the bus mouse card from my NexGen system and connected the PS/2-serial adapter to COM1. While I am able to use the mouse fine in DOS using the Microsoft Intellipoint drivers, Windows 95c, upon boot, does not detect a mouse. I have installed the Windows drivers for the MS Intellipoint mouse from the zip package that came with firmware 1.1 for the adapter. Are we supposed to setup COM port 1 in a particular way from the Device Manager?

glad do hear you made it.

Sorry about all this confusion, its because i`m not very good with proper documentation.
for future revisions hopefully we will make a better way to upload firmware to get around this troubles.

There is no 19200 baud mode driver for windows 95 yet. Maybe the Windows 3.x driver will work ?
The 19200 baud mode reduces transaction delays so you notice lesser lag.

There never was any mouse supporting 19200 baud at all.
So there is need to modify existing drivers.. for NT4/XP/2K this could be done using the reactos drivers.

9600 baud might suffice, however, I've seen a Linux distro that only works at 1200 baud for some reason.

usually a serial mouse works on 1200 bauds, a logitech at 2400 baud..

therefore 19200 baud is highspeed serial mouse. And its needed to speed up serial connection to reduce lag for KVM users.
it should not soo hard to patch a 9x driver..

for linux is much easier as you can specify the baudrate in different drivers and just recompile them..
also reactos.

Why does the Microsoft Intellipoint Mouse driver v1.10 work for Windows 3.11 but not Windows 95? When I read through the readme, it sounds like this driver is supposed to work with Win3.1, Win95, and NT (probably 3.x?).

1  Some Mouse Tabs Are Part of the Operating System
2
3    Under Windows 95, the Pointers and General tabs are a standard 
4    part of the Windows 95 operating system and are not part of 
5    IntelliPoint.  Only tabs with the Microsoft IntelliPoint logo 
6    are installed by IntelliPoint.

1  Return to Previous Position Not Available in Windows NT 
2
3    In Windows 95 and Windows 3.1x, the SnapTo feature includes an option
4    that enables you to return the pointer to its previous position when
5    the dialog box closes.  This option is not available in Windows NT.

matze79 wrote:

usually a serial mouse works on 1200 bauds, a logitech at 2400 baud..

Perhaps the adapter can be setup for 2400 baud and use the Logitech serial drivers then?

Is there a way to get this ready built?

logitech mode always is 2400 baud.

Because only the 16bit Driver inside the Package for Windows 3.x is patched for 19200 Baud yet.
Maybe you can copy over the files and manually add it to your system configuration to make it work.. not yet tested.

Is there a way to get this ready built?

not yet, but soon 😀

i`m working together with dreamblaster so you may can someday purchase one at serdaco.

matze79 wrote:

logitech mode always is 2400 baud.

Because only the 16bit Driver inside the Package for Windows 3.x is patched for 19200 Baud yet.
Maybe you can copy over the files and manually add it to your system configuration to make it work.. not yet tested.

I try to use ps2maset.exe to set the baud to 2400, but it says this is not a valid setting. Thus, I cannot use the Logitech serial drivers.

Do you know which files were patched in the 16-bit driver for MS Intellipoint Mouse drivers? And will they work with [32-bit] Win95c?

Sorry for the bad English. Its not my native language. ^^

The Firmware Version 1.1 supports at the Moment only 1200 Baud and 19200 Baud.

Modification on Intellipoint DOS Drivers:
File "Mouse.exe" - Location $3ECF changed from $60 to $06.

Modification on Intellipoint Win3.x Drivers:
File "msinput.drv" - Location $08B4 changed from $60 to $06. (in the Installpaket it is the File 'winmbp31.dr_')

I think, the Lag-Problem from the old Firmware with KVM-Switchdes is a Time Problem.
Example: You connect a PS2-Mouse to an KVM-Switch. The KVM-Switch to the Ps2/Serial Mouseadapter and the Ps2/Serial Mouseadapter with the Retro-Computer. Then you press a Button on your PS2-Mouse. The Mouse send the Data to the KVM-Switch with the PS2-Mouse Protokoll. This needs ~1 Milliseconds. Then the KVM-Switch interprets the Data and send it to the PS2-Mouseadapter. Again ~1 Milliseconds. The Mouseadapter interprets the Data and send it with 1200 Baud to the PC. On 1200 Bauds, the needed Time are ~8,5 Milliseconds. The complete Transfer for only one Mousedata-Paket / Sample needs more then 10,5 Millisecends. Many Mouse-Hardware works with 100 and More Samples per Second. And that is the Problem.

To most Time is needed for the Serial-Transfer from PS2-Adapter to the PC. The only way to reduce the needet Time is to increase the Baudrate. My Solution was the increased Baudrate, but no Mousedriver, that i know, is working with higher Baudrates. Meanwhile i know, that the Logitech Mousedriver can work with higher Baudrates. I disassembled the Intellisense-Mousedriver and analyse the Code, so i find the right location to modify. I make it with DOS, Win3.X und Win9x Drivers, but only the DOS and the Win3.X Drivers work with the modification. The Win9X-Driver does not work. 🙁

At the next step, i will analyse the Logitech Mousedriver. I hope, that i can write another Firmware-Update to support an unmodified Logitech-Mousedriver with higher Baudrates (4800 or 9600 Baud) under DOS, Win3.X and Win9X. But i need Time for this. ^^

Hello and welcome to the forum! Some of the discussion on this has doubled down in this thread, Re: 8BIT ISA SERIAL I/O TO PS2 MOUSE

OK, so it sounds like it won't be possible to properly patch the Microsoft Intellipoint Mouse v10.10 drivers to work with 19200 baud in Windows 9x. That is very unfortunate.

From what I can see, the Logitech DOS driver allows for up to 9600 baud. I haven't checked the Windows NT driver. I'm hoping to test a new firmware, perhaps v1.2, that will let me switch between 1200 baud and 9600 baud instead of 1200 and 19200 baud. This will allow me to test the serial adapter in DOS, Win9x, and WinNT with Logitech drivers. There are a lot of Logitech revisions to choose from.

oh, thx.
I write then in the new thread on.

Logitech C7 has arrived.

So we can now investigate 9k6 Baudmode

That looks very 1987.

Looking forward to the results.

Does not work on Windows 95 😒 indeed supports 9600 Bauds in Mouse Systems Mode.
But i did not get it working yet.

So we need to hack a 9x driver.

But 9600 Baud mode works on ReactOS 😉

Seems like hacking the Intellimouse driver didn't work for 19200 baud. Which Win9x driver can you hack?

Hello,
could i somewhere buy whole device, not just kit?

I hate soldering from high school times. Or its someone for some crash solder it for me and send it to Czech republic?