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 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Gaming General
  • Marketplace
  • Community
  • Game Programming
  • Site
  • Classic Gaming News
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions
  • Robin Gravel's new blog's My blog
  • Atari Video Club's Harmony Games
  • Atari Video Club's The Atari Gamer
  • Atari Video Club's Video Game Summit
  • Atari Video Club's Discsuuions
  • Star Wars - The Original Trilogy's Star Wars Talk
  • DMGD Club's Incoming!
  • DASM's General
  • AtariVox's Topics
  • Gran Turismo's Gran Turismo
  • Gran Turismo's Misc.
  • Gran Turismo's Announcements
  • The Food Club's Food
  • The Food Club's Drinks
  • The Food Club's Read me first!
  • The (Not So) Official Arcade Archives Club's Rules (READ FIRST)
  • The (Not So) Official Arcade Archives Club's Feedback
  • The (Not So) Official Arcade Archives Club's Rumor Mill
  • The (Not So) Official Arcade Archives Club's Coming Soon
  • The (Not So) Official Arcade Archives Club's General Talk
  • The (Not So) Official Arcade Archives Club's High Score Arena
  • 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
  • ZeroPage Homebrew's Schedule

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start










Custom Status



Currently Playing

Playing Next

Found 75 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 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.15 - 20200916) 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 2.20.13 - 20200219) 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.3 - 20201007) 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 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. 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...
  3. Here's the 6502 assembler I mentioned recently on the Atari 8-bit forum. The reasons to write this were: 1.) None of the assemblers I tried could generate correct code for code assembled to run in zero page and have forward references to other code in zero page, changing their operand in real-time. 2.) I wanted to write an assembler in sh (years ago, I came across osimplay, which I thought was pretty neat). shasm65 is written in sh, the Unix Bourne Shell, with a few extensions used which are not available in all sh incarnations. So far, I have adapted it to work with bash, zsh (~28% faster than bash) and mksh (ksh93, ~52% faster than bash). ash, dash, ksh (ksh88) and pdksh all fail to work, either because they lack array support or do not allow function names to start with a dot. Both issues could be "fixed", but that would make it slower and/or pollute the internal namespace, so I decided against it. Its syntax is different from all other 6502 assemblers, because an input file is treated as just another shell script, which is sourced by the assembler. Mnemonics are function calls and its arguments are the operands. Labels are defined by using the special function L and assembler directives are functions starting with a dot, like .org, .byte, .word, et cetera. Labels are referenced as shell variable names (ex. jmp $label). Numbers/memory locations can be specified in decimal, hexadecimal (ex. 0xfffe) or octal (ex. 0377). To fix the main reason for writing this assembler (see point 1. above), shasm65 uses different mnemonics for some addressing modes. For example, loading A from a zero-page location is lda.z. This way, the assembler knows immediately exactly how much storage an instruction requires. addressing modes: implied no suffix, ex. cli accu .a, ex. rol.a zp .z, ex. lda.z 0xfe zp,x .z, ex. adc.z 128,x zp,y .z, ex. stx.z 64,y (ind,x) .i [,x], ex. lda.i [23,x] (ind),y .i [],y, ex. cmp.i [017],y immediate ., ex. lda. 17 absolute no suffix, ex. dec 0x6ff absolute,x no suffix, ex. inc 0x0678,x absolute,y no suffix, ex. ldx $fubar,y (abs) .i, jmp.i [0xfffe] relative no suffix, ex. beq $loop directives: .org start [dest] start address of next block (optionally loaded at different location) .byte x y z ... include literal bytes (no comma but spaces between the arguments) .word x y z ... include literal 16-bit little-endian words .ascii "ascii string" include literal string .screen "string" include literal string of Antic screen codes .space size reserve size space .align b align to b-bytes boundary .binary filename include _raw_ binary file filename . include source file (shell script, library functions, etc.) L name define label Because both the assembler and the source files it assembles are just shell scripts, you have all of the shell functionality (including calling external applications) as your "macro" language. You can create your own functions, use for loops, tests, if/then/else/fi conditional assembly, arithmetic, all you can think of. # lines starting with a hash are comments # the code below demonstrates a few of the features START_ADDRESS=0x3000 clear_pages() { # start number_of_pages ldx. 0 txa L loop for foo in `seq $1 0x0100 $(($1+($2-1)*256))` ; do sta $foo,x done inx bne $loop } .org $START_ADDRESS L clear_some_mem # inline unrolled loop to clear 0x4000-0xbfff clear_pages 0x4000 $((0xc0-0x40)) rts L host_info .ascii $(uname -a) There are two built-in functions: lsb() least-significant byte, ex. lda. `lsb $dlist` msb() most-significant byte, ex. lda. `msb $handler` Variable-, function- and label names should not start with an underscore or a dot. Both are reserved for the assembler itself. Also, all shell reserved words are prohibited. shasm65 has the following command line options: -oFILE write output (Atari 8=bit $FF$FF binary format) to FILE -v verbose output -h -help --help -? output credits, license and command line options with a short description and their defaults So, why a shell script? Well, because I can, it is fun, the code is short (~300 lines), it runs on many, many platforms, it provides a very powerful scripting/macro language and it's fun So, no drawbacks? Yes, there are. Shell scripts are interpreted and therefore shasm65 is a lot slower than the usual assemblers written in C and compiled to native machine code. I have probably missed describing some features or quirks, but basically, this is it. Have fun Any questions, post below. shasm65-0.91.tar.gz
  4. In my ramblings with Level-2 and Level-3 I/O I found that, if a file is opened for Level-3 I/O, a Level-2 I/O call appears to fail. In a test program I open a DF128 file and read the contents. At EOF I close the file. The test program uses a copy of Tom Bentley's "TCIO" library that I disassembled and modified. I added two functions, 'tstat' and 'tstats' 'Tstat' uses the Level-3 STATUS (Op-code 9) command to get information about the test file. 'Tstats' uses the Level-2 Get-File-Info (0x14) command to get information. I was going to merge the two so I can get info to load a PAB for Level-3 access. Before and after each Level-3 TCIO call I use 'tstat' and 'tstats' to see how the information changes as the program performs the various library calls: Use 'tstat' to get file status (Level-3 Op-code 9). Print results and info. Use 'tstats' to get file information (Level-2 Op-code 0x14) Print results and info. Do a Level-3 operation. Get file status (Level-3 Op-code 9). Print results and info. [Repeat Step 1.] Get file status (Level-2 Op-code 0x14). Print results and info. [Repeat Step 2.] I found that Level-2 'Get File Info' command appears to fail with Error Code 7 (file error) if the file is opened for Level-3 access. After closing the file the Level-2 commands once again work. My merged file-info function will have to skip calling the Level-2 call if the file is open, but I do not see that being a problem. Also, I hate to say that my copy of Thierry Nouspikel's TI99-Pages has the 0x14 command returning the record-count at Result-pointer+8 as a byte value. Fred Kaal says this is a word value, and my experiments seem to indicate the record-count is a word. Both sites have been immensely useful for my experiments. K-R.
  5. I'm learning assembly, and in reading the Editor/Assembler manual for the DIVision statement, I was surprised to find that if the divisor and dividend are equal, DIV doesn't return 1 with remainder=0. It sets the overflow bit. I assume that the DIV statement works by repeated subtractions. So I would naively expect that, say, 5/5 would involve subtracting 5-5, incrementing the quotient to 1, and checking the remainder (0). Why does it cause an overflow, instead? (I don't know if this is really appropriate for the Development sub-forum, but I thought it might be because of getting into the nuts and bolts of the CPU. Apologies if it's in the wrong place.) Related: I have found an error in the E/A manual for the AB command that isn't listed in the Erratum. Is anybody compiling a list of additional E/A manual errata here?
  6. Hi, all, I'm practicing assembly language with the Editor/Assembler, using the xdt99 cross-assembler with Emacs on a Mac and running it on js99er.net for the emulator. So far, everything has gone very smoothly...but this one weird bug: If I have a period in a TEXT directive string, I get unpredictable VDP results when I display it using VMBW. For example, I printed my name to the screen (along with some other text), with the text set as: MSG2 TEXT 'Timothy S. Hamilton' The other strings printed to the screen just fine with VMBW, but this one came up with the last byte displayed as a space: Timothy S. Hamilto Thinking I'd miscounted the bytes by one, I tried other combinations of characters. It turned out it was the period causing the problem. Later, after putting it back in, sending this same string to VMBW caused the screen to flash with colored noise. Another time, it made it go blank, with a solid color on the border. [Edit: It was another version of the string that caused the flashing, with one or two characters changed, but with the period still there. I haven't tried replicating that particular behavior since then.] I thought it might be some glitch in encoding the period, so I opened up my assembly source file in E/A directly and put the period in there. It displayed the period just fine. Does anybody have a suggestion as to what might be causing this and how to get around it?
  7. Hey everyone! It's been a while since I've worked on anything atari, but I've started up a new homebrew project that I hope to finish, tentatively called "Taxi Panic!". It's a top-down city arcade taxi game, I'm aiming for a city that's maybe 7x5 screens or so in size. You'll be picking up fares and delivering them to their destinations while the clock ticks down. Sort of a 2600 homage to Crazy Taxi. So far I've got a first pass at the driving physics and car sprites implemented, and now I'm working on designing the city layout. I'm trying hard to make the car physics feel as smooth and "analog" as possible, right now the movement works in 11.25 degree increments (32 directions), and the visual sprite has 16 increments (22.5 degree precision). movement values are based on a lookup table for sin/cos values times an acceleration curve for speeding up and slowing down. The city will be created entirely with the playfield, and I need each screen to line up properly, so in order to make designing it easier, I've decided to make myself a little tool: It's an app (made in Unity, since I'm familiar with it) that actually runs on my iPad, and lets me design the city easily. Eventually this data will be exported out of the app into playfield data for the game. Anyway, I'm starting this thread because getting feedback tends to keep me motivated. Let me know what you think!
  8. 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:
  9. I'm using my HDR ramdisk a lot while developing my TiVi editor. It's a real time saver. It's especially helpful when dealing with large files (which is kinda my primary purpose why I started working on TiVi). Today I read the updated documenation the InsaneMultitasker provided as draft. In there I learned that with ROS it's possible to use data buffers that reside in CPU RAM insead of VDP RAM. That is something I really want to try, because even with a RAMDISK reading a large file (think >100 kilobytes) takes some time. Now my challenge is; How can I easily detect from assembly language if I'm dealing with a "high-speed" disk device compared to a "slow" disk device ("floppy"). With a high-speed device I mean: CF7+, Nanopeb TIPI HDR ... I see differents possible paths here: CRC checksum on DSR space (but won't work with RAMBOS? Self modifiying code, configuration stored here too?) Check on some specific device feature? Actually I think that the CRC checksum logic would work quite well (I already did a test program on that about a year ago), but I'm not sure about HDR. Thinking about it would be cool if there is some unified way to detect device capabilities accross devices. For example a standard where there's a device "capabilities" file that is automatically created when the device is formatted. That file could then be processed from TI-Basic, assembly language or any other language supporting file I/O. Any ideas?
  10. 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...
  11. 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
  12. walker7


    From the album: The Best Assembly Computer

    A set of 7 different color palettes to use while programming.
  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. 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?
  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. 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
  17. 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....
  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. Just a small demo to celebrate New Year! Enjoy! where_is_the_snow.xex ps. Hope it won't induce any headaches
  20. 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?
  21. First of all - I'm rather a newbie with this system, so excuse me if this is an absurd question. As the title states, I'm looking for a way to run cartridge ROM's from a cassette tape. I saw this post here a while back: I am wondering what this task is. If anybody has even the faintest idea, could they please point me in the right direction? Thanks in advance!
  22. Lumi


    Hey all, I've posted about this before and got positive reception, so I'm trying to bring more attention to it. Any feedback is appreciated, although there's not much space left in the ROM for new features. This is an Atari 2600 homebrew game that's been in development for a while, and I believe it's finished now. It's a 4K, single player paddle game with SaveKey/AtariVox support. Plot: In this game, you must use the paddle controllers to steer your car left and right, avoiding obstacles in your path while collecting treasures. When you touch a treasure, you will get 1500 points and it will be added to your collection (the yellow dots on the left side of the status bar). You can have up to 5 treasures in your collection at a time. At any point, you can press the paddle controller's trigger to "burn" a treasure, giving you the energy to jump a short distance over any obstacles in your path. Any treasures you have left when your game ends will grant you an extra 1500 points. The game is won upon reaching 99,999 points. There are different kinds of treasures. Some of them will grant you unique powers: Gold coin: Does not grant any powers, is only worth points. Necklace: Gives you an extra life (the red dots on the right side of the status bar). You can have up to four lives at a time. Jar: Lets you pass through all barriers for a few seconds. Statuette: Lets you jump as much as you want with no penalties for a few seconds. The game will speed up when you get enough points. There will be a transition period where the game stops generating obstacles briefly, and the speed-up will occur while there are no obstacles on the screen. The difficulty switches toggle certain features. I highly recommend setting both to A for the full experience (Note: Stella sets both to B by default): - The left difficulty switch will make obstacles farther apart (B) or closer together (A). - The right difficulty switch turns moving obstacles off (B) or on (A). If the game feels too easy for you, enable Speed Freak mode! Simply press the game select switch at any point. When the title screen's background is red, this mode is enabled. Finally, the most important feature: if you press the paddle trigger while you have no treasures in your collection, you can honk the horn! Wow! As previously mentioned, the SaveKey and AtariVox are fully compatible for saving high scores (although there are no AtariVox speech functions). It saves unique high scores for Normal and Speed Freak modes. If you want to clear your high scores, press the game select and game reset switches at the same time. Drive! v1.4 NTSC.bin Drive! v1.4 PAL.bin Additionaly, here's a possible label I have for now:
  23. We are excited to introduce Nox Archaist, a new role playing game we are developing exclusively for the Apple II platform and emulators. Currently we are targeting a release date late this year. Nox Archaist will be available 100% free and the complete assembly source code will be posted on our blog. One area that we have been kind of winging is tile graphics art. We would like to offer a chance for members of the retro gaming community to participate in the design of Nox Archaist while hopefully improving the final result and getting the game into your hands more quickly. We are running a tile graphics contest! The top three submitted tiles will be determined on 7-31-2016 and the winners will receive the benefits below: *One custom in-game NPC named and based on input from the winner *Copy of the initial release of Nox Archaist on 5.25” floppy disks *Pre-release digital copy of Nox Archaist *Printed manual *Name mentioned in Nox Archaist game credits *Announcement of winners on our blog and in this forum *Any other goodies we can come up with To participate, just send us one or more tile designs using the criteria provided at the link below. Submissions can be sent via email to [email protected] Here is a link with contest details: http://www.6502workshop.com/p/graphics-contest-rules.html =====ABOUT NOX ARCHAIST===== Nox Archaist is a 2D tile based fantasy RPG with a classic Apple II look and feel. We are taking advantage of the full 128k available on the IIe and later models which will help us create features and effects that may not have been seen in vintage 1980s Apple games. Our goal is to explore how gameplay might have advanced in tile-based RPGs if substantial development had continued on the Apple II platform past the late 1980s. Game play videos and screenshots showing the current evolution of the Nox Archaist game engine are available below. http://www.6502workshop.com- Nox Archaist website with our blog, current gameplay videos, screenshots, and gifs. - Demo gameplay video featuring the current game engine. - Demo gameplay video featuring sunrise/sunset and in-game clock features
  24. Just a quick question regarding illegal opcodes. Have there ever been any cases where such opcodes work on one machine but act erratically on another? Not sure if there are different revisions of 6502s in different 7800s or not. I'm not going crazy with them so far, and have found LAX #$00 ( #$A7 #$00 ) to be handy in a few places, but I'd like a bit of peace of mind they'll work across the board. Thanks in advance!
  25. 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
  • Create New...