Micromys v5 on a Ultimate 64 2 neos mode

Auto-detect may not work, as potentiometer reading may be non-standard on the Ultimate64 (I'd have to ask Gideon about that). The automatic computer detection needs the Pot lines to toggle in a specific pattern just after power-up, otherwise the computer isn't detected as a C64 or C128. There's the jumpers inside Micromys for cases like that.

For NEOS mouse to work, the FIRE signal needs to be programmed to output - again, not sure if the C64U can do that, but I'd be very surprised if it can't.

Jens

There might be differences. First of all, it takes time before the FPGA is configured after the +5V power is applied. Then, the sampling of the paddle inputs (potentiometer reading) will start. The pattern should be exactly the same as what a SID does; 256 PHI2 cycles charge, 256 PHI2 cycles discharge (pull to gnd). But, on the U64, all four channels are sampled at the same time; independently of the PIO settings of the CIA. However, the CIA settings do determine which port is being read on the 'SID' registers. But you can't see on the joystick port which control port is selected. So if this is relied upon for the detection, this won't work.

For NEOS mouse: the FIRE signal is *input only*. It hasn't always been like that, but in the most recent firmware I have turned off the joystick outputs on the U64E2 (and thus C64U). The reason is that the level shifter between the FPGA and the joystick port seemed to be sensitive and break when a naughty joystick ties a pin to +5V instead of to ground only. Well, that's the assumption, which still has to be confirmed. The level shifter may also be sensitive to ESD, more than what the filtering on the board absorbs. The U64 MK1 has a different filter component on the joystick ports, with a higher impedance and a lower cut-off, and had the joystick pins be level shifted by a 5V tolerant Xilinx PLD. This filtering caused issues with the lightpen input in some cases.

So, for the C64U which is produced for the masses, it is better for Commodore to accept a slight incompatibility with something exotic than to repair many boards.

I'd try jumpering for C64, ie bypass the computer auto detection - that should work

Quote from gideonz

But you can't see on the joystick port which control port is selected. So if this is relied upon for the detection, this won't work.

This should actually be better than the original, as auto-detection is only reliable on port 1 - the port where a 1351 mouse is actually expected. However, the delay from power-on to sample-start is probably what takes Micromys into testing for Amiga/Atari ST, so I completely agree with Tobias to jumper the adapter for C64 in order to bypass auto-detection.

Quote from gideonz

For NEOS mouse: the FIRE signal is *input only*.

Too bad! I totally understand that repairing such a board because of a bad joystick or auto-fire circuit is something you want to avoid. If you really want to protect the joystick ports from the described evil circuits, it would have to be some more beefy FETs for pull-down and polyfuses in-line that protect the FETs. Do you have something like this on the paddle pins? Or is that just an appropriately-sized resistor?

Jens

Quote from Jens

[...] However, the delay from power-on to sample-start is probably what takes Micromys into testing for Amiga/Atari ST, so I completely agree with Tobias to jumper the adapter for C64 in order to bypass auto-detection.

I would say that adding a bit of delay at startup of the Micromys will solve it?

Quote from Jens

Too bad! I totally understand that repairing such a board because of a bad joystick or auto-fire circuit is something you want to avoid. If you really want to protect the joystick ports from the described evil circuits, it would have to be some more beefy FETs for pull-down and polyfuses in-line that protect the FETs.

Well, there is only one signal per Joystick I/O from/to the FPGA, and when using a FET, I'd need two: one for controlling the FET and one for reading the data. This would definitely have been more sturdy, but also more expensive to make. With the same number of I/Os, I'd have needed an extra latch/FF for the outputs, a whole row of FETs and all. So there is only a FET-based level translator, which is supposed to hold with the maximum I/O current that is programmed in the FPGA, but somehow it does not. (Although it still needs to be proven; it could also be ESD.)

Quote from Jens

Do you have something like this on the paddle pins? Or is that just an appropriately-sized resistor?

The paddle inputs are different. They are discharged by something similar to an 74LS06, and charged by the external resistor. A comparator is used to capture the moment at which it crosses a somewhat programmable threshold. Pretty much like in a real SID. The difference with a SID is that the leakage current of the SID is non-linear and significant, which makes it very hard to mimic. But external devices (like mice) that time the transition rather than providing an analog resistance just work perfectly.

Quote from gideonz

I would say that adding a bit of delay at startup of the Micromys will solve it?

For the C64U it would certainly solve it, but it would break a key Amiga function: Be able to get into the early startup menu. This was an important improvement over the previous version, which was slow to start and had trouble talking to the mouse when buttons were pressed during power-up. I don't want to remove that, just for being compatible with a machine that can easily be worked with by setting the jumpers for C64.

Quote from gideonz

Well, there is only one signal per Joystick I/O from/to the FPGA, and when using a FET, I'd need two: one for controlling the FET and one for reading the data. This would definitely have been more sturdy, but also more expensive to make. With the same number of I/Os, I'd have needed an extra latch/FF for the outputs, a whole row of FETs and all. So there is only a FET-based level translator, which is supposed to hold with the maximum I/O current that is programmed in the FPGA, but somehow it does not. (Although it still needs to be proven; it could also be ESD.)

While I also use these FET-based translators in other products, I consider them a danger to an expensive FPGA, so I rather spend the extra IO on a circuit that "sacrifices" itself in case of a misbehaving peripheral. In your case, I would have chosen some low-cost 8-bit MCU that's 5V-tolerant or even 5V-powered. It could have served as IO-extender and even handle paddle reading right on power-up. Maybe for a next version that also allows all five ports to be programmed to output? After all, your board currently doesn't work with two of our products, the Autofire module and Micromys in NEOS mode. Hard to explain to customers when they're buying "a real Commodore".

Quote from gideonz

The paddle inputs are different. They are discharged by something similar to an 74LS06, and charged by the external resistor. A comparator is used to capture the moment at which it crosses a somewhat programmable threshold.

The open-drain driver is still in danger if the POT pin(s) are tied directly to +5V. That's why I've asked if you have a current-limiting resistor in series to the pin. That's what I have done on Keyrah V3: thin-film resistors with positive temp coefficient, so the discharge-circuit can't blow them upon applying 5V without a resistor.

Jens

The open drain driver has a series resistance indeed that will survive when the pot pin is tied to +5V directly; which is basically the case when a potmeter is in one of its extremes. The resistor doesn't need to be very small in value, because the capacitor is given 256 µs to discharge. It should be small enough not to cause an excessive offset voltage though with the external pot.

Te drawback of a micro doesn't outweigh the benefits. A micro needs to be programmed in the factory; it needs to be maintained; it needs to be updatable with a firmware upgrade: I remember the pain of the Xilinx PLD not being upgradable with a firmware release; that was a mistake. Additionally, a micro is not suitable for routing the lightpen input (not fast enough), and possibly not fast enough to support fast protocols other than joysticks. The best is to create a discrete solution, but it's bulky. Not really an issue for such a large board, though.

I understand your statement about "a real Commodore", but the C64U is now a real Commodore in every sense of the word, albeit not exactly the same as a machine of 40 years ago. I'll discuss with Commodore if they are open to a hardware change to improve compatibility.

An im provement could be:
- Use the NPIC6C4894DY shift regsiter to drive the outputs with current limiting series resistors. (4 FPGA pins)
- Use a single logic gate with "high bandwidth" protection to read the lightpin input (1 FPGA pin)
- Use two AHCT157's (or similar) to read back the pins (5 FPGA pins, reuse LE pin of the shift register as a select)

Total: 10 FPGA pins, just like now. This will definitely be more robust.

Quote from gideonz

- Use the NPIC6C4894DY shift regsiter to drive the outputs with current limiting series resistors. (4 FPGA pins)

NPIC6C4894DY is EOL.

Have a look at TI's 74HCS595 in DYY package (0.5mm pitch, 4.3 x 3.3mm board real estate, 3 FPGA pins, cascadable, 0.08 USD per 8 bits output) and 74LV06 - that'll give you up to 12 OD-pins controlled with 3 FPGA pins and an update rate of well over 1MHz, given that you really only need to clock out 12 bits and the allowed frequency at 5V supply is well over 1MHz. Cost per pin would be under 3 cents, including decoupling caps and series resistors.

You could even use the spare output bits of the shift regs to control an analogue muxer for the pot pins, just like the 1980s original did. What will make you fully compatible on the joystick ports, and all kinds of dongles, external keyboards(*) and DIY projects will work.

Jens

(*): The German 64er magazine (publisher Markt&Technik) had a hex-entry keyboard that plugged to the two ports; needed software, kernal patch IIRR.

Edit: 74HCS596 might be even better-suited, as it has OD outputs - though only with just under 8mA sink capability. Still good enough, given that the 6526 is spec'd to sink only 3.2mA.

Fair enough, I didn't look at it very long; I was at work and this was a distraction. Just like now actually..

Good catch that the NPIC6C4894DY is EOL. The *74HCS596 is indeed a very nice open drain shift register; only needs 4 FPGA pins: OE, SER, SRCLK and RCLK. Unfortunately the device can only clear itself to all zeros when using SRCLR#, but that means all pins are driving low since there is no inversion, so the OE pin is needed to make sure that all bits have been loaded with '1's, before OE is asserted. Just a power-on issue.

The analog mux is a nice addition, but I doubt it will make any difference in compatibility. Probably to some extent, as the U64 is currently unable to measure the parallel resistance on port 1 and port 2 when both ports are enabled at the same time.

Thanks for the input!