Jump to content

Search the Community

Showing results for tags 'development'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Atari Systems
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Gaming General
    • Classic Gaming General
    • Classic Computing
    • Modern Gaming
    • Prototypes
    • Arcade and Pinball
    • Emulation
    • Hardware
    • Gaming Publications and Websites
    • International
  • Marketplace
  • Community
  • Game Programming
  • Site
  • Classic Gaming News
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching


There are no results to display.

There are no results to display.


  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar
  • ZeroPage Homebrew's Schedule

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start










Custom Status



Currently Playing

Playing Next

Found 13 results

  1. Hi guys! I and my friend decided to bring something new to you. The joystick. But we need some feedback before it. Description: We decided to find out a way how to make new Atari Joysticks and similar joysticks with 3D printer. We try to have as similar as possible construction for the same impression of playing games like the original old joysticks. But we have one thing in our construction different. Our Stick will be exchangeable and modulable. We will have more types of sticks and you can choose what type you want. Sticks will have different shape, size etc. Our questions are: 1) Is this idea interesting for you? 2) Are you looking for some new joystick because your old was damaged? 3) What types of sticks do you prefer? What joysticks do you like? What was your favourite joystick in 80/90's? ( CX40, QuickShot etc. ) 4) Would you like exchangeable stick at your joystick ( when you will get tired of the old type of stick you can simply change it for another one ) or you'd rather buy another new joystick when you want to exchange the stick? 5) Is the autofire function important for you? 6) How long stick movement do you prefer? ( short movement is like pressing a small button, long movement is like pressing a key on your keyboard ) 7) Do you like an idea that you can buy only the 3D data for your 3D printer and make it for your own? 8) Do you have some tips why this idea doesn't make sense? For example you can buy really new QuickShot on Ebay etc. Progress: Thank you for your time, sharing and answers! Best regards, EnJoyStick Team
  2. Hi everyone interested, while we are at the middle of creating our entry for the 30 years Lynx compo organized by atarigamer.com, I thought it might be nice to share some details on tools or concepts we use. I will happily answer questions but some replies may take a while during the compo We work on a rendition of Assembloids, a fast-paced action puzzler. The concept was originally developed by Photonstorm for the flash game 'Quartet' and we ported it to C64 and Atari2600. The original artist contributed to the C64 variant back then and we have the official ok to spread the love across multiple systems. The Atari Lynx surely was missing so far! We try our best to give it some different style and touch for each system and to make the best use of the given hardware. Not too long ago we formed some hobbyist homebrew game-dev group 'PriorArt' and you can find us here: http://priorartgames.eu For Assembloids Lynx, I (Martin) work on the code, Oliver 'v3to' Lindau does most of the main graphics and Kamil 'jammer' Wolnikowski is the man behind the sound effects and music. I get most fun out of developing for any platform when I have everything understood from scratch and am aware of every single byte written. This also means that all bugs are my own So everything is written in assembly language and I usually write my own tools. For this game the only external tool I use is 'sprpck' that basically does exactly what I need and had not time/motivation to write my own converter Thank you for it! But no other libraries, loaders, converters or routines by others were used. This may sound tedious but it is half-the-fun. Of course this approach heavily relies on information available somewhere and I thank in particular: Bjoern Spruck for detailed information and examples, Bastian Schick for much of the legacy documentation and pioneering work, Karri for sharing thoughts and enthusiasm, And LXdev for his 'Diary of an Atari Lynx developer' which was a great start! And also Bernd Thomas for his flashcard that I needed alot to test things on real hardware which still differs alot from emulation, Sascha 'Luchs' for hints and contacts and a couple of hardware-tests, i.e. for the true RGB image routine the Retrokompott podcast (with Oliver Lindau) who triggered my urge to look into the Lynx, Igor from atariage.com for constructing a 'center of knowledge and information' for the Atari Lynx + everyone involved in emulation-development which is the key for anything getting done today [sorry if I forgot something while writing this up, feel free to ping me or simply comment here] And, naturally, my own group mates for their patience during endless (still ongoing) test-iterations Preferring coding in assembler from scratch, I soon needed/wanted some own loading routine. The one I now use loads pretty fast and the whole loader fits into the smallest possible decode-unit of 50 bytes. There is an Atariage thread about the start of my routine. I also prefer to stay optimal and not 'waste' space (this is purely emotional these days as 128KB or 1MB hardly make no cost difference anymore). Anyway, Assembloids Lynx suits into a 128KB cartridge. This is already way too much text so I will take a break here and add details here and there Cheers, Martin 'enthusi' Wendt
  3. We have released new version of our productivity tool named uIPTool, which can shorten your development time on Atari TOS machines significantly and is quite handy for transferring files. With the help of cartridge based ethernet card (Netusbee/Ethernec) you can easily deploy binary built on PC with cross compiler and quickly transfer them via local network to Atari TOS machine and execute it remotely. Additionally all Atari console input / output is redirected to console on PC which is quite handy during development. Tool requires minimal amount of memory and it can run on Atari models with even 512kib of ram. Full write up about what's new is on nokturnal. More information and download section is on an official project page. We have reduced memory requirements significantly, so it should run even on models with 512kib of ram which wasn't possible on previous version. Regards, PG
  4. Introduction Atari Jam is a Windows tool for developing Atari 8-bit computer software. The theoretical concept is that it is a PBI device that maps the memory, allowing an external device to monitor and change things in real-time. In practice, this is accomplished by attaching to an external emulator and accessing the RAM. The program gives the user a suite of tools to interactively modify, tweak, test and program software. It is not intended to be a replacement for a development IDE but rather to let the user experiment and rapidly develop small projects or pieces of something larger. It currently compatible with an Atari 800XL with 64K of RAM. Features Live memory viewer/editor Interactive disassembler Assembler Character editor Character map editor Player/missile editor Graphics control (GRACTL, DMACTL, GPRIOR) and color picker Display list editor Experimental video player (AVI) Vector control Notes The video player is very limited in the input it will accept. It uses a dither pattern that will be applied each frame, using the current palette. The user can adjust colors to find the best match. The program monitors GRACTL and PM registers through the addition of an OS patch that removes shadowing for the paddles. This patch slightly reduces the cycles used by the OS during a refresh. Hopefully, this is something people will find useful. I plan to have a version ready to try by March 1st.
  5. Greetings Starfighter, You have been recruited by the Star League to defend the frontier against Xur and the Ko-Dan armada. --- Sorry, wrong topic. I loved that movie, though. Greetings Atari Fans and Developers! I am a computer programmer, no stranger to assembly language, yet I am new to the 6502 (or 6507, as it were) chip and - more to the point - cpu cycle counting. As such, my first Atari program is an exercise in timing. I have attached my first program for your critiquing pleasure. Basically, the program displays colored lines in the background, each based on the current descending line count. However, that being only marginally interesting, it also changes the color as frequently as possible on the current scan line. Finally, just for fun, it tracks a cycle counter that is added to the current line number. The final effect is 11 scrolling color bands. I have executed this program both in Z26 and Stella, and observed a couple of bugs that I am having trouble tracking down: * At regular intervals there is a short period of increased velocity, as if the program is "catching up". * There is a minor visual anomaly that results in the horizontal seems between scan lines being slightly crooked at times. This is probably related to the previous issue, and could very well be simply due to a limitation of the EMUs. * The first color band is shorter than all the others, while the last is longer. I feel like this is just the nature of the alignment of the cycles, but I am curious if it can be fixed. I haven't the means to dump this to a cart, but I do wonder if those behaviors would be the same on the actual device. If any devs out there have some insight or general advice, I'd be glad to have it! Thanks, Grif PS: This was part of the alphabet would look like if Q and R were eliminated. PPS: I love the Topics Tags. We need more adoption of tags on the internet. student.asm
  6. I got back into coding after porting "Castle" from David Ahl's Creative Computing magazine to QuiteBasic. An excellent classic BASIC interpreter written in Javascript. Here's my game: Castle Something I learned, at least for me, is that I can't code directly to the computer from scratch. I need a notebook. I need to be away from the computer, where there's no pressure to achieve a great deal and have a working program right off the bat. I got familiar with QuiteBasic, wrote a few simple programs to learn the syntax, and then I went to the notebook. I printed the syntax reference and used that as my guide. I spent a few weeks of lunch breaks working on it. Time at the doctor's waiting room, oil change waiting room, etc. It was rather fun. And productive. I found it easy to discard bad code and keep good code. So the itch to create an atari game bit me again. I did not want to replay the damned Zombies debacle. You fine folks have made better adventure games since then. So I'm back to the notebook. I didn't print the Batari Basic manual, and so I did a little, and then sat down to code it. Tossed it. Tried again. Not so bad this time. I initially envisioned a "ambient game" like Knytt but with a honey bee going around collecting rare flowers and encountering various creatures as part of the scenery. Worms, spiders, frogs, etc. Then I thought maybe a shorter, fetch-the-treasure game with a couple predators that hound you as you look for rare nectar from various flowers. I need to flush this out a bit before I continue. However, I'd like to make the code and bin available if you feel like you want to mess with it or use it for inspiration. Use the trigger as you approach a flower to land on it. I envision a sucking sound and a score increase, but not sure. It just seemed right. The cyclescore indicated 2112 when I ran an early version, as you can see in the attachment. An excellent Rush album is a positive sign. Later, it indicated 1984, so I don't know if a classic Orwell novel is a good sign or not. This is all in humor, but I couldn't help but find it funny enough to take a picture. There's a lot of opportunity to use various color schemes for terrain. I considered a wasp that chases you and drags you back to it's hive. Maybe a joystick jiggle routine to escape. Maybe a frog that leaps back and forth and tries to eat you if you get too close to the lily pads. Enough rambling!
  7. Hi, New/old A8 basic coder here (haven't touched it in ~30y). Trying to remember how to use ML strings to redefine character sets... My most immediate problem is that I can't get certain characters on the screen. CHR$(127) does not output the right-facing triangle character. I need to get that in a string to redefine my character set but I'm forgetting how. The screenshot attached shows another person's program that contains said character in a string, but I don't know how it was done. I have access to Atari800MacX, Envision on a windows XP VM, and I'm open to other mac/win/a8 tools if there's an easy-peasy character set generator that outputs what I need. I also don't mind converting the values by hand into ATASCII but I figure there's easier ways My requirements are that the code be self-contained in the basic file and that it be as compact as possible, so I can't use external files to load the charset data, and I figure strings are better than data statements.
  8. Good evening, everyone, I've been wondering, especially since Dropcheck has started inquiring about the Atari's PBI, what the advantages and disadvantages are between the PBI and the cartridge interface itself? What types of devices are best suited for one I/O platform over the other? I imagine from a modding perspective, a cartridge-based mod would have a much broader usability factor since not every Atari 8-bit has a PBI interface— but every Atari DOES have a cartridge port! For me, the primary drawback to these cartridge-based mods is that you only get to have one mod in play at a time. While there are a few pass-thru mods, the reality is that I don't see my utilizing the USB cartridge, the Bluetooth cartridge, and my SpartaDOSX cartridge with MacRorie's R-Time8 cartridge all in a single session, even though that would be something I totally seem myself utilizing. Yet all of these could be in simultaneous use, should someone develop an interface along the lines of the 1090, where the USB cartridge would become a PBI card-based solution, as would the Bluetooth cartridge— both operating through the PBI lines. And wouldn't it be convenient to be able to set something like the RapidUS to card-based, as well? However, with the 65/130XE and their ECI port, it seems like any 1090-like expansion solution would need to support a cartridge port. Anyhoo, I was just wondering what the technical advantages and disadvantages were between the PBI and the cartridge interface insofar as mod development is concerned...? Submitted for your perusal and consideration, Tim
  9. Hey, since I've already posted asking for help with this, I thought I may as well introduce my project: Air Hockey Which may be usurped by RealSports Air Hockey once the Intellivision releases its contender to Air Hockey, and finally Super Air Hockey with it's at-table perspective and red label when the Atari 2600 gets re-released as the Atari Jr. Only Kidding. Move your paddles in not one--but TWO distinct directions! Hold fire to move TWICE AS FAST! Hit reset to reset the game when YOUR FRIEND STARTS TO BEAT YOU! Realize it's still just a work in progress when THE PUCK STARTS TO CLIP WITH THE PADDLE! Here's a screenshot of it so far: Still a work in progress, here's the ROM so far: airhockey.7-25-2017.bin airhockey.7-26-2017.bin airhockey.bas airhockey.7-27-2017.bin
  10. I have given the compiler the name AtaC(Atari C, Pronounced Attack). Any other suggestions? I'm making a new Atari 2600 compiler for a custom C-like language(in C89). It is being created to be efficient but also to hide multi-frame calculations from the programmer(it will notify the programmer, however, if multi-frame calculation is needed), as well as be more readable than assembler. I am currently developing the assembler, and development on AtaC has been paused until it is finished. Here's the GitHub page if you want to watch me develop that mess All examples and syntax specifications have been removed(on accident, to an extent). I will come up with those tomorrow.
  11. I know you can turn on or off the key click (POKE 731,0 or POKE 731,255), but I'm wondering if it's possible to generate the key click sound on command? Is there a bit of code to call from basic, or possibly a way in basic to generate the same or very similar noise? I don't remember my sound coding from back in the day or I'd probably be able to figure it out myself. I don't mind cheating by calling the existing key click routine
  12. Greetings Atari Fans and Developers! My first post was in the n00bs section, but Godzilla suggested I post here and reference that one, so here I am. I feel like my question is beyond the newbie topic, even though I am new to 2600 programming. I do look forward to getting some feedback. Here is my original post: http://atariage.com/forums/topic/212657-jumping-in-head-first/ Thanks, Grif
  13. Hello Everyone, I took the liberty of opening a new topic on the tutorial series. The main reason (besides my big ego) is that the notifications on new parts and potential discussion is now scattered throughout the Atari Lynx and Programming forum and multiple topics. Also, it gives a single, easy to find location for the source code that goes with the tutorials. So, for your convenience, here is the list of tutorial parts: Part 1: Getting started Part 2: Development environment for Windows Part 3: Analyzing Hello World Part 4: Creating a project Part 5: Exploring TGI Part 6: Colors Part 7: Basics of sprites Part 8: Changing appearances Part 9: Advanced sprites Part 10: Collisions Part 11: Pens and more collisions Part 12: Memory mapping Part 13: UART Part 14: Timers Part 15: Memory and segments Part 16: Cartridges Part 17: Interrupts Part 18: Files Let me know if you find things unclear, wrong, have suggestions for topics, see room for improvement or anything else. I hope you will find it useful and take up the programming challenge. You can take my word for it, or that of Karri, ninjabba, Matashen, sage, GadgetUK, vince, obschan, TailChao, Sebastian, Wookie, Shawn Jefferson, toyamigo, or any of the other developers: it is a lot of fun. I've added the sources, tools and documentation for the CC65 2.13.9 SVN 5944 which is a known stable build. Remove the .txt extension for the sources archive. cc65-snapshot-win32- cc65-snapshot-doc- cc65-snapshot-lynx- cc65-snapshot-sources- Tutorials26082016.zip
  • Create New...