Joystick multiplexer help

[+fdr4prez]

1 hour ago, johnnywc said:

Yes, it works with 4 driving controllers you can also use 8 paddles but it only recognizes the buttons of course.... maybe a four player competitive pinball game? ?

 

wow, thanks.

 

that opens up some gaming possibilities

Edited October 5, 2020 by fdr4prez

[Thomas Jentzsch]

BTW: Next release of Stella will support all these controllers with QuadTari.

[+johnnywc]

6 hours ago, Thomas Jentzsch said:

BTW: Next release of Stella will support all these controllers with QuadTari.

Thanks so much TJ for your hard work adding this support into Stella - I really appreciate it!   ?

[+stephena]

6 hours ago, Thomas Jentzsch said:

BTW: Next release of Stella will support all these controllers with QuadTari.

And that will be coming this week ...

[Danjovic]

Essay for a Hammond 1593 box (eagle library for the box also attached).

 

 

And correct me if I am wrong but the final schematics should look like that, right?

 

Jmux.schJmux.brd

 

hammond-1593j.lbr

Edited December 18, 2020 by Danjovic

[gauauu]

Nice! That looks pretty good. 

I've got a design for a bigger box that incorporates dual adapters (for the QUAD part of the quadTari) all ready to go. I've got some nice boxes milled and silkscreened by a company in China, but currently they're lost in the mail between here and China. Otherwise, I would have had some available to sell before christmas ?

[+Gemintronic]

How easy would this be for batari BASIC users to talk to?  Something like reading certain bytes of memory to see which inputs are pressed on joysticks 1-4?

Edited December 18, 2020 by Gemintronic

[gauauu]

Just now, Gemintronic said:

How easy would this be for batari BASIC users to talk to?  Something like reading certain bytes of memory to see which inputs are press on joysticks 1-4?

I've got a development guide up at https://www.bitethechili.com/quadtari/

 

In short: to read controllers 1 and 3, you read the 2 joysticks as usual. To read controller 2 and 4, you first set bit 0 of the VBLANK register, and then wait approximately 1 scanline for the device to stabilize. Then you read the joysticks as usual, and they'll be the inputs for the other 2 controllers.

For bB, that means inserting a snippet like this before reading controllers 2 and 4:
 

    asm
    lda #$80|%10  ;change this as appopriate to whatever you expect to actually have in the VBLANK register, but for mid-frame batari Basic, this is probably correct.
    sta VBLANK
    sta WSYNC
end

 

Also, I haven't formally announced it yet, but I will have a few of the QuadTari devices designated to give away to folks who make compelling games that make use of the device. For more details, you can email me at nathan@bitethechili.com.

[Danjovic]

2 hours ago, gauauu said:

Nice! That looks pretty good. 

Thanks! 

 

2 hours ago, gauauu said:

(for the QUAD part of the quadTari)

Indeed!!! I should rename my board to duAtari :), lol!!! 

 

The QuadTari looks amazing, specially the logo! 

[+Karl G]

On 12/18/2020 at 2:51 PM, gauauu said:

I've got a development guide up at https://www.bitethechili.com/quadtari/

 

I have a couple of development questions for @gauauu and maybe one of the Stella developers.

 

I am working on a simple QT example for batari Basic. I don't have the hardware yet, so I'm not sure if the quirks I'm seeing are related to my code, the emulation, or the way the actual hardware works.

 

First of all, Stella doesn't autodetect my demo as using the QT, so I'm wondering what I can put in to trigger it? My code to check to see if the QT is present does seem to work, but I have to tell Stella that I have the QT in both ports.

 

The development guide says to wait a full 76 cycles before reading the ports after setting or clearing bit 7 of VBLANK, but I had to strobe WSYNC 3 times before Stella would accept my input smoothly. Is the document in error, or is the emulation incorrect in this case?

 

Other than that - my bB QT sample is working in Stella. Right now it doesn't do anything other than let you move 4 objects independently. ? 

 

chaser.zip

 

 

[Thomas Jentzsch]

 Since we have no clear cut code pattern (yet?), the auto-detection in Stella looks for certain strings in the ROM:

• full QuadTari: 'QUADTARI'
• left port only QuadTari: 'QUADL'
• right port only QuadTari: 'QUADR'

[Danjovic]

12 hours ago, Karl G said:

what I can put in to trigger it? My code to check to see if the QT is present

Regarding automatic hardware detection, you can read the pot value on pin 5 to get a low value due to the pullup resistor. I can think of a subtefurge to change the value of the pullup resistor according to the state of pin 5 but that would require more components and more testing.

