Jump to content

Search the Community

Showing results for tags 'assembly'.

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

  1. Welcome to Atari Dev Studio for designing homebrew games for the Atari 8-bit systems (Atari 2600 and 7800). Atari Dev Studio is a one-stop-shop for any programmer and includes a number of built-in features to allow you to design, develop and test games for your favourite system. Get started with batari Basic (2600) or 7800basic (7800) using easy to learn BASIC-like languages or go hard-core with assembly using dasm. During development test your creation using the Stella (2600) or A7800 (7800) emulators right from within Atari Dev Studio. Requirements Atari Dev Studio is an extension for Microsoft's cross-platform IDE Visual Studio Code and will run on the Windows, Linux and macOS platforms. The latest releases of batari Basic, 7800basic, dasm, Stella and A7800 are included so you can begin coding straight after installing the extension. Features Atari Dev Studio includes the following features: Develop your game on Windows, Linux or macOS Compile source code for your Atari 2600 or 7800 using batari Basic, 7800basic or dasm Use scripting (makefile, batch or shell script files) to build your dasm projects [preview] Optionally launch and test your game using the Stella (2600) or A7800 (7800) emulators Document outline support (batari basic, 7800basic, dasm) Peek/Go to Definition and Reference support (batari basic, 7800basic, dasm) Built-in Sprite Editor (also suitable for tiles and other objects) [preview] Manage your project using the File Explorer or version-control your source code directly with GitHub (and others) using the built-in features of the Visual Studio Code platform. Provide references to your own specific releases of each language or emulator rather than use the includes ones via the Settings. Additional features are planned for the future. At this time the focus is on the core functionality and ensuring full cross-platform support. Installing Atari Dev Studio What is Visual Studio Code? Visual Studio Code (VS Code) is a streamlined code editor with support for development operations like debugging, task running, and version control. It aims to provide just the tools a developer needs for a quick code-build-debug cycle and leaves more complex workflows to fuller featured IDEs, such as Visual Studio. Which OSs are supported? VS Code is a cross-platform application which runs on Windows, Linux and macOS. See requirements for the supported versions. Note: Linux users on 64-bit systems will be required to install the 32-bit compatibility libraries on your system to ensure everything will run as expected. Note: macOS users will require a 64-bit operating system to fully utilise all features of Atari Dev Studio and will be required to install the SDL libraries on your system to ensure the A7800 emulator will run as expected. Installing the extension Once you have installed VS Code (available here), open the VS Code program and complete the following: From the Activity Bar, click the Extensions button to display the Extensions window. From the Extensions window, type Atari into the Search box and press Enter to display the list of available extensions. From the list of available extensions, locate Atari Dev Studio and click the green Install button. Updating the extension Updates will be regularly provided and you will be notified via VS Code when one has been made available. Once an update has been installed you will generally be prompted to restart VS Code. Using Atari Dev Studio Compiling your program To display the available extension features press CTRL+SHIFT+P to display the Command Palette. From the command palette prompt type adv to short-list the available options: ads: Open the Welcome page ads: Compile source code (Shift+F5) ads: Compile source code and run in emulator (F5) ads: Kill build process ads: Open the Sprite Editor Language Selection When you load a file the initial language will be chosen based on the file extension. For example: batari Basic (.bas, .bb) [Default for .bas files] 7800basic (.bas, .78b) dasm (.dasm, .asm, .a, .h) To change a language you can click on the Status Bar Language selector and a list will be shown allowing you to choose another language. Optionally in the Settings you will be able to either let the extension choose based on the active language or set a specific language to always compile against. Build scripts [preview] Prefer using scripts to build your dasm games? If you have chosen to override the dasm compiler (select Make via the Settings) , Atari Dev Studio will scan and detect for makefile, batch (makefile.bat) or shell scripts (makefile.sh) files which are located in your root workspace folder to build your game. Note: You are totally responsible to ensure your environment is properly configured to allow you to utilise the tools and applications you will be interacting with. No support will be provided for this feature. Status Bar Apart from using the Command Palette to select compilation, there are a number of short-cut buttons on the Status Bar allowing you to: Display the extension version (might be useful at times) Open the Welcome page Open the Sprite Editor Compile source code (Shift+F5) Compile source code and run (F5) Note: The short-cut buttons on the Status Bar can be turned off via the Settings. Sprite Editor [preview] Atari Dev Studio includes a simple and easy to use Sprite Editor allowing you to create sprites, tiles and other objects for use in your projects. It has the following features: New Project wizard allowing you to select the console (2600 or 7800), size, region (NTSC or PAL palette) and total colors of your sprites Load and Save projects allowing you to save and come back to on-going work Editing features such and palette selector, zoom, pen, eraser, fill and move modes Ability to manage your sprites in a sortable list with options to copy, paste, duplicate, resize and delete Export sprites to batari Basic or assembly source code (2600) Export sprites to .png files (7800) - either selected or all (compatible with 7800basic 3+1 and 12+1 image requirements) Load and save palettes The Sprite Editor is based on Spritemate by Ingo Hinterding (GitHub) and was suggested by RandomTerrain for inclusion in Atari Dev Studio. I have customised the source to provide the required features necessary for editing sprites, tiles and objects for the Atari platforms. This work is currently in preview and will be on-going until all required features have been added. Settings There are a number of compiler, emulator and editor configuration options available in Atari Dev Studio which can be changed via the Settings (Preferences -> Settings -> Extensions -> Atari Dev Studio). Debugging the extension During the development phase of the extension I've added some developer output to assist with any issues that may appear. To view this output, open the VS Code Developer Tools by selecting Help -> Toggle Developer Tools from the menu, and in the debugger window ensure the Console tab is activated. This information may help identify the area where the extension is failing to process as expected. Known Issues There are currently no known feature issues. If you find a problem please raise an issue on GitHub or contact mksmith at the AtariAge community. Acknowledgements This extension is only available due to the great people of the AtariAge community who have created these tools to help developers build their vision. Special thanks to the following for either allowing the inclusion of their tools or for their ongoing help and encouragement: 7800basic - Mike Saarna (RevEng) batari Basic - Fred 'batari' Quimby dasm - the many contibutors Stella emulator - Stephen Anthony (stephena) A7800 emulator - Mike Saarna (RevEng) and Robert Tuccitto (Trebor). The AtariAge community including Albert, CPUWiz, Random Terrain, Trebor, Synthpopalooza, sramirez2008, Defender_2600, Gemintronic, Karl G, ZeroPage Homebrew, Muddyfunster, TwentySixHundred, Lillapojkenpåön, Andrew Davie, splendidnut, andyjp, sexyUnderwriter, MikeBrownEmplas, Generation2Games, cwieland, slacker Mats Engstrom (SmallRoomLabs) Languages Atari Dev Studio includes the following programming languages: batari Basic (release 1.5 - 20200307) batari Basic created by Fred 'batari' Quimby is a BASIC-like language used in the creation of Atari 2600 games. batari Basic is compiled to generate a binary file that can by used on actual Atari 2600 VCS hardware via cartridge (such as a Harmony or UNO cart) or by using an Atari 2600 VCS emulator such as Stella. batari Basic is an external project and can be downloaded separately from here. Further information is about this release is available here at AtariAge. 7800basic (release 0.18 - 20210314) 7800basic is a BASIC-like language for creating Atari 7800 games. It is a compiled language that runs on a computer, and it creates a binary file that can be run with an Atari 7800 emulator, or the binary file may be used to make a cartridge that will operate on a real Atari 7800. 7800basic is derived from batari basic, a BASIC-like language for creating Atari 2600 games. Special thanks to the bB creator, Fred Quimby, and all of the the bB contributors! 7800basic is included as part of this extension with many thanks to Mike Saarna (RevEng). 7800basic is an external project and can be downloaded separately here. Further information about this release is available here at AtariAge. dasm (release - 20201109) dasm is a versatile macro assembler with support for several 8-bit microprocessors including MOS 6502 & 6507, Motorola 6803, 68705 & 68HC11, Hitachi HD6303 (extended Motorola 6801), and Fairchild F8. Matthew Dillon started dasm in 1987-1988. Olaf 'Rhialto' Seibert extended dasm in 1995. dasm has also been maintained by Andrew Davie (2003-2008) and Peter Froehlich (2008-2015). The DASM team has taken over maintaining and updating dasm since 2019. dasm is an external project and can be downloaded separately here. Emulation Atari Dev Studio includes the following emulators for testing purposes: Stella (release 6.5.3 - 20210421) Stella is a multi-platform Atari 2600 VCS emulator released under the GNU General Public License (GPL). Stella was originally developed for Linux by Bradford W. Mott, and is currently maintained by Stephen Anthony. Since its original release several people have joined the development team to port Stella to other operating systems such as AcornOS, AmigaOS, DOS, FreeBSD, IRIX, Linux, OS/2, MacOS, Unix, and Windows. The development team is working hard to perfect the emulator and we hope you enjoy our effort. Stella is included as part of this extension with many thanks to Stephen Anthony. Stella is an external project and can be downloaded separately here. If you enjoy using Stella place consider donating to ensure it's continued development. A7800 (release 4.0 - 20200610) A7800 is a fork of the MAME Atari 7800 driver, with several enhancements added: Support for emulation of Proline Joysticks, VCS Joysticks, Lightguns, Paddles, Driving Controllers, Keypads, Trak-Balls, Amiga Mice, and ST Mice. Maria DMA timing has been improved further, with the addition of accurate DMA hole penalties. Improved saturated/normalized colors with palette selection. Streamlined UI including menu options to have an Atari 7800 system focus. A bug in the existing RIOT emulation has been fixed. POKEY sound emulation improvements. SALLY (CPU) and MARIA (Graphics chip) performance adjustments. Framerate updated to 50Hz/60Hz. Audio indication of no ROM loaded silenced. BIOS files no longer required and made optional. Implementation of XM control registers updated. MAME compatibility and syntax has been maintained, to allow for the reuse of MAME configuration files and front-ends. A7800 is included as part of this extension with many thanks to Mike Saarna (RevEng). A7800 is an external project and can be downloaded separately here. Further information about this release is available here at AtariAge. Releases 20210422 - Build v0.7.1 20210315 - Build v0.7.0 20210305 - Build v0.6.9 / 20210216 - Build v0.6.8 / 20210210 - Build v0.6.7 / 20201124 - Build v0.6.5 / 20201008 - Build v0.6.4 / 20200917 - Build v0.6.3 / 20200915 - Build v0.6.2 / 20200912 - Build v0.6.1 / 20200901 - Build v0.6.0 20200829 - Build v0.5.9 / 20200624 - Build v0.5.8 / 20200622 - Build v0.5.7 / 20200616 - Build v0.5.5 / Build v0.5.6 / 20200608 - Build v0.5.4 / 20200518 - Build v0.5.3 / 20200508 - Build v0.5.2 / 20200429 - Build v0.5.1 / 20200427 - Build v0.5.0 20200415 - Build v0.4.9 / 20200415 - Build v0.4.8 / 20200414 - Build v0.4.7 / 20200409 - Build v0.4.6 / 20200407 - Build v0.4.5 / 20200323 - Build v0.4.4 / 20200321 - Build v0.4.3 / 20200317 - Build v0.4.2 / 20200316 - Build v0.4.1 / 20200314 - Build v0.4.0 20200314 - Build v0.3.9 / 20200312 - Build v0.3.8 / 20200307 - Build v0.3.6/v0.3.7 / 20200305 - Build v0.3.5 / 20200217 - Build v0.3.4 / 20200129 - Build v0.3.3 / 20200128 - Build v0.3.2 / 20200108 - Build v0.3.1 / 20191022 - Build v0.3.0 20190807 - Build v0.2.8 / 20190711 - Build v0.2.7 / 20190614 - Build v0.2.5 / 20190611 - Build v0.2.4 / 20190604 - Build v0.2.3 / 20190528 - Build v0.2.2 / 20190522 - Build v0.2.1 / 20190521 - Build v0.2.0 20190513 - Build v0.1.9 / 20190510 - Build v0.1.8 / 20190506 - Build v0.1.7 / 20190428 - Build v0.1.6 / 20190425 - Build v0.1.5 / 20190421 - Build v0.1.2 & v0.1.3 / 20190420 - Build v0.1.1 20190419 - Build v0.1.0 - Initial release Manual download
  2. Greetings and felicitations, children of technology! A few of you may know me from around three decades back. I have to congratulate you all on this cool forum, that has amazing activity. I am happy that the community is still there. I am contacting the community again, because I am doing some work on Atari again. I am making a new programming language, that will be general-purpose, but that I am targeting at 8-bit Atari first. Most new languages don't target the old machines. There are a few exceptions, but they target the vintage machines specifically, and are not meant as general-purpose languages for modern systems. I think this is feeble and probably wrong in terms of language design: there are many bad reasons, but no good reason to not support small systems. C is still used everywhere, and it can do it. I think any new language should improve on C; it should not be less capable. I always thought this should be possible, and it is turning out to be true. At first I thought it would be harder to support the old systems, but it actually turned out to be easier, and it helped get the project off the ground. Small systems are much easier to work for due to less complexity, they are more motivating, they provide meaningful results earlier, they keep you aware of performance and they prove you can target very small devices, such as for Internet of Things. Like how Contiki became an IoT operating system starting on C64. I have wanted to do this language for some three decades, but the industry became ever more complex faster than I could master it. Every time I thought I could improve some things, the platform I was using was already outdated. For a quarter century, I didn't really know how to improve languages on the newest platforms, so I tried to use the best ones I could find. Yet almost every time I wanted to do a project or a commercial assignment and needed the platform and language to just work, I ran into walls that debilitated my efforts. This was all the more frustrating because there once was a system that I could do anything on that I wanted: my trusty Atari 8-bit. Perhaps my projects are too ambitious, yet this was no problem on Atari. I desperately need that power and control back, and in the past years, the puzzle pieces started to come together. Now it's a matter of doing the enormous amount of work required from a modern language. I am half a year into the project, and am double as productive as I have ever been. The language is mostly inspired by REBOL, of Amiga heritage: https://en.m.wikipedia.org/wiki/Rebol REBOL has great clarity and conciseness of expression, and a great capacity for abstraction, which can be used to define cross-platform abstractions. It has been measured to be the most expressive general-purpose programming language: https://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/ Among others, I was further inspired, for their performance and support of native Atari functionality, by Action!: https://en.m.wikipedia.org/wiki/Action!_(programming_language) and by PL65: https://atariwiki.org/wiki/Wiki.jsp?page=PL65 The language is past the proof-of-concept stage, but it is still very incomplete. On the other hand, it will match features expected from an 8-bit language before it will be able to match expectations for a modern language. I am working on a sneak preview release to let people try it. I will post examples as I go, if you like. After the sneak preview I will be working further on a crowd-funding website, where you will be able to influence the development through donations.
  3. I am developing a new language that I have been introducing here: After the Atari 8-bit, I am now targeting it at the 2600. I just posted the first demo here: Here is the source code: unsafe!!! constant reference volatile byte! [ ; TIA VSYNC= ~0000 VBLANK WSYNC COLUBK= ~0009 PF0= ~000D PF1 PF2 GRP0= ~001B GRP1 ENAM0 ENAM1 ENABL ] vertical-sync-bit= %0000'0010 VBLANK: ; Set beam to on to use the entire vertical-blank overscan area ENABL: ; Ball off ENAM1: ENAM0: ; Missiles off GRP1: GRP0: ; Players off PF2: PF1: PF0: 0 ; Playfield off; we only use the background byte! [jiffies colour] forever [ VSYNC: WSYNC: vertical-sync-bit ; Wait for end of scanline, then start vertical sync ; Vertical sync pulse. ; This lasts 3 scanlines, where some small work can be done to set up the next screen. colour: jiffies ; Begin colour gradient, shifted by jiffy counter ; Wait three scanlines, then end vertical sync, continue vertical blank VSYNC: WSYNC: WSYNC: WSYNC: 0 ; Vertical blank area, followed by the visible display area, ; followed by another vertical-blank overscan area. ; PAL and SECAM officially have 45 + 228 + 36 scanlines here, NTSC has 37 + 192 + 30. ; We generate 283 scanlines (plus the 3 for vertical sync), for a display frequency of 55Hz, ; inbetween PAL/SECAM and NTSC. It will work on all, if you have a tolerant television set. ; The first scanline is used for the setup overhead of the LOOP, ; so it gets the last colour wrapped over from the last scanline of the previous screen. ; Being the first line of the vertical blank overscan area, it is normally not visible. loop 282 [COLUBK: WSYNC: overflow increment colour] ; Increment background colour for every scanline overflow increment jiffies ] Here are some artifacts of the compilation. The assembler listing: https://language.meta.frl/examples/platforms/Atari/2600/rainbow.list A VICE labels file, for debuggers: https://language.meta.frl/examples/platforms/Atari/2600/rainbow.labels The memory sections map: https://language.meta.frl/examples/platforms/Atari/2600/rainbow.map It's my second 2600 program; please be gentle. 😁 The language will be cross-platform on as many systems as possible. 2600 programs are developed by cross-compiling. In many cases, it is also needed to pre-compute data for a 2600 program. You will be able to write such tools in the same language, on your PC or Mac or other favourite system.
  4. After about a year-and-a-half of work, I decided it was time to get some feedback on my my first Atari game, a work-in-progress adventure game, Anguna. The goal is a 2600 version of my Gameboy Advance homebrew game of the same name. I've still got quite a bit of work to do, but it's at least playable right now. My goal is to it in 16K, without any extra ram or DPC or anything like that. (despite having a lot of content, I still want to feel at least some of the constraints of Atari programming!) (The video here doesn't do well with the sprite flicker I use with multiple enemies) The goal is a fairly large-world action-adventure game, with powerups, items, multiple keys, etc. Currently, I just have the first starting dungeon finished, as well as a tiny bit of the overworld around the first dungeon. The inventory/map screen (which can be accessed via the color/bw switch) shows the player's inventory and stats, as well as your position on the world map. (the inventory isn't working yet, it currently shows all sorts of items and keys that you haven't collected). If you manage to find the bow and arrow in the first dungeon, you can use it by holding the attack button for more than half a second. I still have a lot to do, but thought I'd post what I have, to brave everyone's feedback. Some next steps I hope to do are: Improve the player animation (actually have an animation for attacking) Add more enemies (and fix enemy spawn locations in the overworld) Introduce "checkpoint" screens, and handle game-over better Get a password system working The source is all up under a pretty free license at Bitbucket. Some questions for anyone that tries it: Is the Color/BW switch an acceptable way to view the subscreen? Would the controller 2 button be better? Is the difficulty level ok? If anyone happens to try on a TV, how are the colors? I know they may not match, but I want to make sure they at least contrast enough to be playable and look ok. Did you hit any showstopper issues (crashing, getting stuck in a wall, etc?) anguna.bin
  5. Titanium is my first game for the Ti-99/4A written purely in assembly language. The name is a reference to the C64 game Uridium - a favorite of mine - from which I have borrowed many ideas, and, of course, to the TI. The game engine and the graphics on level 1 are based on my half-bitmap mode, vertical scrolling demo. (I would like to do a proper port of Uridium for the TI at some point, but that should be based on a different technique for the scrolling.) The game requires a disk drive, a 32K memory expansion, and a E/A cart or similar to run it. To start the game, insert the disk in any drive and use E/A option 5 to run DSKX.TITANIUM. I have not tried it with a real floppy drive, but I expect it to work. The gameplay is very simple: shoot all the targets, e.g. pyramids, to reach the next level. Avoid the blinking spheres and the enemy ships. Use joystick 1 or S, D, E, X + space to control the ship. P pauses the game. I don't know if it's too easy or too hard - it's difficult to tell when you have tried it so many times. This is the first game I'm aware that’s using the F18A, but only to avoid the sprite duplication issue that exists in the old VDPs (9918A, 9928A) in half-bitmap mode. If an F18A is detected the program uses a standard half-bitmap mode with only one pattern table. If an F18A is not present it uses three pattern tables, but still only one color table. This eliminates the problem on the old hardware, but also lowers the frame rate because it doubles the amount of data that must be sent to the VDP. If you press F on the start page you can manually switch between F18A mode and standard mode. This allows you to see the sprite duplication problem in action on the old hardware, and can also be used to increase performance on MESS where the F18A is not detected (the F18A is detected in Classic99). I'm using Tursi's mod player for the music on the start page. I tried to compose my own music, but it ended up sounding very similar to the Blade Runner, so I decided to use that as my main theme. Within the game I'm using my own, simpler sound player and excerpts from Bach's 'toccata and fugue in d minor' - a reference to Gyruss, which is another favorite of mine. I consider the game in its present stage a beta version. I welcome suggestions for improving the gameplay, but major additions at this point are likely to slow down the game. For now I will fix any reported bugs and release the first version, and in a month or two when I regain some energy I may release a version 2. More levels/maps could easily be added without affecting performance. I include the full source code and data files. The maps were created using Magellan, the music using mod2psg2. Thank you to everyone who has helped me on this project. It has been very interesting and a great learning experience, and I think it demonstrates that there's still some potential left in the old TI. [Edit 14 Aug 2013] Added version 1.0 attachment. Titanium_1.0.zip. An XB loader is now included, and the E/A 5 file is called TITA. 64K bank switched (379) ROM image: Titanium3.zip
  6. Glad to show an emulated MAC/65 environment with DDT, that can be use from a web page when you want to do some assembly in your free time : https://eahumada.github.io/AtariOnline/mac65/mac65-mame.html Example: ENTER #D:SPRITE1.LST ASM DDT G 500B (You can use the numeric keypad as joystick and some times when you have a game-pad and MAME recognize that is connected you can move the sprite) Sadly, JavaScript MAME is not an accurate emulator, but I have the hope than in the future some other JavaScript/WebAssembly emulator emerge (jsAtari800 maybe? jsAltirra?) to allow to publish Atari interactive 8-bit content Here is the page for the work in progress Project, please feel free to fork and use to create your own content: https://eahumada.github.io/AtariOnline/ Credits to '@8-bit and more' for the inspiration, when I see his videos I don't have and Atari with Mac65/DDT cartridge at hand, then I get this idea and also thinking how the authors of 8-bit content can share their creations live online, for teach and learn 6502 Atari programming.
  7. Does anyone know of a good tutorial on making title screens? I am making a home brew right now for a university project and I would like to add a title screen. I took a course on udemy on how to get started but he doesn't go over things like Procedural Generation and title screens and I'm not sure where to start. Also a good tutorial on animation would be helpful. In the course I learned how to make the character move around the screen but and implement an animation for than but not a cycling animation for every frame. I'll also include my code below if anyone is interested in looking at it. Thanks in adavanced! 🦊🐙 labyrinth.asm
  8. Hello! After some searching for MADS highlighting for Vim, I haven't found nothing useful, so I decided to write something new… The only solution like this which I found was vim-xasm, the XASM highlighting, but it wouldn't enough good to use with MADS (lack of preprocesor directives and so on) So, here it is! Completely new plugin, suitable for every serious Atari coder with Vim as his main editor. (Note: If Vim isn't your primary editor yet, give it a try! But remember, some of your habits will be quickly broken :>) URL for GitHub Repository (aka "The Giant DOWNLOAD Button"): https://github.com/skrzyp/vim-mads (of course, if you're not familiar with Git, you can still grab this plugin as archive, but you'll lose the ability to update it when something new will be added/corrected) Installation Manually: Put folders syntax and ftdetect in your Vim configs directory: Windows: %USERPROFILE%\vimfiles Rest of world: ~/.vim Recommended: Using Pathogen Clone this repo into your Vim path: git clone https://github.com/skrzyp/vim-mads ~/.vim/bundle/vim-mads Of course, I'm fully open for any suggestions and comments, even if you found any bug or problem, tell me here or make a pull request. I'm also very interested about any feedback from users. Screenshot (sorry, I don't have a code which use a full potential of MADS, but if someone has, send me your pic, please)
  9. For about a month I have been studying a little bit of Assembly through the great material gathered on the Random Terrain website. (https://www.randomterrain.com/atari-2600-memories.html#assembly_language) Although I managed to create my own kernel, several parts of it I still don't understand. And instead of spending effort with such deep learning, I researched if it was possible to simply create a kernel for batariBasic and continue programming in bB. I found this post which presents a way to use a custom kernel. With some modifications I got to this version below. It's a 2LK and I'm trying to use the same variables as bB to control the players, but this is the problem: I can't (I don't have enough knowledge) use the players pointer correctly. Could anyone clarify my ideas? Player0Draw = $A4 ; I'm not using the vars (0-47) Player1Draw = $A5 BackgroundPtr = $A6 ; $A7 .customdrawscreen custom_eat_overscan ;bB code runs during overscan. We wait for overscan to finish so the ;frame timing doesn't get screwed up. lda INTIM bmi custom_eat_overscan custom_do_vertical_sync ;just a standard vsync lda #2 sta WSYNC ;one line with VSYNC sta VSYNC ;enable VSYNC sta WSYNC ;one line with VSYNC sta WSYNC ;one line with VSYNC lda #0 sta WSYNC ;one line with VSYNC sta VSYNC ;turn off VSYNC custom_setup_vblank_timing ;use bB timing variables so it should work with both PAL and NTSC ifnconst vblank_time lda #42+128 else lda #vblank_time+128 endif sta TIM64T ; feel free to throw useful pre-kernel code in here, so long as it ; completes before vblank is over. custom_eat_vblank ;wait for vblank to complete lda INTIM bmi custom_eat_vblank lda #0 sta WSYNC sta VBLANK custom_setup_visible_timing ;my preference is to use TIM64T to ensure a full screen is drawn. lda #230 sta TIM64T ;------------------------------------------------------------------------------ ; Desenha a parte superior da tela ; 192 - 22 scanlines = 192 - (11*2) = 170 lda #$02 ; Cor cinza no PF sta COLUPF ; COR no PF lda #1 ; sta CTRLPF ; Liga o REFLECT ldx #11 UpperSection: sta WSYNC lda customPFPattern,x sta PF0 sta PF1 sta PF2 lda customPFColor,x sta COLUBK sta WSYNC dex bne UpperSection stx PF0 stx PF1 stx PF2 ; y position lda #80 adc player0height sbc player0y sta Player0Draw ;------------------------------------------------------------------------------ ;-- AREA DE JOGO ;------------------------------------------------------------------------------ ; Desenha a área de jogo ; 170 - 160 scanlines = 170 - (80*2) = 10 (base ... not implemented) ldy #80 ; Carrega o y com o tamanho da área de jogo KernelLoop: ; 15 - todal de 15 ciclos, vindos do bne KernelLoop ; Continuação da segunda linha do 2LK ; precalcula os dados usados na primeiralinha do 2LK lda player0height ; 2 17 - altura do Player0 - IMPORTANTE!! este valor deve ser altura-1 dcp Player0Draw ; 5 22 - Decrementa Player0Draw e compara com a altura bcs DoDrawGrp0 ; 2 24 - (3 25) se o Carry estiver setado, player0 está na scanline atual lda #0 ; 2 27 - caso contrário, desliga o player0 .byte $2C ; 4 31 - $2C = BIT with absolute addressing, trick that ; causes the lda (HumanPtr),y to be skipped DoDrawGrp0: ; 25 - 25 ciclos do pior caso na linha bcs DoDrawGrp0 lda (player0pointer),y ; 5 30 - carrega o formato do player0 <<----------------------------- It's not working sta WSYNC ; 3 33 - Aguarda o fim da scanline ;------------------------------------------------- ; começo da primeira linha do 2LK sta GRP0 ; 3 3 - @ 0-22, desenha o player0 efetivamente (entre os ciclos 0 e 22) lda (BackgroundPtr),y ; 5 8 - Atualizo a linha do BG sta COLUBK ; 3 11 - guardo o valor do BG no resitrador COLUPF lda (player0color),y ; 5 16 - Pega a cor do Player0 sta COLUP0 ; 3 19 - seta a cor do Player0 ; todo esse código acima precisa estar entre o ciclo 0 e 22 ; para adicionar mais alguma coisa neste scanline, é preciso liberar algo acima ; sobraram apenas 3 ciclos ... é possível ainda colocar algum padrão de PF em PF1 e PF2 ;-------------------------------------------------- ; pre calcula os dados necessáriso para a segunda linha do 2LK ; lda player1height ; 2 21 - altura do Player0 - IMPORTANTE!! este valor deve ser altura-1 ; dcp player1y ; 5 26 - Decrementa Player1Draw e compara com a altura ; bcs DoDrawGrp1 ; 2 28 - (3 18) se o Carry estiver setado, player1 está na scanline atual ; lda #0 ; 2 31 - caso contrário, use 0 para desligar o player1 ; .byte $2C ; 4 35 - $2C = BIT with absolute addressing, trick that ; causes the lda (BoxPtr),y to be skipped DoDrawGrp1: ; 28 - 28 ciclos vindo do bcs DoDrawGRP1 ; lda (player1pointer),y ; 5 32 - Carrega a aparencia do player1 sta WSYNC ; 3 35 - Aguarda o inicio de uma nova scanline ;--------------------------------------- ; inicio da segunda linha do 2LK ; sta GRP1 ; 3 3 - @0-22, desenha o player1 efetivamente (entre os ciclos 0 e 22) ; lda (player1color),y ; 5 8 - Pega a cor do Player1 ; sta COLUP1 ; 3 11 - seta a cor do Player1 ; todo o codigo acima precisa estar entre os ciclos 0 e 22. ; ainda há 11 ciclos sobrando, talvez um playfield ou ball, ou missile ; possa entrar aqui neste ponto. dey ; 2 13 - decrementa o y bne KernelLoop ; 2 15 - se não for igual a zero, pula plá pra cima ;------------------------------------------------------------------------------ ;------------------------------------------------------------------------------ ;------------------------------------------------------------------------------ sty COLUBK custom_eat_visible ;wait for the visible display to complete lda INTIM bne custom_eat_visible custom_setup_overscan_timing ifnconst overscan_time lda #35+128 else lda #overscan_time+128-3-1 endif sta TIM64T lda #%11000010 sta WSYNC sta VBLANK ;bB macro to return from a bank-switch gosub or from a regular gosub. RETURN customPFPattern .byte %11011001 .byte %11111111 .byte %11011001 .byte %11001001 .byte %11011111 .byte %11011001 .byte %11011001 .byte %11001001 .byte %01001001 .byte %01001001 .byte %01001001 .byte %01001001 .byte %11001001 .byte %00001000 .byte %00001000 .byte %11001001 .byte %11011001 customPFColor: .byte $00, $AA, $00, $AA, $00, $AA, $00, $AA, $00, $AA, $00, $AA, $00 Thanks in advance.
  10. Hello all, I'm currently teaching myself how to program the 2600 using the 8bit workshop tutorials. Currently, I am wondering how to slow down player movement. Here is the code I am currently using for player movement. ; Read joystick movement and apply to object 0 MoveJoystick ; Move vertically ; (up and down are actually reversed since ypos starts at bottom) ldx YPos lda #%00100000 ;Up? bit SWCHA bne SkipMoveUp cpx #2 bcc SkipMoveUp dex SkipMoveUp lda #%00010000 ;Down? bit SWCHA bne SkipMoveDown cpx #183 bcs SkipMoveDown inx SkipMoveDown stx YPos ; Move horizontally ldx XPos lda #%01000000 ;Left? bit SWCHA bne SkipMoveLeft cpx #16 bcc SkipMoveLeft dex SkipMoveLeft lda #%10000000 ;Right? bit SWCHA bne SkipMoveRight cpx #153 bcs SkipMoveRight inx SkipMoveRight stx XPos rts Normally, I am used to coding for the NES and I would be able to just DEX and NOP until the player slowed down, wondering what I would do here in this instance. Thank you! And here is a link to my current test project, took me all day yesterday how to figure out the 'ground' bit of playfield 2600 Test
  11. I am using this bit of code to decide if the velocity is going to be positive or negative when a new game is started. GetRandomByte lda Random asl eor Random asl eor Random asl asl eor Random asl rol Random ; performs a series of shifts and bit operations rts jsr GetRandomByte ; generate a random number lda #%10000000 ; 1 in most significant bit mean greater then 127 bit Random ; was it less then 127? bne RandomVX ; if it was then branch lda #$ff ; set the starting duck's x velocity to -1 jmp RandomVXDone ; and jump cause we're done RandomVX lda #$01 ; set the starting duck's x velocity to 1 RandomVXDone sta DuckVX ; store duck's initial x velocity jsr GetRandomByte ; generate a random number lda #%10000000 ; 1 in most significant bit mean greater then 127 bit Random ; was it less then 127? bne RandomVY ; if it was then branch lda #$ff ; set the starting duck's x velocity to -1 jmp RandomVYDone ; and jump cause we're done RandomVY lda #$01 ; set the starting duck's x velocity to 1 RandomVYDone sta DuckVY ; store duck's initial y velocity However no matter what the velocity always stays the same. Bin: https://www.dropbox.com/s/ikjnebg1moyn0k4/duckgame.bin?dl=1
  12. So, as I've mentioned before, I've recently come back to Atari 8 bit computing after decades away. Currently I don't actually have any of my old hardware, other than 520ST. I am in the progress of procuring some old hardware in the form of an 800XL and supporting hardware(possible disk drives/SIO solution/display/etc). One of the goals I have set for myself is to *finally* do some programming for the old 800XL. I did BASIC back in the day on my old 400/800XL, when I was a kid. Then didn't really touch computing from 90-96 or so while I was in the US Navy. After leaving the navy I went to school and became a software engineer, which I still am today. But I never have done any assembly programming. Until I have actual hardware to develop on, I plan on using one of the emulators I've used over the years(most likely Altirra) to write/test my code. I'm also considering using a windows editor/compiler for the actual development work, whether I have actual hardware or not. Does anyone have any thoughts on how they would proceed if they were me? More later...
  13. This is how the data is stored in files on this type of computer. NOTE: This is a work in progress. I will be updating this post as I think of stuff to put on here. Bytes $20-$7F represent the standard ASCII character set. Character $7F represents the cursor symbol. Bytes $00-$1F are control codes. $00 - ROM Section Header $01 - Palette $02 - Graphics $03 - Mappings $04 - $05 - $06 - $07 - $08 - Set Tab Width $09 - Tab $0A - Line Feed $0B - Comment Tab $0C - $0D - Carriage Return (same as $0A) $0E - $0F - $10 - $11 - $12 - $13 - $14 - $15 - $16 - $17 - $18 - $19 - $1A - $1B - $1C - $1D - Change Label Line Color $1E - Change Label Line Toggle $1F - Toggle Show/Hide Labels Characters $80-$FF are more control codes. When the file is saved, it is compressed using LZSS.
  14. walker7


    From the album: The Best Assembly Computer

    A set of 7 different color palettes to use while programming.
  15. Hey everyone, I'm very new to programming with assembly. Anyways, from the tutorial in this section of the forums I played around with the first kernel that is presented in Session 8. I made the lines alternate their colors with it. I ran it with SECAM60 after being satisfied, and wow is it an eyesore. I attached an image of the screen when I ran it. Challenge: look at the SECAM60 screenshot for 30 seconds and then turn away. pantomchap_test_game_5-17-2017-2.27PM.bin
  16. Hi, I think I'm doing something dumb but... I cannot see it. I have the address of a sub routine in a variable (System Ram location). I can branch on this address using @@loop CALL WAITVBL ; wait for VBlank ; jump to the current main routine MVI SUBROUT, R1 JR R1 B @@loop ; loop forever But in this case the return address is not set in R5 so within my sub routine, JR R5 won't come back to the @@loop So currently my sub routine ends with B @@loop but that's ugly. Is there a way to do something JSR R1 ? Note, as SUBROUT points to different subroutines along the time, I cannot do B @@ASUBROUT. Thanks....
  17. Operating from a Windows PC development environment, I would like to be able to test my 6502 Assembly code. So, for example: I might have this code: org $0600 CLC LDA #5 ADC #3 STA 203 <end of code> I would like to be able to execute a command from the PC which will check that the above code puts the value of '8' into memory location 203. It may run Altirra or a 6502 emulator in the background, but I need to be able to extract that memory location and then report it back to the calling program. At the end I want "Test passed" or "Test failed" or something similar displaying. This way I can build up an automated test suite for all of my procedures / sections of code / macros. I have no problem with it bringing up windows whilst testing is going on, but I want all of the windows closed at the end of the tests. Any ideas of the best way of implementing this? I guess I'd need to automatically dump the memory contents and then extract the memory values that I require...
  18. I've been playing around with user ISRs, and I'm somewhat puzzled by the result of this program: . main: lwpi ws li r0, handler mov r0, @>83c4 ; set user ISR limi 2 jmp $ position: data 0 handler: mov r11, r10 mov @position, r0 li r1, '# ' bl @vsbw ; standard implementation inc r0 andi r0, >1ff mov r0, @position b *r10 . This does not fill 2/3 of the screen, but simply displays two chars. Even more bizarely, the second char only appears after a couple of seconds. Now I realize that you probably wouldn't want to write to the VDP in the handler itself. In fact, I wouldn't enable interrupts in the first place but use vsync polling in my game instead. But can someone explain to me what is happening here? Is access to the VDP triggering another interrupt?! And what is causing the delay? (This is all in MESS, BTW.)
  19. One thing that has always bothered me about Super Breakout on the 2600 was the colors & sounds. I like the original game's much better and would love to be able to hack Super to use those. I know nothing about programming the 2600 (but I know the very basics of 6250 assembly). I have been playing around with running code at 8bitworkshop and was wondering if anyone had a disassembly of breakout and super breakout or could lend a hand in modding the game?
  20. 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
  21. Just a small demo to celebrate New Year! Enjoy! where_is_the_snow.xex ps. Hope it won't induce any headaches
  22. walker7

    Color Change Screen

    From the album: The Best Assembly Computer

    What a color changing screen for an assembler might look like.
  23. Greetings folks, Just an FYI for anyone looking for reprinted out of print programming books to try Lulu.com I have used Lulu before but this time I found a book I have been desperately looking for years. I have been wanting the Compute! published books Programming the 64 and Programming the Vic by West and was able to find the 64 on Ebay, but the Vic one appears to some rare air to find. I love West's two books for the C64 and Vic and have been wanting them for many years. I even went as far to email libraries in Texas once I found out they had the Vic book to offer them to buy it, however all of them could not sell the book to me.. I visited lulu and it looks like someone just recently uploaded the PDF and Lulu has made Programming the Vic for reproduction. I am just passing this on to anyone who may be looking for this awesome Vic 20 book! The printing is done well and it is the same size of the 64 original one and the binding is excellent. I also bought another copy (I have the original) of the Butterfields Machine Language for the C64, 128 expanded editions. The Butterflied book is printed much smaller but still looks good, I was surprised they went with the small size when it should be the same size of the West book. In any case I am not connected to Lulu and do not make any money or get anything from them.. I just wanted to pass on a place for anyone who was looking for these tough to find books and do not mind a reprint. The books were very reasonable priced. I put a few screenshots here for anyone who might be interested. I hope anyone who is interested in Assembly Commodore programming can find this knowledge useful for them. If anyone here is looking for these
  24. I want to read disk sectors using PAB >0110 and DSRLNK >A. This kind of worked, after I moved my workspace out of harms way. And yet, it wouldn't read beyond sector 0 for my sample disk. No matter which sector I put into >8350, I always got sector 0. After much hair pulling, I discovered that the read routine won't work for disks with random data on them, i.e., for disks without a (partially) valid TI file system. After I fudged a plausible sector 0 it works like a charm. So what's the magic ingredient -- the sector allocation table, disk geometry, number of AUs? And if reading sectors depends on sector 0, how is sector 0 read?
  25. Hey all! I got a lot done on my game today, and I feel that it's mature enough that I can make a post about it. After making a few VCS demos and such but not feeling like finishing them, I thought I'd come up with a game for the VCS I'd get passionate about. After Sprybug's awesome Sidescrolling games, I figured I'd try and make one myself, because sidescrollers are always awesome. Mine's not quite as complex as it only scrolls one way, but I figured I'd keep it simple for my first one. Binaries: Current Binary .8a - Update 10/16/2017 - Fixed Ghosts Old .8 - Update 9/23/2017 Re-coded collision, added 2 levels and under the hood changes. OLD .07h - Update 2/19/2017 Fixes weird bug with input capacitor (MUCH THANKS DIRTY HAIRY!) fixes FBP compatibility. OLD - .07g - Update 2/14/2017 (Later Evening) Adjustment to keep from Breadcat Battle 2x. OLD - Update - 2/14/2017 (Evening) Adds ability to move and shoot and shortens pre-Bread Cat jump. OLD - Update - 2/14/2017 - A lot of polishes, fixes, coloured levels, multi-enemies, etc. OLD - Update 7/28/2016 - Fixes flamethrower sound buzzing on lives screen. OLD - 7/28/2016 - Reduces Scanline usage to 262, tweak UI, Flamethrower Bugfix. OLD - Update 7/15/2016 - Fixes Jittering. OLD - Update 6/7/2016 - Updated Physics Demo. OLD - Update 6/6/2016 - Teaser demo! :3 Lush Multicolour landscapes full of danger! Current Title Screen:
  • Create New...