27 replies to this topic

[PacManPlus]

Hi guys:

Does anyone have any alternate examples of reading the paddles and/or the driving controllers on the 7800? I have the tech demo (I think it's Eric's) and have attached it here. It seems to work fine, as long as there is *nothing* else going on (nothing else on the screen, etc.) which unfortunately doesn't help me with what I am working on.
I have also done a search for code on reading the Driving Controllers but came up empty.

I am moving an object back and forth along the bottom of the screen (like 'Breakout') and right now I am using the joystick, which doesn't feel right.

Thanks,
Bob

[DEBRO]

Hi Bob,

PacManPlus, on Mon Jul 26, 2010 5:20 AM, said:

Does anyone have any alternate examples of reading the paddles and/or the driving controllers on the 7800? I have the tech demo (I think it's Eric's) and have attached it here. It seems to work fine, as long as there is *nothing* else going on (nothing else on the screen, etc.) which unfortunately doesn't help me with what I am working on.
I have also done a search for code on reading the Driving Controllers but came up empty.

I am moving an object back and forth along the bottom of the screen (like 'Breakout') and right now I am using the joystick, which doesn't feel right.

As you know I never finished my work but it seems reading these controllers would be similar to the 2600. I've never worked with the driving controller but there are threads on this on [stella] that can get you going.

My design with the paddle controller was to do a DLI at the start of the display that ran the entire screen. Once I reached 200 scanlines then I would know I could start VBLANK because I controlled nothing would display after 200 scan lines.

DisplayKernel
   ldy #200
.kernelLoop
   sta WSYNC
   lda INPT0
   bmi .nextScanLine
   sty paddleVertPos
.nextScanLine
   dey
   bne .kernelLoop

VerticalBlank
   lda #$80
   sta PTCTRL                       ; discharge paddle potentiometer
   inc frameCount                   ; increment frame count each frame

I believe this is similar to how Breakout and Kaboom! do their paddle processing but it has been a long time.

I hope this helps.

[Bruce Tomlin]

The problem is that (again just like the 2600), the full range of the paddles lasts for up to two frames worth of video (hence why most or all games only use half the paddle turn range). The original way they were used was simply to watch for the trigger to hit as you went down the screen for a pong game.

The best way might be a hsync interrupt in each line (or every 2 or 4 or 8 lines if you need less precision), but whatever you do it will probably eat up some CPU time.

Compared to this, driving controllers are much easier to read.

[PacManPlus]

Thanks Bruce...

I actually tried using the Driving Controllers, but I have a different issue with them; they turn fine (I and I did get them to move the object) slowly, but if you make an abrupt twist it either doesn't move at all or goes in the opposite direction.

Originally I wanted to have all three controllers as an option, but I guess I might be sticking to the joystick.

Thanks,
Bob

[jaybird3rd]

It's such a pity that paddles are so difficult to use with the 7800. There are so many excellent paddle-based games that the 7800 could do so well.

One idea I've had for getting around this problem is a "paddle adapter" built around an A-D converter, which would convert the paddle resistances into numbers in much the same way that POKEY does in the 400/800 computers. The numbers could then be read through the 7800's joystick port. Are A-D converters cheap enough now to make such an adapter feasible? Which one(s) would be best suited for this?

[Bruce Tomlin]

PacManPlus, on Tue Jul 27, 2010 1:42 PM, said:

I actually tried using the Driving Controllers, but I have a different issue with them; they turn fine (I and I did get them to move the object) slowly, but if you make an abrupt twist it either doesn't move at all or goes in the opposite direction.

That would be because you're not sampling fast enough. Apparently 60 times per second isn't enough, even with the coarseness of the control.

Just add in some hsync interrupts to check it more often.

[DEBRO]

Hi there,

Bruce Tomlin, on Tue Jul 27, 2010 5:16 PM, said:

PacManPlus, on Tue Jul 27, 2010 1:42 PM, said:

I actually tried using the Driving Controllers, but I have a different issue with them; they turn fine (I and I did get them to move the object) slowly, but if you make an abrupt twist it either doesn't move at all or goes in the opposite direction.

That would be because you're not sampling fast enough. Apparently 60 times per second isn't enough, even with the coarseness of the control.

Just add in some hsync interrupts to check it more often.