Another way to detect the hardware is to verify the conditions where one of the triggers is pressed while the other is not. That would mostly (statistically)  occur when a quadtari is present than when you get a press/release transition  within a frame.

 

[+Karl G]

4 hours ago, Thomas Jentzsch said:

 Since we have no clear cut code pattern (yet?), the auto-detection in Stella looks for certain strings in the ROM:

• full QuadTari: 'QUADTARI'
• left port only QuadTari: 'QUADL'
• right port only QuadTari: 'QUADR'

In ASCII anywhere in the ROM? I added a data table which doesn't seem to trigger detection. Currently it detects as having a joystick in the left port, and paddles in the right port. Does this data look correct?

 

	data quadtart_detection
	$51, $55, $41, $44, $54, $41, $52, $49
end

 

Also, I just noticed today that I wasn't on the latest Stella version like I thought I was. I upgraded from 6.4.0 to 6.5.1 to see if it would change any of the issues I noticed, but now I've lost the option to select QuadTari in the GUI, so I'll have to rely on autodetection if I can get that to work.

 

I've attached a new version that also includes the generated ASM in case that helps at all.

 

chaser.zip

 

 

[Thomas Jentzsch]

You got it almost right, currently it is $1B, $1F, $0B, $0E, $1E, $0B, $1C, $13. But your pattern is correct (and matches the other two pattern), so we will fix that.

 

The UI bug is known and will be fixed soon.

 

Alternatively you can use the commandline (see doc).

[+Karl G]

47 minutes ago, Thomas Jentzsch said:

You got it almost right, currently it is $1B, $1F, $0B, $0E, $1E, $0B, $1C, $13. But your pattern is correct (and matches the other two pattern), so we will fix that.

 

The UI bug is known and will be fixed soon.

 

Alternatively you can use the commandline (see doc).

Thanks - that worked!

 

Does anyone know the correct number of cycles that one needs to wait after setting/clearing bit7 in VBLANK to reliably read from the correct port? The docs say a full scanline, but I needed to strobe WSYNC 3 times before it would work smoothly for me in Stella. Is Stella being too conservative here, or do the docs need to be updated to indicate a longer wait that is needed?

[gauauu]

5 hours ago, Thomas Jentzsch said:

• full QuadTari: 'QUADTARI'
• left port only QuadTari: 'QUADL'
• right port only QuadTari: 'QUADR'

