Jump to content

Photo

How to integrate single paddle asm code into bB?


13 replies to this topic

#1 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,854 posts

Posted Tue Mar 18, 2014 7:45 AM

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?



#2 bogax OFFLINE  

bogax

    Dragonstomper

  • 724 posts

Posted Tue Mar 18, 2014 1:57 PM

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
 



#3 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • Topic Starter
  • 8,854 posts

Posted Tue Mar 18, 2014 2:12 PM

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.



#4 RevEng ONLINE  

RevEng

    River Patroller

  • 4,722 posts
  • Bitnik
  • Location:Canada

Posted Tue Mar 18, 2014 2:25 PM

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.

#5 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • Topic Starter
  • 8,854 posts

Posted Tue Mar 18, 2014 2:30 PM

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.



#6 RevEng ONLINE  

RevEng

    River Patroller

  • 4,722 posts
  • Bitnik
  • Location:Canada

Posted Tue Mar 18, 2014 8:07 PM

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 by RevEng, Wed Mar 19, 2014 3:16 PM.


#7 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • Topic Starter
  • 8,854 posts

Posted Wed Mar 19, 2014 10:58 AM

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

 

pfcolpad.bas.bin.png

 

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.



#8 RevEng ONLINE  

RevEng

    River Patroller

  • 4,722 posts
  • Bitnik
  • Location:Canada

Posted Wed Mar 19, 2014 11:42 AM

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)

Attached File  std_kernel.asm   17.81KB   50 downloads

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

Edited by RevEng, Wed Mar 19, 2014 11:44 AM.


#9 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • Topic Starter
  • 8,854 posts

Posted Wed Mar 19, 2014 11:53 AM

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)

attachicon.gifstd_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!! =)



#10 RevEng ONLINE  

RevEng

    River Patroller

  • 4,722 posts
  • Bitnik
  • Location:Canada

Posted Wed Mar 19, 2014 11:56 AM

Excellent!

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

Edited by RevEng, Wed Mar 19, 2014 11:56 AM.


#11 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • Topic Starter
  • 8,854 posts

Posted Wed Mar 19, 2014 11:59 AM

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



#12 RevEng ONLINE  

RevEng

    River Patroller

  • 4,722 posts
  • Bitnik
  • Location:Canada

Posted Wed Mar 19, 2014 12:01 PM

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.

#13 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • Topic Starter
  • 8,854 posts

Posted Thu Mar 20, 2014 7:36 AM

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

 

If anyone cares to extend this further please do!

 

pfcolpad.png

Attached File  pfcolpad2.bin   4KB   57 downloads

Attached File  pfcolpad.zip   7.99KB   47 downloads



#14 RevEng ONLINE  

RevEng

    River Patroller

  • 4,722 posts
  • Bitnik
  • Location:Canada

Posted Sat May 28, 2016 10:19 AM

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

Attached File  pfcolpad2.bas.bin   4KB   22 downloads
Attached File  paddle_minikernel.zip   5.69KB   28 downloads

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!




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users