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 General
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Atari VCS
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Classic Consoles
  • Classic Computing
  • Modern Consoles
  • Gaming General
  • Marketplace
  • Community
  • Community
  • Game Programming
  • Site
  • PC Gaming
  • 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
  • Robin Gravel's new blog's Games released
  • 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
  • PlusCart User's Bug reports
  • PlusCart User's Discussion
  • 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
  • Adelaide South Australia Atari Chat's General Chat & Welcome
  • Adelaide South Australia Atari Chat's Meets
  • Adelaide South Australia Atari Chat's Trades & Swaps
  • KC-ACE Reboot's KC-ACE Reboot Forum
  • The Official Lost Gaming Club's Lost Gaming
  • The Official Lost Gaming Club's Undumped Games
  • The Official Lost Gaming Club's Tip Of My Tounge
  • The Official Lost Gaming Club's Lost Gaming Vault
  • The Official Lost Gaming Club's Club Info
  • GIMP Users's Discussion


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

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 25 results

  1. CyranoJ


    JagStudio is an advanced development suite for the Atari Jaguar that allows you to code using Assembler, BASIC or C and is based around Reboot's powerful RAPTOR API. Regardless of your programming capabilities, Beginners to Advanced coders can utilize this flexible package that will fully suit the needs of anyone looking to program exciting new games for the Jaguar. The benefits of using JagStudio are the Hardware Abstraction Layers (HALs) and the combination of external modules available to use. This allows you, the developer, to get on with writing your games while taking advantage of the Jaguar's powerful chipset without worrying about tedious, underlying mundane routines. The same results that once took days or weeks to achieve can now be done in a matter of minutes, thanks to the power of JagStudio! You are one click away from 64-bit creativity! The current release of JagStudio along with any previous versions can be obtained at its homepage: https://jagstudio.reboot-games.com Some of the features of JagStudio are: Code in your language preference of Assembly, BASIC or C. (Assembly and C are currently in Beta... help us make them better!) Commands have been renamed (from rB+) to reflect the individual modules they control and prefixed as such: rapPrint, u235PlaySample, etc. RAPTOR API Debug Function brings useful program variable visibility to the forefront, aiding ease of game development. GameDrive support along with MRQ file creation. ROM builder now adds FAST GPU depack by default for quicker startup times. Ability to build and split ROMs up to 6MB into HI/LO for EPROM burning. Updated both RAPTOR and U235 Sound Engine APIs to current versions, bringing additional benefits of both in a single updated package. Added universal JagPad Input - A single call that works with either U235 or ZeroSquare sound engine so projects can be easily converted between the two should your needs change. Many enhancements and bug fixes to the original rB+ code (eg, you can now include files >4mb, all files unpacked using GPU by default) All documentation and examples have been updated with a simple rB+ to JagStudio conversion guide to bring your old projects over to the fully updated JagStudio. Includes project examples for all supported languages (Assembly, BASIC and C) for anyone looking to get started quickly. We plan on keeping this alive and active, with ongoing improvements and new features and look forward to seeing what you all make with it. If you have any questions, please feel free to ask in this newly created sub-forum. Happy coding, everyone! The JagStudio Team. @CyranoJ @Sporadic @Clint Thompson A huge "Thank-You" to ggn for creating rB+ upon which all this is based. Please do not pester him with support requests for JagStudio. JagStudio 1.1 has been released! We are now feature complete with Raptor 2.0.20. If you already have JagStudio installed, then to upgrade; - Backup your existing JagStudio folder. - Extract the new zip. - Copy the new JagStudio folder over the top of your existing one. (Obviously this will undo any changes you might have made to the example projects, but you can always copy those from your bakup). Head on over to https://jagstudio.reboot-games.com for the download, online docs and details. 1.1 Change log; * Added Angle calculation and direction vector. See example BASIC project 'calcangle' * Added Collision List. See example BASIC project "collisionlist". * Added Z-Sorting for Sprites based on a sprite property. See example BASIC project "zsort". * Added New "fader" BASIC project. Example on how to do CLUT fades. * Added Clock functions. See new clocktest project (BASIC). * Added Raptor Sprite Shift. Eg. rapSpriteShift(xshift, yshift, sprBug1, 3) - See project "spriteshift" (BASIC). * Added Dynamic object scale - See project "shootbang" (BASIC). * Added Simplified version of zeroPlaySample. Now you just pass the start and end addresses - the length and rounding are worked out for you. Eg. zeroPlay(channel,start_address, end_address, frequency, params). * Added Simple way to stop sound on a channel when using Zero player. Rather than the old way of calling zeroPlaySample with 0's. Eg. zeroClearChannel(channel) * Updated All documentation with some further clarity and the new functions. * Fixed BCX Print generating a \n * Fixed Fix build.bat so it creates a <projectname>.s in the build folder for C projects. * Fixed Fix build.bat so it can send ABS files to the JagGD. * Fixed Fix comment in object template for scale max to 228. * Fixed xdivs, xdivu, xmuls, xmulu where sometimes they would use an address register and fail compilation. Have fun and happy coding!
  2. Hi guys, I decided to show what I have made so far with JagStudio. Inside the .zip file, I have included a title screen demo, and a shooter demo. I am also working on platformer and overhead demos as well. Pardon the lack of actual screenshots, but I don't know how to take them in Virtual Jaguar. My JagStudio Demos 4-21-2021.zip
  3. #Atari8bit This video focuses on setting up #VSCode and #PlatformIO under Linux (as an example), so that you can hack on #FujiNet #ESP32 firmware! (or, just get a head start on builds before they reach production!)
  4. Looking for manuals, schematics, software, rom dumps, system pics, board pics, historical info, etc. for Technico/Rosse 9900 development systems including SS-16 and TEC-9900-SS. Currently trying to definitively identify a partial system board set recently sold on Ebay. There are system pics of an SS-16 on bithistory.org's FB, and there is a TEC-9900-SS flyer on archive.org, but unfortunately neither have clear pics of any of the boards except for the TEC-9900-SS CPU board. This is maybe common to both systems but that's one of the things that needs to be resolved. And if there were any other Technico 9900 systems, that would be helpful to know. Thanks, Ebay pics attached (more available):
  5. (Started a new thread from the GCC Topic) Finished a first working and complete version of the game. See the ZIP attached, unzip contents to DSK1 location of emulator or TIPI. Game is menu driven and controlled by either joystick or cursor keys. Still contemplating if on TI target the cursor keys are handy, as they on TI require two keys pressed (while my other targets have dedicated cursor keys). Gladly hear your feedback and suggestions. Not much room for additions though, as I already encountered before removing some test code that I completely fill the allocated expanded upper memory space. So adding stuff will also cause need to remove or reduce stuff elsewhere. Tested over here in Classic99 and on my original TI-99/4a hardware with sidecar TIPI. Full source code: https://github.com/xahmol/ludo/tree/main/TI994a (see upwards tree for the Oric Atmos code and the original Commodore 128 BASIC listing from 1992 that I programmed in my youth and that is the base) ZIP file of latest build: LudoTI994a-v199-20210412-0946.zip Changelog: v199-20210412-0946: Optimised window drawing and screen clearing routines with hchar and vchar commands v199-20210411-1322: Optimised window drawing and screen clearing routines with faster native TI methods. v199-20210410-1435: Added speech to support the TI Speech Synthesizer (or the emulation of it using an Emulator) Added boot tracking with fallback to DSK1. Should allow to place binaries everywhere you want on TIPI as long as you have AUTO switched to ON (Automatic mapping of last accessed dir to DSK1). Also supports DSK2 and DSK3 if needed. Small bugfixes - v199-20210326-1856: Changed file operations location to .DSK1 (was .TIPI) to let it work on more machines.
  6. Well, other consoles have such a thread. Since this is supposed to be an open console, it'll need one too. Put plans & progress here.
  7. Hey! want to sell your PS5™ devkit or testkit but don't want to risk it through eBay? then you are in the right place! I am spanish collector interested in buying PS5 dev and testing kits (boxed, unboxed, expired, working or not working) all anonymously, if interested, please PM me to: [email protected] with your asking price, conditions, etc. (reply in 24h) Please check this "Want to buy" list/interested in: Sony PS5 Development Kit (DFI-D series) Prospero (2018-2020): DEV KIT: Development Kit (for PlayStation®5/PS5) DFI-D1000AA, DFI-D1001AA, DFI-D1002AA, DFI-D1003AA, DFI-D1004AA, DFI-D1005AA, DFI-D1006AA, DFI-D1007AA, DFI-D1008AA, DFI-D1009AA, DFI-D1010AA (DFI-D1000 EU/US series) DEV KIT: Development Kit (for PlayStation®5/PS5) DFI-D1000JA, DFI-D1001JA, DFI-D1002JA, DFI-D1003JA, DFI-D1004JA, DFI-D1005JA, DFI-D1006JA, DFI-D1007JA, DFI-D1008JA, DFI-D1009JA, DFI-D1010JA (DFI-D1000 AS/JA series) DEV KIT: Development Kit (for PlayStation®5/PS5) DFI-D1100AA, DFI-D1101AA, DFI-D1102AA, DFI-D1103AA, DFI-D1104AA, DFI-D1105AA, DFI-D1106AA, DFI-D1107AA, DFI-D1108AA, DFI-D1109AA, DFI-D1110AA (DFI-D1100 EU/US series) DEV KIT: Development Kit (for PlayStation®5/PS5) DFI-D1100JA, DFI-D1101JA, DFI-D1102JA, DFI-D1103JA, DFI-D1104JA, DFI-D1105JA, DFI-D1106JA, DFI-D1107JA, DFI-D1108JA, DFI-D1109JA, DFI-D1110JA (DFI-D1100 AS/JA series) DEV KIT: Development Kit (for PlayStation®5/PS5) DFI-D1200AA, DFI-D1201AA, DFI-D1202AA, DFI-D1203AA, DFI-D1204AA, DFI-D1205AA, DFI-D1206AA, DFI-D1207AA, DFI-D1208AA, DFI-D1209AA, DFI-D1210AA (DFI-D1200 EU/US series) DEV KIT: Development Kit (for PlayStation®5/PS5) DFI-D1200JA, DFI-D1201JA, DFI-D1202JA, DFI-D1203JA, DFI-D1204JA, DFI-D1205JA, DFI-D1206JA, DFI-D1207JA, DFI-D1208JA, DFI-D1209JA, DFI-D1210JA (DFI-D1200 AS/JA series) Sony PS5 Testing Kit (DFI-T series) Prospero (2018-2020): TEST KIT: Testing Kit (for PlayStation®5/PS5) DFI-T1000AA, DFI-T1001AA, DFI-T1002AA, DFI-T1003AA, DFI-T1004AA, DFI-T1005AA, DFI-T1006AA, DFI-T1007AA, DFI-T1008AA, DFI-T1009AA, DFI-T1010AA (DFI-T1000 EU/US series) TEST KIT: Testing Kit (for PlayStation®5/PS5) DFI-T1000JA, DFI-T1001JA, DFI-T1002JA, DFI-T1003JA, DFI-T1004JA, DFI-T1005JA, DFI-T1006JA, DFI-T1007JA, DFI-T1008JA, DFI-T1009JA, DFI-T1010JA (DFI-T1000 AS/JA series) TEST KIT: Testing Kit (for PlayStation®5/PS5) DFI-T1100AA, DFI-T1101AA, DFI-T1102AA, DFI-T1103AA, DFI-T1104AA, DFI-T1105AA, DFI-T1106AA, DFI-T1107AA, DFI-T1108AA, DFI-T1109AA, DFI-T1110AA (DFI-T1100 EU/US series) TEST KIT: Testing Kit (for PlayStation®5/PS5) DFI-T1100JA, DFI-T1101JA, DFI-T1102JA, DFI-T1103JA, DFI-T1104JA, DFI-T1105JA, DFI-T1106JA, DFI-T1107JA, DFI-T1108JA, DFI-T1109JA, DFI-T1110JA (DFI-T1100 AS/JA series) TEST KIT: Testing Kit (for PlayStation®5/PS5) DFI-T1200AA, DFI-T1201AA, DFI-T1202AA, DFI-T1203AA, DFI-T1204AA, DFI-T1205AA, DFI-T1206AA, DFI-T1207AA, DFI-T1208AA, DFI-T1209AA, DFI-T1210AA (DFI-T1200 EU/US series) TEST KIT: Testing Kit (for PlayStation®5/PS5) DFI-T1200JA, DFI-T1201JA, DFI-T1202JA, DFI-T1203JA, DFI-T1204JA, DFI-T1205JA, DFI-T1206JA, DFI-T1207JA, DFI-T1208JA, DFI-T1209JA, DFI-T1210JA (DFI-T1200 AS/JA series) Thanks for watching. Interested also on SDK (Software Development Kit), GDK (Game Development Kit), tools, firmware/updates, etc. Regards Have a Sony PS5 Dev Kit for Sale? contact me. Have a Sony PS5 Dev Kit for Sale? contact me. Have a Sony PS5 Dev Kit for Sale? contact me. Have a Sony PS5 Dev Kit for Sale? contact me. Have a Sony PS5 Dev Kit for Sale? contact me. Have a Sony PS5 Dev Kit for Sale? contact me. Have a Sony PS5 Dev Kit for Sale? contact me. Have a Sony PS5 Dev Kit for Sale? contact me. Have a Sony PS5 Dev Kit for Sale? contact me. Have a Sony PS5 Dev Kit for Sale? contact me. Have a Sony PS5 Dev Kit for Sale? contact me. Have a Sony PS5 Dev Kit for Sale? contact me. Have a Sony PS5 Dev Kit for Sale? contact me. Have a Sony PS5 Dev Kit for Sale? contact me. Have a Sony PS5 Dev Kit for Sale? contact me.
  8. I'm not sure whether anyone else has noticed, but Google have been buying a lot of property in Sunnyvale with some rather disappointing consequences for those who want to make a pilgrimage there. Firstly, there was Moffett Place, a 55 acre tech campus approved in December 2013 and built on the land south of 1265 Borregas Ave. Thus we lost the former Consumer Engineering, Consumer Sub Assembly, Consumer Final Assembly, Coin-Op Printed Circuit and 400/800/Pinball Manufacturing buildings at 1173, 1195 and 1215 Borregas Ave, 155 Moffett Park Drive and 1180 Bordeaux Drive. This was mostly leased to Google by Jay Paul after they already took all of the 26.5 acre Tech Corners just down the road and at least part of the 52 acre Moffett Towers next door as well as Moffett Gateway. Just last year, they signed leases on the units in Moffett Place and Moffett Gateway that they didn't already occupy. In 2017, Google started buying property in the area, particularly around the old WeirdStuff Warehouse. This included: 1190 Borregas Ave 1196 Borregas Ave (second Sunnyvale HQ / Computer Operations / ASRL) 1265 Borregas Ave (first Sunnyvale HQ / Coin-Op Engineering) 1272 Borregas Ave (Consumer Engineering / Microelectronics / Coin-Op Engineering) 1212 Bordeaux Drive 1330-46 Bordeaux Drive (including Consumer Chip Programming, Coin-Op Customer Service and Consumer Customer Service) 1360-68 Bordeaux Drive (including Maintenance Department and Board Games Division) 1323 Borregas Ave 1383 Borregas Ave (Consumer Warehouse? marked 1385 on the Atari map) 1393-95 Borregas Ave (Consumer Warehouse) 160 Gibraltar Court 165 Gibraltar Court (the latest acquisition, formerly TI) 140-146 West Caribbean Drive 360-394 West Caribbean Drive (including Consumer Warehouse - Components, Consumer/Coin-Op Warehouse and Consumer Warehouse - Finished Goods) ...as well as more property on First Avenue, Java Drive, Bordeaux Drive and North Mathilda Ave, bought from Verizon, and 16 acres from NetApp (about where the Atari logo is on the map). In fact, they've spent a staggering $1.4 billion on property in Sunnyvale in the past four years - 50 buildings, apparently... although I think it's more than that. This is what their acquisitions looked like in 2017 - there are more since: There are two further planning applications of particular interest: 1. Google Caribbean Campus (Project 2017-8042) In June 2018, Study Session 18-0536 proposed "to allow the redevelopment of a 40.5-acre site for two new 5-story R&D office buildings totaling 1,041,890 s.f. including a 4-level parking structure resulting in 59% FAR. The existing 679,225 s.f. of office & manufacturing buildings will be demolished." This was followed by Study Session 19-1153 in October 2019, Report to Board 20-0263 in February 2020, Report to Council 20-0356 in March and Report to Council 20-0433 in May, when the project was approved. More details are on the project page as well as the sites of designers Michelle Kaufmann Studio and BIM Designs. The decision is here. 2. 1265 Borregas (Project 2019-7507) In January 2020, Study Session 20-0160 proposed "the demolition of existing buildings and the redevelopment of four (4) parcels, including the construction of a new 5-story, 182,500 sq. ft. building (1265 Borregas Avenue), a lot line adjustment between 1265 Borregas Avenue and 160 Gibraltar Court, and construction of open space and surface parking (1190 and 1196 Borregas Avenue) serving 1265 Borregas Avenue. Phase 2 will include the demolition of the building at 160 Gibraltar Court and the construction of sports fields." It seems there is audio of the meeting. There was also Report to Board 20-0516, which appears to have been approved in May. The decision is here. Yes, they're demolishing the original HQ building. It would seem there's not enough car parking provision, so I believe they want to demolish the second HQ building and 1190 to use as the car park. A bit of a sad end to both buildings, really... but particularly one becoming the other's car park! Anyway, you can see the previous refurb plans and have a look at how the building appears today. This will leave the map of Atari buildings rather depleted: However, it's not all bad news. As you can see, they're introducing some greenery and the Moffett Park Special Plan is for an eco-friendly Smart City and a presentation was given in June on the Green Link and Manila Avenue Bikeway Project. So it would seem Google are thinking about sustainability. It is, of course, a shame that nobody bought one of the HQ buildings to use as a museum... but that's understandable, considering they paid $24 million for 1265 and $25 million for 1196! Perhaps an Atari super fan could contact the developers and ask to keep a piece of Atari history when they knock it down? What would you go for? The reception desk? The doors? The street number? I had a search and couldn't see anything about this on the forums. Sorry if this is the wrong section, but I don't see a general Atari chat - mods feel free to move it somewhere more appropriate.
  9. 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
  10. 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
  11. I made a mini game for my VCS, I call it PittFool , homage to a favorite classic game.
  12. 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!
  13. 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.
  14. 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 meant 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
  15. 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.
  16. 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
  17. 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
  18. 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
  19. 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.
  20. 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.
  21. 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
  22. 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!
  23. 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
  24. 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
  25. 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...