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


Forums

  • 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
  • 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
  • Arcade Gaming's Discussion
  • 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
  • The Green Herb's Discussions
  • Robin Gravel's new blog's My blog
  • Atari Video Club's Harmony Games
  • Atari Video Club's The Atari Gamer
  • Atari Video Club's Video Game Summit
  • Atari Video Club's Discsuuions
  • Star Wars - The Original Trilogy's Star Wars Talk
  • DMGD Club's Incoming!
  • DASM's General
  • AtariVox's Topics
  • Gran Turismo's Gran Turismo
  • Gran Turismo's Misc.
  • Gran Turismo's Announcements
  • The Food Club's Food
  • The Food Club's Drinks
  • The Food Club's Read me first!
  • The (Not So) Official Arcade Archives Club's Rules (READ FIRST)
  • The (Not So) Official Arcade Archives Club's Feedback
  • The (Not So) Official Arcade Archives Club's Rumor Mill
  • The (Not So) Official Arcade Archives Club's Coming Soon
  • The (Not So) Official Arcade Archives Club's General Talk
  • The (Not So) Official Arcade Archives Club's High Score Arena

Blogs

There are no results to display.

There are no results to display.

Calendars

  • 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

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website


Facebook


Twitter


Instagram


YouTube


eBay


GitHub


Custom Status


Location


Interests


Currently Playing


Playing Next

Found 16 results

  1. This is a continuation of an idea that got a little spring-boarding in another thread... Thanks to the participants, for their motivations... Special thanks to @apersson850 for a patient and helpful review. The purpose of version 1.0, at conclusion was simply to directly control an IR device using a physical connection... Further testing, over the course of a few days, revealed inconsistent reliability(keypresses being missed). I tried adjusting the software's timing, circuit changes, to no avail. I then continued to investigate the possibility of adding an external generator circuit to produce the 38K carrier needed for IR transmission.(Nov 17) I determined: To move forward with the IR sender idea, in order to explore physical separation as an electrical isolation solution... Finally, the IR carrier module arrived(May 11th, from China). After the addition of an inverter, the IR sender worked out! However, the "keypress" issue persisted. I had been so close, but, for one thing, had failed to mind the separation pulses, when adjusting the total number of data pulses sent.(Thanks, Classic99's DEBUGGER). After achieving some measure of success... I decided to look into decoding the remote control's signals, on-the-fly... in order to REMOTE CONTROL the TI itself. After reviewing some others findings... https://www.electroschematics.com/ir-decoder-encoder-part-1 This was successful, and also led me to developing a way to produce the needed IR signals, directly from the extracted HEX CODES! Now, only a small buffer is needed to reproduce any device's(NEC) codes! The above images, from >1000 to >1FFF, is ment to load into MINIMEMORY, from >7000 to >7FFF. While reviewing the image, try and pretend that the first >1, in the addresses is a >7. This image contains 5 subroutines that can be called manually by using EASY BUG's (E)Execute COMMAND. 1. RECEIVE IR, at >7120, will scan the output from an IR receiver, connected to a port on the TI's 9901 interface I.C.. The subprogram fills the buffer at >7D00, with word values representing the length of the pulses received. 2. SEND IR, at >7160 will read the values from the buffer at >7D00, and reproduce the pulses needed to drive a 38kHz IR sending module, connected to a port on the TI's 9901 interface I.C.. 3. KEY SEQ. PLAYER, at >7DCA(Execute >7DCC), Sends a series of keypresses(Bursts), repeatedly, by modifying the buffer addresses used in the SEND IR routine. This method is now, as though it were deprecated. 4. KEY DECODER, at >7EA0(Execute >7EA6), will read the buffer at >7D00, and write the derived HEX CODES to addresses >7EA0(DEVICE ID) and >7EA2(COMMAND). 5. KEY ENCODER, at >7F00(Execute >7F08), will read HEX CODES specified in R1 and R2 at addresses >7F0A(DEVICE ID) and 7F0E(COMMAND), than write the pulse length values to the buffer at >7D00, capable of driving the SEND IR subroutine! These synthesized values are experimental. I'm not using a scope of any kind or even a calculator! So, YMMV. These pulse values are within the detection range of, and appear to work well with: The only test unit I'm using. To be sure, I'm not certain if I should be counting MARKs or SPACEs, HIGHs/LOWs, here. I did a lot of trial and error to get this to work... Looking at the buffer(>7D00). The first word(>0266) seems to be a waking-up shift from HIGH to LOW and could perhaps trigger an interrupt. The second word(>0134) at(>7D02) seems to be a header/tail pulse. The third and every other word(>0024) is a LOW, separator pulse. Looking at the fourth word(>0023) in the buffer, from the ASCII view, a #, can be seen. The #'s are the 0's, the o's are the 1's, and the $'s are the separator pulses. So the HEX CODE seen is ########=>00, oooooooo=>FF, #o#o##o#=>52, o#o#oo#o=>AD, or >00FF, >52AD. >00FF being the Device's ID, and >52AD being the COMMAND CODE(for "key 9" on my device). P.S. Any ideas on how I could bottle and sell this are welcome. H.A. phm3058C.BIN phm3058G.BIN
  2. Hi all! Last month I saw the following ad on eBay: I thought the appeal of this kit for homebrew development was very limited: No bankswitching/mapper (only 2K games or 4K games with further modifications on the board) It required messing around with UV lamps, programmers, etc Required some knowledge of electronics Buying the parts separately would probably be less expensive Not possible to ship as a product to customers It would be probably easier and faster to use one of the existing USB/SD carts to test on a real hardware. This did make me think though that I had never seen a development kit for the 2600 which would allow homebrewers without knowledge of electronics to self publish their games. If a mapper is required, then that knowledge need goes up real fast. As in Europe we have very limited offers of good homebrew games available (most of them are from the USA and shipping quickly becomes a problem), I thought about making this my next project. The idea is to have blank carts (populated with all required components but without any game image in them) and a simple to use cable and PC software which would allow the user to create a cart ready to be shipped to customers as well as test games in a real atari. Is this something that would interest the homebrew community? Here are some requirements I have come up with: The final product must cost under 10€ (populated cart PCB) All components must be easy to find. Preference should be given to components still in production Must be usable by people with no experience in electronics No soldering Must support mappers (the ones used by batari Basic at a minimum, as a lot of people seem to use bB) No physical alterations to select the desired mapper (or no mapper) Must fit in a standard Atari cartridge case Components should be SMD to keep production cost as low as possible All comments will be appreciated!! Cheers.
  3. Hi all, I have created the following post yesterday: Someone just told me that I should have created it in this subforum. I don't want to duplicate the post but I have also not found how to move the post here. Any suggestions? Also, if you can comment on the bankswitch schemes you currently use in your programs and any experience you can share on how to implement a bankswitch controller on a 8bit Microchip PIC will be much appreciated. Cheers!
  4. 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
  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. 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
  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. 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!
  9. 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
  10. 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
  11. 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.
  12. 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
  13. 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.
  14. 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
  15. 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-2.13.9.20121203-1.zip cc65-snapshot-doc-2.13.9.20121203-1.zip cc65-snapshot-lynx-2.13.9.20121203-1.zip cc65-snapshot-sources-2.13.9.20121203.tar.bz2.txt Tutorials26082016.zip
  16. 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
×
×
  • Create New...