Jump to content

madscijr

Members
  • Posts

    43
  • Joined

  • Last visited

Posts posted by madscijr

  1. On 4/20/2006 at 10:09 PM, kisrael said:

    We looked at the original for how they handled player movement...the control part is pretty clever and easy, if the player isn't quite centered when they try to turn a corner, they walk the way they're facing 'til they can make it. I guess making sure the players move at a steady pace while everything else speeds up is more tricky...

    I used to love Crossroads on the C64 - is this remake (or better yet the source code) available online anywhere? 
    I would love to try remaking it for Windows using QB64 or QB64PE... 

  2. On 6/3/2005 at 10:20 AM, COMTARI said:

    What is the easiest program to use to create simple 2600 style games to play on the PC? I've seen game creation software that creates first person shooters and 3d renderings...but I want something more simple, without having to go back and learn a programming language.

     

    I just wanted to try my hand at making my own original 2600 type games for my own use, just for the fun of designing my own games.

     

    I know this is a little late to answer, but perhaps it will help someone searching.

     

    I have found QB64 to be awesome for creating simple Atari style games for the PC. 

    It's simple to set up and get using (the IDE / editor / compiler is just one program), 

    it runs on the latest Windows as well as older machines, 

    the language is basically Microsoft QuickBasic (with some updates to support modern computer features,

    but pretty much backwards-compatible for old QBasic and even GWBasic games), 

    it compiles your program into a standalone EXE, or you can just share your source code, 

    AND it works on Linux and Mac.

    There is an active community and the people are very helpful. 

     

    https://qb64phoenix.com/

    https://en.wikipedia.org/wiki/QB64

     

  3. On 10/7/2007 at 1:44 AM, Rybags said:

    Possible. But, I was of the impression that Spelunker came out on the Atari first.

     

    Another thing: has anyone ever produced a hacked version with different levels?

    I don't know, but if someone would make a level editor that would be awesome.

    • Like 1
  4. On 12/4/2007 at 10:43 PM, pboland said:

    My wife and I use to have a website called www.vglist.com. Well, it is back up and running and while I was going through some old material to update the website I found some interesting pictures. I could not find these on the web. (that is not to say that they don't exist, but I could not find them) So, here you go:

     

    post-9874-1196825905_thumb.jpg

     

    post-9874-1196825916_thumb.jpg

     

    That Atari Tank II is pretty neat, I've never seen that one. What was the product number, any idea? 

    • Like 1
  5. On 10/11/2019 at 8:40 PM, ACML said:

    Heard of Retron 77?  

     

    Retron 77: With upgraded community SD card image firmware

     

    1)  Runs Stella 6 so you can play Space Rocks and recent home brews

    2)  Has SD card so you can have unlimited games, plays all home brews

    3)  Has Stella 6 interface so it looks like your on a PC

    4)  Works with stock CX-30 paddles

    5)  Has cartridge slot so it play many original cartridges

    6)  Has a first rate joystick w/10ft cord

     

    No brainer

     

     

     

    Definitely a no brainer! 

    Will it work with the original Pitfall II cartridge? 

    I had the Atari Flashback 9 Gold which, before it stopped working, had Pitfall II - the first Flashback model I have seen that supports the game! I wonder how they did it. 

  6. 1 hour ago, Stephen Moss said:

    The schematic is shown below.

    245179391_Switchablesensitivitypaddles.PNG.200113fc0e710ff618b555231927a357.PNG

    In answer to your question, yes you could use the existing single pot (RV1-B) and a fixed 1M ohm resistor in place of RV1-A, electrically there would not be any difference but if it will fit in the case you may find the connection easier with the stereo pot, plus if one wiper subsequently becomes jittery you could try the other. However, you cannot get away with a SPST switch as you need to make two separate connections, one to change the resistance and one to change the capacitance.

     

    Although having just said that I have just remembered that in the CX2600 schematic there are resistors in between the caps/TIA pins and controller port pins which would mean that the capacitor in the schematic above would be connected to the wrong point and so results would be unpredictable as it would not be altering the capacitance value as intended. Whereas those resistors are not present in the CX2600A schematic and so the desired change in capacitor should occur using the circuit above.

     

    The presence and absence of the resistors between the different console versions is interesting, we only have the one schematic for the paddle controllers, therefore is we assume that all paddle controllers are identical to that of the schematic then the CR charge time will obviously be different between the 2600 and the 2600A as the extra resistors in the 2600 would mean less current is being used therefore increasing the charge time. 

    I did find it odd that game control reported earlier in this thread was only over a small part of the pots range and not the entire (or nearly the entire) scale as you might expect it to be designed for, although what was not indicated was whether this phenomenon was being seen on both 2600's and 2600A's or just the latter. If it was seen only on the latter then the lack of the additional internal resistors could explain that, it would sense that paddle games written/tested for the 2600 with its longer CR time would react differently when played on a 2600A with its shorter CR time, that is unless any firmware in the 2600A or the paddle design was subsequently altered to account for that.

    Assuming, for now that there was no firmware/paddle hardware compensation made for the change in CR time, and that therefore the high sensitively paddle problem is limited only to 2600A's then a possible way to restore the original gameplay/control on 2600A's for those earlier written paddle games could be to simply re-introduce the internal resistance of the 2600 which could be done like this...

    932720269_Switchablesensitivitypaddles2.thumb.PNG.23f1e10d4b2710957dbd7c15eaf3f7d1.PNG   

    With the switch open the additional resistance in included, with the switch closed it is removed

     

    That makes sense. I would be curious what results others report from the above circuits.

     

    Is the 2600 the "heavy sixer" and the 2600A the 4-switch version? (I have the latter.)

     

    I never understood why, if Atari was so bent on saving the cost of a couple switches, they had to move the difficulty ones to the back of the unit instead of the bw/color and maybe power. The big friendly switches up front would get more use for difficulty than enabling color. But whatever. 

     

    Thanks again!

  7. 3 hours ago, Stephen Moss said:

    I think people have been looking at the problem from the wrong angle, that being purely resistively, not electrically.

    Yes, if you halve the total resistance of the pot you will have to turn it twice as far for the same change in resistance, however half the resistance means double the current charging the capacitor faster so at best they are likely to cancel each other out resulting in no significant change and at worse it will make the paddles more sensitive, not less.

     

    Placing Pots in series with is not a good solution generally, and in this case you are say halving the resistance of the initial pot only to then increase it again with the second pot which would seem rather counter productive.

     

    Because you are dealing with a current charging a capacitor the problem is you need to retain the same current range for say twice the angular (resistance) change to maintain the expected CR time constant, and as current is proportion to resistance if you halve the resistance you will need to also double the capacitance to keep the overall CR charge time roughly correct.

    So I think I could be done with a dual gang (stereo) linear 1M potentiometer, a double pole single throw (DPST) switch and an 68nF capacitor. Use one pole of the switch to connect/disconnect the Wipers of the two pots and the other pole to connect the capacitor between GND and the wiper of the pots, placing it in parallel with the one inside the 2600 and doubling the value (switch use is assuming you want to be able to switch between standard and reduced sensitivity). 

    However, results may vary due to the tolerances in values of the pots (+/-5%) and particularly the caps which are typically +/- 20% 

    Very interesting take, thanks for sharing that. 

     

    So the stereo / dual gang pot / DPDT switch is to switch between the normal pot and one with the capacitor? Could this be done with a normal (mono) pot and a SPST switch? 

     

    Also, if you get a free couple minutes and could sketch out a quick wiring diagram, that might help those of us not too familiar with electronics. 
     

    Thanks again...

  8. 20 minutes ago, Brainworm said:

    The fellow who makes the iCode adapters has a couple instructional videos (on jitter reduction and adjusting range of motion and on basic configuration) that focus on lr-stella (the LibRetro Stella core that's used to provide Atari 2600 emulation in RetroArch).

     

    Basically, RetroArch is a wrapper for all kinds of emulators ("cores") that allows you to set up a global configuration for e.g. displays and controllers. That way, you can emulate a 2600, 5200, 7800, NES, SNES, C64, &c. games without having to set up specific configuration files for each one.

     

    And there are a whole bunch of software products that bundle RetroArch with a handy frontend, all on top of a GNU/Linux software stack, to create an OS dedicated to retrogaming. Which one you use mostly depends on which hardware you want to target. RetroPie is of course for Raspberry Pi boards, and derivatives like RecalBox and Batocera use a very similar stack of software to target (mainly) x86. Lakka is something like the official distribution for RetroArch and runs on everything from PCs to single board computers to portables like the Nintendo Switch or RG351.

     

    So you could build a dedicated 2600 emulation machine with pretty much anything you have laying around -- an old PC, a Raspberry Pi. Lakka even runs on some weirdo set top boxes.

     

    Normally, if you were going to build a custom emulation machine from scratch, most people would recommend going with a Raspberry Pi. Once upon a time they were like $25 and powerful enough to run pretty much any game that came out before maybe the year 2000. Now they're hard to find and stupid expensive, so the deal of the year is an old Chromebox (like one of these). They're just a low-power fanless PC with custom firmware/BIOS, which you can reflash with Coreboot/Openboot in order to run basically any version of linux that tickles your tulip -- including Lakka, RecalBox, or Batocera. That's a hard deal to beat for $40.

     

    I have Lakka on mine. The 16GB internal storage is basically enough to run every Atari console game and arcade classic. You can either use an iCode or 2600-daptor to connect your paddles to it, or splurge on a VCS Classic Controller to go totally wireless for both your joystick and (one player) paddle games. And  -- of course -- you can configure your paddle range and everything else per the video from the iCode fellow.

     

    For me, this has been a better experience than the Retron 77 or any of the Flashback consoles because the Chromebox (a) has bluetooth, so you can go wireless with Joystick AND paddles, and (b) is powerful enough to use all kinds of tweaks (hard GPU sync, run ahead) to reduce latency -- something you really notice in fast games like Dragonfire or Kaboom!. It's still not as good as original hardware, but is easily as good as Stella on PC.

    Very cool - thanks for explaining all that and for those iCode videos, I will check them out. 

     

    The thing I find daunting about the RetroPie / RetroArch / etc. stuff (and others may as well) is, I am NOT familiar with Linux, Raspberry Pi, and the "sys admin" side of things in general. So I would benefit from a handheld step-by-step "dummies" guide for setting up one of these things with concrete examples, e.g. here's how to set up an Atari 800: buy this model Raspberry Pi (links), buy these peripherals (links), plug a into b etc.,  download & install the OS (links), download & install the software & ROMs (links), configure the games and controllers, etc.

    I just don't have time or free cycles to dive too deep into such unfamiliar territory (lately what time I do have I spend programming games). But if there are quick & easy instructions to get something up & running, I might give it a try sometime! 

     

    Anyway, thanks again, I will file away this info for future use and check out those iCode vids. 

  9. 1 hour ago, Brainworm said:

    Since this thread is resurrected: I love the degree of technical ingenuity being brought to bear on this.

     

    If, like me, you don't know the first thing about potentiometers or resistors, you can solve this problem in software. All you need is (a) a reasonably fast machine and (b) a spare 2600-daptor. Either Stella or lr-stella (as seen in Lakka and RetroPie) allow adjustments to the paddle sensitivity and dead zone, and at least lr-stella allows you to change both these settings on a per-game basis. You can even "trim" the paddles by adjusting the dead zone.

     

    I like using a reflashed chromebox for this purpose, since fast paddle-based games (e.g. Kaboom!) really bring out the lag in underpowered systems like the Retron 77, the Flashbacks, and even the pi 4. Even in the midst of this chip shortage you can get one for like $50.

     

    Thanks for your reply! Tweaking on the software side is definitely a smart approach. I'm not familiar with lr-stella, or any of the raspberry pi or chromebox stuff, but always curious, so any links welcome!

     

    My Atari activities happen on my original VCS and lately the Flashback 9 (the one with the SD reader) so I'm mainly tweaking the physical controllers for those. I played with linear slide potentiometers which have potential (pun intended) and was even looking at reading an optical mouse with Arduino which would convert it to Atari paddle controller by controlling the resistance with PWM, but that's a little involved, so for me that's on the backburner.

     

    My old Windows XP machine runs Stella, and the optical mouse works fine for one player paddle games. You can easily adapt it to a "spinner" by attaching a paddle knob to an "axle" with the mouse up against that, which detects the movement perfectly. I found a wooden dowel inside of a short section of pool noodle works best! Or instead of a paddle knob, you can use a steering wheel, for controlling driving games like Sprint, Indy 500, Night Driver, Pole Position, etc. But for multi player games, I haven't found a way to connect multiple mice. (If someone could make a software app that would read multiple mice as separate devices and emulate analog game controllers internally, that would be a software solution for inexpensive multiple spinners on a computer.)

     

    For Windows 10, I have the iCode 4-port adapter, and it works great. (Alas it doesn't work for older Windows versions.)

     

    I use the iCode for joysticks for creating my own PC games in QB64, and it works great for joysticks, but I ran into issues getting it to read paddles - it reads them but the values are "jittery". Still a WIP.

     

    I did do some research looking for ways to connect multiple optical mice to a PC that can be read as separate paddle / trackball controllers. It has been done before (RawInput API in Windows, and I saw it also was done on Mac / Linux) but it's a little beyond me technically (at the C/C++ level). Still, if I could get Windows to read multiple optical USB mice as separate devices, it would open up a world of fun for DIY Pong games! LoL

     

  10. 19 minutes ago, zzip said:

    But because it's so popular there are benefits to learning it.

     

    I do my game coding in C for better or worse

     

    100% agreed. 

    If you do C, my hat's off to you, you're way more advanced than me ?

     

    BTW, for anyone curious about QB64, goto qb64.org or check out the forums:

    https://forum.qb64.org/index.php

     

    A game I made in the spirit of the Atari VCS:

    https://forum.qb64.org/index.php?topic=4649.0

     

    And for Atari / classic arcade fans, a couple by Terry Ritchie:

     

    A killer version of Asteroids:

    https://forum.qb64.org/index.php?topic=2264.0

     

    And Berzerk:

    https://forum.qb64.org/index.php?topic=442.0

     

     

  11. 16 minutes ago, zzip said:

    Yeah I agree with these criticisms on python,  but on the other hand Python is now the most popular language in the world and worth learning, while BASIC has kind of fallen by the wayside.  If I was going to write something in an interpretive language now, I'd do it in python.

     

    Also maybe look at something like Godot to help speed up game development:

    https://godotengine.org

     

    EDIT:  Whatever you choose you're going to want to go with something well-supported and  well-documented,  a lot of the open-source projects in your list look iffy in that regard

     

     

    Thank you for your reply! 

     

    I don't see anything wrong with Python for people who like it, it is definitely the most popular language and available for all major platforms. 

     

    However, being _interpreted_, if you want to distribute a game written in Python and PyGame and whatever libraries, the end user would need to install Python and said libraries. And it's not going to perform as fast as a compiled language (of course that depends on a lot of things, like how optimized or poorly designed the individual program is, the library used, etc.)

     

    For me, QB64 is easy to work with, cross platform (pc, mac, and linux), compiled & runs plenty fast, well-documented, and has an active and supportive user community. I haven't got to Free Basic yet, but it seems to have similar benefits. 

     

    But there is definitely nothing wrong with Python if that's your preference!

     

    (I just wish someone would make a compiler for it, add the option to declare types, the option to enclose blocks in { } or some kind of begin/end delimiter instead of indentation, and a simple header line that declares which version (Python 2, 3, 4, etc.). But that's just me.)

     

    Thanks again!

  12. I've been playing with connecting Atari paddles to PC using a USB interface like this

     

    and find that the values on the PC side are "jumpy", 

    ie without moving the controller and just leaving it sitting there,

    and reading the value on the PC, the value fluctuates.

    Not wildly but enough to make my game spastic. 

    This problem happens with working paddles that have been cleaned and are not "jittery" on a real Atari, 

    and it happens with various brand new 1M Ohm linear potentiometers (which also work fine with a real Atari). 

     

    After some googling I came across a discussion where they discuss this problem

    and talk about adding a capacitor to "smooth out" the signal:

    reading a potentiometer ? (avrfreaks.net)

    Quote

     

    Also, you may wish to put a 0.1 uF cap from the junction of the fixed resistor and your 2 wire device to ground.

    Some pots are scratchy, with intermittant ro noisy contact, and this will help smooth out the signal.

    You may wish to average several readings for your real application, once you have it working.

     

     

    I have seen a capacitor used with a guitar tone control potentiometer.

     

    Would adding a capacitor between pin 7 (+5v) and pin 5 (paddle A), and another one between pin 7 and pin 9 (paddle B), be the way to do this? 

     

    Would it work to smooth out the signal or would it no longer be readable by the Atari? 

     

    Before I open up my paddle and soldering iron, I thought it might be prudent to ask the experts.

     

    Any feedback appreciated... 


     

     

     

     

  13. Thanks everyone for your replies. After more searching, I found one which seems to work pretty well, it has a "d" shaft whichis pretty long and is linear taper.  

    Here is the part number and a link in case it helps anyone:

     

    Philmore PC28 1 Meg Ohm Linear Taper Solder Lug Terminal Potentiometer, 24mm Body with 1/4" D Shaft.
    https://marvac.com/products/philmore-pc28-1-meg-ohm-linear-taper-solder-lug-terminal-potentiometer-24mm-body-with-1-4-d-shaft
     

     

  14. I know the Atari paddles are 1M Ohm, linear taper, but searching on mouser, jameco and digikey brings up a ton of choices. 

    Has anyone replaced these in their paddles recently that could recommend an exact part number or the mm size, or other specs that I should be looking for & could filter on? 

    Also, I need a good fire button switch, the standard red classic arcade joystick button, has anyone found any good quality ones at a good price? 

    Any recommendations welcome. 

  15. 17 hours ago, gliptitude said:

    A few years ago I convinced an Atariage member to convert a Pong console to be 2600 paddles. Works okay and is a cool novelty. Still plays the pong games too. 

    That's pretty cool, so the Pong home console paddles use the same 1MOhm potentiometers as the VCS paddles? 

  16. On 12/26/2016 at 1:04 AM, Rhindle the Dragon said:

    Has anyone ever come up with an alternative to the crappy potentiometer-based paddle controllers?

    I know they sell reproductions, but if I'm thinking right, they will also suffer from jitters after a while since they are based on the same mechanism.

    It seems like a super-easy problem to fix. Maybe modify a rotary encoder somehow?

    Somebody look into this!

    In case anyone finds this looking for another solution to this, 

    we discussed using a USB optical mouse as a paddle substitute here

     

    The mouse would plug into a Raspberry Pi or Arduino, which would keep track of the position and use it to control the resistance using pulse wave modulation (PWM). 

    I haven't tried it yet but I'll get around to it! 

  17. Just to update people in case anyone else is interested in writing Atari type games on a modern PC, that I have been playing with QB64 and created a couple simple practice games without too much trouble. They run fast, and it's BASIC, so for anyone who grew up with that language like I did, it's not too hard to pick up. 

    I plan to try my hand at FreeBasic next. 

     

  18. In case it helps anyone, I found another implementation for the TRS-80 MC-10

    Some videos of it running: 

    Atari Adventure in BASIC: Alpha Version - YouTube

    Atari Adventure in BASIC: Lucky Chalice Placement and Easy Win! - YouTube

    Atari Adventure In BASIC Spelling Fix - YouTube

     

    Try it in this online MC-10 Javascript Emulator  (choose ADVNTR from dropdown and type RUN <ENTER>).
     

    Here's the page with a link to the downloadable sound file of the program on cassette(!) and a link to it emulated online:

    Type-in Mania: Programming in BASIC on the TRS-80 MC-10: RetroChallenge 2018/09: Atari Adventure in BASIC Beta Release

     

    More info: Atari Adventure in Basic Lost Sword

     

    There is a download link here for the game and the emulator it runs in:

    Jim Gerrie's TRS-80 MC-10 Games by JimGerrie - Play Online - Game Jolt

     

    I was looking for a utility to convert the program listing on the cassette image to a plain text file, maybe it's in this MC-10 archive (has the emulator and more stuff):

    TRS-80 Color Computer Archive - MC-10
     

    A thread about the MC-10 here on atariage: Remember the TRS-80 MC-10? - Tandy Computers - AtariAge Forums

     

  19. 2 hours ago, madscijr said:

    I might be interested in a option for a scrolling playfield, rather than the flip screen

    Thinking about it, the flip screen version would be fine, but the screen would still need to be redrawn pretty quickly when you move to a new one. On the C64 at least, this would mean reading the new screen data (the whole world would be loaded somewhere in high memory where it won't be overwritten by BASIC) and copying the visible portion to the screen, which would be slow without a ML routine of some sort. I'm not sure what BASIC extensions might have features that would do this quickly, otherwise it would mean writing some assembly or hoping the compiled program runs fast enough so you don't have to wait too long for the screen to be drawn.

  20. Thanks everyone for your replies!

     

      

    On 11/23/2020 at 2:23 PM, zzip said:

    I'm pretty sure I have a version of Adventure written in BASIC for the Atari 8-bit.   I've never tried to modify it though.

    Oooh, any chance you might be persuaded to share the code? I promise you it would not be used for monetary gain :-D 

     

    On 11/23/2020 at 1:38 PM, Preppie said:

    Never tried it but it would be simple enough to do especially if you used FastBasic.

    I'm new to Atari 8-bit and hadn't heard of FastBasic - I looked it up and it is intriguing. Simple, easy, and fast are good attributes for a development language here! 

     

    On 11/23/2020 at 1:19 PM, R.Cade said:

    I wrote one for the VIC-20 when I got one back in 1983, but unfortunately it's lost. It was pretty easy to do with PETSCII character graphics, and being so simple I didn't need a lot of knowledge of game design at all.

     

    I remember getting pretty far into the development of it, never 100% completed though, like all my projects. :)

    My condolences, I'm sure 37 years has removed the sting, but I know the pain of losing one's work. 

    PETSCII graphics can definitely reproduce the look of the backgrounds, but the player, dragons, objects, etc. would need to be sprites, to recreate the smooth motion of the Atari VCS version. I know it's not exactly the most advanced game, but I would like the look and feel to be as true to the original as possible. 

     

    PS However, I might be interested in a option for a scrolling playfield, rather than the flip screen of the original. Maybe even a split screen game where 2 players can interact in the same world. The thing I wouldn't know how to do would be smooth scrolling of character-based (ie tile) graphics, in a window (the top half for player 1, the bottom half for player 2, or maybe right/left, or maybe 2x2 for 4-player split screen, and maybe a non-scrolling area at the top or bottom displaying score, and other attributes). That kind of thing sounds like it would need interrupts and machine language - stuff that is a little daunting, a little too much work - at least on a C64 which I am most familiar with. Maybe the Atari 8-bits have flavors of BASIC that can do that kind of thing easily and quickly? The scrolling is just a nice to have though, I just thought I'd throw that idea out there. If there is no easy way to accomplish it, forget I mentioned it! 

     

    PPS I think my main idea and desire would be to create an EASILY modifiable Adventure game / engine. Kind of an "Atari 2600 Adventure Construction Set". 

     

    Thanks again everyone

  21. Just wondering - the technology used for Adventure was simple enough that just about any 8-bit home computer or newer should be capable of emulating it. 

    I'm wondering if anyone has done it in BASIC (maybe compiled, or with some minor ML routines, or using some BASIC expansion library, for more speed etc.) ? 

    It would be cool to have such a code base to work with, making it easy to modify and create custom adventures... 

     

×
×
  • Create New...