I'm curious (and have only briefly experimented with the 7800). What would the benefit of having multiple interrupts instead of one at the beginning of the display? I thought you would have more control over having one at the beginning of the display so you could check every scanline vs. every zone. Does the WSYNC zap that much from MARIA? Again, I'm just curious.

[GroovyBee]

The problem with the 7800 and polling ports on a per scan line basis is that MARIA eats into the CPU time available. With a complex display there aren't many CPU cycles available on the video line.

[GroovyBee]

jaybird3rd, on Tue Jul 27, 2010 2:41 PM, said:

Are A-D converters cheap enough now to make such an adapter feasible?

You don't need an A2D. It could be done with a comparator and a timer. Pretty much the same way the 2600 does it normally. This gets the problem into the realm of cheap microcontrollers. Then you get the ability to read data out of it serially too.

[DEBRO]

Hi there,

GroovyBee, on Wed Jul 28, 2010 4:29 AM, said:

The problem with the 7800 and polling ports on a per scan line basis is that MARIA eats into the CPU time available. With a complex display there aren't many CPU cycles available on the video line.

Really?! The above routine takes at most 13 cycles to read one paddle. Would MARIA eat up that much?

[GroovyBee]

DEBRO, on Wed Jul 28, 2010 6:06 AM, said:

Really?! The above routine takes at most 13 cycles to read one paddle. Would MARIA eat up that much?

Yep! For a very complex 2BPP display MARIA cycles can be at 390 or so, which doesn't leave very much CPU time.

To be pedantic your routine takes 13.5 because there is the addition of a half a clock cycle for the INPT0 read due to PHI2 being reduced to 2600 clock speed for the TIA register read.

I've been trying to help Bob and even moving the code into a DLI with a tight loop (no loop end condition checking) and thus a second DLI to terminate the code by adjusting the program counter on the stack its still erratic .

It does warrant further investigation but I don't have the time at the moment. CGE is looming large on the horizon .

[Bruce Tomlin]

DEBRO, on Wed Jul 28, 2010 4:21 AM, said:

I'm curious (and have only briefly experimented with the 7800). What would the benefit of having multiple interrupts instead of one at the beginning of the display? I thought you would have more control over having one at the beginning of the display so you could check every scanline vs. every zone. Does the WSYNC zap that much from MARIA? Again, I'm just curious.

First, I was specifically referring to the driving controller.

Basically, it's a quadrature encoding controller (just like in a trackball or ball mouse), and if you don't read it fast enough it won't work right. The original Macintosh used an interrupt line whenever one of the signals changed and it didn't work right during floppy disk access (when interrupts were disabled).

The Driving Controller can't use interrupts, so you have to poll it fast enough to detect fast motion properly. If you only check it once per frame, that's 60 times per second. If you have one hblank interrupt in the middle of the screen, that gives you 120 times per second. If you have three hblank interrupts spread across the screen, that gives you 240 times per second. The more often you check it, the better it responds to fast motion.

And if you haven't already guessed, the real-time nature of the paddle inputs is why they are hard to use in 7800 mode. The 2600 doesn't have a problem because the game code is involved in each and every scanline, and it takes very little time to check the paddles in every or every other scan line.

[EricBall]

PacManPlus, on Mon Jul 26, 2010 5:20 AM, said:

Hi guys:Does anyone have any alternate examples of reading the paddles and/or the driving controllers on the 7800? I have the tech demo (I think it's Eric's) and have attached it here. It seems to work fine, as long as there is *nothing* else going on (nothing else on the screen, etc.) which unfortunately doesn't help me with what I am working on.I have also done a search for code on reading the Driving Controllers but came up empty.I am moving an object back and forth along the bottom of the screen (like 'Breakout') and right now I am using the joystick, which doesn't feel right.Thanks,Bob

Hmm... I can't think of a more efficient way to read the paddles than presented. Are you sure the problem is MARIA DMA? You should have (113.5 - 15.5 ) * 4 = 392 clock cycles per line to play with.

I think I also did some 7800 sample code for driving controllers. Those worked better sampling per zone IIRC. Yep, see: my blog May 10, 2005

Bruce Tomlin, on Mon Jul 26, 2010 3:40 PM, said:

