Jump to content

Search the Community

Showing results for tags 'Development'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Atari Systems
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Gaming General
  • 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 7 results

  1. Been a while since I attempted this, and perhaps I'm getting Atari 8 and 16 bit machines a bit confused, but I remember writing a utility back in the day that moved the screen around memory. One interesting thing was that if the pointer to screen memory was placed just before or just after the start of actual screen memory, there would be a neat artifact like 1-dimensional video feeback, where one line would get duplicated, then that would get duplicated, etc. It looked like a faux 3d perspective effect where the "closer" objects would be taller. I found From Compute's Second Book of Atari Graphics, Program two, here: http://www.atariarchives.org/c2bag/page185.php to move screen memory around, but it's not behaving how I'd like. I have a feeling it's limited to a specific region of memory. I started with it, modified to use graphics 9. It does move the screen through memory using the arrow keys, but does not exhibit the powers-of-two one-dimensional video feedback I remember. Perhaps it's not crossing the screen boundaries in the way I remember? Modified listing using basic mode 9: 5 GRAPHICS 9 10 REM COARSE VERTICAL SCROLLING DEMO 15 REM PRESS UP/DOWN ARROWS TO MOVE DISPLAY THRU MEMORY 20 DLIST=PEEK(560)+PEEK(561)*256:REM GET START OF DISPLAY LIST 30 LMSL=DLIST+4:REM POINTER TO DISPLAY MEMORY 40 LMSH=DLIST+5 50 DISPLAYL=0:REM INITIALIZE ADDRESS OF DISPLAY MEMORY 55 REM READ KEYBOARD 60 IF PEEK(764)=255 THEN GOTO 60:REM WAIT FOR KEY 70 IF PEEK(764)=14 THEN POKE 764,255:GOTO 110:REM UP ARROW / 80 IF PEEK(764)=15 THEN POKE 764,255:GOTO 140:REM DOWN ARROW ? 90 GOTO 60 100 REM MOVE DISPLAY WINDOW INTO LOWER MEMORY 110 DISPLAYL=DISPLAYL-40 120 IF DISPLAYL>=0 THEN GOTO 170:REM CAN'T DISPLAY NEGATIVE MEMORY 122 DISPLAYH=DISPLAYH-1:DISPLAYL=0 124 IF DISPLAYH<0 THEN DISPLAYH=0 126 GOTO 170 130 REM MOVE DISPLAY WINDOW INTO HIGHER MEMORY 140 DISPLAYL=DISPLAYL+40 150 IF DISPLAYL>240 THEN DISPLAYH=DISPLAYH+1:DISPLAYL=0 160 REM CHANGE DISPLAY MEMORY POINTER 170 POKE LMSL,DISPLAYL:REM PUT NEW DIPLAY ADDR IN DISPLAY LIST 180 POKE LMSH,DISPLAYH 200 GOTO 60:REM GO WAIT FOR KEYBOARD ENTRY The eventual goal is to have a split screen using display lists, having a static mode 11 top—rainbow sky—and a "scrolling" (by changing memory that then propagates down the feedback loop) bottom section in mode 9—ground. The features on the ground should ideally be bits from memory (to simplify my landscape drawing code P189L2.bas.txt
  2. This Topic is intended for those who are willing to learn, assist in learning, develop and publish code using GPL, the Graphic Programming Language proprietary to TI 99/4A also known as the GROM Language. To ensure that one can start from scratch and try to dabble a few lines of code in GPL I will list the most basic things that are needed and then show you a very small GPL language program which fills the screen with the letter A. 1. Install python 2.7.11 (Do not install 3.5 as it will not work with the GPL emulator I will propose) https://www.python.org/downloads/ 2. You need an assembler for windows and good documentation according to the assembler chosen. Assembler: https://endlos99.github.io/xdt99/ Documentation : http://www.unige.ch/medecine/nouspikel/ti99/gpl.htm I will assume you install it in C:\XDT99 3. You need a great emulator to run your well crafted virtual cartridges which we shall be creating. Classic 99 is my favourite : http://www.harmlesslion.com/cgi-bin/showprog.cgi?search=Classic99 I will assume you install it in C:\CLASSIC99 4. You need some kind of Editor I prefer Notepad++ : https://notepad-plus-plus.org/ 5. Setting up your assembler > There are clear notes on how to have XGA99 up and running to compile your .GPL code but I will cover this step by step for those who hate reading a lot of material scattered all over the place. Install XDT99, I selected c:\XDT99 folder. Unzip the attached file (xdt99.zip) into C:\XDT99, you can choose a different folder but there are some batch files you would need to change later. This will add a new folder to the standard XDT99 called "myfiles" and also the python program files are in C:\XDT99 (.py files) Point the PATH windows environment variable to point to C:\XDT99 where the.py reside. Please edit C:\XDT99\MYFILES\G.BAT and MG.BAT to point to myfiles and classic99 according to the paths you chose. Please note that all the files you create should be named <filename>G.gpl Example c:\xdt99\myfiles\testG.gpl To compile just go into DOS c:\xdt99\myfiles cd c:\xdt99\myfiles and type G test Note that I did not type G TESTG.GPL as the G.GPL will be auto appended by the G batch file. if no errors just type mg test. This will move TESTG.BIN to CLASSIC99\MODS 6. The last step is to execute the newly created cartridge. Fire Up classic 99 and select Cartridge->User->Open .... navigate to c:\classic99\mods and select the bin file. The TI Program menu will contain the program called TEST in position 2. Have fun... In this post I will place code snippets and BIN files for all to try and enjoy. xdt99.zip
  3. Hello folks, After the positive response from the Homebrew group on Facebook, I decided to start creating a tool for drawing out kernel code. This would ease out development of correctly timed drawing code, using a simple drag-and-drop tool. Here attached is a HTML demo of what I've made last 2 days. It is still very preliminary, but it is just to give the feeling. kernelpaint.html see also on Github: https://github.com/Yvar-deGoffau/Kernel-Paint Please send in any feedback, and I hope to find more free time in my week. Of course, all contribution is more than welcome!
  4. I was looking over an old game in a hex editor recently, and I noticed something interesting with the text data embedded in the program. All of the strings seemed fine until the end character, which was a byte value of 128 or greater. I realized what the program was doing was using the top bit on ASCII characters to determine the string end. This lets you store strings at their exact size, rather than one byte more to store either a length byte or a null terminator byte. Very clever! So I thought, how to leverage this on the TI, where I've spent a considerable amount of effort building menus and interfaces that consumed a lot of memory because of having to store strings and their addresses and lengths? So I write a routine, VTEXT, and it's companion, VTEXTC. It's a subroutine that takes the address on screen into R0, and a pointer to the desired text in R1. No length needed! It writes to the screen until it encounters the eighth bit, and stops. VTEXTC is the same, except it doesn't alter the VDP address. This will allow you to write concurrent strings to the screen one after the other. Advantages are: - Your text strings take up exactly their length in space - Reduced operations for plotting text to screen Disadvantages are: - All static text in source files has to end with the top bit set, which can be aggravating to figure out the value of a given ASCII character - Slower than a straight VMBW due to the need for a COC and copy operation on every character - If you don't have the top bit set, it could overrun the screen buffer and the rest of VDP Future expansion may include the idea of "values". Using characters 0-31 can be used as an indicator to, for example, switch to a stored numeric value in text form, so you can introduce string formatting. "%0 takes %1 damage!" for example, so it knows to plug in the 0 and 1 pre-calculated values into the string as it's writing to the screen. TOPBIT DATA >8000 * Top bit word VDPWA EQU >8C02 * VDP Write address port VDPRD EQU >8800 * VDP Read address port VDPWD EQU >8C00 * VDP access port (input/output) SCRADR EQU >0000 * Screen address TXTLN1 TEXT 'This is sample tex' BYTE 244 TEXT 'More sample tex' BYTE 244 TEXT 'Sample Tex' BYTE 244 TEXT '-Sample Tex' BYTE 244 * Video Text writer, CPU to VDP * Uses only R0 and R1 for location, length is determined by the top bit * Sends R1 value back to calling rouine for continuous stream of text * VTEXTC does not update position in VDP, so you can write multiple strings concurrently VTEXT ORI R0,>4000 * Set address for VDP write SWPB R0 * Swap to low byte MOVB R0,@VDPWA * Move to VDP address SWPB R0 * Swap MOVB R0,@VDPWA * Move to VDP address ANDI R0,>3FFF * remove extra bit so address is preserved for subsequent calls VTEXTC MOVB *R1+,R2 * Copy character to R2 COC @TOPBIT,R2 * Check if top bit is set (end of line indicator) JEQ VTEXT1 * If so, skip to end MOVB R2,@VDPWD * Write character to screen JMP VTEXTC * Loop VTEXT1 ANDI R2,>7F00 * Reset top bit on character MOVB R2,@VDPWD * Write to screen RT * return to calling program * Example LI R0,SCRADR+128 * Set R0 to SCRADR+128 LI R1,TXTLN1 * Set R1 to start of text BL @VTEXT * Write string to screen AI R0,32 * Add 32 to screen position BL @VTEXT * Write a second line of the text LI R0,SCRADR+256 * Change R0 to a different position BL @VTEXT * Write next line to screen BL @VTEXTC * Write the next text segment immediately after the prior * Program continues...
  5. And now, as a free gift to the Intellivision development community, I bring you - RobotFindsKitten. It's as good as finished. The documentation is included. Enjoy! RobotFindsKitten.zip
  6. Hi. I went ahead at full speed for IntyBASIC v0.9 with new powerful features to ease programming, in order to help to the many programmers that are using actively IntyBASIC: Cybearg, catsfolly, freeweed, atari2600land, Tarzilla, grips03 and many other people. (put a message in this thread if I missed you!) Most suggestions made it and some really needed features: Added ON [expr] GOTO/GOSUB statement (to alleviate the need for dozens of IF statements and it's faster!) STACK_CHECK statement to verify your code on the go for unwanted recursion (GOSUB without RETURN) INCLUDE statement to separate your code/graphics/music in different files (needed for bigger games!) DEFINE statement with expressions as parameters. (atari2600land suggestion) Fixed numbers and two fixed operators for playing with them (+. and -.) (GroovyBee suggestion) Multiplication and division operators optimized for constant 256. (intvnut suggestion) Remainder operator optimized for constants 32, 64, 128 and 256. Extra comments in manual for SOUND, MUSIC, MODE and DEFINE. (freeweed suggestion) IntyColor limited to 16 GRAM per block in order to support PLAY without modifications. Thanks everyone for using IntyBASIC, it feels great to contribute! Enjoy it! intybasic_compiler_v0.9.zip
  7. Hi all, So I'm slaving away writing up as much CRPG code as I can... I want to try and get at least an implementation of ALL the game logic done so I can debug and fix and start really focusing on completing the game's story and dungeons and actually try and GET THIS DONE ten years after I started! I have a small problem though to fix... So I have a saved game file, which contains the basic party and character data. However, this isn't enough to preserve the whole game. There are "mob files" associated with each set of maps, which need to be altered ON DISK during play. This will let me make sure treasure chests stay empty, people say different things after you've stopped the bad guy, and so forth. I'm doing this because the one major complaint I've heard with a lot of vintage CRPG's is the total lack of persistence in the world. This is understandable with the older technology, but I'd like to have mine be a much more dynamic experience than that. The problem though, is how to handle saved games. Most gamers are used to being able to just restore from the last save if they don't like what happened in the game, and get a do-over. Allowing for this, though, is going to be a huge strain on the game. In particular, I'll have to actually copy and create WORKING copies of each mob file (4k each) every time you load a saved game, only modify those, and then copy ALL of those records back to the main game files if you actually save the game. (Also, yeah, you'll need to have master copies of the files.) In assembly, this will be significant work. Effectively, I'm using a disk file to act as long-term memory storage. (And before you ask, no, I don't have space for this in CPU RAM anywhere.) So at start-up, it would need to load up the entire mob file and save each record back into the saved mob file. Each mob file is 2048 2-byte records, so it will take awhile to do this. I'd feel better about this if I could treat length-2 records as length 128 for reading/writing purposes, but I suspect this won't work at level 3 access. (I'll have to write some prototype code to test this out.) Then I started thinking... what if you COULDN'T restore a prior save? What if, too bad, you are going to just have to deal with things, no do-overs? So in this case, every time you did something that altered mob records, it auto-saves the game for you, and that's your new restore point. Would this work, or would players hate it? So I'm polling and seeing what people think about saved games in CRPG's! Looking forward to everyone's opinion on the subject!
  • Create New...