Jump to content

fdr4prez

+AtariAge Subscriber
  • Content Count

    3,811
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by fdr4prez


  1. For Brik180, an interesting concept for a two player version would have the each player controlling the bat on their side (like pong).  After the ball bounces off of your bat, then you collect the points from the bricks that the ball touches.  When the ball bounces off of the other player's bat then he'll collect points for bricks


  2. 54 minutes ago, Steve Jones said:

    Very cool so far, my only request is can you map Punch to both lower controller buttons, the way I hold mine I typically press the ones on the right side.

     

    Thanks for this.

    image.thumb.png.3bd27f812c2486293fb86aeb42380f15.png

     

    Watch out :omfg: 

     

    it looks like there's someone hiding behind your computer:peep:

     

    :screwed:

     

     

    :rofl1:

     

    • Haha 2

  3. 20 hours ago, intvnut said:

    At least the part about a row with no trees has been confirmed.  (The checkerboard bits are "tall grass", exposed by a ROM patch.)

    autorace_loop.gif.2a8c8d19b7750fde84a61770dcef25a6.gif

    I recall doing this as a kid in the '80s

     

    i don't remember the tall grass, but it has been a very long time.

     

    Maybe there is more than one endless path?


  4. 25 minutes ago, cmart604 said:

    Rev if you had been following the Amico threads you would have remembered that I gave Tommy the great idea to dress @nurmix up in a furry suit to deliver all the Founder's Editions. I think that's an idea we can all get behind. 

    And don't forget the Tommy's post that if there is more than one founder in any given area then they will host a furry party so the delivery will be the center of attention 

    • Like 1
    • Haha 1

  5. 22 minutes ago, intvnut said:

    I did some digging around, and it appears there's a Python evdev library that provides a UInput interface similar to what you're already unit for injecting events:

    https://python-evdev.readthedocs.io/en/latest/tutorial.html#injecting-input

     

    Thanks, I will look into this.

     

    There is Retrogame that is a GPIO > Keyboard event module available, and makes note on how to make it compatible with SDL2, but it doesn't support the short-press event and the long-press event that i do in my scripts.  So I have at least something else that i can look into to try and mimic what they do.

     

    luckily for now, there isn't a big rush for me to get this completed :) 

     

    22 minutes ago, intvnut said:

    That's what I was hoping to enable, even if it doesn't make sense for the "UFB" type builds.  For example, a dedicated Intellivision-only build. 

    I know of an AA member that is doing an Intellivision only build and he is using an old 2609 console for his build.  I will reach out to him to see where he is at in this build.  If he hasn't purchased adapters, yet, then he may also be willing to try this with the GPIO

     

    22 minutes ago, intvnut said:

    I don't have support for GPIO input events, per se.  But, if you can map GPIO events to keys, then you can bind those keys directly to controller pad bits.  There are 8 input bits for each controller:  PD0L_BIT_[0-7], PD0R_BIT_[0-7], PD1L_BIT_[0-7], and PD1R_BIT_[0-7].  That's enough to get you raw controller pad support.

     

    I have an example kbdhackfile that maps the upper buttons of a suitably-updated Retronic USB adaptor directly to the raw controller pad bits here (also under doc/jzintv/ in the downloads):  http://spatula-city.org/~im14u2c/intv/jzintv/doc/jzintv/retronic-usb-raw.kbd

     

    It looks like, for example, the current Python uinput module supports F13 - F22 input keys, and I'm pretty sure nothing uses them.  So, you could have your GPIO script output F13 - F20 events based on whether those bits read 1 or 0.  "Press" the button for 1, and "Release" the button for 0.  You might want a periodic refresh (e.g. send a redundant "press" or "release") if there's any chance an event could get dropped between your script and jzIntv.  jzIntv's own internal tracking won't care if it gets redundant presses or releases.

    thanks, that all sounds easy enough

     

    22 minutes ago, intvnut said:

    For raw GPIO connections, you'll need a pull-up on the 8 data pins, and to tie the 9th pin to ground.  It looks like gpiozero supports configuring pins as pull-up.

    Yes, I do configure pull_up=True in my scripts

     

    22 minutes ago, intvnut said:

    Note: This doesn't get you raw ECS alphanumeric keyboard and music synth input.  jzIntv needs to be able to drive values out to do that, and to switch ports between input and output.

    No worries for this from me, thanks.


  6. 2 hours ago, PacManPlus said:

    I actually wanted to use the standalone 'stella', but it runs VERY slow on the PiZero.

    Regarding the terminal; nothing comes out there either on the PiZero. :(

    The Pi 2 & 3 worked fine.  I haven't tried 4 yet...

     

    The standalone stella is using SDL1, so the retrogame events should be detectable without doing anything extra.

     

    And since the terminal doesn't display them, then this implies that retrogame isn't running correctly.

     

    You may be able to go to Adafruit's forum and see if there are any posts with similar issues.

     

    What are you connecting to the GPIO?  And are you planning to use only the standalone stella?


  7. 2 hours ago, PacManPlus said:

    I actually wanted to use the standalone 'stella', but it runs VERY slow on the PiZero.

    Regarding the terminal; nothing comes out there either on the PiZero. :(

    The Pi 2 & 3 worked fine.  I haven't tried 4 yet...

     

    Thank you for helping...

     

    I used quite a few Pi0 with the standalone stella - see my Ultimate Atari Joystick

     

    I have not seen any slowdown in any of these that I've built.  I've built about a dozen, but that was some time ago.

     

    There is another AA member that has recently complained about Stella running slow on Pi0 and I built a new image using the latest RetroPie and I did not see any issue.

     

    If there is a documentable issue with the standalone stella, then please go the RetroPie Forum and request them to fix it.  

     

    The version used with RetroPie is made and maintained by those guys, and not by the coders of Stella themselves.


  8. 56 minutes ago, intvnut said:

    I also have corresponding "raw" actions now, so in theory you really could directly wire Intellivision controller bits to GPIOs.  If the wiring is more complicated, that could get challenging.


    I am interested in testing this.

     

    There are only 9 wires in the controller, so it should be easy enough to connect them to the GPIO header.

     

    If I recall, the current RetroPie release is using your jzintv-20181225 release, so is this gpio support added in that version?

     

    Is there a document for how to implement this?  What controller wire goes to what GPIO pin?  How do you configure that set of GPIO to be left or right controller?

     

    I can definitely test this with a Pi and if it works, then I can rebuild my Ultimate Intellivision Controller to use the GPIO for its main input, and then I can use its existing Raphnet adapter to have a DB9 pigtail and it will now be 2-player compatible.  Or wire the player DB9 directly to the GPIO, too, and the Raphnet won't be needed at all... oh boy, this is exciting :wings:

     

    My Pi2 and Pi3 are inside Flashback units right now, but I have a handful of Pi0 that i can easily test this on.


  9. 18 minutes ago, intvnut said:

    Perhaps I could build a direct interface to GPIO so we can retire your Python scripts?  Do your GPIO scripts perform any translation / mapping, or do they mostly just detect GPIO changes and reinsert them as events picked up by SDL1?  That is, what degree of matching and translation do you do?

     

    Do you know offhand how Python accesses the GPIO?  Is it through pigpio, WiringPi, or something else?

     

    When I looked before, it looked like most documentation focused on using some high level libraries or Python.  I have no problem directly mangling the GPIO myself, or consuming GPIO from a commonly-loaded daemon (as pigpio does), or opening a pipe to a Python script (so it can just print the events to me), or whatever.

     

    Biggest challenge:  I'm not really set up to test this.  Would you be willing to test what I build?  I can easily add a bunch of general purpose GPIO events to the event table, and provide platform-specific modules where it makes sense.  

     

    My script(s) is for monitoring the button(s) on the various Flashback shells.

     

    For Intv and CoolCV I am using a python script using the gpiozero library.

     

    For the Intv and Coleco Flashback console shells, there is only a single Reset button on it.  So my script will do a "F12" keypress for a quick press of that Reset button, and the script will do a "F1" on a long hold-down of the Reset button.  So a quick press will reset the game and a long press will do a quit game.  Since the Inty FB shell only has one button, I make the most out of that single button for the user.

    reset - jzintv.txt

     

    My CoolCV script is exactly the same, but uses those particular default keypresses for that emulator's reset and quit.

     

    If someone wants to use jzintv and coolcv at the same time, then I would either change my script accordingly to work with both.  Or remap the emulator settings so both emulators work with the same for the reset and quit events in the script.

     

    My Atari 2600 script doesn't use gpiozero and is completely different, but conceptually the same.  The Atari FB shell has many switches and buttons, and some are latching and some are momentary, so all that is taken into consideration in my Atari script.

     

    And if someone wants to use jzintv, stella and coolcv all in the same FB shell, then I'd recommend to use an Atari FB shell due to the needed Atari console buttons/switches and I will map jzintv and coolcv accordingly so all three emulators work off of the same script.

     

    for me, since I am working with a variety of scripts to help out the many AA member's with their flavor of "ultimate" build, i think it would be better for me to get my script "SDL2 compliant" because then my script could be used with the other "lr-" emulators used in RetroPie

     


  10. 46 minutes ago, Humblejack said:

     

    Please don't think bad of me but I keep my Intellivision Sears and Atari Sears in the same storage envelope. I hope they never co-mingle. I hate to think what the offspring would be.

    They are making some of their own green memories.

     

    extra credit to anyone that knows where that reference is from


  11. 34 minutes ago, PacManPlus said:

    That was the first thing I did :( :

     

    Ah, it seems I missed that part of you original post.

     

    I've never used retrogame

     

    I do have a little python script that I use for GPIO button detection and it will "uinput" keyboard presses into the system, but it isn't SDL2 compatible, so it doesn't work with the "lr-" emulators.

     

    For the RetroPie emulators that I use (jzintv, standalone stella, and coolcv) my script works good for GPIO button detection.

     

    That being said, when I press F4 to get to to the terminal, I am able to press the GPIO buttons and those "keyboard" presses will be displayed in the terminal.  

     

    On your other Pi2 that you say works good, do the retrogame GPIO button detection get displayed in the terminal?  Do you see the same results in the Pi0?


  12. I fear that the SDL2 build will not accept the GPIO script inputs that I've created for the Pi used in the "ultimate" flashback rebuilds.

     

    I've seen this bandied about in my google searches when I first started development of my GPIO python script:

     

    SDL2 applications depend on evdev for input events. Specifically this means applications like the latest version of RetroPie and EmulationStation won't be able to see key events generated by a python script.

     

    Which I forewarn people that using my GPIO script in RetroPie that jzintv, standalone Stella and CoolCV will work with my script, but none of the "lr-" emulators that have been updated to SDL2 will detect the GPIO events generated by my script.

     

    I am going to need to do more research on how to get my little script to work correctly for SDL2.  It seems that I basically need it be recognized as a virtual keyboard instead of just pushing uinput data out into the system.


  13. 11 hours ago, RevEng said:

    I don't really have specific knowledge here, but I do know the gpio layout for RPi2 is different than zero. Have you adjusted for the new layout?

    sorry, that is not correct.

     

    Pi0 uses the same header pinout as the Pi2 and Pi3

     

    It is the Pi1 that is different (it is shorter, so less pins)

    • Thanks 1

  14. 2 hours ago, PacManPlus said:

    Yep, and I did a 'ps -ef | grep retrogame' to make sure it was in the process list.

    Did you try this, from its github page

    https://github.com/adafruit/Adafruit-Retrogame

     

    RetroPie 2.0+ Compatibility

    Note that by default retrogame won't work with SDL2 applications that depend on evdev for input events. Specifically this means applications like the latest version of RetroPie and EmulationStation won't be able to see key events generated by retrogame. However you can fix this issue by adding a small custom udev rule to make retrogame keyboard events visible to SDL2.

    Connect to your Raspberry Pi in a terminal/SSH session and execute the following command to create and edit the file /etc/udev/rules.d/10-retrogame.rules:

    sudo nano /etc/udev/rules.d/10-retrogame.rules
    

    Once the nano text editor loads, copy this single line into the file:

    SUBSYSTEM=="input", ATTRS{name}=="retrogame", ENV{ID_INPUT_KEYBOARD}="1"
    

    Save the file by pressing Ctrl-O and enter, then press Ctrl-x to exit. Restart your Raspberry Pi and run retrogame again, now button presses should register in SDL2 applications like the EmulationStation frontend to RetroPie


  15. 4 minutes ago, colormesticky said:

    Also try explaining "I'm gonna go hang out with a bunch of strange men in Vegas for a few days" to my husband, lol.

    No need to call us strange unless he asks 

     

    Call us "old Intellivision buddies getting together to relive/rehash the good old days of yesteryear", and then if he asks "are they strange", then you can reply with "yes, they are strange, but in a friendly, non-threatening, way"

     

    Or as Douglas Adams puts it - Mostly Harmless

     

    Plus, no reason why he can't join the fun

    :pirates:

    • Like 3
×
×
  • Create New...