The problem is that (again just like the 2600), the full range of the paddles lasts for up to two frames worth of video (hence why most or all games only use half the paddle turn range). The original way they were used was simply to watch for the trigger to hit as you went down the screen for a pong game.The best way might be a hsync interrupt in each line (or every 2 or 4 or 8 lines if you need less precision), but whatever you do it will probably eat up some CPU time.Compared to this, driving controllers are much easier to read.

The problem with doing the paddle reads via a DLI is resolution. With standard 8 line zones you only get 200/8 = 25 positions. Smaller zones give you more resolution but require more work outside of the display since each sprite requires multiple DL updates. Smaller zones also means less CPU time per zone, which is the problem Bob is having.

Starting the paddle capacitor charging at the end of the frame would shift the paddle to the center.

Edited by EricBall, Wed Jul 28, 2010 2:42 PM.

[EricBall]

My bad, that's (113.5 - 16.5) * 4 = 388 MARIA cycles per line.

[Rybags]

For paddles, how about an algorithm where:

. Frame 1 - do the coarse read, at 8 scanline or <whatever> resolution, giving the general vicinity of what the Pot value would be.

. Frame 2 - with knowledge of what the approximate Pot value is, do a fine test per scanline for the +- 8 or so as determinted previously.

Of course, that means you'll lose that bunch of cycles that might otherwise be critical, at practically any part of the screen. And, it mightn't work so well if the user is moving the paddle quickly.

[PacManPlus]

Thanks for the input, everyone. I'm going to give these suggestions a try.

Bob

[PacManPlus]

Hi guys:

I tried just about everything mentioned, but with 12 zones (each 16 high) it doesn't look like there is a way to read the paddles completely.
It sounds like I may have to drop paddle support from this game... Which is a shame as the 2600 version of what I am working on used the paddles.

Thanks for your help,
Bob

[kenfused]

PacManPlus, on Mon Aug 9, 2010 4:22 AM, said:

Hi guys:

I tried just about everything mentioned, but with 12 zones (each 16 high) it doesn't look like there is a way to read the paddles completely.
It sounds like I may have to drop paddle support from this game... Which is a shame as the 2600 version of what I am working on used the paddles.

Thanks for your help,
Bob

(1) Maybe Curt needs to put a paddle port on the expansion module and let POKEY do the paddle reading? (2) Maybe a POKEY IRQ interrupt could be used on the expansion module to aid in reading the paddles? (ballblazer carts don't connect it to try a test, don't know if the CC2 does in its POKEY mapper/startup files). (3) Only things I can think of is use a lot smaller zones. This means more memory for DL's and DL's, and more cpu time building them, and more maria time reading them.

Were you able to get driving controllers to work? I would think they could be read a lot less frequently.

[PacManPlus]

Hey Ken -

I did get the driving controllers to work, although to me they are too slow. I need to find places to sample them more often (in addition to each DLI - which is only 12 times per frame).

Thanks!
Bob

[EricBall]

Note: don't use WSYNC outside of the DLI, if you have a DLI.

[GroovyBee]

EricBall, on Wed Aug 11, 2010 11:38 AM, said:

Note: don't use WSYNC outside of the DLI, if you have a DLI.

The only time I use WSYNC outside a DLI is for PAL/NTSC detection.

[DEBRO]

Hi there,

I was working with Bob and hacked a kernel in his code. He tested it though and it crashes. I wonder if I missed something in his code. I'd test this while making code changes but it seems both of my 7800s died. They no longer power up

[DEBRO]

Hi there,

DEBRO, on Wed Aug 11, 2010 6:30 PM, said:

Hi there,

I was working with Bob and hacked a kernel in his code. He tested it though and it crashes. I wonder if I missed something in his code. I'd test this while making code changes but it seems both of my 7800s died. They no longer power up

I was able to get the 7800 working and I tested my original paddle kernel test from a couple of years ago and it works. There needs to be some tweaking to stop the jitter but that shouldn't take much. I have confidence that this will work for Bob too. I must be missing a jump some where that is causing the crash.

[PacManPlus]

Dennis - your demo worked!

I would like to know how you did your DL/DLL, etc. please so I can try and duplicate it.

Thanks!
Bob

[Nukey Shay]

Couldn't you AND the low bit off the value to eliminate jitter? Lowers resolution by every other pixel tho, I know...but it's a workaround if there's no other way.