Whoa, I didn't realize that was there!  That's amazing (and I'll add it to the docs)

 

53 minutes ago, Thomas Jentzsch said:

Alternatively you can use the commandline (see doc)

(the incantation I use is this)

stella mygame.bin -lc Quadtari -rc Quadtari

 

15 hours ago, Karl G said:

The development guide says to wait a full 76 cycles before reading the ports after setting or clearing bit 7 of VBLANK, but I had to strobe WSYNC 3 times before Stella would accept my input smoothly. Is the document in error, or is the emulation incorrect in this case?

We never worked out an EXACT timing for how long it takes the multiplexor to reliably change...I imagine I'll be updating the docs for awhile as we tweak it. The document might very well be in error. I'll check my test cases and get back to you.

[gauauu]

Also...I just yesterday received the last shipment of parts to start assembling the QTs in earnest. I'll bump you to the top of the list and get yours in the mail to you today since you're doing development on it ?

[+Karl G]

1 minute ago, gauauu said:

Also...I just yesterday received the last shipment of parts to start assembling the QTs in earnest. I'll bump you to the top of the list and get yours in the mail to you today since you're doing development on it ?

Thanks! No promises that I'll actually do anything interesting or fun, but I might. My goal at the moment is to have a bare-bones reference example for batari Basic (and maybe 7800Basic as well if nobody beats me to it).

[+johnnywc]

12 minutes ago, Karl G said:

 

Does anyone know the correct number of cycles that one needs to wait after setting/clearing bit7 in VBLANK to reliably read from the correct port? The docs say a full scanline, but I needed to strobe WSYNC 3 times before it would work smoothly for me in Stella. Is Stella being too conservative here, or do the docs need to be updated to indicate a longer wait that is needed?

Hi Karl,

 

In my testing, I was able to get reliable readings on real hardware using 21 cycles between reads, so perhaps Stella is being too conservative.  That 21 cycle limit can probably be smaller; I checked the timings of the multiplexer we're using and the switching can occur in less than 1 CPU cycle in theory, but we bumped it up to 1 scanline to take into account any propagation delays with other chips, the cable, etc.  

 

I thought TJ had set the threshold to 1 scanline; if you're not getting reliable readings with less than 3 WSYNCs perhaps it's a change that needs to be done in Stella.

 

Hope this helps!

John

Edited February 4, 2021 by johnnywc

[Thomas Jentzsch]

10 minutes ago, Karl G said:

Thanks - that worked!

 

Does anyone know the correct number of cycles that one needs to wait after setting/clearing bit7 in VBLANK to reliably read from the correct port? The docs say a full scanline, but I needed to strobe WSYNC 3 times before it would work smoothly for me in Stella. Is Stella being too conservative here, or do the docs need to be updated to indicate a longer wait that is needed?

Stella has a wait time of 1 scanline (76 cycles) implemented. We found this number to be safe after some experimenting. Not sure why you need multiple scanlines here.

[+Karl G]

7 minutes ago, Thomas Jentzsch said:

Stella has a wait time of 1 scanline (76 cycles) implemented. We found this number to be safe after some experimenting. Not sure why you need multiple scanlines here.

Me either. Can you see anything that I might be doing wrong looking at the generated ASM?  I put the labels "Frame0" and "Frame1" before the sections where I set VBLANK and do the WSYNCs. If I do 1 WSYNC, the input is choppy, and sometimes the wrong controlled is selected. If I do two WSYNCs, the input is choppy, but the correct controller is selected when it does work. It takes 3 WSYNCs before it is smooth and reliable. Here's the relevant ASM from a version where I only strobe WSYNC twice, and the input is choppy:

 

.Frame1
 ; Frame1

.L058 ;  VBLANK = 130

	LDA #130
	STA VBLANK
.L059 ;  WSYNC = 0

	LDA #0
	STA WSYNC
.L060 ;  WSYNC = 0

	LDA #0
	STA WSYNC
.
 ; 

.L061 ;  if !joy0up  &&  !joy0right  &&  !joy0down  &&  !joy0left then Player2Direction  =  0  :  goto ____end_p2_direction

 lda #$10
 bit SWCHA
	BEQ .skipL061
.condpart19
 bit SWCHA
	BPL .skip19then
.condpart20
 lda #$20
 bit SWCHA
	BEQ .skip20then
.condpart21
 bit SWCHA
	BVC .skip21then
.condpart22
	LDA #0
	STA Player2Direction
 jmp .____end_p2_direction

chaser.bas.asm

 

[Thomas Jentzsch]

I cannot see "Frame0", but I can only see one full WSYNC after setting VBLANK in your code.

[+Karl G]

15 minutes ago, Thomas Jentzsch said:

I cannot see "Frame0", but I can only see one full WSYNC after setting VBLANK in your code.

It's actually ".Frame0" since bB prepends "." to labels that are in Basic code, but it's in the ASM file I posted. There's more than one VBLANK, since VBLANK is enabled before executing any Basic code (which runs in overscan). I set VBLANK to 2 during even frames (redundantly, I guess), and I set VBLANK to 130 on odd frames, and I have two WSYNCs after each. Here's the relevant snipped from Frame0:

 

.Frame0
 ; Frame0

.L041 ;  VBLANK = 2

	LDA #2
	STA VBLANK
.L042 ;  WSYNC = 0

	LDA #0
	STA WSYNC
.L043 ;  WSYNC = 0

	LDA #0
	STA WSYNC
.
 ; 

.L044 ;  if !joy0up  &&  !joy0right  &&  !joy0down  &&  !joy0left then Player0Direction  =  0  :  goto ____end_p0_direction

 lda #$10
 bit SWCHA
	BEQ .skipL044
.condpart3
 bit SWCHA
	BPL .skip3then
.condpart4
 lda #$20
 bit SWCHA
	BEQ .skip4then
.condpart5
 bit SWCHA
	BVC .skip5then
.condpart6
	LDA #0
	STA Player0Direction
 jmp .____end_p0_direction

 

[Thomas Jentzsch]

Your first WSYNC is not a full WSYNC. It can be anything between 3 and 76 cycles. So you need at least two WSYNCs. 

 

Can you describe the choppyness you experience with two WSYNCs? Or post a bin?

[+Karl G]

6 minutes ago, Thomas Jentzsch said:

Your first WSYNC is not a full WSYNC. It can be anything between 3 and 76 cycles. So you need at least two WSYNCs. 

 

Can you describe the choppyness you experience with two WSYNCs? Or post a bin?

Right - I figured that two would be needed to ensure enough cycles have passed. I'm attaching a zip that includes source and bin from a version with two WSYNCs, but by choppiness, I mean that the movement happens in the correct direction, but it starts and stops intermittently. This is with Stella 6.5.1 on MacOS.

 

chaser.zip