Mike's PCjr Page

Brutman wrote:I've had a jrIDE on my system since 2012 and I've never had a problem with the joystick controls.

Diagnostics just passed. A BASIC program reports values from 3 to about 130 with 55 being mostly centered. According to the BASIC manual the exact values depend on the joystick.

Figured as much, but thanks for confirming . . . this information in hand, I tried the following mechanically and aesthetically un-sound configuration: https://1drv.ms/u/s!AqVrKLbX9W2f5XWq_Jo ... 2?e=pz9Vgu

and, lo and behold, joysticks work fine, along with all other functions of both the Jr-IDE and the Racore (I have the memory expansion removed from the latter so the edge connector in the expansion chassis isn't needed)

Could this be a problem with power on the expansion bus?

It's not obvious what you did in the picture; is the Racore sidecar now downstream from the jrIDE? Is that the only change?

I'm not sure why power on the bus would matter. It seems to be more of an I/O port conflict, but neither card should be touching 0x0201. Unless there is an aliasing problem.

Yep, the only change is reversing the order of the sidecars - the Jr-IDE is now directly attached to the system unit, with the Racore sidecar outboard.

So the joysticks are non-functional again - the sidecar re-arrangment must just be coincidence.

Getting a little more scientific, I've tried writing/reading the value of emulated machine port 201 from BASIC, and the problem becomes apparent - the values of bits 2 and 3 are stuck high at all times - in other words the port value is hex FC, even with no joysticks plugged in, and for an arbitrary long time after a write of any value to the port. If I understand things correctly, this should only be the case for a short period after a write to the port, if joystick1 is at max x-axis position, and joystick2 is at max y-axis position.

By "non-functional" do you mean they don't work at all, or that existing code simply doesn't work very well with them in a sped-up system?

Try testing the sticks using this: http://www.oldskool.org/pc/joycalib/joycalib.zip
(If you have a single stick plugged in and it says it doesn't find a stick, either plug it into the other port, or start it with JOYCALIB.EXE /b )
I wrote it and it defaults to reading the 8253 timer for its timing information, so it should return consistent numbers on any system regardless of speed. While it can't fix badly-written software (or BIOSes that never expected the PCjr to run past a certain speed), it can at least verify that your sticks and ports are working fine. In other words, if your sticks work okay with JOYCALIB, then all of your other issues are just unfortunate software choices by software programmers.

Speeding up a PCjr will cause the BIOS stick routines to return different values because it uses fixed timing loops for the sticks. This in turn will cause the INT 15h joystick read routines to not work properly, which will then cause joysticks to not work with any program that uses the INT 15h routines. And, unfortunately, it is reasonable to expect that any program detecting a PCjr would default to using the official BIOS joystick routines, because programmers had it beaten into them to use the BIOS routines as much as possible on PCjrs for compatibility reasons.

Because the BIOS relies on the speed of code execution loops to determine axis values, I don't think it's possible to fix on a sped-up PCjr.

Many thanks for JOYCALIB, extremely helpful.

So, joycalib works successfully (ie. detection, ranging, and then the final screen for trimming all work normally) with a joystick in port B (regardless of processor speed).

With the joystick in port A, a joystick is detected, but after setting upper-left/lower-right, the program reports "both stick ranges were identical" (again regardless of speed) - I think this matches my finding in BASIC, w/ two bits stuck high on port 201.

So this does seem like a hardware fault w/ port A, not a software interaction with the sprint board . . .

So, this would be funny if it weren't so dumb, but I finally found the problem, and it was that I literally had a screw loose

there was a case screw loose underneath the motherboard, making intermittent contact with something.

I apologize to anyone who wasted seconds or minutes of their lives reading this thread . . .

On the other hand, we can all testify that bagelswitch has a loose screw ... ;-0

I did a simple stick test,
only tested one stick

with the Sprint board OFF, using the built in BIOS test routines, ALT CTL INS.

I centered the joystick marker in the box

Then turned ON the Sprint board, the marker moved 1/4 way to the lower right corner.

Repeated turning ON / OFF Sprint the test was repeatable.

Anyone care to confirm ( no screw loose here, took them all out, test MB sitting on the table)

I can confirm this. The offset increases (towards the lower right) with increasing CPU speed. Here's an image with a V20 at 9MHz (after centering at 4.77MHz).

The trim levers don't have quite enough range to get it centered at 9MHz, but I haven't had any trouble using it in actual software (I played through the first three areas of Silpheed in this configuration) - if someone's particular stick normally needed more up/left trim though, this could be a problem.