Well, I've noticed that the vaults don't use the whole range of the game. And so I had fun playing a little arkanoid during my lunch break.
The values I could read out of the game are shown here:
Arkanoid:
Red vault
- Left boarder: 151
- Right boarder: 297
Black vault
- Left boarder: 148
- Right boarder: 296
Arkanoid II
Red vault
- Left boarder: 164
- Right boarder: 306
Black vault
- Left boarder: 162
- Right boarder: 304
The vaults range is middled to the game.
I made sure to touch the walls just enough. So here deviations are allowed and due to my motor skills.
Well, I've noticed that the vaults don't use the whole range of the game.
Yes, this is explained by the fact that the games have decoration bezels, plus a large score board at the right.
This reinforces the importance of having more paddles tested, so we can figure what's the safe range.
Will that be the case of all black paddles, or maybe just one that needs some maintenance?
I don't have a real Vaus paddle, but I have seen in many photos that it provides a mechanism to perform calibration, though I have seen any trimpot in the teardown pictures I have seen so far. Could it be a mechanical adjustment?
This paddle is very picky with the way it's read. I created a new TESTVAUS.BIN application from scratch using a slightly modified version of HIDlib/analoglib (just to output all 9bits instead of 8bits), and published it here.
This new app gets very little variation between different machines, is compliant to the MSX coding guidelines, and also supports turbo.
Could it be a mechanical adjustment?
No, this is just a cover for a hole. Maybe they planned such adjustment in the beginning, but gave up and just covered the hole.
No, this is just a cover for a hole. Maybe they planned such adjustment in the beginning, but gave up and just covered the hole.
Well, nevertheless I have included a trimpot in my clone. and that should compensate for components tolerance.
Did you have noticed some instable behaviour on the values read? I got some and for my surprise they were not caused by a noisy potentiometer but due to gliches induced by the shift register. A capacitor on the data pin killed the glitches (indeed they were very fast) and provided a smooth movement of the Vaus ship on screen.
I will run your test program and return here with results (it can take some time though
Did you have noticed some unstable behaviour on the values read?
I've noticed no unstable behaviour. In fact, while it has some flaws, one of the advantages of this design seems to be how stable it is. I've never seen DAC-like noise either. By that I mean when the controller is in a position that makes it keep floating between two neighbouring values.
TestVaus v2.0 with my red Arkanoid II controller displays 104 far left and 365 far right.
@Avkooi said:TestVaus v2.0 with my red Arkanoid II controller displays 104 far left and 365 far right."
Could you please tell us what MSX Computer was used?
And can you make the same test with other different MSX Computer also?
P.S.: my new test with TESTVAUS.bin V2.0 at:
@alexito:
That was with a Panasonic TurboR A1 GT.
With a Sony HB-F1XDJ the results are almost the same, 101 far left and 359 far right.
OCM with KdL 3.8, 102 left and 362 right.
SM-X with KdL 3.8, 102 left and 357 right.
I made a compatible vaus paddle some months ago, tha Arkanavi. During the development, I reverse engineered the protocol and made some tests with an Arduino:
https://twitter.com/i/status/1143606786299179010
The range for the paddle was between ~55-~180. In my Arkanavis, I adjusted them to match the game area perfectly. I'll look for the correct values later.
This is the Arkanavi working, you can see that the physical position of the pot matches the display position.
https://drive.google.com/file/d/1XZ5hUNdfft6q9Mxwhfbwv6KZ7Hylkyn3/view?usp=sharing