Arkanoid pad

Página 4/5
1 | 2 | 3 | | 5

Por NYYRIKKI

Enlighted (5889)

imagem de NYYRIKKI

24-01-2017, 01:46

I just wonder why Arkanoid pad does not work correctly with MSX tR... Even if the computer is running on Z80 the paddle jumps irrationally on the side all the time. On normal MSX2 it works totally smoothly. I can't think of any reason that could cause the difference.

Por mars2000you

Enlighted (6014)

imagem de mars2000you

24-01-2017, 01:55

I think paddle controllers support has been removed on MSX Turbo R.

More info here: https://www.msx.org/wiki/MSX_Paddle_Controller

Por NYYRIKKI

Enlighted (5889)

imagem de NYYRIKKI

24-01-2017, 10:35

mars2000you wrote:

I think paddle controllers support has been removed on MSX Turbo R.

I know that MSX paddles are not supported, but Arkanoid paddle is not MSX paddle, so the explanation does not apply.

Ok, ok... I would put my chin to the chest and accept your explanation if I would be calling to tech support, but here I'm more interested about the "why?" rather than interested to get it fixed for me.

Could it be that Arkanoid reads it with interrupts enabled or something like that?

Por gdx

Enlighted (4805)

imagem de gdx

24-01-2017, 10:54

Reading the value from MSX paddle controllers directly depends of CPU timings. This must be the reason for the removal of the support on Turbo R. I do not think that is the case for Arkanoid controllers that read a bit like the mouse.

In addition, the MSX paddle controllers are extremely rare.

Por sd_snatcher

Prophet (3480)

imagem de sd_snatcher

25-01-2017, 01:47

For the R800, this problem is easy to understand when the schematics are analyzed.

The Vaus paddle (not to be confused with the standard MSX-paddle) has a design flaw, maybe as a result of being hacked from the NES design without putting too much thought into it.

The circuit is prone to the famous race condition bug. To cut costs (for the NES design), it doesn't use a DAC to convert the potentiometer position to a number. Instead, it uses a 556 and a CD4040 ripple counter. As I mentioned before, this designed was intended to be as-cheap-as-possible for the NES serial transmission, but was way more expensive than the standard MSX-paddle. IMHO, they should have done it the other way around: design it as an standard MSX-paddle, then implement a way to read it by bit-banging on the NES.

It's works like this:

(Note: the 556 is a dual-555 timer. I'll refer them as 1st 555 and 2nd 555 to make the explanation shorter.)

- The 1st 555 seem to be configured as a PWM generator, very similar to the one inside the MSX-paddle. In fact, just a single 555 would have been enough to build the standard MSX-Paddle.
- The 2nd 555 is configured as a fixed clock generator
- The CD4040 is a ripple (pulse) counter that transmit data serially

The steps are:
1) The Out pin pulse from the MSX resets the CD4040 counter and the trigger the 1st 555 (PWM)
2) While the 1st 555 is active, the clocks from the 2nd 555 are counted by the CD4040. Since is PWM, the length of the pulse is active will be adjusted by the potentiometer position
3) When the 1st 555 is done, it blocks the clock input of the CD4040, and a RC filter delays the same signal a bit so the 8bit value is loaded into the 74HC165 a tad later.
4) The CD4040's 8bit value is then read serially by the MSX using bit-banging

The racing condition occurs because the time to perform the steps 1~4 is variable and there's no way for the MSX to know how long it will take since it depends on the knob position. Apparently, the race condition bug was so sensitive that even a small change in the BIOS routines like the turbo-R has was enough to trigger the bug even when running with the Z80.

This bug would have been easily avoided if the pin-1 of the 74HC165 had been connected to one of the MSX joystick port input pins, like pin-4, for example. This way, the MSX software would only have to monitor the pin-4 status, and when =LOW it would have known that the internal counting would have ended and the start the serial reception safely. Very similar to what was done for the MSX-touchpad.

There are many ways to solve or workaround the problem.

1) If you want to use unmodified original cartridges, the only way is to fix the paddle hardware:

This compatible design uses a DAC to read the potentiometer value, thus it it performs instantly. It should work with any CPU speed and the original/unpatched cartridges.

But if you want to use original/unmodified paddles, then the only way is a software workaround, They'll obviously require software patching:

2) The software would have to be patched to add some delay after the joyport-Out pulse and before the serial read bit-banging. For the Turbo-R, the system-timer would have to be used for this delay.

The problem with this approach is that it only fixes it for the Turbo-R. Some turbo Z80 machines would still have the problem since they don't have the system-timer. It wouldn't work for the Victor HC-90 & HC95 turbo too.

3) Then there's the hybrid solution: hardware+software fix

The pin-1 of the CD4040 would be connected to the pin-4 of the joystick port. The software would then be patched to read the pin-4 as a flag, as described before. This fixes the original joypad for any CPU speed, regardless if it was a system-timer or not. And the use of the system timer on the TR wouldn't be necessary. There are two good news with this approach:

a) There are enough wires available in the Vaus paddle chord for that. The extra wires are just lying inside the controller. It's a very small mod that just can't be detected externally.
b) This approach solves the hardware problem without breaking the compatibility with the original/unpatched cartridges. The new status bit would just be ignored by the original software. They unpatched software will still have the bug, of course.

Please note that this is an untested/unproven idea based on a quick analysis of the circuit. If anyone is going to try it, I would advice to him make some heavy testing (preferably with a logic analyzer) to check if it indeed does work properly.

4) The standard solution

Then, there's the last and standard solution. Just store the original Vaus controller in a glass box for exposition, build yourself a standard MSX-paddle and patch the Arkanoid games to use the BIOS routines as they should have done since the beginning. (and we wouldn't have this problem, and then the TR paddle BIOS wouldn't probably have been removed)

