Arkanoid paddle controller for NES on MSX

Champion (344)

23-02-2020, 14:23

dproldan wrote:

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.

When you read your Vaus paddle you have considered only 8 bits instead of 9.
The range of your Vaus should be ~110..360.

Par sd_snatcher

Prophet (3675)

23-02-2020, 14:48

dproldan wrote:

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:

A slider controller is a nifty idea, and it could also be applied to the standard MSX-Paddle. Since you used an Arduino PCB, it shouldn't be hard for you to add a way to switch to the PWM protocol so you can play Galaga.

Your current range for the Vaus protocol is very limited though, seems to have been custom tailored for the Arkanoid1 game. Does it work fine for the Arkanoid2?

Anyway, it would be hard to support your current Arkanavi on future patches for other games. Your range will probably restrict it to the Arkanoid games. But the switch to select the PWM protocol would be enough to workaround the problem.

Par dproldan

Resident (44)

23-02-2020, 14:56

I never saw the need or the reason to use 9 bits. The device inside , the 74LS165 is 8 bits as is our MSX, plus everything works fine using 8 bits. Maybe the 9 bits thing was not correctly deduced before?
I have to put the osciloscope sometime to confirm, but extracting 9 bits from a 8 bit shift register looks weird to me.

@sd_snatcher, yes, works for both original Taito games.

Par Danjovic

Champion (344)

23-02-2020, 15:27

@dproldan, the 165 can be cascaded using pin 10 (SERIAL INPUT) and that input is used to provide the 9th bit

The original vaus paddle circuit induces an offset at the counting and if only 8 bits were transmitted that would result in a significant loss of resolution. In fact the value range is still 8 bits (or close) but due to the offset it is transmitted using 9

Never disassembled the full game, only the data shift part, but I don' think the game perform any kind of autoscaling.
Your clone Most probably should be providing a dummy 9th bit. Please do some tests with testvaus provided by @SD_Snatcher and return us the results.

Par dproldan

Resident (44)

23-02-2020, 15:57

@Danjovic What I mean is that I think the MSX is only reading 8 bits from the shift register. Pin 10 is connected to the counter, not being used as serial input. I saw your pictures now and this one shows only 8 clock pulses:

This coincides with what I did to read the original pad and to clone the protocol with the arduino. Even if there are 9 bits of data, the 9th bit is being discarded when the signal from the MSX loads the shift register, there are only 8 spaces to hold data.
Reading assembler is out of my league, I trust you on that one.

Quote:

In fact the value range is still 8 bits (or close) but due to the offset it is transmitted using 9

If the value range is 8 bits, as you noted, that ghost 9th bit is not relevant. I'll try to see with the testvaus.bin and report back.

Par Danjovic

Champion (344)

23-02-2020, 16:51

The most significant bit is ready at 165 pin 9 as soon as the shift register is loaded at the end of the sampling time provided by U4B (556). The eight clock pulses are issued to read the remaining 8 bits. Take a look at the disassembly of the game with comments.
The basic structure of the code is:

Read the MSB, store in H register
Repeat eight times:
- pulse clock
- read bit, store in C register
save the 9bit value as a 16 bit (H:C) in 0xE0C1

Some time back I have missed the detail about the 9th bit too, and the post I have linked is indeed an update of a previous post.

Par Danjovic

Champion (344)

23-02-2020, 17:16

The Vaus circuit uses a fixed sample time to count a variable number of pulses. The frequency varies within a given range, from a minimum frequency to a maximum frequency. It implies that either side of the range will have a value that is greater than zero.
Then if you want a value between 0-255 and you have an offset that is greater than zero, the sum will exceed 8 bits.

In real world figures, the minimum frequency provides a counting of ~110 and a maximum of ~390 counts. Such values suggest that the Vaus controller designers considered the value 256 as the center of the scale, and any values below (256-128) or above (256+127) could be safely clipped and tha would provide a safe margin at both sides of the potentiometer turn.

last, if you don't transmit a 9th bit your paddle will surely work (and it does) but the game sees your paddle jumping 2 steps at a time (2 lsbits equal) and that will hardly be noticed while playing the game.

Par Danjovic

Champion (344)

23-02-2020, 19:39

sd_snatcher wrote:

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.
...

I have tested Testvaus2 using a White Hotbit and the diy clone. Here are the measurements:

Full counter clockwise: 62
Centered: 255
Full clockwise: 411

Turned the pot left and right many times to check the consistency of the values (they may float a little bit specially when fully clockwise).

May I suggest you to add a key to exit the program?

Par dproldan

Resident (44)

23-02-2020, 20:07

I don't know man. As far as I can see in the schematic, when the latch signal arrives, the shift register gets only 8 bits from the counter, if Arkanoid stores a bit before that, I don't know what it is.

I don't have the original paddle any more, would you do a test with your clone? remove the connection between the counter and the pin 10 of the shift register. Is there any difference in behavior when you do that?

Anyway, X. Sorinas did the test with his Arkanavi and the results are: slider to the left: 140, slider to the right: 320.
I did clip the range of the Arkanavi by software, so the slider has a correspondence with the movement area of the game.
These are the values I used (arduino uses 1024 levels):
paddleValue = map(sensorValue,0,1023,70,160);

Par Danjovic

Champion (344)

23-02-2020, 22:50

Removing the connection from 4040 to Pin 10 of the 165 provides the same readings at the extremes, but the least signficant bit got stuck on 0 (with a pulldown on pin 10).

The schematic that I have based myself into is on the wiki page here on MSX.org and it have 9 bits coming from 4040 to the 165, being the least significant connected to Serial Input of the 165.

The 9th bit is the least significant bit, and that is why the difference is not so pronunciated. As you only shift out 8 bits, the game reads the least signficant bit twice with the same value and the output is reported by Testvaus as the double of the values you have mapped.

I have used a different approach on my arduino based paddle clone. My first approach was to use the SPI register but unfortunately AVRs can only do 8 bit SPI tranfers (by hardware). Then I have decided to literally emulate a shift register.

Code is organized like below. Main function is a dummy and everything happens on interrupts.

And while the game is running that what happens.

But in my code I still need to map my ADC value into a range compatible with Vaus ;)