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 CDFJ+
  • 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
  • Robin Gravel's new blog's The Flintstones Comic Strip
  • 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
  • The Homebrew Discussion's Topics
  • Hair Club for Men's Bald? BEGONE!


There are no results to display.

There are no results to display.


  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start










Custom Status



Currently Playing

Playing Next

Found 25 results

  1. Has anyone thought of using some of the unused opcodes for debugger output instructions? For instance, you could have an instruction PRINT R0 that you insert in the program which would print the current value of R0 to the debugger's console. This would only work on a combination of an assembler and an emulator that understood the new instructions, of course. I assume a real TI would ignore illegal instructions if you left them in (wasting some clock cycles), but usually you would remove them first by setting a switch in the assembler. The instruction set could include instructions for printing registers/PC/ST/CPU/VDP/GROM memory, strings, VDP registers, statuses, etc. The point is that in many cases this would be faster and easier than traditional debugging using single stepping and breakpoints because the debugger output would be resistant to program changes that shifts the memory addresses around.
  2. I am working on a project (still working out some display and register issues) when it dawned on me. The original 400/800 had four controller ports and each port, in simple terms, had its own player register in PM Graphics (or in the OS). XL and XE machines removed two of the controller ports I assume to cut production costs. Does this mean that the extra player registers were removed as well or are they still intact? I'm asking because my game project is designed on paper to take advantage of all four player registers. I don't want to create something for just a specific line of Atari 8-bits...I want it to be able to play on all of them. Thanks in advance!
  3. Since we want to always share our source code, I have been wanting to post this for some time, but I wanted to add better comments first. I did try to add comments to communicate what the general purpose of a section of code is, but there is still a lot that will need to be interpreted. This was written in MADS and requires BATCMP9.xex to be in the source folder. I hope that this is useful to someone. If anyone reviews the code and thinks of tips you would like to share with us, that would be most welcome. We are relatively new at this as War Room is the first game that we created that was created entirely in assembly. This started out as a movement demo for acceleration, deceleration, skidding, etc. As the ABBUC contest deadline loomed, we didn't have a new entry so we worked quickly to make this an entry which ended up being a very rudimentary game. Since we were developing it up to the last minute, you will see some hard coded memory locations. We also added the Halloween characters for our "final" release after ABBUC since the ABBUC version still had some shortcomings that we thought needed to be fixed. One of the nice aspects is that since the game really doesn't come close to pushing the abilities of the computer so we were able to leave the code pretty straightforward. I don't think there is anything novel here but we hope that since the examples are so simple, they can be beneficial for learning: 1. DLI - a very simple DLI that changes the playfield colors after that top of the screen 2. VBI - Deferred - again, very basic - it updates player locations, checks CD, disables break key and other housekeeping. It also uses a very sloppy shortcut to stop the players from turning to double-width which was a recurring bug that would happen- as I recall, this bug was properly fixed, but the code to set it to single-width is still in the vbi. 3. Self-modifying code. In order to save space, we overwrite the lo byte and hi byte of the LDA target. 4. Custom character set - very basic character set changes 5. Simple movement physics - acceleration 6. Very simple AI - I know what the AI is doing, and I very rarely win - simply stated, the AI is more aggressive when it has more life left than the opponent. If it has less life or equal life, it runs around shooting bullets. The big advantage that the AI has, is that it shoots very accurately. 7. PAL/NTSC detection and adjustments to try to make gameplay and music the same speed. The characters were built with Paul Lay's player editor - 16 frames, 15 high. The order of the frames is listed in the source - left, left, right, right, down left, down left, down right, down right, up left, up left, up right, up right, Up, Up, Down, Down. I would attach some/all of those files but it won't let me attach .apl files. Any questions regarding sound & music will need to be deferred to Eric. I tried to acknowledge the help we received in creating this, but I am sure that I missed someone. Eric probably has more to add because I don't know who he worked with. Enjoy! batcmp9.xex Published WarRoom.asm
  4. Nox Archaist is a new role playing game in development by 6502 Workshop exclusively for the Apple II platform and emulators, with floppy and hard disk support. We are excited to announce the first in a series of mini stories using the Nox Archaist engine to demo the newest features in the game. The Nox Archaist story line is still under development. Any names or characters used in these mini stories are not intended to depict real or imagined NPCs, events, or bovines in the actual game. Any similarities are coincidental. ----Nox Archaist S1E1: Shattered Sword---- In this episode our hero travels to town and faces an epic struggle to get his sword repaired after breaking it over an ogre's head. http://www.6502workshop.com/2016/11/nox-archaist-s1e1-shattered-sword.html New game play elements to look for in this video include: *Conversation with NPCs *NPCs moving between locations on the map based on their daily schedule *New interactive tiles ----About Nox Archaist---- Nox Archaist, by 6502 Workshop, is a 2D tile based fantasy RPG with a classic Apple II look and feel. Our mission is to develop a modern evolution of the Apple II RPG genre, while exploring how gameplay might have advanced in tile-based RPGs if large scale development had continued on the Apple II platform after the 1980s. http://www.noxarchaist.com
  5. LEARN ASSEMBLY IN 8 HOURS with bB and the ASDK Tutorial Intro This tutorial will teach you 6502 Assembly programming for the Atari 2600 using a RAD Framework that abstracts the hardware so you can quickly marshal high level objects to build games like batari BASIC. Due to the similarities we will use BASIC examples side by side and use the bB compiler to illustrate (and to help with creating Assembly when preferred). Peruse and complete these short lessons over time or stay up all night drinking coffee and taking breaks to play Defender
  6. I understand that it would be good practice to "restore" the previous VBI routine address when "unhooking" a VBI routine that is no longer used. But where would I get the address to restore to from? Can I simply read it from VVBLKI? Do I assume correctly that if VBI program A is installed first and saves the correct address to restore to, and VBI program B is installed thereafter, uninstalling A would kill B as well as A knows nothing of B. Or ist there a defined way to tell a "previous" VBI routine about another one installed later? Thanks!
  7. Hello, I'm learning TI assembly at the moment, so far i have had relativly good progress with it but i was wondering if there were any TI asm tutorials out there. -Sam
  8. On March 26, 2018, I posted the following message to the BallyAlley Yahoo group: Is anyone interested in having a programming contest for the Astrocade? My ideas: 1) Program in machine language or BASIC 2) Short programs for a start 3) Program of any kind (game, demo, music, video art, etc). 4) Prize? I've no idea. Does anyone want to give this a go? Adam ----------------- David Dibbern responded with: My skills were fair back in The day, but I would be interested in a retro port contest. A contest to make any retro arcade game that was not already done for the Bally, ported over . I would even pay pal $10 for starting a prize fund for this. We could get some cool retro games that we wanted to see ported but didn’t ever make it to the Astrocade Thanks- Dave ----------------- Thomas Burtell said: This would be very interesting! Programming has changed so much over the years and we all have gotten better. I'm focusing on other stuff right now, but I'd definitely like to see this Bally-battle. It's like what they do on StackExchange with "Code Golf". You have to write the tightest code with the minimal of resources. ... back to lurking. ----------------- Is anyone here on AtariAge interested in a programming contest for the Astrocade, either in BASIC or machine language? Adam
  9. Hey Guys, As some of you know I'm in the process of releasing my first homebrew game called Candy Catcher which I'm very excited about and have been extremely happy with the responses I have gotten from the game so far. However during the development of that game, i quickly realized not only the complexity of my statements I was making in batari Basic, but also the amount of ROM (Read Only Memory) space my code was taking, I had some statements that were easily pushing 50 ~ 75 bytes. That doesn't sound like much but when you only have 4096 bytes to work with, you only have ten of those statements, you have used a 1/5th of your available ROM space. I was limited to 4k, easiest way for my to make my game into a cartridge and release what I was considering a budget title. I had many more ideas for additional features in Candy Catcher that never saw the light of day because of ROM limitation issues. So for my next game that I'm keeping quite until I have a playable demo to present, I decided to learn assembly to reduce the amount of ROM space my code is taking and to give me great control of the number of objects that appear on the screen and to give me more flexibility with the speed and execution of my code as well as cutting down on the ROM space my code requires. I'm going through Atari 2600 Programming Tutorial posted on Random Terrain's site, getting my machine setup and learning the basics of Machine Langauge from the beginning. I also have Machine Language For Beginners by Richard Mansfield and 6502 Software Design by Leo J. Scanlon as references as I go. I'm going to be doing all my development on my Mac Mini Server as its my main desktop (Mirror Raid Harddrives are freaking awesome) and I'm not having to run a VM of Windows XP to do development of my game which is also nice which I did for Candy Catcher. My goal is to update this blog weekly with examples of what I have figured out and with tips to help others along as well. Thanks Disjaukifa
  10. Hi, I am having an issue with getting a simple display going. What's supposed to happen is a brown smiley face is supposed to appear.on the screen. Instead, all I get is a black screen with nothing being shown. I tried using the debugger, but couldn't figure out what was going on as it kept getting stuck on the line checking to see if the players y position is equal to the current scanline until the overscan period. Source Code: https://www.dropbox.com/s/4vb0fdklz2oz2qb/source.asm?dl=0
  11. Hey guys. Need some help with this one... In particular, this one is focused on the internals of Extended BASIC, So I know we have some guru's around here on the subject. (Hey Rich!) I'm disappointed that the TI Tech pages fail to have any memory dumps or extensive exploration of the Extended BASIC cartridge. I forget where I got it from, but I found this method long ago to execute the start of an EA option #5 program through Extended BASIC: 100 F$="DSK1.PROG" :: ON ERROR 200 110 CALL INIT :: CALL LOAD(8196,251,214) :: CALL LINK("OPT5",F$) 200 PRINT "DEVICE ERROR!":"CORRECT AND PRESS A KEY" 210 CALL KEY(0,K,S) :: IF S=0 THEN 210 ELSE RETURN 100 Clearly it's linking to some subprogram that's part of Extended BASIC's initializations called OPT5... I'm not sure why it's loading >FBD6 to >2004, but I presume it's over-writing a utility vector of some kind, the value there upon INIT is >4000 initially. Anyway, this method works fine with most option 5 programs, but fails with my CRPG loader.... Probably because I'm placing my load program in low memory. I have it at the >3000 mark, so it should be preserving the part of low RAM it needs, but it still fails and just cycles endlessly. Can anyone describe exactly what the above routine is doing, and if there's anything I can do to make it work? I could see the XB utility only working in high memory, so I suppose in that case I'll just have to embed the assembly code using SYSTEX and execute it directly...
  12. What is the standard practice when configuring memory for programs written in assembly on the Atari 8bit? I can think of three ways to do it: Static definition, macro driven and allocation at run time. -The first two are akin to hardcoding and would still have to be compiled for a specific memory size. For example, if you had a game that could fit in 16k, you would just set your RAMTOP, Screen Memory, Player memory, etc accordingly and it should run on any Atari 400, 800, XL, XE that had 16k or more memory. Is this correct? -Would there be any advantage, in terms of compatibility, to using the third (runtime allocation)? In assembly, I see this as a slight disadvantage because references to screen memory, player location, etc. become more difficult or add cycles using indirect indexing.
  13. First, I have a Mini Memory, but after fighting with it for a week, I cannot seem to work out exactly how to create something that will work with Extended Basic & a 32K RAM expansion. So, I've been looking to buy the Editor Assembler package (cart, disks, manual, ref, & keyboard overlay/slip.) Though that might take a while. Until then, I've been working with several emulators to try and get some practice in. The problem is that I cannot seem to write anything that will work. I tried entering a program from the "Introduction to Assembly Language for the TI Home Computer" book available elsewhere here, but it still wouldn't run. I tried the code exactly as written in the TI Basic option of the Editor/Assembler cartridge. I also tried adding in EQU instead of REF for the 2 calls (VSBW & VMBW,) in Extended BASIC. The example program ran fine with (3 Load and Run) from E/A (with the return altered by decrementing twice to freeze at the end.) Am I missing some important step? My code included... It's just a simple program to place text at a specific screen location. IDT 'HSTR' * MAY NOT BE NECESSARY, BUT DOESN'T HURT DEF HSTR VMBW EQU >2024 XMLLNK EQU >2018 NUMREF EQU >2000 *ALSO TRIED REMOVING ALL THESE AND USING STRREF EQU >2014 * COPY "DSK2.XB-EQUATES GPLWS EQU >83E0 *WHICH I PAINSTAKINGLY COPIED FROM THE STATUS EQU >837C *EDITOR/ASSEMBLER MANUAL (WITH CORRECTIONS) CFI EQU >12B8 *ALSO TRIED VALUES FROM A COMPUTE! BOOK FAC EQU >834A USRWS BSS 32 BUFFER BSS 256 SAVRTN DATA >0000 EVEN HSTR MOV R11,@SAVRTN LWPI USRWS CLR R0 LI R1,1 BLWP @NUMREF BLWP @XMLLNK DATA CFI DEC @FAC LI R3,32 MPY @FAC,R3 INC R1 BLWP @NUMREF BLWP @XMLLNK DATA CFI DEC @FAC A @FAC,R3 INC R1 LI R2,>FF00 MOVB R2,@BUFFER LI R2,BUFFER BLWP @STRREF MOV R3,R0 MOV R2,R1 MOVB *R1+,R2 SRL R2,8 BLWP @VMBW LWPI GPLWS MOV @SAVRTN,R11 CLR @STATUS B *R11 * ALSO TRIED RT END
  14. I am trying to read the keyboard in order to implement a pause routine in a patched version of Shamus. I read all I could find about SKSTAT and KBCODE but it doesn't really work as expected. I do not use system VBI routines. I tried to load SKSTAT during VBI, AND $04 and act on the results of that, i.e. interpreting anything not zero as a keypress. I then check for a specific KBCODE (Space) to enter the pause routine. After a little delay I check for SKSTAT and KBCODE again to end the pause when it is pressed again. That works as well but the game only stays "unpaused" when I keep the space bar pressed. then SKSTAT seems to remain "latched" as the game will end the pause but jump right back unless that key is held. My understanding is that SKSTAT bit 2 should revert to zero if no key is depressed. In reality it seems to remain set (always?) and as KBCODE does not change when a key is released the next VBI jumps right back into the pause routine. My code is below. Any ideas what I did wrong? (The "PAUSECTR" and countdown from 4 in the PAUSING routine were intended to make sure the key is really depressed for a little while. The behaviour of the routine doesn't change when I leave them out, so I assume I am doing something wrong with SKSTAT.) XITVBV equ $E462 NMIEN equ $D40E DLISTL equ $D402 DLISTH equ $D403 KBCODE equ $D209 SKSTAT equ $D20F SKCTL equ SKSTAT AUDF1 equ $D200 HITCLR equ $D01E CHECKKEYS LDA SKSTAT ;this is where VVBLKI points AND #$04 BEQ EXIT LDA KBCODE CMP #$21 BNE EXIT0 INC PAUSECTR LDA PAUSECTR CMP #$04 BNE EXIT2 PAUSE LDA #$00 STA NMIEN ;no more VBIs while pausing STA PAUSECTR LDA <PAUSEDLIST ;change to dedicated display list STA DLISTL LDA >PAUSEDLIST STA DLISTH LDA #$00 LDY #$03 KILLAUDIO STA AUDF1,Y DEY BPL KILLAUDIO PAUSING LDX #$04 KEYPRESSED LDA SKSTAT AND #$04 BNE PAUSING LDA KBCODE CMP #$21 BNE PAUSING DEX BEQ ENDPAUSE BNE KEYPRESSED ENDPAUSE LDA #$B8 STA DLISTL LDA #$35 STA DLISTH LDA #$C0 STA NMIEN STA HITCLR EXIT0 LDA #$00 EXIT STA PAUSECTR EXIT2 JMP XITVBV PAUSECTR .BY $00
  15. I would like to add some sound effects to my game that are a little more interesting than the usual square wave crash and chime examples from the A/E manual. Do you have any suggestions for tricks or techniques to use to produce other effects or wave forms? I have read about the sample trick used by the Sound FX program, but I have no room for samples, so it has to be programmed and relatively short, but it doesn't have to be limited to a 60 FPS data feed. One idea I have is to rapidly changing the frequency on two generators slightly out of sync to obtain an illusion of phase shifting. I have no idea if that's possible or what that would sound like. Before I start experimenting, are there any limitations to the sound emulation in Classic99 and MESS that I should be aware of?
  16. 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...
  17. Hey all, Here is a question... so the TI disk system reserves space at the top of VDP memory for file buffers. You can reduce this by from 3 file support to 1 by calling the FILES subprogram, but it still takes up space from about >3B00 onwards. My question is... can you safely wipe out this section, say if you wanted to put the sprite pattern table at >3800 onwards? Obviously it would trash the sprite pattern table if you had to do a file load later on, but if you could restore the data from CPU memory afterwards it seems alright. Obviously it would be stupid to try and do a memory image load INTO this section...
  18. Anyone feel like writing a MegaDemo? Well now you can! Here are two versions of an assembler that was used extensively for demo coding back in the day: http://www.pouet.net/prod.php?which=47999 http://www.pouet.net/prod.php?which=62372 (apparently this one includes a manual) If anyone knows of other assemblers that are good for this sort of thing, feel free to post links in this thread.
  19. I'm looking for a couple of utility disks that don't seem to be in any of the archives. QuickCode is a set of macros for use with Mac/65: QuickCode - Atarimania FlashBack is a backup program for use with SpartaDOS: FlashBack - Atarimania Info for both can also be found here: Antic Reviews - Power Tools If anybody has an ATR of either of these to share, or has a real copy and would be so kind as to make an image, it would be greatly appreciated. Thanks, MF
  20. Hey all, I just got the editor assembler cart with the manual. However, I do not have access to the diskettes. Does anyone know where I can find a link to a .dsk file of the files on those disks that I can run off of my nanoPEB? Thanks!
  21. Hey, guess what?!? It's just about 80 days until Tandy Assembly!! Are you going? Are you going to exhibit? Are you going to speak/present? Oh, I hope so, I hope so, I hope so! Start making your preparations today! Tandy Assembly Even if you can't make it, you can also help by sponsoring the event! Tandy Assembly | Sponsors
  22. In the April 1984 issue of Compute! is a favorite type-in game called Worm of Bemer. It was largely written in basic, and is a great example of a basic action game. The author challenged readers to improve upon the game, and I do not know how many times this has already been done, but my son and I are taking the challenge! The author Stephen Fultz said "Some features you might add include a routine to save the high score to disk, adding more players, or having Nerm go to a different room depending on which exit he takes. " Now - I'm telling everyone about the WIP, because I just love hearing all the news about other works in progerss, and I hope everyone enjoys various updates around this game as well. Also, so that this doesn't become a never ending project, the feature list is set in stone. We are taking Stephens challenge by adding these features: 1. Save high score to disk 2. Two player mode 3. Different exits lead to different room PLUS: 4. Rewriting in C/Assembly 5. 2 player mode will be competitive or cooperative 6. And re-doing the graphics, including new welcome screen and animated snakes. There is always the possibility that the game never finishes, but I have a good feeling about this one.... be setting out the goals, in public no less, I will not let feature creep cause this to never finish....lol This weeks task, is to re-do the Welcome screen. Here is the original One thing we could do is change the fonts only - and leave it at that, here is a new font: And lastly, we could try to put an image on the screen - or do that and the fonts also, here is a mockup of placing an image:
  23. I am confused with certain tutorials on whether to make certain routines part of the main file or start a new one for that routine? (The tutorials on SuperFamicom.org and SMS Power don't clarify this, which is why I asked.)
  24. I found this pretty cool looking mouse driver on an old L.A.C.E. disk today and decided to pull the documentation together and format it a little. I fixed a lot of errors, but maybe introduced a few new ones, since I didn't really go over it with a fine-toothed comb yet. I've included the L.A.C.E. disk as well as the all the original files pulled off the disk, including the Docs ARC and Programs ARC. I've only tried out the little BASIC test program that was included, but it looked pretty good, and the documentation and utilities seem to be pretty thorough. I also liked that he set it up to use CIO. Supposedly it will work with TBXL with a little configuring. Many thanks to Simon Trew, the author. Multi-Mouse.zip
  25. Hello, Just starting to learn TMS9900 assembly, just wondering if anyone had any good ideas for some mini projects to do in assembly? Samishal
  • Create New...