Yes, the Turbo-R doesn't have the MSX-paddle BIOS routines anymore, but the DRAM mode allows an easy solution for that: just load a driver to patch the BIOS and implement the paddle routines again, using the system timer to measure the length of the PWM pulse. This would kill two rabbits with a single stone. ;)

Por NYYRIKKI

Enlighted (5889)

imagem de NYYRIKKI

25-01-2017, 08:37

Thanks sd_snatcher!

I think your explanation must be very close to correct answer... How ever Arkanoid II first does serial read and after that it triggers new measure cycle. This should give more than enough time (whole screen draw) for paddle to retrieve new status. How ever I think they forgot that BIOS "ON STRIG GOSUB" causes pin 8 to be pulled low on interrupt... Not sure at all if this is a correct explanation either, but something like that it must be...

Por sd_snatcher

Prophet (3480)

imagem de sd_snatcher

25-01-2017, 23:44

Some more info: If I understood the circuit correctly, the 2nd 555 timer is configured to run at 96.2KHz. This means that in the worst case it takes 2.651ms to reach the value 255 in the CD4040 counter, and a tad more to load it to the shift register.

2.651ms are roughly equivalent to 9489 Z80A cycles. Way too much time to sit waiting for a read. Definitely the only way to read this awfully slow paddle is to trigger the counter, then only after a frame return to do the serial read of the value. This explains why Taito coded it like this.

They just added insult to injury when they made an internal NOT over the signal that comes from the joyport pin-8 before feeding it to the CD4040's reset pin. This means the pin-8 must be kept HIGH all the time, because if it goes LOW the CD4040 counter will be reset and the process will start all over. As you mentioned, the MSX-BIOS interrupt handler toggles the state of the pin-8. So definitely not only they ignored the MSX documentation about the MSX-Paddle, but also totally ignored the way that the BIOS handles the joystick ports. Without that NOT this problem wouldn't occur.

All of this mean that the just the READY flag solution isn't wouldn't help this poorly designed circuit.

They really should receive an award of how to create a worse circuit than the standard MSX-Paddle while making it a lot more complex & expensive. Running Naked in a Field of Flowers

Por NYYRIKKI

Enlighted (5889)

imagem de NYYRIKKI

26-01-2017, 08:53

sd_snatcher wrote:

Some more info: If I understood the circuit correctly, the 2nd 555 timer is configured to run at 96.2KHz. This means that in the worst case it takes 2.651ms to reach the value 255 in the CD4040 counter, and a tad more to load it to the shift register.

Gotcha! You still expect that they did something actually correctly, but you are wrong... If I'm correct the counter runs roughly from 152 to about 309, so not only that the counter overflows (ATM I don't actually even know if only one time) but despite using internal counter the resolution is also pretty bad.

Quote:

They just added insult to injury when they made an internal NOT over the signal that comes from the joyport pin-8 before feeding it to the CD4040's reset pin. This means the pin-8 must be kept HIGH all the time, because if it goes LOW the CD4040 counter will be reset and the process will start all over.

Mmm... Even if they would have used pin 7 instead the BIOS compatibility problem would have been removed and it would have been more easy to handle both joystick ports from software side... Indeed it seems that they really used some effort to find all possible ways to do it wrong with maximum cost & effort. I mean... How would you even come up with idea jumping from 6 to 8 without considering 7? If it is still just random accident then it is like getting all numbers correct in a negative lottery. There just must be something more to this story... They originally wanted to use the 100% same controller in some different system... or something like that.

Quote:

They really should receive an award of how to create a worse circuit than the standard MSX-Paddle while making it a lot more complex & expensive. Running Naked in a Field of Flowers

Indeed I agree... and I can confirm that the monkey who wrote the software side of the story did keep the same original style.

Por sd_snatcher

Prophet (3480)

imagem de sd_snatcher

27-01-2017, 01:53

There's one subtlety in the circuit I haven't noticed Albeit it uses an 8bit shift register, the internal counter and the transmission are indeed 9bit. The trick is that they used the "serial input" of the CD4040, which is normally used to cascade multiple shift registers, to input one more bit into the shift register. At least one nifty trick in a otherwise dumb circuit.

> the counter runs roughly from 152 to about 309

Tested two paddles here:One goes from 208 to "763". Yes, since it's 9bit, this "763" means that it has overflown the 9bit limit by 252. The other goes from 211 to "843": this means it has overflown the 9bit limit two times!

Judging by the limits you reported, the ones hap reported on the OP, and the ones I've just read from two different devices, it seems that these paddles can't even produce normalized results! The values also seem to be also influenced by the temperature. Talk about a terrible design.

I'm seriously suspecting that hap's paddle in fact goes from 236 to "821", what would it also overflows two times.

I wonder what kind of magic the software implements to accommodate such huge variation in the range of values, and even then overflows. I'm guess that it deals just with offsets between the read values.

Por sd_snatcher

Prophet (3480)

imagem de sd_snatcher

28-01-2017, 01:43

If found out why I was having so many overflows in the paddle value and having bad precision. From what I had understood from hap's explanation, I had to pulse a clock, then read a bit. After carefully reading the 74HC165 datasheet, I noticed that the fact it's the opposite order: first I have to read a bit, then pulse the clock to have the next bit loaded. The good thing is that this investigation also allowed me to find a quick way to detect if the paddle was disconnected.

I added that info and the enhanced algorithm with disconnection detection to the Arkanoid Paddle wiki article.

Unfortunately, openMSX doesn't support the disconnection detection yet.

Página 4/5
1 | 2 | 3 | | 5