How to integrate single paddle asm code into bB?

[+Gemintronic]

Thomas Jentzsch posted this code in the Arkanoid 2600 topic:

 

 

 

Most people skip because reading the paddle takes away precious kernel time (minimum 8 out of just 76 cycles ). So when you add paddle support, the game will have to look less impressive. And most people will not know why and probably blame the developer.

 

Here is the minimum code. You have to make sure that the *address* of e.g. paddle1 is an 1 byte opcode, e.g. $ea (nop) or $d8 (cld).

MAC READ_PADDLE_1
lda INPT0 ; 3
bmi .save+1 ; 2/3
.save
sty paddle1 ; 3/2
ENDM

 

 

bBs own readpaddle support sacrifices pfcolors and pfheights which is a needed feature in my paddle game. I'm wondering if this bit of code can allow me to use paddle 1 and still retain the features I need. What kind of setup is needed to actually use this code snippet in bB?

[bogax]

First off I've only read about it
(and played with similar hardware),
but I don't have any real experience
with the 2600

The kernel takes most of the cpu time
drawing the screen.

The paddles are read by watching how
long it takes the paddle to charge
a capacitor.
Judging from the schematics the time
it takes can vary from around one scanline
to two or three frames (drawscreens).
Probably (I'm guessing) it's usually
limited to the time it takes to run the
kernel so anything over that is max ie some
(substantial) fraction of a paddle turn
reads max.
I gather that the the paddle is read
each scanline to see if the capacitor
has charged yet and the usual thing is
to return the time in scanlines.

So you have to shoe horn the paddle read
in to a scanline and the time is so tight
that if you do you'll have to leave out
some other stuff.

I believe 76 is the scanline and 8 is
the minimum paddle read to shoehorn in.

The kernel already is not enough time
to allow for the entire paddle range
and the time bB has is a fraction of that.

The normal thing (I think) is to discharge
the capacitor then see how long it takes
the paddle to charge it.
You could (maybe) work it the other way
around let the capacitor charge and then
see how long it takes to discharge it.
but you probably wouldn't have much
resolution or range.

There's another question in that pots
are generally either log or linear.
I'll assume the paddle pots are linear.
I'll also assume that caps charge/discharge
linearly (not true).

According to the docs/schematics the
pots are 1M ohm and the caps are .068uF
a charge time of one frame/drawscreen
works out to 245k ohm or about a quarter
turn (that sounds like too little
but this is all grossly inaccurate -
first approximation).

If you charge 245k is the maximum or
you run out of time.
if you charge then discharge 245k is
the mininimum, but discharging would
be much faster (which it would have to
be to fit into the time bB has to run)
but also much coarser.

I don't really know what the TIA can do
but if it's NMOS and it's anything like
I'd expect you might only get a resolution
of 5 (or less) for the full useful range
of the paddle.

tldr
you can't use that code in bB
but you might be able to get a crude reading

[+Gemintronic]

Yeah. That pretty much makes the reality of the situation apparent. I guess what I'm looking for is a way to test that code. Not becaue I expect it to work: more as an exercise in integrating and using inline assembly in bB.

 

It seems to me I'd have to DIM some value that his code returns. There must be other gotchas that I'm not thinking about.

[RevEng]

Not sure if its clear, theloon, but the paddle read code posted is supposed to be integrated into a display kernel. It also expects a kernel that keeps the current scanline in Y.

 

bB doesn't track the current scanline as such, and already has similar paddle read code...

 

        ifconst readpaddle
             ldy currentpaddle
             lda INPT0,y
             bpl noreadpaddle
             inc paddle
             jmp continuekernel2

...switching bB's code over to single paddle would gain you about 4 cycles, which isn't enough for the features you want to enable.

[+Gemintronic]

I'd be fine with just pfcolors. The bB kernel only gives you the option of no_blank_lines though. Seems kind of weird with the timing constraints of paddle reading.

[RevEng]

Try this out. I stuck paddle reading code in place of "player1colors" code in the kernel...

 

[removed]

 

Use "set kernel_options player1colors pfcolors" and read the paddle value through the missile1y variable. You'll need to scale the value, just as you would with the regular kernel.

 

You may or may not be able to use other compatible kernel options. I didn't test others than the ones above.

 

Fair warning, its only been tested in stella.

Edited March 19, 2014 by RevEng

[+Gemintronic]

HOLY GORF SNOT THAT WORKED! Er, at least in Stella

 

 

UPDATE: The currentpaddle does not switch which paddle to be read. This makes the kernel mod a single paddle only affair. You seem to lose the topmost row of playfield. Also, the last two columns of playfield are repeated as the first two rows. I can live with that Thanks RevEng!!

 

UPDATE II: playercolors doesn't work but pfheights does.. at least in Stella. If pfheights works then the bricks can look like Arkanoid blocks just fine.

[RevEng]

Try this one. I think I borked the cycle count leading into the kernel, which is likely causing the odd playfield effects.

 

This one also should allow you to choose the paddle with missile1height. (didn't want to bog this hack down with remapping the bB variable locations)

 

std_kernel.asm

 

Let me know how it works out... I can't test it at the moment.

Edited March 19, 2014 by RevEng

[+Gemintronic]

Try this one. I think I borked the cycle count leading into the kernel, which is likely causing the odd playfield effects.

 

This one also should allow you to choose the paddle with missile1height. (didn't want to bog this hack down with remapping the bB variable locations)

 

std_kernel.asm

 

Let me know how it works out... I can't test it at the moment.

 

Looks like the missing row and first/last two columns issues is defeated! missile1height doesn't seem to do anything if not 0. I don't think people are into 2-4 player paddle games though. Not a biggie. This is a huge step forward in itself!! =)

[RevEng]

Excellent!

 

When you changed missile1height to 1, did you test the other stella paddle?

Edited March 19, 2014 by RevEng

[+Gemintronic]

Excellent!

 

When you changed missile1height to 1, did you test the other stella paddle?

 

I tried values 0-3 and also the old bB "currentpaddle" with 0-3

[RevEng]

OK. I know it's not critical for you, but I'll play with it when I get some time. Maybe someone else will want the feature.

[+Gemintronic]

Here is my work using RevEngs generously modified standard kernel. I even put comments in!

 

If anyone cares to extend this further please do!

 

pfcolpad2.bin

pfcolpad.zip

[RevEng]

Here's a "paddle" mini-kernel version of theloon's demo. It draws the paddle graphic without using existing bB objects.

 

pfcolpad2.bas.bin

paddle_minikernel.zip

 

The mini-kernel paddle is drawn with color and graphics data inside paddlemini.asm, which can be modified. You also need to dim a "paddlex" variable, which is used to control the paddle position.

 

Other objects can't cross into the paddlemini.asm area, with the exception of missile0. There's a further modified version of the standard kernel I posted earlier in this thread, included in the zip. It now ensures missile0 can transition smoothly between the kernel and mini-kernel.

 

It's called a "paddle" mini-kernel, but there's no reason it couldn't be used for a space ship or whatever, so long as the game object is constrained to the bottom of the screen.

 

Enjoy!

[ZippyRedPlumber]

On 3/19/2014 at 1:42 PM, RevEng said:

Try this one. I think I borked the cycle count leading into the kernel, which is likely causing the odd playfield effects.

 

This one also should allow you to choose the paddle with missile1height. (didn't want to bog this hack down with remapping the bB variable locations)

 

std_kernel.asm 17.81 kB · 340 downloads

 

Let me know how it works out... I can't test it at the moment.

What's STD Kernel & what does it do?

[RevEng]

It's a hack of the bB standard kernel. Gemintronic wanted playfield colors and paddle reading, but those options aren't available together, so I traded off the "player1colors" code for paddle reading.