QuadTari 7800Basic code demo

[+Karl G]

I had previously tried to make a QT code demo for 7800Basic with my raindrops minigame, but this was more complex than it needed to be for a code demo, and was also missing joystick button support because I couldn't get that to work. It is now working with the help of a code sample from @RevEng. Here is a simple demo with four emojis that can be moved with the joystick, and made to smile with the fire button. I just thought I'd share it in case anyone else wanted to try making a four-player joystick game for the 7800.

 

qtdemo.zip

[+Gemintronic]

Thank you (and RevEng) once again!

 

I really want to focus on the 7800 now.. but, I need to make something Quadtari which is mostly 2600 oriented.  This is (literally) a game changer!

[+SmittyB]

Where were you a week ago when I was trying to figure out the Quadtari? 😁 

 

I'm curious as to why you're checking the fire button bits directly instead of using the basic command as I've not found that to be necessary. Admittedly I don't have a Quadtari to test with and have been relying on @brpocock generously donating their time.

Knowing that 8 wsyncs is enough of a delay for consistent reading is interesting because for some games it should then be possible to read all ports each frame instead of alternating.

 

Thanks for the example code. There's surprisingly little information about the Quadtari that I could find and what there was contradicted itself so even though supporting it is very simple, understanding what was needed to get it going was not. I hope having some examples to work from will encourage others to give it a go.

[+Karl G]

43 minutes ago, SmittyB said:

Where were you a week ago when I was trying to figure out the Quadtari? 😁

I was working on figuring out the Quadtari! 

 

43 minutes ago, SmittyB said:

I'm curious as to why you're checking the fire button bits directly instead of using the basic command as I've not found that to be necessary.

It didn't work correctly for me in my raindrops demo using the joyXfire or joyXfire1 commands. I double-checked just now swapping in these commands for this demo, but it also didn't work here. More specifically, one pair of joysticks always register as having the button pressed.

 

43 minutes ago, SmittyB said:

Admittedly I don't have a Quadtari to test with and have been relying on @brpocock generously donating their time.

Well, I have my QT out and connected to my 7800 currently, so I'd be happy to help with any testing you need as well.

 

43 minutes ago, SmittyB said:

Knowing that 8 wsyncs is enough of a delay for consistent reading is interesting because for some games it should then be possible to read all ports each frame instead of alternating.

I'm not a hardware guy, but based on discussion on the Hardware forum, it seems like the amount of delay time might vary a little from unit to unit (different batches/suppliers of parts when making a QT). If so, mine seems to be one of the slower ones. No less than 8 WSYNCs were needed, which seems to be more than was expected. I've not seem anyone try to read both pairs of controllers in one frame, and I don't know if this is feasible or not. But, again, I'm willing to test if needed.

 

43 minutes ago, SmittyB said:

Thanks for the example code. There's surprisingly little information about the Quadtari that I could find and what there was contradicted itself so even though supporting it is very simple, understanding what was needed to get it going was not. I hope having some examples to work from will encourage others to give it a go.

That's what I was hoping as well! I think the 7800 is a great platform for the QT due to its sprite capabilities.

[RevEng]

I'm having a lightbulb momement... When you test for joyXfire in your game, 7800basic tests against fire-button state variables, rather than INPT1 or INPT2 directly. Every frame, the registers get polled and those variables get updated.

 

The reason behind that is the firebuttons are virtualized. i.e. devices, like mice and paddles, still cause joyXfire signals, despite being wired differently than joysticks. The end goal for this is to make the game's controller handling code simpler.

 

So every other frame should work with joyXfire and QuadTari, for now. Or work with the registers directly, as you have.

[+Karl G]

On 7/12/2023 at 3:39 PM, RevEng said:

I'm having a lightbulb momement... When you test for joyXfire in your game, 7800basic tests against fire-button state variables, rather than INPT1 or INPT2 directly. Every frame, the registers get polled and those variables get updated.

So presumably using those would end up reflecting their state in the previous frame, I suppose. That doesn't exactly match what I am seeing when I try to use them, however. When during the frame are these variables updated, then? 

[RevEng]

1 hour ago, Karl G said:

So presumably using those would end up reflecting their state in the previous frame, I suppose. That doesn't exactly match what I am seeing when I try to use them, however. When during the frame are these variables updated, then? 

The majority of the 7800basic frame-based housekeeping happens after the top of the visible screen, via a display interrupt. There's a few things that happen before the fire-button reading, like the user's top-screen routine, any long controller reads, sound effect servicing, and any music tracker servicing. So the exact screen position depends on what options you've enabled.

 

In terms of your program flow, it should happen "right" after drawscreen.